Re: Anyone else feel like C++ is getting too complicated?
* 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!