Tuesday, January 6, 2015

Digest for comp.lang.c++@googlegroups.com - 22 updates in 2 topics

"Öö 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: