- The effectiveness of C++14 - 19 Updates
- The effectiveness of C++14 - 3 Updates
"Öö Tiib" <ootiib@hot.ee>: Jan 05 09:42PM -0800 On Monday, January 5, 2015 11:08:05 PM UTC+2, Scott Lurndal wrote: > >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. Yes, but "does it compile (without diagnostics)?" is also one of such tests. That test is usually required from developer to be done before committing a change to repository. When compiling is expensive (in terms of time and resources) it can be moved to responsibility of separate automatic build farm that does it right after commit and reverts the commit on case of issues. Why not to wait until we really need a binary for testers? Because building immediately provides fast feedback to defect's author and so fixing is cheapest. Other tests that can be organized to provide fastest feedback are unit tests and static analysis. Trying to build with other compiler or with different version of same compiler is just a form of static analysis. It can give false positives (like any other automatic test) but since it is fast feedback the issues are cheap to fix and false positives cheap to silence. > 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. Updating to compiler that has been anyway used as static analysis during development process is cheaper. Update is usually triggered because the binaries built with newer compilers tend to show lot better results in stress tests and in performance tests. > 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. Certainly there can be reasons why still not to upgrade to newer compiler for building end-user binaries. What I argue is that I do not see much reasons for not to take newer compiler as automatic static analysis tool. Compiler that people have used for some time (like gcc 4.7 or clang 3.4) can give valuable hints what is wrong with your code. Clang even comes bundled with some great tools. |
Louis Krupp <lkrupp@nospam.pssw.com.invalid>: Jan 05 11:27PM -0700 On Mon, 5 Jan 2015 17:51:01 +0000 (UTC), >>No, my "boss" requires that I stick with a C++98 compiler. [...] >Again, choices that you (or your organization) have made. This is a >problem of your own making. It's not an uncommon situation. I would say that most organizations with large code bases are very conservative when it comes to upgrading compilers. And imagine that you're responsible for one of those third-party libraries. You've tested it with C++98, or whatever, but not with C++11, as you might have other things you need to do, like maintain and enhance your own product. Are you going to swear to your customers that it will work with a newer compiler? Do you tell them to try it at their own risk? If they do, and something goes wrong, do you want to spend the time debugging something that might or might not be your fault? Or do you schedule the upgrade and the testing and live with the time it takes to make sure that if and when something goes wrong, it's almost certain to be someone else's fault. As a developer, it's frustrating. It's always more fun to use the latest and greatest tools. But the business world and reality often get in the way. Louis |
"Öö Tiib" <ootiib@hot.ee>: Jan 05 11:11PM -0800 On Tuesday, January 6, 2015 8:27:16 AM UTC+2, Louis Krupp wrote: > It's not an uncommon situation. I would say that most organizations > with large code bases are very conservative when it comes to upgrading > compilers. If there is some development going on then there will be major releases sometimes. If there are no development going on then it is frozen product. You can milk money for decade and half from frozen product but one day the milking itself becomes too expensive. > to try it at their own risk? If they do, and something goes wrong, do > you want to spend the time debugging something that might or might not > be your fault? Depends on goals. What are your goals? Protect yourself against failures or try to achieve successes? Sure way to not fail is to do nothing, doing anything may bring failures. Sure way to not succeed is to do nothing, doing anything may bring successes. ;) > As a developer, it's frustrating. It's always more fun to use the > latest and greatest tools. But the business world and reality often > get in the way. Business world pays best money to successful engineers who follow progress and shitty money to frustrated engineers who fear to fail. The problems can be of your own making. ;) |
Paavo Helde <myfirstname@osa.pri.ee>: Jan 06 01:46AM -0600 legalize+jeeves@mail.xmission.com (Richard) wrote in news:m8ej1p$qb5$2 > I find it ironic that although I work (at least until the end of > today) at a mostly linux shop that it's Visual Studio that has the > best C++ compiler between the different operating system. The compiler which has not yet implemented half of the C++11 standard from 4 years ago? I guess the meaning of "best" is extremely relative ;-) |
scott@slp53.sl.home (Scott Lurndal): Jan 06 02:28PM >used for some time (like gcc 4.7 or clang 3.4) can give valuable >hints what is wrong with your code. Clang even comes bundled with some >great tools. from a typical project makefile: PHONY: cppcheck cppcheck: ${CPPCHECK} *.cpp |
scott@slp53.sl.home (Scott Lurndal): Jan 06 05:19PM > teach C++ (and not cancelled-and-replaced languages like > C++11 (?), C++03, C++98, C++ARM, C++preARM, or C with classes): > First, I deem to teach the students for the future, not the past. That's useless. You should teach them so they can get jobs today, not next century. tschuss |
Louis Krupp <lkrupp@nospam.pssw.com.invalid>: Jan 06 10:47AM -0700 On Mon, 5 Jan 2015 23:11:04 -0800 (PST), 嘱 Tiib <ootiib@hot.ee> wrote: >sometimes. If there are no development going on then it is frozen product. >You can milk money for decade and half from frozen product but one day >the milking itself becomes too expensive. "Conservative" doesn't necessarily mean stagnant. Things get upgraded, but not as fast as some might like. >or try to achieve successes? Sure way to not fail is to do nothing, >doing anything may bring failures. Sure way to not succeed is to do >nothing, doing anything may bring successes. ;) Businesses have an annoying habit of being risk-averse. And it's possible to avoid failure and try to succeed at the same time. Most successful businesses have been doing it for years. >Business world pays best money to successful engineers who follow >progress and shitty money to frustrated engineers who fear to >fail. The problems can be of your own making. ;) Not necessarily. If you haven't read _The Difference Between God and Larry Ellison_, you really should. It talks about how Ingres had a better query language ("Quel") than Oracle's SQL, but Oracle ran on more platforms and had better marketing, so Oracle became #1 in the database market. And then there's MS-DOS. Did Microsoft take over the world because it had the best operating system? I have to ask: How long have you been a programmer? My guess is that once you've been at this for 20 or 30 years, you'll have seen some of what I'm talking about. If you can spend all of those 20 or 30 years on the cutting edge, using the latest tools, then you're exceptionally good. The world needs a new word processor, among other things, and you might just be the person to do it... Louis |
"Öö Tiib" <ootiib@hot.ee>: Jan 06 10:01AM -0800 On Tuesday, 6 January 2015 16:28:55 UTC+2, Scott Lurndal wrote: > PHONY: cppcheck > cppcheck: > ${CPPCHECK} *.cpp Oh, cppcheck is nice tool. Sad its team is perhaps too small so it does crawl out of hand a bit: http://trac.cppcheck.net/report/13 I feel it does not understand preprocessor macros too well. Microsoft's PreFast and Clang Static Analyzer seem to understand code bit better. The warnings of real compilers are still good to have. If a tool that tries to compile your code is worried with it then it is most likely that some developer is also confused when trying to read it. |
Ian Collins <ian-news@hotmail.com>: Jan 07 07:58AM +1300 Scott Lurndal wrote: > The third party libraries we link with aren't qualified by their > vendor for anything other than certain versions of GCC that don't > include any with full C++11 support, much less C++14. Whether to upgrade tools really comes down to two things: how well the tool vendor supports the process and how much you trust your release process. Some vendors (such as Sun/oracle) go out of their way to provide compatibility modes which support compiling existing code with the newer compiler. This decouples the compiler upgrade from code changes. If your release process is up to the task, the costs of a compiler upgrade can be minimised. -- Ian Collins |
Louis Krupp <lkrupp@nospam.pssw.com.invalid>: Jan 06 12:50PM -0700 On Wed, 07 Jan 2015 07:58:47 +1300, Ian Collins <ian-news@hotmail.com> wrote: >the newer compiler. This decouples the compiler upgrade from code >changes. If your release process is up to the task, the costs of a >compiler upgrade can be minimised. GNU tools (which I've been using for the last ten or fifteen years) are cheap and good, but there are no guarantees, and it's all down to the qualification and release process. For some products, like the embedded systems that run inside printers, there is basically zero tolerance for regression. Sending technicians to customer sites to replace PROMs isn't an option. Louis |
Jorgen Grahn <grahn+nntp@snipabacken.se>: Jan 06 08:19PM On Tue, 2015-01-06, 嘱 Tiib wrote: > On Tuesday, January 6, 2015 8:27:16 AM UTC+2, Louis Krupp wrote: ... > or try to achieve successes? Sure way to not fail is to do nothing, > doing anything may bring failures. Sure way to not succeed is to do > nothing, doing anything may bring successes. ;) Well said. In my experience (or opinion) that's a pretty common disease in organizations. And as a programmer, it seems to be easy to get sucked into it, overestimating the risks and the effects of a potential bug, and eventually getting to the stage where you take pride in how carefully you can get very little work done ... Disclaimer: I also hate it when people create artificial problems and risks for themselves, as if excitement is more important than getting things done. That's the other extreme, and it's not what I'm advocating. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
Louis Krupp <lkrupp@nospam.pssw.com.invalid>: Jan 06 01:21PM -0700 On Tue, 06 Jan 2015 17:19:27 GMT, scott@slp53.sl.home (Scott Lurndal) wrote: >> First, I deem to teach the students for the future, not the past. >That's useless. You should teach them so they can get jobs >today, not next century. The two aren't mutually exclusive. A C++ course that *didn't* teach the latest and greatest would be missing something; it's the difference between training and education. On the other hand, since the language is evolving, an instructor would be remiss in not telling students that not all features are supported by all compilers, and that they can expect to have to work within some of those constraints -- at least for a while. As more and more people who understand the newer features move into the profession and into technical leadership positions, institutions adopt newer standards as well. Things might not change as rapidly as everyone might like, and there's always a gap between what's new and what's commonly accepted, but if nobody pushed for change, it wouldn't happen at all. Louis |
"Öö Tiib" <ootiib@hot.ee>: Jan 06 12:42PM -0800 On Tuesday, January 6, 2015 7:47:11 PM UTC+2, Louis Krupp wrote: > >the milking itself becomes too expensive. > "Conservative" doesn't necessarily mean stagnant. Things get > upgraded, but not as fast as some might like. Yes but "Stick to C++98" sounds fully stagnant. > Businesses have an annoying habit of being risk-averse. And it's > possible to avoid failure and try to succeed at the same time. Most > successful businesses have been doing it for years. What risk? Most of the features added by C++11 made the language more safe, complete and efficient. Perhaps the only thing I dislike is that pointless multitude of ways of initialization. > database market. And then there's MS-DOS. Did Microsoft take over > the world because it had the best operating system? > I have to ask: How long have you been a programmer? 28 years. > those 20 or 30 years on the cutting edge, using the latest tools, then > you're exceptionally good. The world needs a new word processor, > among other things, and you might just be the person to do it... What cutting edge? 1998 was whole human generation ago. Little kid of coworker back then goes to baby-moon vacation now herself. I typically don't use software that isn't at least 2 years old. I consider myself conservative. However 1998? It is stagnant. It is like using CVS while we have had Git and Mercurial for years. |
Ian Collins <ian-news@hotmail.com>: Jan 07 09:44AM +1300 Louis Krupp wrote: > For some products, like the embedded systems that run inside printers, > there is basically zero tolerance for regression. Sending technicians > to customer sites to replace PROMs isn't an option. My recent management experience is in embedded controllers, that's why I put so much weight on all forms of testing! -- Ian Collins |
scott@slp53.sl.home (Scott Lurndal): Jan 06 09:28PM >> "Conservative" doesn't necessarily mean stagnant. Things get >> upgraded, but not as fast as some might like. >Yes but "Stick to C++98" sounds fully stagnant. How so? gcc 4.4.7 (on our build cluster systems) dates to 2012. There is nothing wrong with C with classes paradigms or C++98 paradigms or C++11 paradigms or whatever. Nothing. They are perfectly acceptable paradigms for modern application development. >What risk? Most of the features added by C++11 made the language more >safe, complete and efficient. Perhaps the only thing I dislike is=20 >that pointless multitude of ways of initialization. Why should I make pointless changes to a working 5, 10 or 15-year old application just because someone thought adding a new feature to a mature language was a good idea? I'm sure as hell never going to spend the architecture, engineering and validation time to change a half-million line application from using raw pointers to using std::unique_ptr - it buys nothing, zero for the product nor for my employer. >> I have to ask: How long have you been a programmer? >28 years. 39 years, in my case. >don't use software that isn't at least 2 years old. I consider myself=20 >conservative. However 1998? It is stagnant. It is like using CVS while >we have had Git and Mercurial for years.=20 see above. and for that matter, I'm familiar with projects that still use SCCS, some that use CVS and many that use SVN in addition to some that use git. They all have their uses, even clearcase, perforce or bitkeeper. |
Vir Campestris <vir.campestris@invalid.invalid>: Jan 06 09:45PM On 05/01/2015 17:15, Scott Lurndal wrote: > and updating the sources to compile correctly with the new compiler > (often because GCC changes the set of fatal warnings from one > release to the next and we compile with -Wall -Werror). When we did an MS compiler upgrade it was a right PITA because of all the new errors that came up. Several of them were real bugs it had caught. I don't recall any problems with code failing because of a compiler error - although we did have a few problems with compiler crashes, where we had to re-work the code to make its life easier. Andy |
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jan 06 09:52PM On 06/01/2015 21:28, Scott Lurndal wrote: >>> I have to ask: How long have you been a programmer? >> 28 years. > 39 years, in my case. 39 years? That explains your intransigent stubbornness then. Old dog new tricks innit. /Flibble |
Ian Collins <ian-news@hotmail.com>: Jan 07 11:08AM +1300 Scott Lurndal wrote: >>> upgraded, but not as fast as some might like. >> Yes but "Stick to C++98" sounds fully stagnant. > How so? gcc 4.4.7 (on our build cluster systems) dates to 2012. So you do have a compiler which supports a decent sized subset of C++11 and its library. > There is nothing wrong with C with classes paradigms or C++98 > paradigms or C++11 paradigms or whatever. Nothing. They are > perfectly acceptable paradigms for modern application development. True enough. > Why should I make pointless changes to a working 5, 10 or 15-year old > application just because someone thought adding a new feature to a > mature language was a good idea? Don't you ever add new features or rework old ones? If you are using gcc 4.4.7, you may as well take advantage some of the performance and safety offered by C++11. Upgrades don't have to be a big bang. Big projects always ave a mix of old and new code. I bet most modern kernels include both pre-ansi and C99 code. Code gets modernised if and when it is updated. > validation time to change a half-million line application from using > raw pointers to using std::unique_ptr - it buys nothing, zero for the > product nor for my employer. Nor should you, but there's nothing wrong with adopting modern techniques for new code. -- Ian Collins |
"Öö Tiib" <ootiib@hot.ee>: Jan 06 02:24PM -0800 On Tuesday, January 6, 2015 10:20:07 PM UTC+2, Jorgen Grahn wrote: > and risks for themselves, as if excitement is more important than > getting things done. That's the other extreme, and it's not what > I'm advocating. Changes can be made more or less safely. For example I have experienced that it is safer to write replacement module side-by-side for a while instead of replacing or changing old "legacy" module right away. Old things have often accumulated some vital cleverness over time and may have some hidden responsibilities or badly documented (but important) features. So even when the reasons of replacing are firm the estimations what it takes to write fully better one are usually naive. |
ram@zedat.fu-berlin.de (Stefan Ram): Jan 06 05:16PM >As a developer, it's frustrating. It's always more fun to use the >latest and greatest tools. But the business world and reality often >get in the way. I teach C++ in adult evening classes, and I have reasons to teach C++ (and not cancelled-and-replaced languages like C++11 (?), C++03, C++98, C++ARM, C++preARM, or C with classes): First, I deem to teach the students for the future, not the past. Second, sometimes, student ask me about what's new in C++. Third, IIRC Bjarne Stroustrup recommends to teach C++ (and not the cancelled-and-replaced languages like C++11 (?), C++03, C++98, C++ARM, C++preARM, or C with classes): And I just was revising the lesson, where I explain what the current norm for C++ is. It is this lesson (in German): http://www.purl.org/stefan_ram/pub/c++_grundbegriffe I do and did not know whether ISO/IEC 14882:2014(E) is already in force, so how can I tell my students what the currently valid norm is? That was the reason I asked here. |
ram@zedat.fu-berlin.de (Stefan Ram): Jan 06 05:27PM >>First, I deem to teach the students for the future, not the past. >That's useless. You should teach them so they can get jobs >today, not next century. Go to an 18 hour adult evening C++ course for beginners. Get a job in C++ programming. I see. |
ram@zedat.fu-berlin.de (Stefan Ram): Jan 06 08:32PM >A C++ course that *didn't* teach the latest and greatest would be Another reason might be that according to the ISO, the meaning of »C++« is »the latest standard«, so when someone anounces to »teach C++« this should refer to the latest standard by default - at least when one is taking the ISO norms seriously. |
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