- Why not exend character set in C++ code? - 6 Updates
- Ascertaining if objects are in the standard namespace - 2 Updates
- are new delete operators thread safe? - 7 Updates
- Implementing methods of local classes in "global" namespace - 7 Updates
| asetofsymbols@gmail.com: Oct 27 10:32PM -0700 Only for that? It is not only for the character set If I rethink the question if one editor allow one in the normal mathematical style define operator as position too b a === pow(a, b) Or index A === a[j] j A. == A[1,2,3,4] 1,2,3,4 |
| red floyd <no.spam.here@its.invalid>: Oct 27 10:34PM -0700 > j > A. == A[1,2,3,4] > 1,2,3,4 What part of "The Standard says you can not define new operators" are you having trouble understanding? Therefore, you can not have === |
| asetofsymbols@gmail.com: Oct 28 12:27AM -0700 You want to say is not possible define operator as one of these symbols? ♠ Ω ♤ ♣ ♧ ♥ ♡ ♦ ♢ ♔ ♕ ♚ ♛ ⚜ ★ ☆ ✮ ✯ ☄ ☾ ☽ ☼ ☀ ☁ ☂ ☃ ☻ ☺ ☹ ۞ ۩ εїз Ƹ̵̡Ӝ̵̨̄Ʒ ξЖЗ εжз ☎ ☏ ¢ ☚ ☛ ☜ ☝ ☞ ☟ ✍ ✌ ☢ ☣ ♨ ๑ ❀ ✿ ψ ♆ ☪ ☭ ♪ ♩ ♫ ♬ ✄ ✂ ✆ ✉ ✦ ✧ ♱ ♰ ∞ ♂ ♀ ☿ ❤ ❥ ❦ ❧ ™ ® © ✖ ✗ ✘ ⊗ ♒ ■ □ ▢ ▲ △ ▼ ▽ ◆ ◇ ○ ◎ ● ◯ Δ ◕ ◔ ʊ ϟ ღ ツ 回 ₪ 卐 ™ © ® ¿ ¡ ½ ⅓ ⅔ ¼ ¾ ⅛ ⅜ ⅝ ⅞ ℅ № ⇨ ❝ ❞ # & ℃ ∃ ∧ ∠ ∨ ∩ ⊂ ⊃ ∪ ⊥ ∀ Ξ Γ ɐ ə ɘ ε β ɟ ɥ ɯ ɔ и ๏ ɹ ʁ я ʌ ʍ λ ч ∞ Σ Π ➀ ➁ ➂ ➃ ➄ ➅ ➆ ➇ ➈ ➉ ➊ ➋ ➌ ➍ ➎ ➏ ➐ ➑ ➒ ➓ Ⓐ Ⓑ Ⓒ Ⓓ Ⓔ Ⓕ Ⓖ Ⓗ Ⓘ Ⓙ Ⓚ Ⓛ Ⓜ Ⓝ Ⓞ Ⓟ Ⓠ Ⓡ Ⓢ Ⓣ Ⓤ Ⓥ Ⓦ Ⓧ Ⓨ Ⓩ ⓐ ⓑ ⓒ ⓓ ⓔ ⓕ ⓖ ⓗ ⓘ ⓙ ⓚ ⓛ ⓜ ⓝ ⓞ ⓟ ⓠ ⓡ ⓢ ⓣ ⓤ ⓥ ⓦ ⓧ ⓨ ⓩ ℘ ℑ ℜ ℵ ♏ η α βεℓℓα · ¨ … ¦ ┅ ┆ ┈ ┊ ╱ ╲ ╳ ¯ – — ≡ ჻ ░ ▒ ▓ ▤ ▥ ▦ ▧ ▨ ▩ █ ▌ ▐ ▀ ▄ ◠ ◡ ╭ ╮ ╯ ╰ │ ┤ ╡ ╢ ╖ ╕ ╣ ║ ╝ ╜ ╛ ┐ └ ┴ ┬ ├ ─ ┼ ╞ ╟ ╚ ╔ ╩ ╦ ╠ ═ ╬ ╧ ╨ ╤ ╥ ╙ ╘ ╒ ╓ ╫ ╪ ┘ ┌ ツ ♋ 웃 유 Σ ⊗ ♒ ☠ ☮ ☯ ♠ Ω ♤ ♣ ♧ ♥ ♡ ♦♢♔ ♕ ♚ ♛ ★ ☆ ✮ ✯ ☄ ☾ ☽ ☼ ☀ ☁ ☂ ☃ ☻ ☺ ۞ ۩ ♬ ✄ ✂ ✆ ✉ ✦ ✧ ∞ ♂ ♀ ☿ ❤ ❥ ❦ ❧ ™ ® © ✗ ✘ ⊗ ♒ ▢ ▲ △ ▼ ▽ ◆ ◇ ○ ◎ ● ◯ Δ ◕ ◔ ʊ ϟ ღ 回 ₪ ✓ ✔ ✕ ✖ ☢ ☣ ☤ ☥ ☦ ☧ ☨ ☩ ☪ ☫ ☬ ☭ ☹ ☺ ☻ ت ヅ ツ ッ シ Ü ϡ ♋ ♂ ♀ ☿ ♥ ❤ ❥ 웃 유 ♡ ۵ ❣ ☼ ☀ ☁ ☂ ☃ ☄ ☾ ☽ ❄ ☇ ☈ ⊙ ☉ ℃ ℉ ° ♪ ♫ ♩ ♬ ♭ ♮ ♯ ° ø ✽ ✾ ✿ ❀ ❁ ❃ ♚ ♛ ♜ ♝ ♞ ♟ ♔ ♕ ♖ ♗ ♘ ♙ ✉ ✍ ✎ ✏ ✐✑✒ ⌨ ☑ ✓ ✔ ☒ ☓ ✕ ✖ ✗ ✘ ✦ ★ ☆ ✰ ✮ ✯ ❇ ❈ ❅ ❄ ❆ ╰☆╮ Æ æ ❖ ℘ℑℜℵ♏η αβεℓℓα· ¨…¦┅┆┈ ┊╱╲╳¯– —≡჻░▒▓ ▤▥▦▧▨▩█ ▌▐▀▄ ◠◡╭╮╯╰ │┤╡╢╖╕╣ ║╝╜╛ ┐ └┴┬├─┼ ╞╟╚╔╩╦ ╠═ ╬╧╨╤ ╥╙╘╒╓ ╫╪┘┌ {｡^◕‿◕^｡} (◕^^◕) ✖✗✘♒♬✄ ✂✆✉✦✧♱ ♰♂♀☿❤❥ ❦❧ ™®©♡♦ ♢♔♕♚♛★ ☆✮ ✯☄☾☽ ☼☀☁☂☃☻ ☺☹ ☮۞۩ εїз☎☏¢ ☚☛☜☝☞☟✍ ✌☢☣☠☮☯ ♠♤♣♧♥ ♨๑❀✿ ψ☪☭♪ ♩♫℘ℑ ℜℵ♏ηα ʊϟღツ回 ₪™ ©®¿¡½⅓ ⅔¼¾⅛⅜⅝⅞℅ №⇨❝❞ ◠◡╭╮╯╰ ★☆⊙¤㊣ ★☆♀◆◇ ▆▇██■ ▓回□〓≡ ╝╚╔╗╬ ═╓╩ ┠┨┯┷┏ ┓┗┛┳⊥ ﹃﹄┌ ┐└┘∟「 」↑↓→ ←↘↙♀ ♂┇┅﹉﹊ ﹍﹎╭╮╰╯ *^_^* ^*^ ^-^ ^_^ ^︵^∵∴‖ ︱︳︴﹏ ﹋﹌♂♀ ♥♡☜☞☎ ☏⊙◎☺☻ ►◄▧▨ ♨◐◑↔↕ ▪▫☼♦▀ ▄█▌▐ ░▒▬♦◊ ◦☼♠♣▣ ▤▥▦▩ ぃ◘◙◈♫ ♬♪♩♭♪ の☆→あ ￡❤｡◕‿ ◕｡✎✟ஐ ≈๑۩ ۩.. ..۩۩๑ ๑۩۞۩๑ ✲❈➹ ~.~◕ ‿-｡☀☂☁ 【】┱┲❣ ✚✪✣ ✤✥ ✦❉ ❥❦❧❃ ❂❁❀✄☪ ☣☢☠☭♈ ✓✔✕ ✖㊚㊛ *.:｡ ✿*ﾟ'ﾟ･ ⊙¤㊣★☆ ♀◆◇ ◣◢◥▲ ▼△▽⊿◤ ◥▆▇ ██■▓ 回□〓≡╝ ╚╔╗ ╬═╓╩ ┠┨┯┷┏ ┓┗┛ ┳⊥﹃﹄ ┌┐└┘∟ 「」↑↓ →←↘↙ ♀♂┇┅﹉ ﹊﹍﹎ ╭╮╰╯ *^_^* ^*^ ^-^ ^_^ ^︵^∵ ∴‖ ︱︳ ︴﹏﹋﹌ ♂♀♥♡☜ ☞☎☏⊙ ◎☺☻►◄ ▧▨♨◐◑ ↔↕ ▪▫ ☼♦▀▄█ ▌▐░▒▬ ♦◊◦☼ ♠♣▣▤▥ ▦▩ぃ◘◙ ◈♫♬♪ ♩♭♪の☆ →あ￡❤｡ ◕‿◕｡ ✎✟ஐ≈ ๑۩۩.. ..۩ ۩๑๑۩۞ ۩ ๑✲❈ ➹ ~.~◕‿-｡ ☀☂☁【】 ┱┲❣✚ ✪✣✤✥ ✦❉❥❦ ❧❃❂❁❀ ✄☪☣☢☠ ☭♈ ✓ ✔✕✖㊚ ㊛ *.:｡✿*ﾟ 'ﾟ･ ◊♥╠═╝▫■๑»«¶ஐ©† εïз♪ღ♣ ♠•± °•ิ.•ஐஇ *×○▫ ♂•♀◊©¤ ▲↔™®☎ε їз♨ ☏☆★ ▽△▲ ∵∴∷ ＃♂♀♥♠♣ ♧♤♧ ♡♬♪ ♭♫♪ﻬஐღ ↔↕↘••● ¤╬﹌▽☜♥☞ ♬✞♥♕☯☭☠☃ ─ ━ │ ┃ ┄ ┅ ┆ ┇ ┈ ┉ ┊ ┋ ╭ ╮ ╯ ╰ ╱ ╲ ╳ ╴ ╵ ╶ ╷ ╸ ╹ ╺ ╻ ╼ ╽ ╾ ╿ ▰ ▱ ◆ ◇ ◈ ◉ ◊ ○ ◌ ◍ ◎ ● ◐ ◑ ◒ ◓ ◔ ◕ ◖ ◗ ◘ ◙ ◚ ◛ ◜ ◝ ◞ ◟ ◠ ◡ ◢ ◣ ◤ ◥ ◦ ◧ ◨ ◩ ◪ ◫ ◬ ◭ ◮ ◯ ◰ ◱ ◲ ◳ ◴ ◵ ◶ ◷ ◸ ◹ ◺ ◻ ◼ ◽ ◾ ◿ ☀ ☁ ☂ ☃ ☄ ★ ☆ ☇ ☈ ☊ ☋ ☌ ☍ ☎ ☏ ☐ ☑ ☒ ☓ ☔ ☕ ☖ ☗ ☘ ☙ ☟ ☠ ☡ ☢ ☣ ☤ ☥ ☦ ☧ ☨ ☩ ☪ ☫ ☬ ☭ ☮ ☯ ☰ ☱ ☲ ☳ ☴ ☵ ☶ ☷ ☸ ☹ ☺ ☻ ☼ ☽ ☾ ☿ ♀ ♁ ♂ ♃ ♄ ♅ ♇ ♔ ♕ ♖ ♗ ♘ ♙ ♚ ♛ ♜ ♝ ♞ ♟ ♠ ♡ ♢ ♣ ♤ ♥ ♦ ♧ ♨ ♰ ♱ ´ ῾ ‐ ‑ ‒ – — ― ‖ ‗ ' ' ‚ ‛ " " „ ‟ † ‡ • ‣ ․ ‥ … ‧ ‰ ‱ ′ ″ ‴ ‵ ‶ ‷ ‸ ‹ › ※ ‼ ‽ ‾ ‿ ⁀ ⁁ ⁂ ⁃ ⁄ ⁅ ⁆ ⁊ ⁋ ⁌ ⁍ ⁎ ⁏ ⁐ ⁑ ⁒ ⁓ ⁔ ⁕ ⁖ ⁗ ⁘ ⁙ ⁚ ⁛ ⁜ ⁝ ⁞ ₕ ₖ ₗ ₘ ₙ ₚ ₛ ₜ ₠ ₡ ₢ ₣ ₤ ₥ ₦ ₧ ₨ ₪ ₫ € ₭ ₮ ₯ ℀ ℁ ℂ ℄ ℅ ℆ ℇ ℈ ℉ ℊ ℋ ℌ ℍ ℎ ℏ ℐ ℑ ℒ ℓ ℔ ℕ № ℗ ℘ ℙ ℚ ℛ ℜ ℝ ℞ ℟ ℡ ™ ℣ ℤ ℥ Ω ℧ ℨ ℩ K Å ℬ ℭ ℮ ℯ ℰ ℱ Ⅎ ℳ ℴ ℵ ℶ ℷ ℸ ℹ ℺ ℻ ℼ ℽ ℾ ℿ ⅀ ⅁ ⅂ ⅃ ⅄ ⅅ ⅆ ⅇ ⅈ ⅉ ⅊ ⅋ ⅌ ⅍ ⅎ ⅏ ⅐ ⅑ ⅒ ⇫ ⇬ ⇭ ⇮ ⇯ ⇰ ⇱ ⇲ ⇳ ⇴ ⇵ ⇶ ⇷ ⇸ ⇹ ⇺ ⇻ ⇼ ⇽ ⇾ ⇿ ∀ ∁ ∂ ∃ ∄ ∅ ∆ ∇ ∈ ∉ ∊ ∋ ∌ ∍ ∎ ∏ ∐ ∑ − ∓ ∔ ∕ ∖ ∗ ∘ ∙ √ ∛ ∜ ∝ ∞ ∟ ∠ ∡ ∢ ∣ ∤ ∥ ∦ ∧ ∨ ∩ ∪ ∴ ∵ ∶ ∷ ∸ ∹ ∺ ∻ ∼ ∽ ∾ ∿ ≀ ≁ ≪ ≫ ≬ ≭ ≮ ≯ ≰ ≱ ≲ ≳ ≴ ≵ ≶ ≷ ≸ ≹ ≺ ≻ ≼ ≽ ≾ ≿ ⊀ ⊁ ⊂ ⊃ ⊄ ⊅ ⊆ ⊇ ⊈ ⊉ ⊊ ⊋ ⊌ ⊍ ⊎ ⊏ ⊐ ⊑ ⊒ ⊓ ⊔ ⊕ ⊖ ⊗ ⊘ ⊙ ⊚ ⊛ ⊜ ⊝ ⊞ ⊟ ⊠ ⊡ ⊢ ⊣ ⊤ ⊥ ⊦ ⊧ ⊨ ⊩ ⊪ ⊫ ⊬ ⊭ ⊮ ⊯ ⊰ ⊱ ⊲ ⊳ ⊴ ⊵ ⊶ ⊷ ⊸ ⊹ ⊺ ⊻ ⊼ ⊽ ⊾ ⊿ ⋀ ⋁ ⋂ ⋃ ⋄ ⋅ ⋆ ⋇ ⋈ ⋉ ⋊ ⋋ ⋌ ⋍ ⋎ ⋏ ⋐ ⋑ ⋒ ⋓ ⋔ ⋕ ⋖ ⋗ ⋘ ⋙ ⋚ ⋛ ⋜ ⋝ ⋞ ⋟ ⋠ ⋡ ⋢ ⋣ ⋤ ⋥ ⋦ ⋧ ⋨ ⋩ ⋪ ⋫ ⋬ ⋭ ⋮ ⋯ ⋰ ⋱ ⋲ ⋳ ⋴ ⋵ ⋶ ⋷ ⋸ ⋹ ⋺ ⋻ ⋼ ⋽ ⋾ ⋿ ⌀ ⌁ ⌂ ⌃ ⌄ ⌅ ⌆ ⌇ ⌈ ⌉ ⌊ ⌋ ⌌ ⌍ ⌎ ⌏ ⌐ ⌑ ⌒ ⌓ ⌔ ⌕ ⌖ ⌗ ⌘ ⌙ ⌚ ⌛ ⌜ ⌝ ⌞ ⌟ ⌠ ⌡ ⌢ ⌣ ⌤ ⌥ ⌦ ⌧ ⌨ ⟨ ⟩ ⌫ ⌬ ⌭ ⌮ ⌯ ⌰ ⌱ ⌲ ⌳ ⌴ ⌵ ⌶ ⌷ ⌸ ⌹ ⌺ ⌻ ⌼ ⌽ ⌾ ⌿ ⍀ ⍁ ⍂ ⍃ ⍄ ⍅ ⍆ ⍇ ⍈ ⍉ ⍊ ⍋ ⍌ ⍍ ⍎ ⍏ ⍐ ⍑ ⍒ ⍓ ⍔ ⍕ ⍖ ⍗ ⍘ ⍙ ⍚ ␋ ␢ ␣ ─ ━ │ ┃ ┄ ┅ ┆ ┇ ┈ ┉ ┊ ┋ ┌ ┍ ┎ ┏ ┐ ┑ ┒ ┓ └ ┕ ┖ ┗ ┘ ┙ ┚ ┛ ├ ┝ ┞ ┟ ┠ ┡ ┢ ┣ ┤ ┥ ┦ ┧ ┨ ┩ ┪ ┫ ┬ ┭ ┮ ┯ ┰ ┱ ┲ ┳ ┴ ┵ ┶ ┷ ┸ ┹ ┺ ┻ ┼ ┽ ┾ ┿ ╀ ╁ ╂ ╃ ╄ ╅ ╆ ╇ ╈ ╉ ╊ ╋ ╌ ╍ ╎ ╏ ═ ║ ╒ ╓ ╔ ╕ ╖ ╗ ╘ ╙ ╚ ╛ ╜ ╝ ╞ ╟ ╠ ╡ ╢ ╣ ╤ ╥ ╦ ╧ ╨ ╩ ╪ ╫ ╬ ╭ ╮ ╯ ╰ ╱ ╲ ╳ ╴ ╵ ╶ ╷ ╸ ╹ ╺ ╻ ╼ ╽ ╾ ╿ ▀ ▁ ▂ ▃ ▄ ▅ ▆ ▇ █ ▉ ▊ ▋ ▌ ▍ ▎ ▏ ▐ ░ ▒ ▓ ▔ ▕ ▖ ▗ ▘ ▙ ▚ ▛ ▜ ▝ ▞ ▟ ■ □ ▢ ▣ ▤ ▥ ▦ ▧ ▨ ▩ ▪ ▫ ▬ ▭ ▮ ▯ ▰ ▱ ◆ ◇ ◈ ◉ ◊ ○ ◌ ◍ ◎ ● ◐ ◑ ◒ ◓ ◔ ◕ ◖ ◗ ◘ ◙ ◚ ◛ ◜ ◝ ◞ ◟ ◠ ◡ ◢ ◣ ◤ ◥ ◦ ◧ ◨ ◩ ◪ ◫ ◬ ◭ ◮ ◯ ◰ ◱ ◲ ◳ ◴ ◵ ◶ ◷ ◸ ◹ ◺ ◻ ◼ ◽ ◾ ◿ ☀ ☁ ☂ ☃ ☄ ★ ☆ ☇ ☈ ☊ ☋ ☌ ☍ ☎ ☏ ☐ ☑ ☒ ☓ ☔ ☕ ☖ ☗ ☘ ☙ ☟ ☠ ☡ ☢ ☣ ☤ ☥ ☦ ☧ ☨ ☩ ☪ ☫ ☬ ☭ ☮ ☯ ☰ ☱ ☲ ☳ ☴ ☵ ☶ ☷ ☸ ☹ ☺ ☻ ☼ ☽ ☾ ☿ ♀ ♁ ♂ ♃ ♄ ♅ ♇ ♎ ♏ ♐ ♑ ♒ ♓ ♔ ♕ ♖ ♗ ♘ ♙ ♚ ♛ ♜ ♝ ♞ ♟ ♠ ♡ ♢ ♣ ♤ ♥ ♦ ♧ ♨ ♰ ♱ ☫ ª ↀ ↁ ↂ Ↄ ➟ ➡ ➢ ➣ ➤ ➥ ➦ ➧ ➨ ➚ ➘ ➙ ➛ ➜ ➝ ➞ ➸ ♐ ➲ ➳ ➳ ➴ ➵ ➶ ➷ ➸ ➹ ➺ ➻ ➼ ➽ ← ↑ → ↓ ↔ ↕ ↖ ↗ ↘ ↙ ↚ ↛ ↜ ↝ ↞ ↟ ↠ ↡ ↢ ↣ ↤ ↥ ↦ ↧ ↨ ➫ ➬ ➩ ➪ ➭ ➮ ➯ ➱ ↩ ↪ ↫ ↬ ↭ ↮ ↯ ↰ ↱ ↲ ↳ ↴ ↵ ↶ ↷ ↸ ↹ ↺ ↻ ↼ ↽ ↾ ↿ ⇀ ⇁ ⇂ ⇃ ⇄ ⇅ ⇆ ⇇ ⇈ ⇉ ⇊ ⇋ ⇌ ⇍ ⇎ ⇏ ⇐ ⇑ ⇒ ⇓ ⇔ ⇕ ⇖ ⇗ ⇘ ⇙ ⇚ ⇛ ⇜ ⇝ ⇞ ⇟ ⇠ ⇡ ⇢ ⇣ ❂ ⋆ ✢ ✣ ✤ ✥ ✦ ✧ ✩ ✪ ✫ ✬ ✭ ✮ ✯ ✰ ★ ✱ ✲ ✳ ✴ ✵ ✶ ✷ ✸ ✹ ✺ ✻ ✼ ❄ ❅ ❆ ❇ ❈ ❉ ❊ ❋ ╰☆╮ ✡ ❂ -'๑'- ⎈ |
| guinness.tony@gmail.com: Oct 28 04:06AM -0700 > You want to say is not possible > define operator as one of these > symbols? <snip font dump> Yes. If you have a copy of the standard, read the [over.oper] chapter. If you don't, read the final draft (N3797, which can be found at http://open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3797.pdf) section 13.5, which lists exactly which operators can be overloaded and which can not. New operator names cannot be created. You can only overload existing-named operators (except for a few for which this is not permitted, either). |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Oct 28 11:05PM +0100 > ρι6 What? > Why one can not define in C++ a set of operators as > int operatorρ(Matrix<T>& a) > ? As I recall Prolog supports definining new operators, but C++ doesn't. The C++ syntax is just too complex already. You can however redefine the meaning of most existing operators, for class and enumeration type arguments. > Why not add 1/2 of new 16 bit character set "new 16-bit character set"? I think you must be referring to 16-bit Unicode. That's 1991, 24 years ago. Since then, I think it was in 1996, Unicode has been extended to effectively 21 bits. Still, Windows console windows are effectively constrained to the 16 bit subset of Unicode corresponding to original Unicode. That subset is called the "BMP", the Basic Multilingual Plane of Unicode, and using it for encoding of characters is called UCS2, which effectively is a subset of UTF-16 (i.e., can be interpreted as UTF-16). > as definable as operators (points) and other 1/2 as letter for names? Regarding names, formally C++ supports using general Unicode letters in identifiers, from a specific subset of Unicode that some standard designates as suitable for identifiers across programming languages. Unfortunately compilers such as GNU g++ generally refuse anything but the English alphabet present in ASCII. This means that code that uses national characters in names, e.g. "antall_blåbærsyltetøyglass", may compile with e.g. Visual C++ and fail to compile with g++. Disclaimer: I haven't tested this with g++ the last couple of years. I guess the time is ripe to test again. ;-) Cheers & hth., - Alf |
| Anand Hariharan <mailto.anand.hariharan@gmail.com>: Oct 28 03:43PM -0700 > set as definable as operators > (points) and other 1/2 as > letter for names? Guess what? Bjarne Stroustrup 'agrees' with you: http://www.stroustrup.com/whitespace98.pdf (Make sure you read the paper in *entirety*) - Anand |
| Paul <pepstein5@gmail.com>: Oct 28 02:36PM -0700 Is there any way of ascertaining (other than looking it up) whether objects are in the standard namespace? For example, INT_MIN from the <climits> header is not in the std namespace but cout from <iostream> is in the std namespace. How could one deduce that beforehand to avoid compile errors from writing std::INT_MIN? Is the rule that functions from header files are in the std namespace but variables from header files are not in the std namespace? Or is it subtler? Or something else I haven't thought of? Thanks, Paul |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Oct 28 11:22PM +0100 On 10/28/2015 10:36 PM, Paul wrote: > not in the std namespace but cout from <iostream> is in the std namespace. > How could one deduce that beforehand to avoid compile errors from writing > std::INT_MIN? As evident from the all uppercase name, INT_MIN is a macro. A macro is not in any namespace: it is a text substitution rule. > Is the rule that functions from header files are in the std namespace > but variables from header files are not in the std namespace? Or is it > subtler? Or something else I haven't thought of? Generally, * Identifiers from the pure C++ part of the standard library are in the std namespace. * Identifiers from the C standard library (which is mainly wholesale adopted into the C++ standard library) can be in the std namespace, or in the global namespace, or both, depending on which header you include. Heads-up: the last point is COMPLICATED. So, here's a concrete example. In C the "<string.h>" header declares functions such as "strcpy". In C++ the basic corresponding header is "<cstring>". Unlike C, when you include "<cstring>" you're only guaranteed that "strcpy" is available in the std namespace. C++ code that refers just to unqualified strcpy, may fail to compile, while in C that's how it has to be expressed. But with "<cstring>" the identifiers may also be placed in the global namespace, so that unqualified name usage can compiler; it's just not guaranteed to compile. Originally for backwards-compatibility and leveraging existing expertise, C++ also provides a header "<string.h>", which is distinct from the original C "<string.h>". The effect of including "<string.h>", like in C programming, is to get every name from "<cstring>" placed in the global namespace, without necessarily being available in the std namespace. This means that when you include "<string.h>" in C++, you MAY get the identifiers also available in the std namespace, and there's no way to check that in the C++ code. Effectively this means that there's no point in using "<cstring>": it has negative utility because it presents possible portability issues, with code that uses unqualified "strcpy" (for example) compiling nicely with the original compiler, and then failing with some other compiler. So, use "<string.h>". And be aware that none of the three headers discussed above, namely C's "<string.h>", C++'s "<cstring>", and C++'s "<string.h>", have ANYTHING to do with C++' "<string>", which declared std::string and std::wstring + support. Cheers & hth., - Alf |
| asetofsymbols@gmail.com: Oct 28 12:13AM -0700 are new delete operators thread safe? |
| Paavo Helde <myfirstname@osa.pri.ee>: Oct 28 02:20AM -0500 asetofsymbols@gmail.com wrote in news:48c66481-127a-4d3c-a0da-9de728486124 > are new delete operators thread safe? yes |
| Juha Nieminen <nospam@thanks.invalid>: Oct 28 08:06AM > @googlegroups.com: >> are new delete operators thread safe? > yes It's actually one of the reasons why they are so slow. --- news://freenews.netfront.net/ - complaints: news@netfront.net --- |
| Paavo Helde <myfirstname@osa.pri.ee>: Oct 28 12:18PM -0500 Juha Nieminen <nospam@thanks.invalid> wrote in >>> are new delete operators thread safe? >> yes > It's actually one of the reasons why they are so slow. Yes, better safe than sorry. I'm not actually sure what kind of thread safety the OP meant. Maybe he was just concerned if one can call new in two different threads at the same time. This is of cource guaranteed, otherwise we would need to put a mutex lock around each string+=char operation. For allocators, the next level of thread safety means that the memory allocated in one thread can be released in another. Without this, any inter-thread communication would become extremely fragile and cumbersome. One could not legally call e.g. string.c_str() in a wrong thread. So there are good reasons why the default allocator must provide such thread safety. However, there is no inherent reason that thread-safety must mean slowness. For example, there are general allocator libraries like Intel TBB with drastically better performance than the default MSVC one, at least in massive multithreading regime and at least some years ago (have not bothered to check recently). Of course, dynamically allocating something will always be slower than not allocating. Here C++ has an edge over many competitors as it can easily place complex objects on stack, in a buffer of std::vector, etc. Cheers Paavo |
| Marcel Mueller <news.5.maazl@spamgourmet.org>: Oct 28 08:14PM +0100 On 28.10.15 09.06, Juha Nieminen wrote: >>> are new delete operators thread safe? >> yes > It's actually one of the reasons why they are so slow. Well, it should be possible to have implementations that are mainly lock-free by simply associating smaller memory pools with threads. So if new and delete is called from the same thread, which is not that uncommon for short lived objects, no lock is required. And even if the object belongs to another thread's pool it might be sufficient to place a marker in a lock free FIFO that is executed by the other thread at the next new/delete call. The memory in the pool of the other thread cannot be reused unless an allocation comes from this thread anyway. Of course, this should not be done for large objects. And the pool should have a lock free allocation counter so that the entire pool can be disposed once it gets empty. Marcel |
| scott@slp53.sl.home (Scott Lurndal): Oct 28 08:06PM >this should not be done for large objects. And the pool should have a >lock free allocation counter so that the entire pool can be disposed >once it gets empty. At least on the linux side, the thread-safe allocators are only slow when there is contention. If one is allocating frequently enough that the locks are frequently contented, then perhaps the application could be refactored to avoid such frequent allocation. Hard to do when using STL, however. |
| "Chris M. Thomasson" <nospam@nospam.nospam>: Oct 28 01:57PM -0700 > "Scott Lurndal" wrote in message news:PU9Yx.41512$Iw3.2245@fx30.iad... [...] > slow when there is contention. If one is allocating frequently > enough that the locks are frequently contented, then perhaps the > application could be refactored to avoid such frequent allocation. AFAICT, there is no "real need" for locks in the "hot spots" of allocators. |
| Juha Nieminen <nospam@thanks.invalid>: Oct 28 08:05AM > auto main() -> int Isn't that a bit... of an exaggeration? --- news://freenews.netfront.net/ - complaints: news@netfront.net --- |
| David Brown <david.brown@hesbynett.no>: Oct 28 10:36AM +0100 On 28/10/15 09:05, Juha Nieminen wrote: > Alf P. Steinbach <alf.p.steinbach+usenet@gmail.com> wrote: >> auto main() -> int > Isn't that a bit... of an exaggeration? For some reason, the "int" needs to be explicit for main, at least on gcc 4.9. Maybe that's just an issue with the partial C14 support in that version of gcc4.9, and later versions are happy with "auto main()". |
| scott@slp53.sl.home (Scott Lurndal): Oct 28 01:17PM >For some reason, the "int" needs to be explicit for main, at least on >gcc 4.9. Maybe that's just an issue with the partial C14 support in >that version of gcc4.9, and later versions are happy with "auto main()". The C++ committee needs someone that can say "no". int main() auto main() -> int how is the latter superior in any way? Why is it a good idea to have two ways of expressing the same thing? |
| Juha Nieminen <nospam@thanks.invalid>: Oct 28 01:25PM > auto main() -> int > how is the latter superior in any way? Why is it a good idea > to have two ways of expressing the same thing? The new alternative syntax is useful with certain template functions where the type of the return value couldn't be calculated otherwise. The archetypal example is: //------------------------------------------ template<class T, class U> auto add(T t, U u) -> decltype(t + u) { return t + u; } //------------------------------------------ There is, however, at least one situation where the new syntax actually makes the function declaration more readable even with a regular non-templated function: auto get_fun(int arg) -> double (*)(double) vs. the old way: double (*get_fun(int))(double) --- news://freenews.netfront.net/ - complaints: news@netfront.net --- |
| Cholo Lennon <chololennon@hotmail.com>: Oct 28 10:39AM -0300 On 10/28/2015 05:05 AM, Juha Nieminen wrote: > Alf P. Steinbach <alf.p.steinbach+usenet@gmail.com> wrote: >> auto main() -> int > Isn't that a bit... of an exaggeration? IMHO, yes, but I understand that he is trying to write homogeneous code everywhere. This a recurrent topic when Alf P. Steinbach post his code ;-) It's similar to Stefan Ram usage of ::std:: with the standard library. Regards -- Cholo Lennon Bs.As. ARG |
| David Brown <david.brown@hesbynett.no>: Oct 28 04:00PM +0100 On 28/10/15 14:25, Juha Nieminen wrote: > auto get_fun(int arg) -> double (*)(double) > vs. the old way: > double (*get_fun(int))(double) For functions whose body is known (inline functions, local functions, etc.), you don't even need to give the type afterwards in C++14: auto get_fun(int arg) { return make_function_pointer(arg); } The ability to write "auto main() -> int" is just a side-effect of this, and some people may prefer it if they think it is nice to be consistent. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Oct 28 06:01PM On 28/10/2015 08:05, Juha Nieminen wrote: > Alf P. Steinbach <alf.p.steinbach+usenet@gmail.com> wrote: >> auto main() -> int > Isn't that a bit... of an exaggeration? Yes it is totally unnecessary but then again Alf is a bit of a tit. /Flibble |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment