Anyone else feel like C++ is getting too complicated?

I know I'm going to get flamed here, but I really feel like C++ is
just getting way too complicated to be as practical as I feel it
should (and could) be. Before you start, I've been doing C++
professionally for probably 12 years, it's easily my strongest
language, and I consider myself a "C++ programmer", not a programmer
of some other language. I'm pretty comfortable with probably 90% of
what's in C++98, and have played around quite a bit (and actually
rather enjoy) things such as template metaprogramming and other more
advanced applications of C++.

But looking at what's coming in C++0x, I'm starting to feel like it's
just going too far. It actually started with Boost. I mean I greatly
value the genericity and flexibility of the utilities that boost
provides, but honestly, every time I need a new class that Boost
provides, it takes me an hour just to figure out what the heck the
documentation is talking about. Even for things which SHOULD be
simple. The other day I needed a pool, I figured "hey I bet boost has
a pool". Sure enough it did, and after an hour I realized it was a
waste of time and I could have written the class I needed in about 5
minutes, so I did. As another example, look at the date time library
in boost. It's insane and it takes forever even to figure out how to
use it in the most basic ways. MPI is even more ridiculous, if you
can even come close to understanding how MPI and Lambda work, you
deserve a PhD in something, for real.

I'm getting off a little off topic talking about boost, but the
principle is carrying over into C++0x, albeit with basic syntax
issues. There are a few saving graces to C++0x, most notably I think
the type inference features being introduced are long overdue and
frankly pretty amazing. But rvalue references? I've tried explaining
these to FIVE different C++ programmers, and nobody has any idea what
I'm talking about. It's like I'm trying to teach them Haskell or
Hungarian, or something. But it sure doesn't sound to them like I'm
talking about C++. Concepts are almost as bad. I mean the intention
is in the right place, but that was the case with templates as well,
and I've actually quit TWO jobs over the fact that I had inherited
someone else's template code, and it was fundamentally ruined because
the person didn't understand how to correctly design large-scale
template libraries. In one case, after I quit I was told by a former
colleague that the company wrote into their coding standard that
templates were strictly forbidden from all future use, with the
exception that standard library templates could be used. Just that no
future template classes could be created.

My heart is and always has been with C++, but honestly if these trends
continue I might find myself honing my expertise in other languages in
the (near) future. C++ is still an amazing language if you're on a
team full of other people who have written a standards conformant C++
compiler, but in the real world where most of your colleagues are
average (by definition of the word average), it's becoming more
painful than it is enjoyable.

Agree? Disagree? Flame?

Zachary Turner

* Zachary Turner:
> I know I'm going to get flamed here, but I really feel like C++ is
> just getting way too complicated to be as practical as I feel it
> should (and could) be. Before you start, I've been doing C++
> professionally for probably 12 years, it's easily my strongest
> language, and I consider myself a "C++ programmer", not a programmer
> of some other language. I'm pretty comfortable with probably 90% of
> what's in C++98, and have played around quite a bit (and actually
> rather enjoy) things such as template metaprogramming and other more
> advanced applications of C++.
>
> But looking at what's coming in C++0x, I'm starting to feel like it's
> just going too far. It actually started with Boost. I mean I greatly
> value the genericity and flexibility of the utilities that boost
> provides, but honestly, every time I need a new class that Boost
> provides, it takes me an hour just to figure out what the heck the
> documentation is talking about. Even for things which SHOULD be
> simple. The other day I needed a pool, I figured "hey I bet boost has
> a pool". Sure enough it did, and after an hour I realized it was a
> waste of time and I could have written the class I needed in about 5
> minutes, so I did. As another example, look at the date time library
> in boost. It's insane and it takes forever even to figure out how to
> use it in the most basic ways. MPI is even more ridiculous, if you
> can even come close to understanding how MPI and Lambda work, you
> deserve a PhD in something, for real.
>
> I'm getting off a little off topic talking about boost, but the
> principle is carrying over into C++0x, albeit with basic syntax
> issues. There are a few saving graces to C++0x, most notably I think
> the type inference features being introduced are long overdue and
> frankly pretty amazing. But rvalue references? I've tried explaining
> these to FIVE different C++ programmers, and nobody has any idea what
> I'm talking about. It's like I'm trying to teach them Haskell or
> Hungarian, or something. But it sure doesn't sound to them like I'm
> talking about C++. Concepts are almost as bad. I mean the intention
> is in the right place, but that was the case with templates as well,
> and I've actually quit TWO jobs over the fact that I had inherited
> someone else's template code, and it was fundamentally ruined because
> the person didn't understand how to correctly design large-scale
> template libraries. In one case, after I quit I was told by a former
> colleague that the company wrote into their coding standard that
> templates were strictly forbidden from all future use, with the
> exception that standard library templates could be used. Just that no
> future template classes could be created.
>
> My heart is and always has been with C++, but honestly if these trends
> continue I might find myself honing my expertise in other languages in
> the (near) future. C++ is still an amazing language if you're on a
> team full of other people who have written a standards conformant C++
> compiler, but in the real world where most of your colleagues are
> average (by definition of the word average), it's becoming more
> painful than it is enjoyable.
>
> Agree? Disagree? Flame?

At meeting of Oslo C++ User Group I asked how many knew of MPL. 1 out of approx
12 did. I think, in fact pretty sure, that those 12 were among the most
enthusiastic C++ programmers in Norway.

So I think you're right that there's a gap between the direction the language &
library is taking, and ordinary use of the language.

If you care to look at old threads (not so very old) in [comp.std.c++] you'll
find the one where Andrei argued for reasonable defaults for the new random
number generators, so that you'd not need a PhD to use them. It seemed to me
that his arguments were not understood.

One of the most useful things in Boost, boost::intrusive_ptr, is not in C++0x.

That's a shame.

And I think the reason is that it's simple and useful. It's not academic enough.
If it was just a lot more complicated and subtle and less practically useful,
so that it could be discussed for ages with no clear conclusion, always with
some new subtlety pointed out by someone, then I think it would be in C++0x.

Modules, ditto. They would be simple and practically useful. But unfortunately,
no modules, at least not this time.

That's what I'm missing the most in C++. It's kind of ridiculous having a
language designed for "programming in the large", without module support. So we
swing it by manually creating header files, manually adhering to various
conventions, manually tweaking things by employing compiler-specific
pre-compiled headers, all that stuff that should have been standardized and
automated and checkable by the compiler, or at least the build system.

Also missing among practical features, a standard way to disable some common
silly-warnings, I think that could help a lot for the practical use of the
language. In particular the silly-warnings about implicit conversion to bool,
warnings about unused argument or local variable (the latter isn't really so
much an issue because a conforming compiler should detect non-trivial
constructor and not warn in that case), and warnings about constant condition
expression in 'if' or other selection. As it is, without a standard way to avoid
diagnostics all kinds of compiler-specific means are brought to bear.

However, there are some good things.

Type deduction, as you write, is basically just good, although the way it's
designed lets you very easily access otherwise practically inaccessible types.
With 'auto' in the picture, no longer does it suffice to declare a type private
or protected. Anyone can 'auto' to declare a holder for the result of a
function, so e.g. that useful C++98 proxy you've designed can easily outlive the
expression where it was meant to exist, with its referent no longer valid...

Argument forwarding is decidedly good, I think.

With argument forwarding we can finally, /I believe/, haven't tried this with
C++0x compiler, create reasonable smart pointers that take care of creation, not
just destruction. And that opens a large new frontier. Really usable things.
It's very awkward to do this with macros, and there's a syntax issue, for
default construction. I started exploring that but didn't go very far (for
various non-technical reasons).

Function attributes, good. But I'm missing the one really useful attribute, the
one that says this function will never throw. An empty throw specification
"throw()" doesn't do quite the same, because it obliges the standard-conforming
compiler to add a catch clause in order to invoke std::unexpected; an attribute
would on the other hand enable the compiler to avoid adding that catch clause.
In particular this would enable the style I prefer, a 'bool throwX(char
const*)', without using compiler-specific means to suppress warnings.


Cheers,

- Alf

PS: I think this thread ideally would belong in [comp.std.c++], but few read
that group.

--
Due to hosting requirements I need visits to <url: http://alfps.izfree.com/>.
No ads, and there is some C++ stuff! Just going there is good. Linking
to it is even better! Thanks in advance!

Alf P. Steinbach

Zachary Turner wrote:
> I know I'm going to get flamed here, but I really feel like C++ is
> just getting way too complicated to be as practical as I feel it
> should (and could) be. Before you start, I've been doing C++
> professionally for probably 12 years, it's easily my strongest
> language, and I consider myself a "C++ programmer", not a programmer
> of some other language. I'm pretty comfortable with probably 90% of
> what's in C++98, and have played around quite a bit (and actually
> rather enjoy) things such as template metaprogramming and other more
> advanced applications of C++.
>
> But looking at what's coming in C++0x, I'm starting to feel like it's
> just going too far. It actually started with Boost. I mean I greatly
> value the genericity and flexibility of the utilities that boost
> provides, but honestly, every time I need a new class that Boost
> provides, it takes me an hour just to figure out what the heck the
> documentation is talking about. Even for things which SHOULD be
> simple. The other day I needed a pool, I figured "hey I bet boost has
> a pool". Sure enough it did, and after an hour I realized it was a
> waste of time and I could have written the class I needed in about 5
> minutes, so I did. As another example, look at the date time library
> in boost. It's insane and it takes forever even to figure out how to
> use it in the most basic ways. MPI is even more ridiculous, if you
> can even come close to understanding how MPI and Lambda work, you
> deserve a PhD in something, for real.

MPI and Lambda are not so bad if you are familiar with the problem they
solve.

Have you had a look at GIL ? It is terrible. I succeeded in using it and
was very happy with the result but I had to double my ration of caffeine
to keep up with the concepts, how they interact and how they were
implemented.

>
> I'm getting off a little off topic talking about boost, but the
> principle is carrying over into C++0x, albeit with basic syntax
> issues. There are a few saving graces to C++0x, most notably I think
> the type inference features being introduced are long overdue and
> frankly pretty amazing. But rvalue references? I've tried explaining
> these to FIVE different C++ programmers, and nobody has any idea what
> I'm talking about. It's like I'm trying to teach them Haskell or
> Hungarian, or something. But it sure doesn't sound to them like I'm
> talking about C++. Concepts are almost as bad. I mean the intention
> is in the right place, but that was the case with templates as well,
> and I've actually quit TWO jobs over the fact that I had inherited
> someone else's template code, and it was fundamentally ruined because
> the person didn't understand how to correctly design large-scale
> template libraries. In one case, after I quit I was told by a former
> colleague that the company wrote into their coding standard that
> templates were strictly forbidden from all future use, with the
> exception that standard library templates could be used. Just that no
> future template classes could be created.
>
> My heart is and always has been with C++, but honestly if these trends
> continue I might find myself honing my expertise in other languages in
> the (near) future. C++ is still an amazing language if you're on a
> team full of other people who have written a standards conformant C++
> compiler, but in the real world where most of your colleagues are
> average (by definition of the word average), it's becoming more
> painful than it is enjoyable.
>
> Agree? Disagree? Flame?

I agree in the sense that IMHO C++ is becoming more and more expert
friendly but I think it reflects the organization in the C++ community:
some write libraries with very elaborate stuff and MPL, others write
applications and use those libraries with the expressiveness they provide.

The problem is now a problem of communication between these two groups.
Typically Boost has a formal way of documenting (with Concepts ...)
which IMHO is useful for other library builders but not so much for
users who are looking for a solution and not necessarily the
architecture or the underlying idea of a tool.

From what I have seen in the software factory (in France), very few
people use templates and, if so, in a very limited manner. The questions
regarding C++ I saw in interviews (Looking for a job - hint, hint) were
all related to OOP and expert questions were related to patterns of the
GoF book (I even saw evaluation test still using the old headers).

All of that to say, yes modern C++ is very powerful and very difficult
to harness but the next standard provides many tools to overcome the
limitations of the language which helps in closing the gap between
library builder and user. Ideally, the users won't have to debug tons of
output for a deeply nested error but will have a clean static_assert
error and they won't have to understand the limitation of the language
that skewed the design or the possibilities of a lib.

--
Michael

Michael DOUBEZ

Zachary Turner wrote:
> But rvalue references? I've tried explaining
> these to FIVE different C++ programmers, and nobody has any idea what
> I'm talking about. It's like I'm trying to teach them Haskell or
> Hungarian, or something. But it sure doesn't sound to them like I'm
> talking about C++. Concepts are almost as bad.

You don't have to know anything about rvalue references or concepts in
order to benefit from them.

Concepts help the compiler give you more understandable error
messages. Is that a bad thing? Rvalue references help making your code
more efficient. Is that a bad thing?

If it's not a bad thing, then who cares if the internal details are
complicated to understand? I don't understand how exceptions work
internally, but that doesn't stop me from benefiting from them. So why
should I care if the details are complicated?

If you don't like rvalue references because they are too complicated,
then the solution is rather simple: Don't use them. You can keep
programming exactly as you have done to this day. You don't need to
understand them. It's not like you would be forced to understand rvalue
references in order to program in C++0x. I honestly can't see the problem.

Juha Nieminen

Juha Nieminen wrote:
> Zachary Turner wrote:
>> But rvalue references? I've tried explaining
>> these to FIVE different C++ programmers, and nobody has any idea what
>> I'm talking about. It's like I'm trying to teach them Haskell or
>> Hungarian, or something. But it sure doesn't sound to them like I'm
>> talking about C++. Concepts are almost as bad.
>
> You don't have to know anything about rvalue references or concepts in
> order to benefit from them.

Exactly. Unless you're writing a library that uses move semantics I'm
pretty sure you simply don't need to care what rvalue references are or
how they work. The rvalue reference solves an important problem for
library writers. For instance, you'll now be able to store uncopyable
objects in the standard containers because of this language feature.

> Concepts help the compiler give you more understandable error
> messages.

More than that I believe. The boost::concepts can do that. The
concepts in the new standard, as a feature of the language and not some
coding hack, allows you to write template code that will only activate
for types that represent the required concepts. In other words, you'll
be able to competently decide which template code to use based on the
concepts your type represents! This is a MAJOR benefit, especially for
library authors.

Although not everyone understands concepts in C++, everyone SHOULD.
Concepts are far from new and the entire standard library uses them.
They're just not possible to enforce by the language yet and when you
violate the documented concept interface of a type in the STL you get
template error vomit instead of something nice. The new language simply
takes something you've been using all along and makes it a feature of
the language.


> If you don't like rvalue references because they are too complicated,
> then the solution is rather simple: Don't use them. You can keep
> programming exactly as you have done to this day. You don't need to
> understand them. It's not like you would be forced to understand rvalue
> references in order to program in C++0x. I honestly can't see the problem.

Exactly. The standard philosophy of C++ still stands: don't make anyone
pay for anything they don't need to use.

People complaining about these things should go talk to the people who
are behind why they are going in. Go sit down with Steven Wantanabe, as
I did, and have it explained to you why rvalue references are important.
Frankly, they're a mystery to me too but he was able to point out
several cases where all these "complex" language features will make
writing code easier.

I don't know what the complaint about boost::lambda is besides the fact
that it actually doesn't work that great. Unlike boost::bind, for
instance, it can't deal with smart pointers and the like. The new
lambda syntax going into the language is a might bit strange but I don't
have to use it.

Variadic templates fall into this category as well. The whole pack
thing is quite a change in perspective, but the template code that
results is a whole lot better than the preprocessor code required to
work around the language limitation that currently exists. Furthermore,
nobody has to use them.

I'll tell you what though, you're going to benefit from all of these
features in the form of very nice additions to the standard library.
The whole bind1st, bind2nd crap is GONE! Well, it's there, you can use
it, but there's much better in its place: bind(). Function pointers are
basically a thing of the past to be replaced by a function object that
can store and use any function that is callable with the arguments
supplied...no more undefined behavior because your void function pointer
points at a function returning an int.

The threading stuff is also a major improvement and relies upon at least
one of the features being complained about here: rvalue references.
Because threads are "movable" they can be stored in a container that can
hold movable objects. As I said, the new standard containers will.

So your really trying to toss out the baby with the bathwater. Ok, the
bathwater is gross and ugly to some people...but the baby will be loved
by most. If you don't want the bathwater, don't drink it.

Noah Roberts

Juha Nieminen wrote:

> Zachary Turner wrote:
>> But rvalue references? I've tried explaining
>> these to FIVE different C++ programmers, and nobody has any idea what
>> I'm talking about. It's like I'm trying to teach them Haskell or
>> Hungarian, or something. But it sure doesn't sound to them like I'm
>> talking about C++. Concepts are almost as bad.
[snip]
> If you don't like rvalue references because they are too complicated,
> then the solution is rather simple: Don't use them. You can keep
> programming exactly as you have done to this day. You don't need to
> understand them. It's not like you would be forced to understand rvalue
> references in order to program in C++0x. I honestly can't see the problem.

That is _not_ the solution unless you program in solitude. As soon as you
are a maintenance programmer or have to deal with code of others, you have
to be fluent in the C++ _they_ use. That can include all the new features.

Related: code should not be regarded solely as a means of instructing a
computer. It is also a means of communicating with other programmers. In
that regard a language can fail by being overly complex. At some point, a
language can get so large that the investment it takes to familiarize
yourself with all features becomes too large to make (after all, there are
other things competing for my attention). But a language needs to be shared
in order to serve as a means of communication.


Best

Kai-Uwe Bux

Kai-Uwe Bux

On Mar 19, 10:44 am, Juha Nieminen <nos...@thanks.invalid> wrote:
> Zachary Turner wrote:
> > But rvalue references? I've tried explaining
> > these to FIVE different C++ programmers, and nobody has any idea what
> > I'm talking about. It's like I'm trying to teach them Haskell or
> > Hungarian, or something. But it sure doesn't sound to them like I'm
> > talking about C++. Concepts are almost as bad.
>
> You don't have to know anything about rvalue references or concepts in
> order to benefit from them.
>
> Concepts help the compiler give you more understandable error
> messages. Is that a bad thing? Rvalue references help making your code
> more efficient. Is that a bad thing?
>
> If it's not a bad thing, then who cares if the internal details are
> complicated to understand? I don't understand how exceptions work
> internally, but that doesn't stop me from benefiting from them. So why
> should I care if the details are complicated?
>
> If you don't like rvalue references because they are too complicated,
> then the solution is rather simple: Don't use them. You can keep
> programming exactly as you have done to this day. You don't need to
> understand them. It's not like you would be forced to understand rvalue
> references in order to program in C++0x. I honestly can't see the problem.

The problem is, who's going to want to program in a language if they
know that only, say, 50% of the language is going to be accessible to
them at their IQ level? Why would the person not just pick another
language in that case, a language where they personally would feel
more productive since they know they're getting everything out of the
language that it has to offer?

It's like trying to get your grandmother to use Linux. It's more
powerful and she can do more stuff with it, but if the only thing she
can *figure out* how to do is click the Firefox icon, while in Windows
she can also figure out how to change her password and her desktop
wallpaper, then she's not going to use it.

The problem is that C++ markets itself as a mainstream language, a
language for the masses so to speak (where the masses is anyone who
wants to write code that is close to the OS level), yet ALOT of the
constructs it provides are almost solely of academic interest.

So then what happens? You get your C++ programmer who deep down would
love to to start a national C++ Bee (http://www.christiannewswire.com/
news/513588015.html) to see who can recite more of the C++ Standard
conducting all the job interviews (everyone knows there's 1 of these
guys at every company), and the guy who answers "no" when asked if he
understands r-value references doesn't get the job, because the next
guy answers "yes" and answers something that remotely resembles a
correct answer, and then when he gets the job he ruins the entire
product because he started sprinkling all these cool features all over
the code for no other reason than that they're advanced and cool, and
he thinks that using them everywhere will make people respect him more
because he's obviously smart. Another product destroyed....

Honestly, if 90% of the users of a language aren't going to understand
how to use something effectively, or for that matter AT ALL, it
shouldn't be in the language.

Zachary Turner

