Why C++ is vastly superior to C

[MikeP]

http://www.tiobe.com/content/paperinfo/tpci/images/tpci_trends.png

, C++ has lost half of its »market share« in relation to C
since 2003.

Surely because of C#. Where Java couldn't really dent C++, C# (combined
with .Net) is coming on strong. (I find C# rather useless though because
programs written in it can be so easily reverse-engineered". Download
Reflector and the details of the code in all its glory are revealed).

 

[MikeP]

On 05/17/11 10:58 AM, Stefan Ram wrote:

No, they don't. They may have to if they are supporting legacy code
that uses every feature under the sun (which tends to be written by
novices keen to use them!). For new projects, they can choose a
subset they are happy with.

Not really. The idioms have evolved for very good reasons. Not knowing
how to write exception-safe code, for example, is indeed to not know how
to program in C++, for writing unreliable software is not really doing
much of anything but playing.

The complexity of any given problem is constant. Whether that
complexity is hidden in a language or exposed user code is a choice.
Most of the new features will remove complexity from user code.

Two things (there surely are more, and will be more, but just off the top
of my head) that I appreciate from the new features and have helped me
are:

1. 'auto': I now have for_each, yay!
2. That namespace-within-a-class-hierarchy-thing. Yay! No more virtual
derivation to get around the diamond inheritance problem.

 

[MikeP]

As an attempt at an objective evaluation, we can check sourceforge's
project trove and count the number of projects associated with a given
programmng language. We have:

Java 46,457 http://sourceforge.net/softwaremap/?&fq[]=trove:198
C++ 37,078 http://sourceforge.net/softwaremap/?&fq[]=trove:165
PHP 30,193 http://sourceforge.net/softwaremap/?&fq[]=trove:183
C 28,204 http://sourceforge.net/softwaremap/?&fq[]=trove:164
C# 13,593 http://sourceforge.net/softwaremap/?&fq[]=trove:271
Python 13,460 http://sourceforge.net/softwaremap/?&fq[]=trove:178
etc etc etc...

How many are new? How many are active? How many users? What are the
trends in the last year or 2? (All rhetorical questions). Your attempt at
objectivity seems rather lame.

 

[MikeP]

The beauty of C is the elegance of its simplicity. It is a very simple
language and can be learned in a day. Yet it allows one to build
complex
programs with optimal performance.

"beauty", "elegance" in the same sentence as "C" is surely oxymoronic.

The beauty of C++

Similarly, on "beauty and C++": "A face only a mother could love", for
sure. (I wouldn't go as far as to call it butt-ugly though).

The investment of learning C++
probably only pays of when you use it in mid to large scale software
projects, that also need its C style performance characteristics.

"probably" may be the key word in that sentence. I noted in another post
that I find C# defficient because of its ease-of-reverse-engineering
"flaw".

If
you happen to know C++ quite well, it is great for small programs
too

I had been using C# for the past few weeks and was going to actually
write a useful program in it, but in the end I wrote-off what I was doing
with it as an investigation into the language and am now back to writing
that same program in C++. So I'm one of those you mention in your
sentence above that will even do the "quick hacks" in C++ because I
already know it well.

 

[MikeP]

The simplicity of the language is measured by how complicated it is
to implement a given task with the language, not how long the the
language specification is. If that were the measurement, then
brainfuck would be much simpler than C. It certainly isn't.

It is neither. It is both and more. If a language is simple to implement,
i.e., write a compiler for, then that is indeed a measure of
"simplicity". Another equally valid (perhaps to a different group)
measure of simplicity is "simplicity of usage".

In the case of C, its "simplicity" actually becomes a limiting
factor, not a beneficial one. The language offers no tools that would
help writing simple programs. Even small tasks can become overly
complicated, especially if dynamic memory management and data
structures other than basic arrays are involved.

The assumption is though that after years of use, one's toolbox will be
chock-full of useful tools, idioms, etc. Indeed, I forego many of the C++
"built-in" offerings for ones that I craft myself. The focus on
large-scale development and million-line programs is way over-done. Using
the heavy-lifting equipment on small jobs is many times a burden.

 

[MikeP]

Actually, it says:


You won't notice the difference between C and C++ until you start
looking at non-trivial programs.

And I'll add that one won't notice until one starts thinking in terms of
higher-level abstraction(s) and not solely in terms of bits and bytes.
C++ will ween one away from the bits-n-bytes and on to bigger and better
things.

 

[MikeP]

[...] I would say that
the C++ automatic constructor/destructor paradigm (which was a C++
innovation as far as I know?) is also extremely valuable.

Innovation? Looks like a quite nice and convenient side-effect.

 

[MikeP]

http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf

Reference counted strings (or more generally flyweight patterns
of various kinds) are very useful tools. Just because they don't
interact well with a badly broken model of concurrency is not a
reason to abandon them entirely. You simply don't use said model
of concurrency (yes, believe it or not their are other superior,
for most uses, models) or don't use flyweights together with it.

Immutable strings and reference counting works out quite nicely, e.g.

 

[MikeP]

C does, however, have (early-) return, break/continue/goto, and
longjmp(). All of which create headaches for resource management,
i.e. either needing to add many nearly-identical copies of any
clean-up code or just foregoing the use of any of the above
mechanisms.

The basic OOP concepts of objects and classes (with virtual methods)
can be implemented easily enough in C (look at a C GUI toolkit such
as Xt or GTK), but RAII is the point at which you have to decide
whether to go to C++ or go without.

That seems like a juxtaposed statement, for it is C++ exceptions that
instigate the NEED for the RAII idiom. Without exceptions, RAII is merely
a convenience (still nice, but not important/necessary).

 

[MikeP]

Besides what others responded, I'll like to comment that I have not
previously heard the argument that "RAII is only needed because of
exceptions". (Ok, you are not exactly saying that, but it sounds like
it.)

RAII would certainly be exactly as useful even without exceptions. In
fact, in many compilers you can compile a C++ program without any
support for exceptions by using a compiler option (naturally it
requires that your code has no explicit throws). That wouldn't
diminish the importance of RAII in the least bit.

It indeed would diminish all of it's importance because the idiom becomes
just a convenience and not a necessity.

 

[MikeP]

Le 16/05/11 17:08, Lynn McGuire a écrit :

Of course C++ is vastly superior than C.

We are in comp.lang.c++. Nobody will say otherwise.

Your point being that people who live in houses with conveniences like
indoor plumbing and electricity simply don't understand how simple living
in caves is so much better? Even though most of these people used to be
cave-dwellers? ;-)

 

[Joshua Maurice]

The trade-off (there always is one) being Template Code Bloat (TCB).

I laughed when I saw your acronym. I assume that was just made up on
the spot.

The point is, C++ programmers can choose between "The C way"(tm) and
templates. C people are stuck with one side of the tradeoff. I don't
think you're disagreeing, but I'm just being contrarian to your
contrarian.

 

[Nobody]

That seems like a juxtaposed statement, for it is C++ exceptions that
instigate the NEED for the RAII idiom.

C exceptions (i.e. longjmp) also require it.

Without exceptions, RAII is merely a convenience (still nice, but not
important/necessary).

I suppose it depends upon whether legibility is important/necessary or
merely a convenience. The contortions required to get by without it can be
pretty ugly. Similarly, one could ask whether high-level languages are
important/necessary, or merely a convenience.

 

[Joshua Maurice]

That seems like a juxtaposed statement, for it is C++ exceptions that
instigate the NEED for the RAII idiom. Without exceptions, RAII is merely
a convenience (still nice, but not important/necessary).

That's a matter of opinion.

The first thing that Bjarne Stroustrup added to C to make C++ was
destructors, more or less. In his own words in this forum, it predated
all the other cool things, like templates, virtual, exceptions, by
years. I agree with Bjarne that the thing I miss the most when I'm
forced to do C, or maintain C-like C++ code, is destructors.

The utility of destructors is not mere syntactic sugar like a ranged-
based for loop ala Java and C++0x or even the virtual keyword.
Implicit calling of functions when objects leave scope is incredibly
"powerful" and useful. It greatly reduces a whole class of programming
errors. It does this IMHO in two main ways. First it helps the
programmer not forget to add a free-resource call to a deinit call
(now also usually a destructor), and helps the programmer not forget a
free-resource call (now also usually a destructor) on an exit path in
a function.

Second, it helps foster a certain kind of programming paradigm where
the coder ensures that all resources have an owner at all times. Most
of the time, that is except for the occasional no-throw block or no-
throw operation which transfers ownership or allocates a resource, you
can unwind the stack at any time and you will not leak resources -
required with exceptions, but still useful otherwise. When all
resources have a clearly identified owner (and thus destruction
condition), and the ownership graph in large part has all of its roots
in stack objects, leaks become much rarer, especially with the
idiomatic usage.

I'm not sure what this example is worth, but here it is.

In my little make replacement that I wrote and play around with in my
spare time, I have a grand total of 13 actual "delete"s (and no frees,
etc.). 11149 lines of code, for whatever that silly measurement is
worth.

