What has C++ become?

[plenty900]

I was looking over someone's C++ code today and despite
having written perfectly readable C++ code myself,
the stuff I was looking at was worse than legalese.
The people who are guiding the development of C++
have really made a mess of things, I mean templates
and competing libraries and all that just render the
code impossible to comprehend. Sure there is
going to be a certain amount of complexity,
that's a given, but if code is not readable except by
a kind of clergy then there is something wrong with
the language. Of course, I suppose the code I was
looking at could have been deliberately obfuscated
so that the developer could maintain control over it,
but shouldn't a language (or its libraries) be designed
to prevent that?

 

[jason.cipriani]

I was looking over someone's C++ code today and despite
having written perfectly readable C++ code myself,
the stuff I was looking at was worse than legalese.
The people who are guiding the development of C++
have really made a mess of things, I mean templates
and competing libraries and all that just render the
code impossible to comprehend. Sure there is
going to be a certain amount of complexity,
that's a given, but if code is not readable except by
a kind of clergy then there is something wrong with
the language. Of course, I suppose the code I was
looking at could have been deliberately obfuscated
so that the developer could maintain control over it,
but shouldn't a language (or its libraries) be designed
to prevent that?

Not everybody is a good C++ writer. It's a combination of two things:

1) A person not using the language as effectively as possible (and for
many people there is nothing you can do about it other than accept it
as inevitable). A poor legal writer can produce unusually unclear
legal documents (some legalese is easier to understand than others).

