- The effectiveness of C++14 - 3 Updates
- using namespace std - 2 Updates
- Function returning && - 2 Updates
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Jan 05 07:32PM On Mon, 2015-01-05, Scott Lurndal wrote: > legalize+jeeves@mail.xmission.com (Richard) writes: >>slp53@pacbell.net spake the secret code >><iWxqw.1082954$Rp.81761@fx23.iad> thusly: ... >>you have chosen to stick with a C++98 compiler. I know people who > No, my "boss" requires that I stick with a C++98 compiler. Qualification > of a new compiler is expensive, in terms of man-hours for both testing Do you really perform independent testing of compilers that everyone else has been using for years? If you mean testing for defects in your own code being triggered by the new compiler, aren't you performing testing for other reasons (like actual code changes) and wouldn't those tests be likely to catch those defects? /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| scott@slp53.sl.home (Scott Lurndal): Jan 05 09:07PM >your own code being triggered by the new compiler, aren't you >performing testing for other reasons (like actual code changes) and >wouldn't those tests be likely to catch those defects? Before any compiled binary is delivered to a customer/end-user, it goes through a battery of tests. Updating the compiler, sans any other change to an application, triggers a full test cycle, which can take months. This has been the case regardless of whether the application is an operating system, a hypervisor or an application that executes in user mode on a given CPU. Third party libraries and ISO 9001 compliance (tracking what version of the compiler was used to build every application, for example) also come into play. |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Jan 05 09:46PM On Mon, 2015-01-05, Scott Lurndal wrote: > Before any compiled binary is delivered to a customer/end-user, it > goes through a battery of tests. Updating the compiler, > sans any other change to an application, triggers a full test cycle, ^^^^^^^^^^^^^^^^^^^^^ > which can take months. This has been the case regardless of whether > the application is an operating system, a hypervisor or an > application that executes in user mode on a given CPU. Yes, but my point was, surely you make other changes? Can't you slip in a compiler upgrade together with them? /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Vincenzo Mercuri <nomail@yahoo.it>: Jan 05 03:44PM +0100 Il 05/01/2015 15:35, Jorgen Grahn ha scritto: > On Mon, 2015-01-05, Vincenzo Mercuri wrote: .. > explain twice that he doesn't, really. > BTW, I don't think anyone minds us quoting the book from a copyright > perspective. "Fair use" was invented for exactly this scenario. Yes, I just felt a bit uncomfortable when I opened the book and copied the text. I wasn't aware of this legal term actually, thanks for pointing that out. -- Vincenzo Mercuri |
| Mike Austin <spam@null.net>: Jan 05 12:35PM -0800 On 1/5/15 1:29 AM, Öö Tiib wrote: > that explicitly. 'vector<string>' is only half way. typedef it as 'Names' > right away. Lot less to type also more readable (than 'auto') immediately > but YMMV. That is also a very good habit. It also helps clean up the nested template ">>" issues. Another example to complement yours: namespace UI { using std::shared_ptr; // Can change to boost if no C++11 support using std::vector; // Can change to list or deque if needed struct View { typedef shared_ptr<View> Ptr; // Hide the implementation typedef vector<View::Ptr> ChildView; // Again, hide details }; } Mike |
| Luca Risolia <luca.risolia@linux-projects.org>: Jan 05 07:15PM +0100 On 05/01/2015 17:21, Bo Persson wrote: >> return std::move(x); >> } > This seems to work, but returns a dangling reference to the parameter. Sure, I should have added that. I read "did not work" as "did not compile" - as if the OP was trying to experiment some stuff. |
| Luca Risolia <luca.risolia@linux-projects.org>: Jan 05 07:41PM +0100 On 05/01/2015 17:22, Joseph Hesse wrote: > } > In the above, x is clearly an int && and that is what the function > promises to return. No, in short, the expression "x" refers to an lvalue, after x has been initialized. There are valid reasons why this happens. If you are interested, there should be some more detailed explanations at the Stroustrup's web page: http://www.stroustrup.com/C++11FAQ.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