Re: The effectiveness of C++14

[Melzzzzz]

On 1 Jan 2015 21:18:43 GMT
r...@zedat.fu-berlin.de (Stefan Ram) wrote:

> In 2014, C++14 was »ratified« or »adopted«. But it seems not to
> have been published by the ISO yet. So, is it in effect or not?
>
> Many ISO norms contain wordings like »This specification cancels
> and replaces ...«. So, when C++14 is in effect, it cancels and
> replaces C++11, and the meaning of the unqualified name »C++«
> is »C++14«, according to the ISO.
>
> When the norm is »ratified« or »adopted«, but not yet published,
> I assume that it is not yet in effect. So, »C++« still is »C++11«?
>

C++ is still C++98...
By the time C++98 compilers go out of usage I will be retired...

[Richard]

[Please do not mail me a copy of your followup]

Melzzzzz <m...@zzzzz.com> spake the secret code
<20150101230912.7f8d0dfd@maxa-pc> thusly:

>By the time C++98 compilers go out of usage I will be retired...

If you are still using a C++98 compiler at this point, you have noone
to blame but yourself. C++11 compilers are widely and easily available
and C++14 is mostly implemented by the major tool chains.

<http://clang.llvm.org/cxx_status.html>
<https://gcc.gnu.org/projects/cxx1y.html>
<http://blogs.msdn.com/b/vcblog/archive/2014/11/17/c-11-14-17-features-in-vs-2015-preview.aspx>
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

[Scott Lurndal]

legaliz...@mail.xmission.com (Richard) writes:
>[Please do not mail me a copy of your followup]
>
>Melzzzzz <m...@zzzzz.com> spake the secret code
><20150101230912.7f8d0dfd@maxa-pc> thusly:
>
>>By the time C++98 compilers go out of usage I will be retired...
>
>If you are still using a C++98 compiler at this point, you have noone
>to blame but yourself. C++11 compilers are widely and easily available
>and C++14 is mostly implemented by the major tool chains.

One doesn't always have the choice. Just because a compiler is available
doesn't mean that it has been qualified for use in a particular project.

[Richard]

[Please do not mail me a copy of your followup]

sl...@pacbell.net spake the secret code
<iWxqw.1082954$Rp.8...@fx23.iad> thusly:

I'm going to disagree and say that you always have a choice, but that
you have chosen to stick with a C++98 compiler. I know people who
have chosen to stick with VC6, for instance. For whatever reason they
hated the new IDE, but the consequence of that choice is being stuck
with a really ancient version of Microsoft's compiler at this point.

If you target enterprise linux, then the default compiler is an
ancient version of gcc. That doesn't mean you're stuck with that.
There are many ways to get around that problem. If quality of
implementation is the issue, then you're almost certainly going to get
a better implementation with a newer compiler than sticking with a
really ancient one.

[Scott Lurndal]

legaliz...@mail.xmission.com (Richard) writes:
>[Please do not mail me a copy of your followup]
>
>sl...@pacbell.net spake the secret code
><iWxqw.1082954$Rp.8...@fx23.iad> thusly:
>
>>legaliz...@mail.xmission.com (Richard) writes:
>>>[Please do not mail me a copy of your followup]
>>>
>>>Melzzzzz <m...@zzzzz.com> spake the secret code
>>><20150101230912.7f8d0dfd@maxa-pc> thusly:
>>>
>>>>By the time C++98 compilers go out of usage I will be retired...
>>>
>>>If you are still using a C++98 compiler at this point, you have noone
>>>to blame but yourself. C++11 compilers are widely and easily available
>>>and C++14 is mostly implemented by the major tool chains.
>>
>>One doesn't always have the choice. Just because a compiler is available
>>doesn't mean that it has been qualified for use in a particular project.
>
>I'm going to disagree and say that you always have a choice, but that
>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
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).

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.

The code works. The compilers compile. The programmers get paid.
Everyone is happy except for those who think C++14 is better than
sliced bread. pthreads work with any C++ compiler.

[Jorgen Grahn]

On Mon, 2015-01-05, Richard wrote:
...

> If you target enterprise linux, then the default compiler is an
> ancient version of gcc. That doesn't mean you're stuck with that.

It's note even that bad. The stable distribution of Debian is
infamous for containing old software, but its gcc is 4.7 -- not the
best C++11 coverage you can get, but very decent subset.

> There are many ways to get around that problem. If quality of
> implementation is the issue, then you're almost certainly going to get
> a better implementation with a newer compiler than sticking with a
> really ancient one.

