- Feedback welcome on early version of `stdlib` (e.g. UTF-8 console in Windows) - 3 Updates
- Template type deduction from value for class templates and value templates - 2 Updates
- Combining modified flag with a class member modification - 1 Update
- Bog in condition_variable_any wait_for - 1 Update
- Intel C++ Compiler - 2 Updates
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jun 10 06:59AM +0200 I welcome feedback on the current early version of `stdlib`, which provides e.g. UTF-8 console i/o via `cout` etc. in Windows. More generally `stdlib` aims to provide an easier to use view of the C++ standard library, a view with far fever header inclusions required for common small programs, and where things Just Work™ by default. Note: I haven't tested anything in *nix-land yet, so those claims in the README file are entirely unsubstantiated as yet, but it will get there. https://github.com/alf-p-steinbach/stdlib Cheers!, - Alf |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jun 10 09:47PM +0100 On 10/06/2017 05:59, Alf P. Steinbach wrote: > Note: I haven't tested anything in *nix-land yet, so those claims in the > README file are entirely unsubstantiated as yet, but it will get there. > https://github.com/alf-p-steinbach/stdlib "stdlib" is an egregious choice of name, it suggests both hubris on your part and clashes with the common community term of "C++ stdlib" which refers to the C++ Standard Library; I suggest you rename it to something that more resembles what it is/what it does. /Flibble |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jun 10 11:29PM +0200 On 10-Jun-17 10:47 PM, Mr Flibble wrote: > part and clashes with the common community term of "C++ stdlib" which > refers to the C++ Standard Library; I suggest you rename it to something > that more resembles what it is/what it does. I chose `stdlib` because that says exactly what the library is: a wrapper/view of the standard library, no more and no less. With the most ungood behavior of the standard library fixed, that's true. So maybe `bugfixed_stdlib` would be better, but that's quite verbose! :-o If someone who uses my library say they are using the "standard library" or "stdlib", then that would communicate exactly what they are using, namely the C++ standard library. That's why I think it's a good name. Thanks for the heads-up about what some people might think. However, I don't really give a turd about whether some conformists might think I'm a megalomaniac or whatever to use a name that in their mind is associated with something beyond my place. I say, ignore the idiots. :) Cheers!, - Alf |
| Adam Badura <adam.f.badura@gmail.com>: Jun 10 01:48PM -0700 > Just define the function in the first place. Much easier. You can even > make it `constexpr`. Sure I can! However, it is not the same (although maybe close enough). A simple approach with function would be to have following: constexpr inline char const* enum_value_to_string(color v) { switch(v) { case color::black: return "color::black"; case color::gray: return "color::gray"; case color::white: return "color::white"; } return "<unexpected>"; } First issue is that now we no longer have compilation error for missing value. At best we will get a warning. Not so bad, but I would prefer a required error rather then optional warning. Second issue is that by doing so I'm loosing a piece of information: size of the string. sizeof(enum_value_name<color, color::black>) is expected 13. While with enum_value_to_string function I'm left with calling std::strlen. Regarding your example it is all fine however doing it properly is no longer that simple. To do it properly you should take into account: namespaces, class enum vs. old enum, underlying type, programmer-provided values, including repeated values, and maybe even some more. This leads to complicated machinery that also results in code harder to read (now try to grep for "enum color"...). I'm not against such approaches - only showing that they are far from perfect. Finally showing that there are alternatives (for a reminder: non-perfect) doesn't really answer my questions as their existence doesn't prevent larger flexibility for classes and values. Why not allow my_class<1> instead of my_class<int, 1>? PS 1 Why are you consistently using "auto" for return type and then "-> <type>"? Syntactically it seems to be longer in cases here. What are the advantages? PS 2 Why are you using "const" for non-reference function arguments? Does it provide any benefit? |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jun 10 11:18PM +0200 On 10-Jun-17 10:48 PM, Adam Badura wrote: > } > return "<unexpected>"; > } Well, no I meant a function like the (working) example I showed, #define DEFINE_CSTRING_FROM_ENUM( Enum ) \ template<> \ constexpr inline auto cstring_from( Enum const v ) \ -> char const* \ { \ constexpr char const* const enum_value_names[] = { NAMES }; \ return enum_value_names[int( v )]; \ } Arrays are nice for arrays of values. > First issue is that now we no longer have compilation error for > missing value. No problem, just add that. > size of the string. sizeof(enum_value_name<color, color::black>) is > expected 13. While with enum_value_to_string function I'm left with > calling std::strlen. No problem, just let that function return a C++17 stringview, or corresponding DIY class. > namespaces, class enum vs. old enum, underlying type, > programmer-provided values, including repeated values, and maybe even > some more. Sounds like premature generalization. Do you really need all that? > non-perfect) doesn't really answer my questions as their existence > doesn't prevent larger flexibility for classes and values. Why not > allow my_class<1> instead of my_class<int, 1>? Write up a detailed proposal. Find someone on the committee to champion it. Might take some years. ;) > PS 1 Why are you consistently using "auto" for return type and then > "-> <type>"? Syntactically it seems to be longer in cases here. What > are the advantages? I use a single syntax for functions. I don't see any advantage in also (arbitrarily) using the old more limited syntax. > PS 2 Why are you using "const" for non-reference function arguments? Same reason as for using `const` for local variables: it constrains what can change, so it helps with understanding and maintaining the code. > Does it provide any benefit? Because you ask, I think it wouldn't help to discuss the merits and disadvantages objectively: you have likely already dismissed that. So, authority arguments it is. That's fallacious, of course, but I don't shy away from a few fallacies here and there if they can do good, so: Some, /mainly C-oriented programmers/, argue that `const` has little or no benefit. The existence of `const` in C++, and in C, however, testifies to the fact that some pretty competent people, language designers, thought it was worth the effort to provide it. Cheers & hth., - Alf |
| JiiPee <no@notvalid.com>: Jun 10 10:14PM +0100 On 09/06/2017 05:08, JiiPee wrote: > others suggestions good as well and might use them in the future. Just > that I could not use bool& modified_; but a pointer, because I had to > be able to do assignment for Player so needed a pointer. the pointer thing I was trying... now I found out that its a bit dangerous as its possible the modified_ is pointing to a non-existence variable if its a pointer. If there any way to solve the problem that assignment cannot be done If I use your reference method? how can i copy Point's if it has that reference? |
| Chris Ahlstrom <OFeem1987@teleworm.us>: Jun 10 12:38PM -0400 Fred.Zwarts wrote this copyrighted missive and expects royalties: >>Why do you think so? > Because I told you that my wait_for loop became effectively a busy loop and > then you continued to say that even sleep does not have to sleep. Melzzz meant that in some cases it does not need to sleep. -- Mind! I don't mean to say that I know, of my own knowledge, what there is particularly dead about a door-nail. I might have been inclined, myself, to regard a coffin-nail as the deadest piece of ironmongery in the trade. But the wisdom of our ancestors is in the simile; and my unhallowed hands shall not disturb it, or the Country's done for. You will therefore permit me to repeat, emphatically, that Marley was as dead as a door-nail. -- Charles Dickens, "A Christmas Carol" |
| Melzzzzz <Melzzzzz@zzzzz.com>: Jun 10 01:39AM > Intel C++ compiler. > I've never tried that compiler. My question would be if they have > support for string_view yet. For a period of time intel offered their compiler suite for free on Linux for non commercial development. Not any more. Now you have to be student and have student address. -- press any key to continue or any other to quit... |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jun 10 05:27AM -0700 > > specific compiler division or sales division for compilers? > Maybe you could contact one of these guys: > http://cppcast.com/2017/04/udit-patidar-anoop-prabha/ Will do. Thanks for the guidance. Thank you, Rick C. Hodgin |
| 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