2) The ability to read it well (once you see enough strange looking
code it starts to make more sense and doesn't look as confusing). An
experienced lawyer can read even the most obtuse legalese document
without much of a problem.

The best thing that can be done to prevent that is to stop the problem
at it's source (#1). Rather than trolling newsgroups with questions
like this, which don't help anything at all, instead look for people
with legitimate problems in their code and give them constructive
criticism and suggestions.

Jason

 

[Erik Wikström]

I was looking over someone's C++ code today and despite
having written perfectly readable C++ code myself,
the stuff I was looking at was worse than legalese.
The people who are guiding the development of C++
have really made a mess of things, I mean templates
and competing libraries and all that just render the
code impossible to comprehend.

Sure, templates can be a bit hard to read before you get used to them
(and template meta-programming even harder) but considering how powerful
they are I do not think they are overly complex.

As for competing libraries, that is something that all moderately
successful languages have to deal with. There are always someone who
thinks that the standard libraries are not good enough and starts their
own. In some languages it is even worse with multiple standard libraries.

Sure there is
going to be a certain amount of complexity,
that's a given, but if code is not readable except by
a kind of clergy then there is something wrong with
the language.

Most code in non-trivial systems is hard to read if you are not familiar
with the specific domain and the structure of the code. Good coding
guidelines and a clear architecture will mitigate this but can never
remove it entirely.

 

[peter koch]

I was looking over someone's C++ code today and despite
having written perfectly readable C++ code myself,
the stuff I was looking at was worse than legalese.
The people who are guiding the development of C++
have really made a mess of things, I mean templates
and competing libraries and all that just render the
code impossible to comprehend. Sure there is
going to be a certain amount of complexity,
that's a given, but if code is not readable except by
a kind of clergy then there is something wrong with
the language. Of course, I suppose the code I was
looking at could have been deliberately obfuscated
so that the developer could maintain control over it,
but shouldn't a language (or its libraries) be designed
to prevent that?

Now I don't know what kind of code you did look at, but I remember
first time I looked at a C program: it looked more or less like
gibberish (I used to program in a Pascal variant with some assembly
woven in). A few days practice, and I found the code readable, and
after a few months I even liked it better than Pascal.
So what it all came up to was a need to familiarise myself with the
syntax and get acquainted to the principles behind C.
I guess it is the same stuff that troubles you. Writing templated code
is somewhat different from writing normal code: much more must take
place at compile-time, but when you learn the tricks and the way
things work, it is not so difficult again.
Also, if you did look at some code that was either library code or
code that was supposed to be supported to many (possibly old)
platforms, you will likely see code that is seemingly somewhat
obfuscated.
Probably, a few days of dissecting the code will make you well
comfortable with it: if not, you are welcome to ask questions here (or
to your collegues, of course).

/Peter

 

[James Kanze]

On 2008-05-31 18:36, (e-mail address removed) wrote:

Sure, templates can be a bit hard to read before you get used
to them (and template meta-programming even harder) but
considering how powerful they are I do not think they are
overly complex.

It's always a costs-benefits tradeoff. Making the code harder
to read is a definite cost. Afterwards, you have to weigh the
benefits, and see if they are worth it.

 

[coal]

I was looking over someone's C++ code today and despite
having written perfectly readable C++ code myself,
the stuff I was looking at was worse than legalese.
The people who are guiding the development of C++
have really made a mess of things, I mean templates
and competing libraries and all that just render the
code impossible to comprehend.

I think competing libraries are going to be around for
a while. Hybrid cars are selling well lately and
I don't think that is going to change anytime soon.
Perhaps surprisingly, the increased complexity and
knowledge required to develop and maintain a hybrid
doesn't overwhelm the relative total cost of ownership
given high energy prices. By relative I mean relative
to a car with only a gas engine.

For whatever reason, the gas engine/"traditional C++"
approach is not producing efficient results in some
contexts -- http://webEbenezer.net/comparison.html.
We're working on a new version of those tests that uses
Boost 1.35 and MSVC9. The preliminary results show no
significant differences from those using Boost 1.34.1 and
MSVC8. We're also planning to expand the test cases.
There are other reasons beside run-time performance that
our approach may be successful. We believe our approach
will also help improve build times. We aren't there yet,
though as no one has provided automated support for
integrating our services into the build process.

Sure there is
going to be a certain amount of complexity,
that's a given, but if code is not readable except by
a kind of clergy then there is something wrong with
the language.

I agree there is room for improvement with the language, but
still don't really agree with your conclusion. Your mention
of clergy is interesting... when it comes to providing
thoughtful and helpful services, a good priest is essential.

Of course, I suppose the code I was
looking at could have been deliberately obfuscated
so that the developer could maintain control over it,

Unfortunately, I think that happens. It requires good
leadership to deal with someone who behaves that way.


Brian Wood
Ebenezer Enterprises
www.webEbenezer.net

 

[plenty900]

Now I don't know what kind of code you did look at, but I remember
first time I looked at a C program: it looked more or less like
gibberish (I used to program in a Pascal variant with some assembly
woven in).

I recall having the same experience, the *first* time I looked
at a C program, having before that seen only Pascal,
Modula-2, Basic and assembly. But I've seen C++ many times
now, albeit mostly my own which is deliberately readable.

 

[plenty900]

Unfortunately, I think that happens.  It requires good
leadership to deal with someone who behaves that way.

I should mention that this is open source code,
so there is no leadership. Could be worse though,
could be the Linux kernel.

 

[Juha Nieminen]

I was looking over someone's C++ code today and despite
having written perfectly readable C++ code myself,
the stuff I was looking at was worse than legalese.

"Someone's C++ code"? Are you sure that "someone" is an experienced
C++ programmer who knows how to write good-quality understandable C++?

Anyone can write incomprehensible code with any language. And what is
worse, most people actually do.

The people who are guiding the development of C++
have really made a mess of things, I mean templates
and competing libraries and all that just render the
code impossible to comprehend.

What "competing libraries"?

And as for templates making a "mess of things", I'd say that's more
often than not just a myth. My personal experience is that templates
actually *simplify* things in most cases, they don't complicate things.
Just a small example:

int table[100];
....
std::sort(table, table+100);

I believe that's pretty simple and understandable code, or would you
disagree? (Never mind the "table+100" pointer trickery. That's not the
point here.)

Well, you know what? That's template code. It's precisely *because* of
templates that that code can be so simple as it is. Without templates it
would have to be much more complicated (compare to C's qsort()).

Maybe you think using <> makes template code "a mess"? I don't
understand why. Is this somehow unclear:

std::vector<int> table;
table.push_back(5);

What's so unclear about that? I think it's perfectly clear and legible
code. How else would you want it to be?

Sure there is
going to be a certain amount of complexity,
that's a given, but if code is not readable except by
a kind of clergy then there is something wrong with
the language.

It's impossible to design a language so that it cannot be written in
an unclear way. It's always possible to write obfuscated code.

However, that doesn't mean it's impossible to write clear code.

 

[James Kanze]

I don't believe readability is a cost benefit tradeoff.

It is in the sense that it's not binary. Totally unreadable
code has such high cost that nothing can outweigh it, but there
are times when you might give up a little bit of readability
(without the code becoming totally unreadable) if the other
benefits are large enough.

I attended Scott Meyers' presentation at NWCPP (slides
here:http://www.nwcpp.org/Downloads/2008/code_features.pdf).
Scott mentioned that he'd had help from TMP experts in
creating the code examples, so we can discount the idea that
the readability problems are caused by lack of programmer
ability in C++ TMP.

After looking at it for a while, it seems to me that there is
no way to lay out the whitespace to make it look right. C++
TMP simply eats up far too much horizontal space.

More to the point, the "language" isn't really designed for what
it is being used for. You need all sorts of strange constructs
to do fundamentally simple things, like loop or a conditional.

Second of all, once you figure out what it is doing, what it
is doing is rather simple. It is just a very poor notation for
that (which is consistent with TMP for C++ being discovered
rather than designed).

Is it necessary to have such a poor notation? I don't believe
so. C++ TMP is an FP language, and other FP languages tend to
have much better notation.

Exactly. Because they were designed with that in mind.

What it does mean is that you don't use TMP, at least in its
more complete forms, unless the benefits are extremely high, and
even then, probably only in contexts where you can be sure that
only real experts (who can cope with the loss of readability)
have to maintain it.

 

[Matthias Buelow]

The people who are guiding the development of C++
have really made a mess of things, I mean templates

IMHO, the opposite has happened.. it has been hammered into shape over
the years. My "last" experience with C++, before I resumed my use of it
about a year ago, had been from the early 90ies and the current C++ is,
while being a larger and still not very pretty language, imho more
usable than back then (of course that might also be because my memory
betrays me, or the old compilers I used [Turbo and Zortech C++ in that
case] were Not Very Good back then, or whatever.)

 

[Noah Roberts]

Sure, templates can be a bit hard to read before you get used to them
(and template meta-programming even harder) but considering how powerful
they are I do not think they are overly complex.

Both of these things simply require an understanding of the language
and, in the case of TMP, the conventions used. The authors of MPL
created and documented, quite well I think, the underlying concepts of
metafunctions and their associated algorithms and tools. An
understanding of these concepts makes TMP code completely understandable.

The problem I think that is going on here, without actually seeing any
code sample, is that people are expecting that they can just learn C++
and then work in the field for 20 years without having to learn anything
new.

 

[Noah Roberts]

I don't believe readability is a cost benefit tradeoff. I attended Scott
Meyers' presentation at NWCPP (slides here:
http://www.nwcpp.org/Downloads/2008/code_features.pdf). Scott mentioned
that he'd had help from TMP experts in creating the code examples, so we
can discount the idea that the readability problems are caused by lack
of programmer ability in C++ TMP.

I also attended that discussion, but the first one in 07...Red Green.
At least in that talk it seemed to be that Meyers specifically had help
in dealing with certain aspects of the TMP library and more
specifically, with things that should have worked but did not.

Furthermore, it wouldn't surprise me if Scott initially had trouble
understanding or working in TMP because it is an utterly new technique
that is very different than anything else people normally do in C++.
The closest one might come to the kind of coding that you are doing
might be LISP or Scheme, except you are unable to assign to anything.
However, by learning the concepts behind the TMP method, what a
metafunction is and things like that, the code really becomes rather
easy to comprehend.

And I'm not a C++ "expert". There are a LOT of people that know the
language better than I do.

 

[Erik Wikström]

Maybe you think using <> makes template code "a mess"? I don't
understand why.

Is this somehow unclear:

std::vector<int> table;
table.push_back(5);

What's so unclear about that? I think it's perfectly clear and legible
code. How else would you want it to be?

It's the wordiness of it. If the code gets more complicated than such
trivial examples, it gets rather hard to visualize. I would want it to
use a much more compact notation, like maybe:

int[] table;
table ~= 5;

The natural interpretation of the above would in C++ be "table != 5".
Assigning non-intuitive meanings to operators is much worse than a lack
of compactness. If you really want an operator use either += or <<.

 

[Roland Pibinger]

I recall having the same experience, the *first* time I looked
at a C program, having before that seen only Pascal,
Modula-2, Basic and assembly. But I've seen C++ many times
now, albeit mostly my own which is deliberately readable.

You can safely ignore this geek style 'template programming' because
it will never reach the mundane area of real-world programming.

 

[Fernando Gómez]

You can safely ignore this geek style 'template programming' because
it will never reach the mundane area of real-world programming.

Yeah, like, you know, WTL, Loki or the Standard C++ Library. Those are
clear examples of imaginary-world programming.



Hope you weren't serious about that...

 

[Ramon F Herrera]

I was looking over someone's C++ code today and despite
having written perfectly readable C++ code myself,
the stuff I was looking at was worse than legalese.
The people who are guiding the development of C++
have really made a mess of things, I mean templates
and competing libraries and all that just render the
code impossible to comprehend. Sure there is
going to be a certain amount of complexity,
that's a given, but if code is not readable except by
a kind of clergy then there is something wrong with
the language. Of course, I suppose the code I was
looking at could have been deliberately obfuscated
so that the developer could maintain control over it,
but shouldn't a language (or its libraries) be designed
to prevent that?

It has been said many times before. The solution (or cure) to C++ is
the KISS principle.

-RFH

 

[Michael DOUBEZ]

Walter Bright a écrit :

You're quite right. That's why the D programming language introduced the
operators ~ and ~= to mean concatenate and append, respectively. That
eliminates the meaning ambiguity in the + and += operators.

Another usual argument with using + for concatenation is that one expect
commutativity (a+b==b+a) but a.append(b)!= b.append(a) .

 

[Juha Nieminen]

It's the wordiness of it.

I disagree. Using longer keywords and notation does not make the code
unclear, but all the contrary: It makes the code more understandable and
unambiguous. When you try to minimize the length of elements what you
end up is basically an unreadable obfuscated regexp.

I think that your suggestion itself is a perfect example of that:

table ~= 5;

Yes, that uses less characters than "table.push_back(5);". However,
why would that be any clearer and more understandable? On the contrary,
it's more obfuscated.

I have never understood the fascination some people (and almost 100%
of beginner programmers) have with trying to minimize the size of their
source code. They will sometimes go to ridiculous extents to try to make
the code as short as possible, at the cost of making it completely
obfuscated.

Brevity does not improve readability, but all the contrary.

 

[Juha Nieminen]

Another usual argument with using + for concatenation is that one expect
commutativity (a+b==b+a) but a.append(b)!= b.append(a) .

OTOH, multiplication of matrices is not commutative, yet it may make
sense to still support the * operator for matrix types...