Yes, unless you're trying the very latest snapshot from the gcc people
or something.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Richard]

[Please do not mail me a copy of your followup]

sl...@pacbell.net spake the secret code

<hFzqw.173219$pr4....@fx26.iad> thusly:

>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.

[Richard]

[Please do not mail me a copy of your followup]

Jorgen Grahn <grahn...@snipabacken.se> spake the secret code
<slrnmalirb.4...@frailea.sa.invalid> thusly:

>> There are many ways to get around that problem. If quality of
>> implementation is the issue, then you're almost certainly going to get
>> a better implementation with a newer compiler than sticking with a
>> really ancient one.
>
>Yes, unless you're trying the very latest snapshot from the gcc people
>or something.

Yeah, snapshots are outside the scope of what I'm talking about here
-- I'm referring to released, stable, versions of tools, not nightly
builds from a development branch.

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. (Xcode's
clang might edge out VS, depending on the version we're using, I'm not
sure.)

[Jorgen Grahn]

On Mon, 2015-01-05, Scott Lurndal wrote:

> legaliz...@mail.xmission.com (Richard) writes:
>>sl...@pacbell.net spake the secret code
>><iWxqw.1082954$Rp.8...@fx23.iad> thusly:

...

>>>One doesn't always have the choice. Just because a compiler is available
>>>doesn't mean that it has been qualified for use in a particular project.
>>
>>I'm going to disagree and say that you always have a choice, but that
>>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?

[Scott Lurndal]

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]

On Mon, 2015-01-05, Scott Lurndal wrote:
> Jorgen Grahn <grahn...@snipabacken.se> writes:
>>On Mon, 2015-01-05, Scott Lurndal wrote:
>>> legaliz...@mail.xmission.com (Richard) writes:
>>>>sl...@pacbell.net spake the secret code
>>>><iWxqw.1082954$Rp.8...@fx23.iad> thusly:
>>...
>>
>>>>>One doesn't always have the choice. Just because a compiler is available
>>>>>doesn't mean that it has been qualified for use in a particular project.
>>>>
>>>>I'm going to disagree and say that you always have a choice, but that
>>>>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?
>>
>
> 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?

[Öö Tiib]

On Monday, January 5, 2015 11:08:05 PM UTC+2, Scott Lurndal wrote:
> Jorgen Grahn <grahn...@snipabacken.se> writes:
> >On Mon, 2015-01-05, Scott Lurndal wrote:
> >> legaliz...@mail.xmission.com (Richard) writes:
> >>>sl...@pacbell.net spake the secret code
> >>><iWxqw.1082954$Rp.8...@fx23.iad> thusly:
> >...
> >
> >>>>One doesn't always have the choice. Just because a compiler is available
> >>>>doesn't mean that it has been qualified for use in a particular project.
> >>>
> >>>I'm going to disagree and say that you always have a choice, but that
> >>>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?
>
> 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.

> 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.

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]

On Mon, 5 Jan 2015 17:51:01 +0000 (UTC),
legaliz...@mail.xmission.com (Richard) wrote:

>[Please do not mail me a copy of your followup]
>
>sl...@pacbell.net spake the secret code
><hFzqw.173219$pr4....@fx26.iad> thusly:
>
>>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]

On Tuesday, January 6, 2015 8:27:16 AM UTC+2, Louis Krupp wrote:
> On Mon, 5 Jan 2015 17:51:01 +0000 (UTC),
> legaliz...@mail.xmission.com (Richard) wrote:
>
> >[Please do not mail me a copy of your followup]
> >
> >sl...@pacbell.net spake the secret code
> ><hFzqw.173219$pr4....@fx26.iad> thusly:
> >
> >>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.

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.

> 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?

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. ;)

> 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.

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]

legaliz...@mail.xmission.com (Richard) wrote in news:m8ej1p$qb5$2
@news.xmission.com:

> 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 Lurndal]

from a typical project makefile:

PHONY: cppcheck
cppcheck:
${CPPCHECK} *.cpp

[Scott Lurndal]

r...@zedat.fu-berlin.de (Stefan Ram) writes:

>Louis Krupp <lkr...@nospam.pssw.com.invalid> writes:
>>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.

That's useless. You should teach them so they can get jobs
today, not next century.

tschuss

[Louis Krupp]

On Mon, 5 Jan 2015 23:11:04 -0800 (PST), 嘱 Tiib <oot...@hot.ee>
wrote:

