- Inherited enum - 1 Update
- This way or the other - 2 Updates
- Initialization in modern C++ - Timur Doumler - Meeting C++ 2018 - 2 Updates
- "Is C++ fast?" - 1 Update
| JiiPee <no@notvalid.com>: Jan 28 11:23PM On 28/01/2019 10:29, Öö Tiib wrote: > } > Personally to me such whole logic feels messed up, regardless if it is > enum or struct. Thanks, looks promising, I ll check that. How elso it could be solved? If you have a parent class and you want to store some kind of name there, how would you store? So that the name can be used via inherited class objects. |
| Daniel <danielaparker@gmail.com>: Jan 28 02:28PM -0800 On Monday, January 28, 2019 at 4:27:50 PM UTC-5, Mr Flibble > > libraries as possible. I have removed most of the wchar_t from "neolib" > and only have one instance of wchar_t in "neoGFX" (which is much larger > than "neolib"). I note that CharT is a template parameter in your basic_json_value, hopefully everything will work as expected if someone plugs in a wchar_t, because char and wchar_t are probably the only things that anybody will plug into it. I believe RapidJson supports templated encoding, jsoncons has a CharT parameter, but I don't think any of the other libraries do. nhlomann doesn't, and its absence certainly hasn't hurt it's popularity. In jsoncons, the assumption is that char is UTF8, char16_t is UTF16, char32_t is UTF32, and wchar_t is UTF16 if sizeof(wchar_t) is 2 chars, and UTF32 if sizeof(wchar_t) is 4 chars. Unicode validation is performed based on those assumptions. In any case, I wouldn't expect anyone to specialize with anything other than char and wchar_t. In retrospect, I think that having a CharT template parameter in jsoncons may have been a mistake, and an approach more similar to std::filesystem might have been better. It would, after all, be relatively straightforward to hold text in the variant as UTF8, and have templated accessor as<String> to return whatever encoding the user wants as deduced from String::char_type, performing the conversion from UTF8 on demand. Similarly with stream operators. Daniel |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jan 28 11:00PM On 28/01/2019 22:28, Daniel wrote: > char16_t is UTF16, char32_t is UTF32, and wchar_t is UTF16 if > sizeof(wchar_t) is 2 chars, and UTF32 if sizeof(wchar_t) is 4 > chars. Is that UTF16BE or UTF16LE? In my JSON lib the whole point of the CharT template parameter is that is matches the document text format and that allows string objects to be created without performing an allocation (they just point to the document text). /Flibble -- "You won't burn in hell. But be nice anyway." – Ricky Gervais "I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Bryne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
| Vir Campestris <vir.campestris@invalid.invalid>: Jan 28 09:52PM On 27/01/2019 20:54, Alf P. Steinbach wrote: > conventions that they use in a social way: those who don't use that > solution are not in the in-group and can be criticized and ridiculed. > Ha, you're not using "always auto"! So it's your own fault mate! I'm "almost never auto". I don't see how code clarity can be improved by hiding the type of a variable. Andy |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jan 28 09:58PM On 28/01/2019 21:52, Vir Campestris wrote: > I'm "almost never auto". > I don't see how code clarity can be improved by hiding the type of a > variable. Because most of the time you don't care what the type is so the type just adds noise: auto is very easy on the eyes. I blogged about this subject in 2014: https://leighjohnston.wordpress.com/2014/10/13/new-c-auto-keyword-condsidered-awesome-not-harmful/ /Flibble -- "You won't burn in hell. But be nice anyway." – Ricky Gervais "I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Bryne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
| Daniel <danielaparker@gmail.com>: Jan 28 01:50PM -0800 On Monday, January 28, 2019 at 4:22:18 PM UTC-5, Paavo Helde wrote: > These tests are single-threaded so the global locale dependencies > probably do not play a great role; things might be different in a > heavily multithreaded regime. Appreciate you posting numbers, when I have time, I'll see if I can replicate. Just to note, my 40x number was comparison to David Gay's netlib code, which is much faster than the C functions. Those are old benchmarks, too, probably using vs2010. Do you happen to have an implementation of the C++2017 from_chars/to_chars for floating point? I would be very interested in how those compare. I believe vs2017 versions still only support integer. I understand that compiler vendors would be very cautious and conservative in introducing any changes to floating point algorithms, as "improvements" could have huge impacts on real world validation suites. But hopefully new functions with new specifications will allow incorporation of new research. Daniel |
| 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