- On the nature of non-blocking techniques... - 2 Updates
- std::byte - 4 Updates
- Passing a constexpr member function pointer as template paramter - 4 Updates
| "Chris M. Thomasson" <invalid@invalid.invalid>: Apr 01 02:17PM -0700 On 3/22/2017 1:35 PM, Chris M. Thomasson wrote: > will keep you safer. However, by all means, if interested, learn all > about C++'s ability to provide the ability to implement these things > _before_ you use them for anything other than a "toy example test program". [...] How many people in this group are actually interested in this type of ability provided by C++? [...] |
| Ian Collins <ian-news@hotmail.com>: Apr 02 10:35AM +1200 On 04/ 2/17 09:17 AM, Chris M. Thomasson wrote: > [...] > How many people in this group are actually interested in this type of > ability provided by C++? More mow the idea are becoming mainstream. I appreciate that you have been post about lock-free for many years, you'll probably be able to converse with people other than your self before too long! As a point of reference, there are a small group of us on the large project team I am currently working with who are investigation how we can incorporate this stuff into the existing code. -- Ian |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Apr 01 05:49AM On Wed, 2017-03-29, Daniel wrote: > UTF-8 is a Unicode byte encoding. It's something you send over a wire or > serialize to a stream. It's not something the application programmer should > have to be aware of. Well, it's also something which looks like ASCII to any program which doesn't look too closely. It was one of the selling points. Surprisingly few of my programs look that closely. Parsing text files works. Case-insensitive operations, sorting and alignment into columns does not. > } > should loop over unicode codepoints, irrespective of the encoding of s > (likely UTF-8). Programs which *do* have to care would want that kind of support, yes. (Note that I'm not claiming to be an expert on the subject. I'm still puzzled by the implications, especially in mixed environments -- I have 25 years worth of data encoded as iso8859-1.) /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Manfred <noname@invalid.add>: Apr 01 05:05PM +0200 On 4/1/2017 7:49 AM, Jorgen Grahn wrote: > (Note that I'm not claiming to be an expert on the subject. I'm still > puzzled by the implications, especially in mixed environments -- I have > 25 years worth of data encoded as iso8859-1.) I don't claim to be an expert in this area either, but FWIW in my experience this is handled reasonably well by using utf-8 for I/O and external data encoding, and converting to wchar_t (i.e. std::wstring) for text manipulation and user interface. Note that wchar_t is required by the standard to "represent distinct codes for all members of the largest extended character set specified among the supported locales" (3.9.1-5) so not necessarily limited to UCS-2. IME the extra memory cost is acceptable for the applications that require this functionality - being typically GUI applications where the resource cost of the UI itself is much higher than that of data content. |
| Mr Flibble <flibble@i42.co.uk>: Apr 01 08:51PM +0100 On 01/04/2017 16:05, Manfred wrote: > IME the extra memory cost is acceptable for the applications that > require this functionality - being typically GUI applications where the > resource cost of the UI itself is much higher than that of data content. wchar_t is only 16 bits on Windows and UTF-16 is the WORST option out of UTF-8, UTF-16 and UTF-32. /Flibble |
| Manfred <noname@invalid.add>: Apr 01 11:36PM +0200 On 4/1/2017 9:51 PM, Mr Flibble wrote: >> UCS-2. > wchar_t is only 16 bits on Windows and UTF-16 is the WORST option out of > UTF-8, UTF-16 and UTF-32. Possibly, but still it is the encoding recommended by Microsoft. In Linux/gcc wchar_t is 32 bits. |
| bitrex <bitrex@de.lete.earthlink.net>: Apr 01 04:45AM -0400 Why does the following hack to have each instance of Bar inherit from a unique "identifier" non-class type, based on the address of the wrapper class Foo compile with -std=c++17, but not 14 or 11? struct Foo { void type_id() {} using type_id_t = void (Foo::*)(); struct BarBase { virtual ~BarBase(); }; template <void (Foo::*ID)()> struct Bar : BarBase { }; static BarBase* make_base_ptr() { constexpr type_id_t id = &Foo::type_id; return new Bar<id>; } }; |
| Marcel Mueller <news.5.maazl@spamgourmet.org>: Apr 01 12:13PM +0200 On 01.04.17 10.45, bitrex wrote: > Why does the following hack to have each instance of Bar inherit > from a unique "identifier" non-class type, based on the address of the > wrapper class Foo compile with -std=c++17, but not 14 or 11? No idea what inheritance you mean within this context, but with constexpr is up to the compiler to evaluate it at compile time or at run time. So the fragment > constexpr type_id_t id = &Foo::type_id; > return new Bar<id>; may not work because id might be evaluated at run time. But return new Bar<&Foo::type_id>; works even with C++11. Marcel |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 01 12:36PM +0200 On 01-Apr-17 12:13 PM, Marcel Mueller wrote: >> constexpr type_id_t id = &Foo::type_id; >> return new Bar<id>; > may not work because id might be evaluated at run time. No, you're conflating with `constexpr` functions. `constexpr` on a variable forces compile time; that's a way to test that a `constexpr` function call can really be done at compile time. I think that simply due to some peculiarity of the literal rules, the initializer is not considered a compile time expression in C++14 and earlier. Just my gut feeling, though. > But > return new Bar<&Foo::type_id>; > works even with C++11. Cheers!, - Alf |
| Alvin <Alvin@invalid.invalid>: Apr 01 01:12PM +0200 On 2017-04-01 10:45, bitrex wrote: > return new Bar<id>; > } > }; Explained in N4198: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4198.html C++17: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4268.html |
| 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