>On Tuesday, January 6, 2015 8:27:16 AM UTC+2, Louis Krupp wrote:
>> On Mon, 5 Jan 2015 17:51:01 +0000 (UTC),
>> legaliz...@mail.xmission.com (Richard) wrote:
>>
>> >[Please do not mail me a copy of your followup]
>> >
>> >sl...@pacbell.net spake the secret code
>> ><hFzqw.173219$pr4....@fx26.iad> thusly:
>> >
>> >>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.
>
>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.

"Conservative" doesn't necessarily mean stagnant. Things get
upgraded, but not as fast as some might like.

>
>> 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?
>
>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. ;)

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.

>
>> 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.
>
>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]

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]

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]

On Wed, 07 Jan 2015 07:58:47 +1300, Ian Collins <ian-...@hotmail.com>
wrote:

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]

On Tue, 2015-01-06, 嘱 Tiib wrote:
> On Tuesday, January 6, 2015 8:27:16 AM UTC+2, Louis Krupp wrote:

...

>> 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?
>
> 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. ;)

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.

[Louis Krupp]

On Tue, 06 Jan 2015 17:19:27 GMT, sc...@slp53.sl.home (Scott Lurndal)
wrote:

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]

On Tuesday, January 6, 2015 7:47:11 PM UTC+2, Louis Krupp wrote:
> On Mon, 5 Jan 2015 23:11:04 -0800 (PST), 嘱 Tiib <oot...@hot.ee>
> wrote:
>
> >On Tuesday, January 6, 2015 8:27:16 AM UTC+2, Louis Krupp wrote:
> >> On Mon, 5 Jan 2015 17:51:01 +0000 (UTC),
> >> legaliz...@mail.xmission.com (Richard) wrote:
> >>
> >> >[Please do not mail me a copy of your followup]
> >> >
> >> >sl...@pacbell.net spake the secret code
> >> ><hFzqw.173219$pr4....@fx26.iad> thusly:
> >> >
> >> >>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.
> >
> >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.
>
> "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.

> >> 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?
> >
> >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. ;)
>
> 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.

> >
> >> 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.
> >
> >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?

28 years.

> 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...

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]

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 Lurndal]

=?ISO-8859-1?Q?=D6=F6_Tiib?= <oot...@hot.ee> writes:
>On Tuesday, January 6, 2015 7:47:11 PM UTC+2, Louis Krupp wrote:

>> On Mon, 5 Jan 2015 23:11:04 -0800 (PST), =E5=98=B1 Tiib <oot...@hot.ee>
>> wrote:

>> >You can milk money for decade and half from frozen product but one day

>> >the milking itself becomes too expensive.=20
>>=20

>> "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.

>
>> 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...
>
>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=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]

On 05/01/2015 17:15, Scott Lurndal wrote:
> 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
> 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]

39 years? That explains your intransigent stubbornness then. Old dog
new tricks innit.

/Flibble

[Ian Collins]

Scott Lurndal wrote:
> =?ISO-8859-1?Q?=D6=F6_Tiib?= <oot...@hot.ee> writes:
>> On Tuesday, January 6, 2015 7:47:11 PM UTC+2, Louis Krupp wrote:
>>> On Mon, 5 Jan 2015 23:11:04 -0800 (PST), =E5=98=B1 Tiib <oot...@hot.ee>
>>> wrote:
>
>>>> You can milk money for decade and half from frozen product but one day
>>>> the milking itself becomes too expensive.=20
>>> =20
>>> "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.

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.

>> 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?

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.

> 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.

Nor should you, but there's nothing wrong with adopting modern
techniques for new code.

--
Ian Collins

[Öö Tiib]

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.

[Öö Tiib]

On Tuesday, January 6, 2015 11:28:25 PM UTC+2, Scott Lurndal wrote:
> =?ISO-8859-1?Q?=D6=F6_Tiib?= <oot...@hot.ee> writes:
> >On Tuesday, January 6, 2015 7:47:11 PM UTC+2, Louis Krupp wrote:
> >> On Mon, 5 Jan 2015 23:11:04 -0800 (PST), =E5=98=B1 Tiib <oot...@hot.ee>
> >> wrote:
>
> >> >You can milk money for decade and half from frozen product but one day
> >> >the milking itself becomes too expensive.=20
> >>=20
> >> "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.

4.4 has decent amount of c++11 support.

> 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.

For example the C++98 tricks to achieve the move semantics were rather
complex.
See that: http://en.wikibooks.org/wiki/More_C++_Idioms/Move_Constructor
And that: http://en.wikibooks.org/wiki/More_C++_Idioms/Temporary_Base_Class
It indeed does work once made and tested but I don't see why someone
should do something like that instead of using C++11 move semantics
in *new* code. Just for sake of "Stick to C++98"?

> >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?

Why can not old module written in C-with-classes live well together with
new module written in C++11? I merely suggest to take the new features
and idioms into use in new code written.

> 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.

Yes. Whatever changes, (including outright bug-fixes) do cause new defects
as rule. I do not suggest to make changes just for sake of changing.

[Scott Lurndal]

Actually, "old dog" and "experience" are probably closer. I've no
problem using learning new tricks when necessary. Change for the
sake of change isn't a new trick, just a waste of time.

(started programming at 14 on a B5500, so not so old, either :-).

[Bo Persson]

On 2015-01-08 02:44, Stefan Ram wrote:

> Ian Collins <ian-...@hotmail.com> writes:
>> 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.
>

> I just read that Google switched from their (custom) gcc 4.8
> to Clang to compile Chrome for Linux. One of the reasons
> given was that this was the simplest way to get »modern C++
> features«. I am sure that friends of gcc might dispute whether
> Clang has better support for modern C++, but this shows that
> Google cares to use modern C++.
>

One major difference is that Clang 3.5 is released, while gcc 5.0 is not.


Bo Persson

[woodb...@gmail.com]

I think it would be interesting to know if the idea for the
switch was from people working on Chrome or Clang. It may
have just been a nuisance the Chrome people couldn't fend off.

Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net

[Melzzzzz]

clang develops pretty fast, it is big competition to gcc, but gcc
has better optimizer last time I checked.
[bmaxa@maxa-pc sci]$ g++-trunk -Wall -Ofast -march=native *.c -o scimath2gcc -lm
[bmaxa@maxa-pc sci]$ ./scimath2gcc
** **
** SciMark2 Numeric Benchmark, see http://math.nist.gov/scimark **
** for details. (Results can be submitted to po...@nist.gov) **
** **
Using 2.00 seconds min time per kenel.
Composite Score: 2290.40
FFT Mflops: 2139.58 (N=1024)
SOR Mflops: 2442.17 (100 x 100)
MonteCarlo: Mflops: 672.62
Sparse matmult Mflops: 2175.19 (N=1000, nz=5000)
LU Mflops: 4022.46 (M=100, N=100)
[bmaxa@maxa-pc sci]$ clang -Wall -Ofast -march=native *.c -o scimath2clang -lm
[bmaxa@maxa-pc sci]$ ./scimath2clang
** **
** SciMark2 Numeric Benchmark, see http://math.nist.gov/scimark **
** for details. (Results can be submitted to po...@nist.gov) **
** **
Using 2.00 seconds min time per kenel.
Composite Score: 2679.03
FFT Mflops: 1811.36 (N=1024)
SOR Mflops: 2425.46 (100 x 100)
MonteCarlo: Mflops: 649.38
Sparse matmult Mflops: 1624.94 (N=1000, nz=5000)
LU Mflops: 6884.02 (M=100, N=100)

g++ 5.0 has regression in comparison to 4.9...

>
>
> Bo Persson
>

[Chris Vine]

On 8 Jan 2015 01:44:09 GMT

r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> Ian Collins <ian-...@hotmail.com> writes:

> >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.
>

> I just read that Google switched from their (custom) gcc 4.8
> to Clang to compile Chrome for Linux. One of the reasons
> given was that this was the simplest way to get »modern C++
> features«. I am sure that friends of gcc might dispute whether
> Clang has better support for modern C++, but this shows that
> Google cares to use modern C++.

Big deal. Google are significantly involved in (that is, employ some of
the developers of) llvm and clang. Presumably they have some commercial
interest in getting a greater stake in one particular compiler chain.
That may, or may not, be connected with the fact that gcc is GPL (with
exception for compiled code) whereas llvm is not. gcc and clang are
more or less equivalent in C++11/14 support.

Google's code doesn't even use exceptions let alone "modern C++".

Chris

[Bo Persson]

On 2015-01-08 19:46, Melzzzzz wrote:
> On Thu, 08 Jan 2015 17:36:37 +0100
> Bo Persson <b...@gmb.dk> wrote:
>
>> On 2015-01-08 02:44, Stefan Ram wrote:
>>> Ian Collins <ian-...@hotmail.com> writes:
>>>> 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.
>>>
>>> I just read that Google switched from their (custom) gcc 4.8
>>> to Clang to compile Chrome for Linux. One of the reasons
>>> given was that this was the simplest way to get »modern C++
>>> features«. I am sure that friends of gcc might dispute whether
>>> Clang has better support for modern C++, but this shows that
>>> Google cares to use modern C++.
>>>
>>
>> One major difference is that Clang 3.5 is released, while gcc 5.0 is
>> not.
>
> clang develops pretty fast, it is big competition to gcc, but gcc
> has better optimizer last time I checked.

The thing here was that both of them claim to support the full C++14
language. One already being released, and the other one available "real
soon now".



Bo Persson

[Chris Vine]

On 8 Jan 2015 23:55:21 GMT
r...@zedat.fu-berlin.de (Stefan Ram) wrote:

> Bo Persson <b...@gmb.dk> writes:
> >The thing here was that both of them claim to support the full C++14
> >language. One already being released, and the other one available
> >"real soon now".
>

> The last time I looked was about 9 months ago with - IIRC - GCC 4.8.
>
> There were two things I wanted to show in the classroom.
>
> The first was wished by the students, they wanted to learn
> about threads. IIRC, the C++11 thread library was not yet
> available with GCC 4.8.

You recall incorrectly. gcc-4.8 supports C++11 threads, including the
C++11 memory model. Most of C++11 threads, but not the full memory
model, was available from gcc-4.5.

> The other thing was something that I wanted to show to the
> students: regular expressions. But that was also not available.
>
> Maybe GCC 4.8 supported the C++11 syntax, but not the libraries.

gcc-4.8 did not properly implement regular expressions: it was its
major fail. gcc-4.9 does support them.

> Or maybe I should have tried to use GCC 4.9? But GCC 4.8 was
> easily available to me, while I was not sure how to install GCC 4.9
> under Windows.

Are you surer about how to install clang-3.5 than gcc-4.9? What's your
point?

Chris

[Chris Vine]

On Fri, 09 Jan 2015 00:03:55 +0100

gcc releases new branches at approximately annual intervals. The *.0
release is usually in March or April. As far as I understand it, that
is what is intended with gcc-4.10/gcc-5.0/whatever.

gcc does not claim to fully support C++14 in any of its current
releases. Nor have I seen the expression "real soon now" used in
respect of such support: the published schedule does not use that
expression. Care to provide a URL which does?

Chris

[Öö Tiib]

Perhaps the news on front page can be interpreted like that?
https://gcc.gnu.org/index.html#news :
"GCC 5 C++14 language feature-complete [2014-12-23]
Support for all C++14 language features has been added to the
development sources for GCC, and will be available when GCC 5
is released next year. Contributed by Jason Merrill, Braden
Obrzut, Adam Butcher, Edward Smith-Rowland, and Jakub Jelinek."

[Chris Vine]

On Thu, 8 Jan 2015 23:08:02 -0800 (PST)
Öö Tiib <oot...@hot.ee> wrote:
> On Friday, January 9, 2015 at 2:49:32 AM UTC+2, Chris Vine wrote:

[snip]

> > gcc releases new branches at approximately annual intervals. The
> > *.0 release is usually in March or April. As far as I understand
> > it, that is what is intended with gcc-4.10/gcc-5.0/whatever.
> >
> > gcc does not claim to fully support C++14 in any of its current
> > releases. Nor have I seen the expression "real soon now" used in
> > respect of such support: the published schedule does not use that
> > expression. Care to provide a URL which does?
>
> Perhaps the news on front page can be interpreted like that?
> https://gcc.gnu.org/index.html#news :
> "GCC 5 C++14 language feature-complete [2014-12-23]
> Support for all C++14 language features has been added to the
> development sources for GCC, and will be available when GCC 5
> is released next year. Contributed by Jason Merrill, Braden
> Obrzut, Adam Butcher, Edward Smith-Rowland, and Jakub Jelinek."

Right. The problem with "real soon now" is that it is usually intended
perjoratively, implying vapourware or something running seriously
behind schedule. gcc-4.10/5.0 is neither of those. It is following the
normal gcc release cycle, apparently.

google did not choose clang over gcc for its future chrome releases
because it got its full C++14 feature set out 6 months earlier than
gcc, any more than it used gcc (gcc-4.6) beforehand because gcc got most
of its C++11 features out first. clang offers other advantages -
particularly the llvm toolset and better error messages. And, whilst
apple is the main contributor to clang, google also contributes
significantly, which means that it can tailor it more to its needs. The
clang C++ implementation is also a lot less buggy than it used to be.

