is C++ worth it ?

[Lynn McGuire]

Is C++ worth it ?
http://lemire.me/blog/archives/2012/07/23/is-cc-worth-it/

"But we are also moving away from low-level programming
and, yet, our software is still getting faster. I believe
that a major understated trend in the last decade or so
has been the increase in performance of the higher level
languages."

I disagree.

Lynn

 

[Cholo Lennon]

Is C++ worth it ?
http://lemire.me/blog/archives/2012/07/23/is-cc-worth-it/

"But we are also moving away from low-level programming
and, yet, our software is still getting faster. I believe
that a major understated trend in the last decade or so
has been the increase in performance of the higher level
languages."

I disagree.

I agree with one of the comments:

"Please stop posting misleading microbenchmarks like these. Your
methodology is not rigid and your benchmark is 3 lines of code. The
whole loop might be replaced with a nop if the array doesn’t escape."

Also the author doesn't have a good answer to it.

Internet is full of this type of biased / non scientific tests :-(

Best regards

 

[Chris Gordon-Smith]

Is C++ worth it ?
http://lemire.me/blog/archives/2012/07/23/is-cc-worth-it/

"But we are also moving away from low-level programming

I don't think of C++ as low level. I think of it as a language that
supports programming in terms of the concepts of the problem domain.
Oh, and yes, you can program in bits and bytes when needed.

Chris Gordon-Smith
www.simsoup.info

 

[Jorgen Grahn]

Is C++ worth it ?
http://lemire.me/blog/archives/2012/07/23/is-cc-worth-it/

"But we are also moving away from low-level programming
and, yet, our software is still getting faster. I believe
that a major understated trend in the last decade or so
has been the increase in performance of the higher level
languages."

I disagree.

It's a weird read, mostly because his implicit assumption is that Java
is a "higher level" language and C++ is not. What's so high about
Java -- garbage collection?

/Jorgen

 

[Juha Nieminen]

It's a weird read, mostly because his implicit assumption is that Java
is a "higher level" language and C++ is not. What's so high about
Java -- garbage collection?

There's a close almost 1-to-1 correspondence between C++ statements and
their equivalent assembler opcodes (with only a few exceptions, an
ironic example being, precisely, exceptions, which are not direct asm
constructs but are much higher concepts).

The correspondence between Java statements and asm opcodes is significantly
less straightforward. For example, one could hastily think that references
in Java are just asm memory addresses (like the references/pointers in C++),
but in fact they aren't. Java references are much more abstract than that.
(As an example of how abstract Java references are, they allow for automatic
behind-the-scenes memory compaction without the program even noticing. The
same is just impossible in C++ because references/pointers are literal
memory addresses, and memory compaction is basically impossible without
breaking the program.)

Also, the runtime environment where Java programs are run is (or at least
can be made to be) more akin go a virtualized environment than running the
program "raw". For example, if you made your own "Java compiler" that tried
to break some assertions made by the language specifications, the RTE can
catch it and refuse to run your program. (For example, if you tried to
make references that access illegal memory, or perform some other non-Java
weirdness such as pointer arithmetic, the RTE can catch such attempts and
stop the program before it wreaks havoc.)

As both hardware and compiler technology has advanced during the decades,
these security measures, including also such things as garbage collection,
cause less and less overhead to the actual execution times of the programs.

In C++ this would be much more difficult to implement and impose because
of the semantics of the language.

 

[Juha Nieminen]

I agree with one of the comments:

"Please stop posting misleading microbenchmarks like these. Your
methodology is not rigid and your benchmark is 3 lines of code. The
whole loop might be replaced with a nop if the array doesn???t escape."

I also agree. Comparing two languages with a two-line "benchmark" is
completely bollocks. It says absolutely nothing about anything.

When comparing languages for actual projects, there are many more important
questions than "which one can optimize a tight loop better?", such as:

- Does the language allow me to implement this project?
- How easily does it allow me to do that?
- How much effort is needed to implement the project, including writing the
actual implementation, and debugging it?
- What libraries and ready-made utilities does the language offer? How easy
are they to use?
- How safe is the language? How likely is it for a hidden bug to be uncaught
in testing, get to a release version, and then causing severe harm to the
user's system?
- If the application requires efficiency, how efficient is the code generated
with the programming language?

All those question are highly subjective, and there's no way to objectively
and unambiguously "measure" them.

 

[Jorgen Grahn]

There's a close almost 1-to-1 correspondence between C++ statements and
their equivalent assembler opcodes

That definition of higher-level didn't come to mind. But yes, I
suppose that's what the author was thinking of.

I was thinking more of the mapping between code and my design, problem
domain and terminology -- the smaller the gap is there, the better.

/Jorgen

 

[Gerald Breuer]

C++ has a lot of unnecessary complexity, but it is both:
low-level as well as high-level.

 

[Seungbeom Kim]

There's a close almost 1-to-1 correspondence between C++ statements and
their equivalent assembler opcodes (with only a few exceptions, an
ironic example being, precisely, exceptions, which are not direct asm
constructs but are much higher concepts).

That surprises me when I recall that, even without exceptions, a benign-
looking plus operator or even an absence of a statement can emit dozens
of instructions, due to operator overloading and constructors/destructors.

 

[Juha Nieminen]

C++ has a lot of unnecessary complexity

Care to give some examples?

 

[Juha Nieminen]

That surprises me when I recall that, even without exceptions, a benign-
looking plus operator or even an absence of a statement can emit dozens
of instructions, due to operator overloading and constructors/destructors.

As I said, there are exceptions. C++ is definitely "higer-level" than C,
but it's still pretty "close to the metal". (And that's how we like it,
really.)

 