On Mar 19, 11:15*am, Zachary Turner <divisorthe...@gmail.com> wrote:
> On Mar 19, 10:44 am, Juha Nieminen <nos...@thanks.invalid> wrote:
>
>
>
> > Zachary Turner wrote:
> > > But rvalue references? *I've tried explaining
> > > these to FIVE different C++ programmers, and nobody has any idea what
> > > I'm talking about. *It's like I'm trying to teach them Haskell or
> > > Hungarian, or something. *But it sure doesn't sound to them like I'm
> > > talking about C++. *Concepts are almost as bad.
>
> > * You don't have to know anything about rvalue references or concepts in
> > order to benefit from them.
>
> > * Concepts help the compiler give you more understandable error
> > messages. Is that a bad thing? Rvalue references help making your code
> > more efficient. Is that a bad thing?
>
> > * If it's not a bad thing, then who cares if the internal details are
> > complicated to understand? I don't understand how exceptions work
> > internally, but that doesn't stop me from benefiting from them. So why
> > should I care if the details are complicated?
>
> > * If you don't like rvalue references because they are too complicated,
> > then the solution is rather simple: Don't use them. You can keep
> > programming exactly as you have done to this day. You don't need to
> > understand them. It's not like you would be forced to understand rvalue
> > references in order to program in C++0x. I honestly can't see the problem.
>
> The problem is, who's going to want to program in a language if they
> know that only, say, 50% of the language is going to be accessible to
> them at their IQ level? *Why would the person not just pick another
> language in that case, a language where they personally would feel
> more productive since they know they're getting everything out of the
> language that it has to offer?
>
> It's like trying to get your grandmother to use Linux. *It's more
> powerful and she can do more stuff with it, but if the only thing she
> can *figure out* how to do is click the Firefox icon, while in Windows
> she can also figure out how to change her password and her desktop
> wallpaper, then she's not going to use it.
>
> The problem is that C++ markets itself as a mainstream language, a
> language for the masses so to speak (where the masses is anyone who
> wants to write code that is close to the OS level), yet ALOT of the
> constructs it provides are almost solely of academic interest.
>
> So then what happens? *You get your C++ programmer who deep down would
> love to to start a national C++ Bee (http://www.christiannewswire.com/
> news/513588015.html) to see who can recite more of the C++ Standard
> conducting all the job interviews (everyone knows there's 1 of these
> guys at every company), and the guy who answers "no" when asked if he
> understands r-value references doesn't get the job, because the next
> guy answers "yes" and answers something that remotely resembles a
> correct answer, and then when he gets the job he ruins the entire
> product because he started sprinkling all these cool features all over
> the code for no other reason than that they're advanced and cool, and
> he thinks that using them everywhere will make people respect him more
> because he's obviously smart. *Another product destroyed....
>
> Honestly, if 90% of the users of a language aren't going to understand
> how to use something effectively, or for that matter AT ALL, it
> shouldn't be in the language.

Just to add one more thing, I'm not saying that these things like
concepts and r-value references aren't useful. I just don't think
they should be *in the language*. Designining the standard libraries
with them would be great since it would allow people to benefit from
them without introducing the inevitability that they will cause more
harm than good over the long run. I would argue that maybe even
templates have done more harm than good, I honestly have never
maintained a single usable code base where the original author used
templates. It's always a complete nightmare, even though I personally
understand templates perfectly.

Obviously the idea of implementing the libraries in a superset of the
language raises its own set of issues, but I don't think it's a
totally unsolvable problem. Maybe that's not even the best solution,
but I'm pretty sure that the current direction things are heading is
one of the *worst possible* solutions from a practical standpoint.

Zachary Turner

Zachary Turner wrote:

> It's like trying to get your grandmother to use Linux.

My grandmother uses Linux.

Noah Roberts

Noah Roberts wrote:

> Exactly. The standard philosophy of C++ still stands: don't make anyone
> pay for anything they don't need to use.

The "standard philosophy" rather seems to be: trade programmer time for
execution time. C++ has become so spectacularly unproductive for me, I
even have written ad-hoc interpreters to implement parts of an app in a
less bureaucratic language (a small dialect of Lisp, in that case) for
the simple reason that juggling with C++ only is so utterly unwieldy and
frustrating.

Matthias Buelow