Chris

[David Brown]

Just a comment for balance - google also contributes significantly to
gcc, and gcc's error messages have improved greatly in the past few
versions (arguably dues to "competition" with clang).

In most comparisons I have seen, gcc results in faster code than clang,
while clang compiles and links a lot faster. I suspect that google
continuously use both compilers, and make sure their code base is fully
compatible with both. At the moment, it looks like clang gives a
smaller and/or faster binary for chrome - but it could easily change in
the future.

[Chris Vine]

On Fri, 09 Jan 2015 11:08:04 +0100
David Brown <david...@hesbynett.no> wrote:
[snip]

> Just a comment for balance - google also contributes significantly to
> gcc, and gcc's error messages have improved greatly in the past few
> versions (arguably dues to "competition" with clang).
>
> In most comparisons I have seen, gcc results in faster code than
> clang, while clang compiles and links a lot faster. I suspect that
> google continuously use both compilers, and make sure their code base
> is fully compatible with both. At the moment, it looks like clang
> gives a smaller and/or faster binary for chrome - but it could easily
> change in the future.

I think that's fair.

It is also worth noting that the switch to clang is only for making
chrome's pre-compiled binaries for linux. Chrome for android still uses
gcc, and for windows still uses visual studio. Looking at their own
blurb, it looks as if they decided they wanted to update their
compilers on the android and linux side to either gcc-4.8/4.9 (which
they have done for android) or clang-3.5, and they chose clang for
their linux binaries. One of the reasons for this appears to be
because with clang it is easier to integrate the binaries with the
system libraries, and in particular the older libstdc++ versions, which
may be used by linux distributions. In other words, they seem to be
using C++11/14 at the language level but not at the standard library
level except by bundling their own components, and that is easier to do
with clang. And chrome still apparently compiles with gcc-4.8/4.9, if
that is what individual distributions want to do.

Chris

[Öö Tiib]

On Friday, 9 January 2015 14:13:54 UTC+2, Stefan Ram wrote:

> Öö Tiib <oot...@hot.ee> writes:
> >"GCC 5 C++14 language feature-complete [2014-12-23]
>

> Back to my OP: This might mean that GCC is feature-complete
> /before/ the standard is actually published! When one takes
> the standpoint that the standard does not exist as long as
> it's not published as a standard by the ISO, one might
> wonder what language they actually refer to. I mean:
> People can get the /implementation/, but can't buy the
> /specification/ of that language called »C++14«!

It is not yet approved as ready standard but it has been good enough
to implement the changes and improvements in it. Should the compiler
and library implementers wait until standard is fully ready?
No by modern agile development. Yes by waterfall.

Standard is specification for compiler and library implementers.
Like all specifications written by non-gods it contains some unclear
wording, ambiguities and other issues. A draft of it was approved
two years ago as draft. What has been done later is fixes.

> But then, they say »language feature-complete«,
> not »library feature-complete«!


The libstdc++ status:
https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.2014

The libc++ status:
http://libcxx.llvm.org/cxx1y_status.html

[woodb...@gmail.com]

On Saturday, February 14, 2015 at 11:10:06 PM UTC-6, Stefan Ram wrote:
> r...@zedat.fu-berlin.de (Stefan Ram) writes:
> >In 2014, C++14 was »ratified« or »adopted«. But it seems not to
> >have been published by the ISO yet. So, is it in effect or not?
>
> In the meantime, ISO/IEC 14882:2014 has been published, and
> the publication date now is given as 2014-12-15 if I recall
> correctly. But this information was not yet visible on the
> ISO page as of 2015-01-01, and possibly even later, as far
> as I remember. So, the publication date might have been
> »backdated« to be in accordance with the name »ISO/IEC 14882:2014«.

Nice catch. Sounds like Brian Williams joined the committee.

Brian
Ebenezer Enterprises
http://webEbenezer.net

[Richard]

[Please do not mail me a copy of your followup]

r...@zedat.fu-berlin.de (Stefan Ram) spake the secret code
<ISO-20150...@ram.dialup.fu-berlin.de> thusly:

> So, the publication date might have been

> backdated to be in accordance with the name ISO/IEC 14882:2014.

I find it more believable that an international standards body
bureaucracy is sluggish to update its web site.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>