[Stuart]

Is C++ worth it ?

Sadly, the answer to this question is yes.

If you are working in the industry, there is hardly a way around C++.
First of all, most drivers are provided with a C interface, which makes
C++ a "natural" choice. Besides this, hardware independence is mostly a
minor issue since the hardware asset of a large company won't be changed
overnight to a different platform, and for GUI related stuff there are
still platform independent libraries out there.

Curiously, the answer won't be to use Java or C#, as they are supposed
to be more high-level languages. Those are good languages that can be
easily learned by the majority of programmers. Even after 12 years as
C++ programming, and delving into some more obscure parts of template
programming, not even I would consider myself an expert on C++ (I think
Victor is one, and James).

Probably the flat learning curve that is what makes Java and C# so
popular. What the software industry needs is a language that can be used
suffiently well by the average programmer. I know that this sounds
contemptuous, but I know a lot of small companies that employ
Quereinsteigers (didn't find a proper English word for it, there is
probably none). Those companies have to make do with the "human
resources" they could get, so they want their programmers to struggle
with the problem domain and not with the programming language.


Setting the "human" factor aside, when we want to talk about programming
languages we have to consider several points:
(1) is the actual language better,
(2) are the available compilers/debuggers/whatever tools better, and
(3) are the available libraries better?

I think that C++ beats Java in point (1), but is inferior with regard to
point (3). Point (2) is maybe a draw. Since the decision for either Java
or C++ must always be based on all three points, it'll always be quite
difficult to decide. And most often it are some very minor points that
let the programmer tend to one or the other language.

For example, I start to tend to favour Java over C++ because whenever I
make some grave mistake and get a Memory Access Violation, this is more
or less the end of the world for a C++ application. Java, in contrast,
nicely captures this and gives me an exception. This not only makes me
able to shut down gracefully, but also provides me with enough error
information about where I went wrong (there is no standard way under C++
to retrieve the stacktrace of an exception). I don't understand why such
a feature is not important enough to make it into the C++ standard,
while such gimmicks like lambdas and whatnot get huge attention.
Happily, I can now finish with the only answer for the whole topic:

Everyone can chose the programming language that meets his needs best.

Regards,
Stuart

 

[Jorgen Grahn]

[...] And most often it are some very minor points that
let the programmer tend to one or the other language.

For example, I start to tend to favour Java over C++ because whenever I
make some grave mistake and get a Memory Access Violation, this is more
or less the end of the world for a C++ application. Java, in contrast,
nicely captures this and gives me an exception. This not only makes me
able to shut down gracefully, but also provides me with enough error
information about where I went wrong (there is no standard way under C++
to retrieve the stacktrace of an exception). I don't understand why such
a feature is not important enough to make it into the C++ standard,
while such gimmicks like lambdas and whatnot get huge attention.