Once I get C++0x std::function, take off 2. If I had a
std::auto_array, take off 2 more. (Dealing with C interfaces.) Another
2 for dealing with other misc C interfaces. If I had a
std::vector<T*>, std::set<T*>, std::map<---, T*> that owned its
contained pointers, scratch another 4. The last 3 are some hacky
stuffs that I'm doing with "delete this;". (Speaking of that, I should
refactor that to be more sane. Not sure what I was thinking.)

All of the deletes appear in destructors, or they are early deletes
that a later delete in a destructor would catch anyway. I have a /
tolerable/ measure of certainty that my code is leak free, at least
much better than I would have if it was C-style.

 

[Juha Nieminen]

It is neither. It is both and more. If a language is simple to implement,
i.e., write a compiler for, then that is indeed a measure of
"simplicity". Another equally valid (perhaps to a different group)
measure of simplicity is "simplicity of usage".

The point is that C advocates try to ride on the concept of language
simplicity. With other languages simplicity means not only that the
language specification is relatively short, but also that writing
programs is simple and straightforward (because, among other things,
the programmer is not burdened by memory management and other similar
issues). The simplicity of the language directly correlates to how much
you have to write in order to implement a given task, and how much of
what you write is directly related to the task itself (rather than to
ancillary things like memory management). Also, how easy it is to
understand the code.

C advocates commit a fallacy of equivocation here. They pretend that
the brevity of the language specification equates to simplicity. That's
not what is meant by simplicity when talking about programming languages.
If you need to write 200 lines of code for something that can be done in
20 lines of (clear and easy-to-understand) code in another language, that's
not "simplicity". That's the exact opposite.

In C the brevity of the language specification actually becomes a
hindrance because of the lack of standard tools for common tasks. This
burdens the programmer with useless work that must be repeated over and
over.

I'm not saying C++ is a "simple" language. However, it is, by this
definition, *simpler* than C.

The assumption is though that after years of use, one's toolbox will be
chock-full of useful tools, idioms, etc.

There are, of course two problems with that:

1) It's not standard, and hence if you need to do a project somewhere where
you don't have your toolset, you'll have to start from scratch. Also, it
doesn't help others to understand your code if they haven't used the same
toolset.

2) Most generic tools you could write in C are harder and less safe to
use (compared to most other languages, including C++). Typically the
more generic the library, the less efficiency, type safety and usability.

Indeed, I forego many of the C++
"built-in" offerings for ones that I craft myself.

If you use your own tool instead of a standard tool even in situations
where the standard tool would be perfectly suited, that's not very smart.

 

[Juha Nieminen]

The trade-off (there always is one) being Template Code Bloat (TCB).

What's that, exactly?

 

[Juha Nieminen]

That seems like a juxtaposed statement, for it is C++ exceptions that
instigate the NEED for the RAII idiom. Without exceptions, RAII is merely
a convenience (still nice, but not important/necessary).

I don't understand where this notion is coming from.

Even if exceptions were disabled (in many compilers you can disable them
so that they will never be thrown) it would still be a nightmare to develop
a large project without RAII.

I would say the opposite of you: RAII is essential. The fact that it
allows making code exception-safe is a nice side-effect, but not the main
point.

 

[Rui Maciel]

Your point being that people who live in houses with conveniences like
indoor plumbing and electricity simply don't understand how simple
living in caves is so much better? Even though most of these people used
to be cave-dwellers? ;-)

I don't believe that the differences between C++ and C are equivalent to
the differences between a house with indoor plumbing and electricity and a
cave. I see it more as the difference between a house fully stocked with
a hefty set of conveniences and features such as home automation, HVAC and
even HAL from 2001: A Space Odyssey, and the exact same house with barely
any furniture and stripped of any of those bells and wistles. Both are
good houses, you can live confortably in any of those but in some cases
you don't have those gadgets helping you/constantly getting on your way.


Rui Maciel

 

[Rui Maciel]

How many are new? How many are active? How many users? What are the
trends in the last year or 2? (All rhetorical questions).

If you really wish to know that then all you have to do is put in the leg
work and check it for yourself. Why did you failed to do that and instead
opted to simply whine?

Your attempt at objectivity seems rather lame.

You can whine about anything you wish, really. The fact is, I've
criticized an attempt at evaluating the market share of a set of languages
and, to complement that, I've provided a more objective, quantitative way
to evaluate that. You, on the other hand, threw a set of questions to
which, as a demonstration on how relevant you think they are, you don't
even want to get the answer to and, based on that silly permisse, went
forward to bitch about how "lame" this source of data was.

So, if you really want to discuss how "lame" a source of data is then at
the very least provide any data which you believe is better than this.
Until that, tone down your "lame" posts.


Rui Maciel

 

[Rui Maciel]

In attempt to achieve greater interoperability amongst programmers?

Why do you believe that using std::string hinders "interoperability
amongst programmers"?


Rui Maciel