tag:blogger.com,1999:blog-6950833531562942289.post5164913986716915743..comments2024-03-25T03:36:48.099-07:00Comments on C0DE517E: Integrating C++11 in your dietDEADC0DEhttp://www.blogger.com/profile/01477408942876127202noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-6950833531562942289.post-59647083818665066202013-07-03T01:44:08.510-07:002013-07-03T01:44:08.510-07:00"It doesn't even attempt to deprecate any..."It doesn't even attempt to deprecate anything"<br /><br />http://www.cplusplus.com/reference/memory/auto_ptr/<br /><br />"Note: This class template is deprecated as of C++11."<br /><br />datgamehttp://twitter.com/datgamenoreply@blogger.comtag:blogger.com,1999:blog-6950833531562942289.post-24235821685509426402013-05-17T18:01:58.506-07:002013-05-17T18:01:58.506-07:00The same goes for SFINAE and other tricks like tha...The same goes for SFINAE and other tricks like that. Yes, they are neat, usually neat abuses of systems that were never meant to do that... They are HACKS.<br /><br />Now, let me be clear. Hacks can be beautiful, elegant, great. E.G. like boost::lambda was. And you can do whatever in C++ as you can overload whatever and templates are turing complete.<br /><br />That said, let me be SUPER clear. The problem with all these is that if on a level you can look at them and masturbate all day long on how pretty they are and how smart you are to use them. But. They are not ideomatic in the language. They were never thought that way, they are not supported. You use them in a team and then what? Tools won't know what you're doing, your team won't know, your new hires won't know. They will either accept that this magic works in way they don't understand (let's again think of things like boost::lambda) or they have to become experts in your extensions to the language...<br /><br />I will never allow such things to happen in my teams.<br /><br />Templates already abused in most cases, they were, lets be honest, designed for parametric polymorphism, for "generics", not for metaprogramming. They are not scheme's hygienic macros and even if they can do a lot of things, they SUCK at it.DEADC0DEhttps://www.blogger.com/profile/01477408942876127202noreply@blogger.comtag:blogger.com,1999:blog-6950833531562942289.post-15752051030694487722013-05-17T17:40:02.633-07:002013-05-17T17:40:02.633-07:00The problem with rvalues is not that they are conc...The problem with rvalues is not that they are conceptually complex, but that they add more resolution rules which in turn add more pitfalls.<br /><br />Now, I wouldn't ban them from a project, but it's one of these things, like templates, that I would allow only from experts and after a good review process to make sure you really need to use them and there are no other ways around.<br /><br />In case of rvalue references as I wrote, most times we don't want objects, surely we don't want fat objects, even less fat objects with complex constructors. So the whole issue of copying around and creating temporaries should be most of the times a non-issue, and thus, rvalues offer little benefits.<br /><br />The C "heritage" is a lame excuse, sorry. Most of the evils in C++ come from decisions on the part of the language that is new, not the part that keeps compatibility with C. E.G. to name a few: the "explicit" keyword horror, the "automatic" class functions scandal, the incredibly naive templates, a standard library that can't really be used in interfaces, etc etc etc.<br /><br />Last but not least, it's not at all a problem of effort and of learning new things. It's a problem of complexity and handling large teams. I think from what you write that you've worked in c++ teams at companies. How many programmers on average will be even just able to understand your average STL compile error (thanks standards committee from non giving us contracts)? And we're just talking about STL, containers, not crazy metaprogramming things... Not to mention that templates make code much bigger, compile times much longer, are a hell to debug and so on and so forth. DEADC0DEhttps://www.blogger.com/profile/01477408942876127202noreply@blogger.comtag:blogger.com,1999:blog-6950833531562942289.post-64707604540236748352013-05-16T13:45:48.853-07:002013-05-16T13:45:48.853-07:00I think you've missed a trick with rvalue refe...I think you've missed a trick with rvalue references, they are not as complex as you think (though there is some 'interesting' overlap between rvalue references and auto .. also search for universal references)<br /><br />C++ as a language has a heritage that is impossible to ignore - C. That is the single most important reason why C++ is how it is today. If you want to cast off the chains of C then in my opinion the logical progression is to program in D.<br /><br />C++11 represents a lot of hard work from some of the best minds in the industry, however C++ is not perfect. I doubt it ever will be, but it will always serve the purpose for which it was intended, to imbue C programmers with the tools necessary to create higher level object oriented abstractions.<br /><br />C++ development is in fact accelerating, C++14 is already being worked on, and the new features are already appearing in cutting edge compilers such as Clang.<br /><br />I know from experience that TMP is generally avoided in the games industry, but not always for the right reasons. Just as you have already decided that rvalue references are just 'too complicated', this is the same as saying it's too much effort to learn something new. TMP has a great name, but it's not as complex as it sounds, constructs like SFINAE are actually remarkably elegant solutions for problems which would normally be solved with C-style macros, without sacrificing type-safety or performance.Chttps://www.blogger.com/profile/11364822757626615318noreply@blogger.comtag:blogger.com,1999:blog-6950833531562942289.post-38555354716128479572013-05-14T00:36:54.818-07:002013-05-14T00:36:54.818-07:00nice post. just disagree on one thing though : C++...nice post. just disagree on one thing though : C++ is the best language in the world :)cubeenoreply@blogger.com