Java is more than a language: it's an environment and a lifestyle.
That's why it can specify such things, but that's also a reason Java
unsuitable in my environments!

In those environments (Linux-based) uncaught C++ exceptions give
excellent diagnostics. But you cannot standardize that.

/Jorgen

 

[Stuart]

Am 7/30/12 2:42 PM, schrieb Jorgen Grahn:

[...] And most often it are some very minor points that
let the programmer tend to one or the other language.

For example, I start to tend to favour Java over C++ because whenever I
make some grave mistake and get a Memory Access Violation, this is more
or less the end of the world for a C++ application. Java, in contrast,
nicely captures this and gives me an exception. This not only makes me
able to shut down gracefully, but also provides me with enough error
information about where I went wrong (there is no standard way under C++
to retrieve the stacktrace of an exception). I don't understand why such
a feature is not important enough to make it into the C++ standard,
while such gimmicks like lambdas and whatnot get huge attention.

Java is more than a language: it's an environment and a lifestyle.
That's why it can specify such things, but that's also a reason Java
unsuitable in my environments!

In those environments (Linux-based) uncaught C++ exceptions give
excellent diagnostics. But you cannot standardize that.

Um, can you try to explain that to me. Beware, I only majored
theoretical computer science, so I might not understand everything you
say ;-) It is probably not because the design of C++ inherently forbids
such a feature, as there are solutions for various platforms.

I think that this a rather important feature of a language. It is of
little use that the C++ standard says that we will get UB once we
dereference a pointer that points to unallocated memory. Erring is
human, so as long as the language allows me to fail, it would be nice if
it could provide me with some decent information about at which point
the error occurred. Just like the MS compilers do.

I know that some people would say that there are platforms where this is
not possible. So I would be content with a standardization of a subset
of platforms where stacktraces of exceptions or caught Access Violations
are possible. Maybe the standardization of C++ should not stick to the
smallest possible denominator.

Thanks in advance,
Stuart

 

[Jorgen Grahn]

Am 7/30/12 2:42 PM, schrieb Jorgen Grahn:

[...] And most often it are some very minor points that
let the programmer tend to one or the other language.

For example, I start to tend to favour Java over C++ because whenever I
make some grave mistake and get a Memory Access Violation, this is more
or less the end of the world for a C++ application. Java, in contrast,
nicely captures this and gives me an exception. This not only makes me
able to shut down gracefully, but also provides me with enough error
information about where I went wrong (there is no standard way under C++
to retrieve the stacktrace of an exception). I don't understand why such
a feature is not important enough to make it into the C++ standard,
while such gimmicks like lambdas and whatnot get huge attention.

Java is more than a language: it's an environment and a lifestyle.
That's why it can specify such things, but that's also a reason Java
unsuitable in my environments!

In those environments (Linux-based) uncaught C++ exceptions give
excellent diagnostics. But you cannot standardize that.

Um, can you try to explain that to me.

Well, technically I guess you *can* standardize, but as I understand
it the committee has traditionally chosen not to intervene in such
things. The closest I can think of is that if your code is
sufficiently broken, the compiler must tell you.

And of course, a compiler can ignore the standard, like almost all did
with 'export'. Stroustrup won't sue you.

... it would be nice if
it could provide me with some decent information about at which point
the error occurred. Just like the MS compilers do.

Wait a minute -- you say the MS compiler works as you want; I say gcc
does on Linux ... where *do* you see the problem?

/Jorgen

 

[Stuart]

Wait a minute -- you say the MS compiler works as you want; I say gcc
does on Linux ... where *do* you see the problem?

I thought gcc did not turn Access Violations into exceptions. AFAIK,
this is a unique feature of the MS compilers. However, I would very much
like to be proven wrong.

And to come back to backtraces in exceptions: Why not standardize it
"optionally", so that if the platform provides this feature, it can be
used in a standard way?

Thanks,
Stuart

