| JiiPee <no@notvalid.com>: Jan 23 01:55AM In this thread/post you can tell what you like in C++11/C++14. How it made things nicer, how you use it and how it made those things easier. Why you like C++11/C++14 more than the old C++? |
| JiiPee <no@notvalid.com>: Jan 23 02:09AM I used many times lambda in functions where I need to repeat some code but I do not want to create a function for it (because it reallly belong to that function, so I do not like to create an outside function which others can access, it only belong to this function). I like this. Example from one of my class (handling windows messages): LRESULT GDIHandler::WindowProcedureHandler(HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam) { ... auto sendMouseMessage = [this] (World::MouseMessage msg, int x, int y) { for(auto game : getGames()) game->onMouseMessage(msg, x, y); }; int x{LOWORD(lParam)} int y{HIWORD(lParam)} switch (message) { case WM_LBUTTONDOWN: sendMouseMessage(World::LBUTTON_DOWN, x, y); break; case WM_LBUTTONUP: sendMouseMessage(World::LBUTTON_UP, x, y); break; ............. } } (maybe WM_ messages could be mapped also somehow, but anyway if I want to do with switch then this is good) I know some maybe dont like it but I like this :). Like above, I do not want to create a function "sendMouseMessage ", becouse then other functions can also access it. Now only WindowProcedureHandler can get access to it. Also I heard this can possibly be optimized better by compiler than normal functions. |
| JiiPee <no@notvalid.com>: Jan 23 02:17AM "enum class" solved my long term problems... becouse before I had to create long names like: enum Animal {AN_DOG, AN_CAT} becouse somewhere surely I had another DOG.... so now I can: enum class Animal {DOG, CAT} no more AN_ kind of adding but just DOG, which it really should be imo. "auto" nice..... because am a bit lazy, so helps me :). also good to know it finds the best type, so reduces mistakes. so started using it. |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Jan 23 06:34AM On Sat, 2016-01-23, JiiPee wrote: > In this thread/post you can tell what you like in C++11/C++14. How it > made things nicer, how you use it and how it made those things easier. > Why you like C++11/C++14 more than the old C++? So far, ranged-for and auto. 'auto' for "trust me, the exact type here is not interesting in any way" -- not everywhere. I'm also fairly impressed by Boost.Asio, and how you can use lambdas there. But the best part is that it includes all of C++98. IMO, that's when C++ became useful. Without the standard containers and without people used to using templates, the language sucked. I'm still dealing with the fallout from that, 15+ years later. The C++98 compatibility might seem obvious, but look at Python 3.x which chose to break all old code. I'm so happy we're not going in that direction: it's a tempting stratey for a language person, but in practice it means a world of pain for a lot of real users. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Paavo Helde <myfirstname@osa.pri.ee>: Jan 23 10:45AM +0200 On 23.01.2016 3:55, JiiPee wrote: > In this thread/post you can tell what you like in C++11/C++14. How it > made things nicer, how you use it and how it made those things easier. > Why you like C++11/C++14 more than the old C++? Apart other things like ranged-for and auto I would like to point out rvalue references and std::move(). Earlier I had to emulate such things with swap, but this was cumbersome, error-prone and leaked implementation details over interface borders. Rvalue references solve this nicely and bring C++ to its stated goal of zero-overhead abstractions (in a specific area). This is not important for everybody, but for some it is very important. Cheers Paavo |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jan 23 12:34PM +0100 On 1/23/2016 2:55 AM, JiiPee wrote: > In this thread/post you can tell what you like in C++11/C++14. How it > made things nicer, how you use it and how it made those things easier. > Why you like C++11/C++14 more than the old C++? C++11 got rid of `std::auto_ptr` (especially the Visual C++ implementation was unreliable and buggy) and put `std::shared_ptr` and `std::function` in the standard library. That was nice. Also the removal of the requirement that a container item had to be assignable. Most people will probably mention rvalue references and support for move semantics as a real improvement, especially considering how Andrei Alexandrescu's "Mojo" demonstrated that C++03 was not up to the task. However, rvalue references are a kind of hack and they were not well understood when they were adopted. We don't have perfect forwarding, which was a goal (e.g. literal 0 can't be forwarded as such, and try forwarding e.g. `std::endl`), and e.g. `&&` can mean either an rvalue reference or a universal reference, depending on the context. It's a mess. So I'm happy that there's SOMETHING, but unhappy with the number of warts and imperfections, which IMHO is needlessly far too great. I like `using` aliases. They brought a much needed notational simplification. Lately I've started to use aliases such as `In_` to specify the type of a formal in-argument, `Ref_` to specify a reference type, and so on, and this makes the code more readable and easier to figure out, at the cost of ungood verbosity: not yet sure if it's worth it, but it looks OK so far, and for teaching it avoids confronting a learner up-front with the (according to Kernighan and Stroustrup) failed syntax experiment of C and early C++, which can be a barrier. Cheers & hth., - Alf |
| JiiPee <no@notvalid.com>: Jan 23 11:38AM On 23/01/2016 08:45, Paavo Helde wrote: > this nicely and bring C++ to its stated goal of zero-overhead > abstractions (in a specific area). > This is not important for everybody, but for some it is very important. yes I also like that we now just return the object itself from a function if there is move semantics for that class. no need to hassle with pointers or references. Makes coding also faster. |
| "Öö Tiib" <ootiib@hot.ee>: Jan 23 04:00AM -0800 On Saturday, 23 January 2016 04:17:45 UTC+2, JiiPee wrote: > becouse somewhere surely I had another DOG.... so now I can: > enum class Animal {DOG, CAT} > no more AN_ kind of adding but just DOG, which it really should be imo. The syntax sugar (if we write 'Animal_Dog' or 'Animal::Dog') feels of low importance about 'enum class' to me. The improved type safety of it feels more important improvement. Other thing about syntax. IMHO code that screams HERE_IS_MACRO is fine, because macros should be avoided and if not avoided then readers should be warned about these. The DOG and CAT are not macros so why you suggest to scream there? |
| JiiPee <no@notvalid.com>: Jan 23 12:23PM On 23/01/2016 12:00, Öö Tiib wrote: > because macros should be avoided and if not avoided then readers should > be warned about these. The DOG and CAT are not macros so why you suggest > to scream there? I think its because it seems to be the way many do it. Like here: http://www.cprogramming.com/c++11/c++11-nullptr-strongly-typed-enum-class.html enum Color {RED, GREEN, BLUE}; http://www.learncpp.com/cpp-tutorial/45-enumerated-types/ enum Color { RED, BLUE, // BLUE is put into the global namespace GREEN }; ######################### So many use that syntax. But am still not sure which one to use |
| JiiPee <no@notvalid.com>: Jan 23 12:24PM On 23/01/2016 12:00, Öö Tiib wrote: > 'Animal_Dog' or 'Animal::Dog' hmm, i prefer that latter one. There is a type separation there, but in the first there is a name separation, so its not exatclly the same. |
| "Öö Tiib" <ootiib@hot.ee>: Jan 23 04:28AM -0800 On Saturday, 23 January 2016 03:55:43 UTC+2, JiiPee wrote: > In this thread/post you can tell what you like in C++11/C++14. How it > made things nicer, how you use it and how it made those things easier. > Why you like C++11/C++14 more than the old C++? I really like most language and library improvements by C++11/C++14. I somewhat dislike only few things like the syntactic looseness of initialization and rvalue references and move. Something had to be done there and how C++11/C++14 added those is maybe not best but certainly not worst anyway. |
| David Brown <david.brown@hesbynett.no>: Jan 23 01:32PM +0100 On 23/01/16 13:23, JiiPee wrote: >> because macros should be avoided and if not avoided then readers should >> be warned about these. The DOG and CAT are not macros so why you suggest >> to scream there? Macros should not be avoided, nor are they something to panic about and warn people "HERE BE DRAGONS". They are a tool in the toolbox - if you use them properly and appropriately, they are perfect safe, functional and useful - and they don't need special treatment. > }; > ######################### > So many use that syntax. But am still not sure which one to use My advice is don't scream - I don't even do it for macros. The only time I use all-caps is for macros that get defined on the command line (such as "gcc -DDEBUG=1"). |
| "Öö Tiib" <ootiib@hot.ee>: Jan 23 04:46AM -0800 On Saturday, 23 January 2016 14:23:41 UTC+2, JiiPee wrote: > }; > ######################### > So many use that syntax. But am still not sure which one to use Yes, I have also noticed that many use screaming caps for constants and enumerators but I do not understand what is the reason. I would feel like Loud Howard from Dilbert when screaming GREEN and that is not good feeling. Therefore I capitalize just the first letter of types and constants. Syntax highlighting of code editor typically can color types and constants differently so there are no ambiguity. |
| "Öö Tiib" <ootiib@hot.ee>: Jan 23 05:32AM -0800 On Saturday, 23 January 2016 14:32:36 UTC+2, David Brown wrote: > warn people "HERE BE DRAGONS". They are a tool in the toolbox - if you > use them properly and appropriately, they are perfect safe, functional > and useful - and they don't need special treatment. Macros have numerous weaknesses compared to functions or constants. C++11/C++14 added features (like 'constexpr' functions) to further reduce the scope of usefulness of macros in C++ and I consider it good thing. There are indeed nothing to panic about those weaknesses but ... macros may have hard to realize effects, do not have namespace or scope, are difficult to debug etc. So if there is alternative to macro then it is usually cheaper to make, to use and to maintain. That is plenty of reason to avoid macros where possible and to warn readers that such weak text substitution thing was used where it isn't possible. |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Jan 23 03:04PM On Sat, 2016-01-23, JiiPee wrote: >> This is not important for everybody, but for some it is very important. > yes I also like that we now just return the object itself from a > function if there is move semantics for that class. Or maybe if there isn't move semantics we do it anyway, because it's now the normal way to do things, not just something which happens to be efficient for small objects. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Jan 23 03:16PM On Sat, 2016-01-23, 嘱 Tiib wrote: ... > because macros should be avoided and if not avoided then readers should > be warned about these. The DOG and CAT are not macros so why you suggest > to scream there? People interpret the all-caps thing differently. To you it says HERE_IS_MACRO; for others (like me) it says HERE_IS_A_CONSTANT. That split probably happened (without anyone noticing) in C in the 1980s. I concede that your view won in some sense ... but personally I still haven't made the switch, and I suspect there are a lot of people like me. One of the many obstacles in our line of work ... /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| JiiPee <no@notvalid.com>: Jan 23 03:38PM On 23/01/2016 15:04, Jorgen Grahn wrote: > Or maybe if there isn't move semantics we do it anyway, because it's > now the normal way to do things, not just something which happens to > be efficient for small objects. sure , especially if the returned object is small and there is no need to maximize speed there. I personally do not see any reason to optimize such small things (unless there is a real need for speed). Also, there is also an option to add the move semantics later on if speed is needed I guess. so returning by value is fixable later on easily like that if speed is needed. |
| David Brown <david.brown@hesbynett.no>: Jan 23 05:55PM +0100 On 23/01/16 14:32, 嘱 Tiib wrote: >> use them properly and appropriately, they are perfect safe, functional >> and useful - and they don't need special treatment. > Macros have numerous weaknesses compared to functions or constants. Yes, that's true. So don't use macros where a constant, or constexpr, or static inline function, or templated function, would be a better choice. That leaves you with using macros where macros are the best choice. It is no different from using any feature in any language - when there is more than one way to achieve the result, use the "best" method available for whatever criteria of "best" you think is most appropriate. > usually cheaper to make, to use and to maintain. That is plenty of reason > to avoid macros where possible and to warn readers that such weak text > substitution thing was used where it isn't possible. If you have used macros appropriately, they are not dangerous or weak. If you use them /inappropriately/, they can quickly be risky. We all know about potential problems from macros like these: #define maxValue 10*2000 #define square(x) ((x) * (x)) #define show(x) showDecimal(x); showHex(x) But the solution is not to give macros names in all-caps to show we are using a risky feature - the solution is not to write or use bad macros, thus avoiding using the feature in a risky manner! |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jan 23 06:51PM +0100 On 1/23/2016 5:55 PM, David Brown wrote: > But the solution is not to give macros names in all-caps to show we are > using a risky feature - the solution is not to write or use bad macros, > thus avoiding using the feature in a risky manner! The reason for the common [1]all uppercase naming convention for macros is not to make risky macros more evident to the source code reader, but mainly to reduce the risk of inadvertent text substitution, and secondly to make the macros less sexy, more of an eyesore, and keep this ugly convention for names that should not be much used, instead of having it applied to names that are much used such as constants. I.e., if it were intentional then the above would be a [2]classic Straw Man fallacy. Lowercase macro names can work when the source code is pretty small. And we've inherited a few such from the early C days, including `assert` and `errno` (in C++ the latter is guaranteed to be a macro, e.g. C++11 §19.4/1). But as the source code size increases, so does the risk of unintended substitutions, and modern code gets large fast. Cheers & hth., - Alf Notes: [1] See e.g. <url: http://www.stroustrup.com/bs_faq2.html#macro> [2] See e.g. <url: http://www.nizkor.org/features/fallacies/straw-man.html> |
| JiiPee <no@notvalid.com>: Jan 23 06:19PM On 23/01/2016 17:51, Alf P. Steinbach wrote: > keep this ugly convention for names that should not be much used, > instead of having it applied to names that are much used such as > constants. this is how I also think. its like static_cast. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jan 23 06:23PM On 23/01/2016 16:55, David Brown wrote: > It is no different from using any feature in any language - when there > is more than one way to achieve the result, use the "best" method > available for whatever criteria of "best" you think is most appropriate. "Macros should be avoided" is good *general* advice given their associated problems sausages. /Flibble |
| Ian Collins <ian-news@hotmail.com>: Jan 24 08:49AM +1300 JiiPee wrote: > yes I also like that we now just return the object itself from a > function if there is move semantics for that class. no need to hassle > with pointers or references. Makes coding also faster. We could do that before C++11 thanks to RVO. -- Ian Collins |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jan 23 09:08PM On Sat, 23 Jan 2016 17:55:29 +0100 David Brown <david.brown@hesbynett.no> wrote: [snip] > But the solution is not to give macros names in all-caps to show we > are using a risky feature - the solution is not to write or use bad > macros, thus avoiding using the feature in a risky manner! The issue is not just avoiding macros when straightforward text substitution may give the wrong results in certain contexts. The problem is that the macro/definition names are unscoped and unnamespaceable (is that a word?), so they merit attention being given to them by using capitals, and they ought also to be prefixed as a substitute for a namespace. One example is from Qt. Their 'emit', 'signal' and 'slot' keywords are macros, and they are an abomination. They break boost, for example. The workaround that the Qt library provides is the option is to disable the unprefixed lower case macros and substitute for them upper case prefixed macro names. Chris |
| "Öö Tiib" <ootiib@hot.ee>: Jan 23 03:40AM -0800 On Friday, 22 January 2016 20:39:59 UTC+2, Dmitry Chichkov wrote: > And specifically *excludes* solutions that expect the compiler to use > optimization hacks to statically resolve virtual/pimpl calls at a > compile time. I think that we do not actually need any virtual/pimpl calls. If functions are or are not inlined is up to complier and linker and can not be affected from C++ code (without using platform-specific extensions). > There are 'CRTP' and 'traits' patterns that allow one to do it in C++. > And preprocessor hacks. It looks like this inline namespace trick > described here could be an alternative to these approaches. CRTP and traits patterns are not really meant for separating platform-specific code from code that is common for all platforms but for simplifying any compile-time meta-programming code. > Question - does anyone see any potential pitfalls with this technique? It can look as confusing as slicing code with preprocessor and unlike when done with preprocessor it assumes that the platform-specific code compiles on all platforms (that is rarely the case in practice). I myself prefer simply to link to platform-specific implementation file. Different files implement same thing for different platforms. It is better because then there may be platform-specific extensions to language used in platform-specific code if needed. |
| 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