What has C++ become?

Guest

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?

Advertisements

Guest

On May 31, 12:36 pm, wrote:
> 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.

Advertisements

On 2008-05-31 18:36, wrote:
> 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.

On 31 Maj, 18:36, wrote:
> 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).

On May 31, 7:25 pm, Erik Wikström <> wrote:
> On 2008-05-31 18:36, wrote:
> > 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.

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.

Guest

On May 31, 10:36 am, wrote:
> 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.

Guest

On May 31, 3:57 pm, peter koch <> wrote:
> 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.

Guest

On Jun 1, 1:01 am, wrote:
> > 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.

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

wrote:
> 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()).

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.

On Jun 2, 7:41 am, Walter Bright <>
wrote:
> James Kanze wrote:
> > On May 31, 7:25 pm, Erik Wikström <> 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.
> 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.

wrote:
> 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.)

Erik WikstrÃ¶m wrote:
> On 2008-05-31 18:36, wrote:
>> 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.

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.

Walter Bright wrote:
> James Kanze wrote:
>> On May 31, 7:25 pm, Erik Wikström <> 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.
>
> 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.

On 2008-06-02 12:27, Walter Bright wrote:
> Juha Nieminen wrote:
>> Maybe you think using <> makes template code "a mess"? I don't
>> understand why.
>
> It's because of the parsing ambiguities that come from using < > as a
> parameter delimiter.
>
>> 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 <<.

On Sun, 1 Jun 2008 16:34:58 -0700 (PDT), wrote:
>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.

--
Roland Pibinger
"The best software is simple, elegant, and full of drama" - Grady Booch

On Jun 2, 12:27 pm, (Roland Pibinger) wrote:
> On Sun, 1 Jun 2008 16:34:58 -0700 (PDT), wrote:
> >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.
>

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

On May 31, 12:36 pm, wrote:
> 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.

Walter Bright a écrit :
> Yannick Tremblay wrote:
>> What do you think should happen on:
>>
>> std::vector<int> c;
>> c = a + b; // ??
>> Various peoples will say: sum elements individually, concatenation of
>> the two vectors ??? The fact is that '+' for vectors have no natural
>> (universal?) meaning, using it as a short hand for something else is
>> more likely to obfuscate the code rather than a more verbose solution.
>
> 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) .

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.

Share This Page

Welcome to The Coding Forums!

Welcome to the Coding Forums, the place to chat about anything related to programming and coding languages.

Please join our friendly community by clicking the button below - it only takes a few seconds and is totally free. You'll be able to ask questions about coding or chat with the community and help others.
Sign up now!