PS: Of course my list of C++ gurus was not exhaustive. Of course, you
are on it, too, as well as Igor Tandetnik. Unfortunately he is no longer
to be seen on usenet, he's probably off to the MS web-based forums.
That's a pity.

 

[Jorgen Grahn]

I thought gcc did not turn Access Violations into exceptions.

Ok, I didn't notice the switch in subject. As far as I know gcc
doesn't do this -- on Unix the program is pretty much dead if a
segmentation fault happens.

....

PS: Of course my list of C++ gurus was not exhaustive. Of course, you
are on it,

I'm flattered but sorry, I'm not. I'm sometimes vocal here and I *do*
think I can use C++ effectively most of the time, but I'm not an
expert. There are large chunks of the language I've never used and
probably never will use.

/Jorgen

 

[Bo Persson]

Seungbeom Kim skrev 2012-07-28 20:59:

That surprises me when I recall that, even without exceptions, a benign-
looking plus operator or even an absence of a statement can emit dozens
of instructions, due to operator overloading and constructors/destructors.

You mean unlike other languages, where an innocent looking function f(x)
can call other functions 10 levels deep?


Bo Persson

 

[Bo Persson]

Stuart skrev 2012-07-30 19:32:

Am 7/30/12 2:42 PM, schrieb Jorgen Grahn:

[...] And most often it are some very minor points that
let the programmer tend to one or the other language.

For example, I start to tend to favour Java over C++ because whenever I
make some grave mistake and get a Memory Access Violation, this is more
or less the end of the world for a C++ application. Java, in contrast,
nicely captures this and gives me an exception. This not only makes me
able to shut down gracefully, but also provides me with enough error
information about where I went wrong (there is no standard way under C++
to retrieve the stacktrace of an exception). I don't understand why such
a feature is not important enough to make it into the C++ standard,
while such gimmicks like lambdas and whatnot get huge attention.

The language standard cannot require a stacktrace without first
requiring that ALL implementations must use a stack. That would be
limiting, and exclude some of the platforms that were available when the
first C and C++ standards were written. ISO standards strive for a
consensus, which is hard if some manufacturers are excluded.

Java doesn't have this problem as it only runs on one platform, the JVM.
All JVMs have to do the same thing, even if the underlying platform does
not.

I think that this a rather important feature of a language. It is of
little use that the C++ standard says that we will get UB once we
dereference a pointer that points to unallocated memory. Erring is
human, so as long as the language allows me to fail, it would be nice if
it could provide me with some decent information about at which point
the error occurred. Just like the MS compilers do.

The Java VM requires that access violations are caught. The C++ standard
allows it, but also allows programs to run on systems without hardware
memory management. On those systems it is perhaps unacceptably expensive
to detect a violation. So the language allows it to fail instead.

I know that some people would say that there are platforms where this is
not possible. So I would be content with a standardization of a subset
of platforms where stacktraces of exceptions or caught Access Violations
are possible. Maybe the standardization of C++ should not stick to the
smallest possible denominator.

The standard committee members have been VERY reluctant to standardize
functionality that not all of them can implement. How good is it to be
almost standard C++?

It is also possible to standardize this outside of the language, like
POSIX does for some other things.


Bo Persson

 

[James Kanze]

On 7/30/12 Jorgen Grahn wrote:

I thought gcc did not turn Access Violations into exceptions.
AFAIK, this is a unique feature of the MS compilers. However,
I would very much like to be proven wrong.

This error is unique to MS compilers I think (and I think it's
optional there). With g++ under Linux (and all other Unix
compilers, I think), and access violation results in a core
dump, which is far preferrable for most applications.

And to come back to backtraces in exceptions: Why not
standardize it "optionally", so that if the platform provides
this feature, it can be used in a standard way?

The reason C++ doesn't have backtraces in exceptions is that
that's not what exceptions are for. Exceptions are designed to
be caught, so any backtrace would be ignored. If you have a
programming error, you want to stop immediately (in most
applications, anyway). Violently, and with a backtrace. In the
core file, or its equivalent---your client can't do anything
with a backtrace, but he can send you a core dump, so that you
can do something. (And of course, if the core dump isn't in
your test cases, you're not testing sufficiently.)