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

Discussion in 'C++' started by Zachary Turner, Mar 19, 2009.

  1. 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, Mar 19, 2009
    1. Advertisements

  2. * Zachary Turner:
    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.


    - Alf

    PS: I think this thread ideally would belong in [comp.std.c++], but few read
    that group.
    Alf P. Steinbach, Mar 19, 2009
    1. Advertisements

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

    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
    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 DOUBEZ, Mar 19, 2009
  4. 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, Mar 19, 2009
  5. Zachary  Turner

    Noah Roberts Guest

    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.
    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.

    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 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, Mar 19, 2009
  6. Zachary  Turner

    Kai-Uwe Bux Guest

    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.


    Kai-Uwe Bux
    Kai-Uwe Bux, Mar 19, 2009
  7. 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 (
    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, Mar 19, 2009
  8. 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, Mar 19, 2009
  9. Zachary  Turner

    Noah Roberts Guest

    My grandmother uses Linux.
    Noah Roberts, Mar 19, 2009
  10. 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
    Matthias Buelow, Mar 19, 2009
  11. Zachary  Turner

    Noah Roberts Guest

    Whatever. Then stop using it.
    Noah Roberts, Mar 19, 2009
  12. That kind of whining makes no sense.

    There's no such a thing as the perfect programming language which is
    optimal for all possible tasks. That's a physical impossibility.

    Many fanatics of some languages will boast how superb their pet
    language is and how it can be used for basically anything, but usually
    when you start studying the language in question, you always find
    shortcomings and things which it's not very suited for.

    Bashing a language for the reason that it's not the optimal language
    for all possible tasks is just stupid.
    Juha Nieminen, Mar 19, 2009
  13. Many people benefit greatly from the new features. Some people might
    require extra studying to understand these features.

    Your argument basically says that it's better to deny the former
    people the useful tools for the sake of the latter people.

    I can't say I agree with that.
    Juha Nieminen, Mar 19, 2009
  14. Are you seriously suggesting that C++ should be dumbed down so that
    people with lower IQ can use it?

    I'm not even sure how I should understand that.
    Juha Nieminen, Mar 19, 2009
  15. Yes.. I haven't tried to "bash" C++ for not being optimal. I was merely
    substantiating the OP's point that C++ is getting too complicated, from
    my perspective. IMHO, C (or the early, much simpler C++) isn't a vehicle
    suitable for building a complex multi-paradigmatic language upon, like
    C++ is trying to be. It's all hacks and horrible ad-hoc voodoo. C is,
    despite quite a few sores and tumours, a relatively elegant language for
    what it was designed to be. The early C++ was a working add-on hack,
    neither particularly elegant, rather quirky but practical enough that
    people picked it up. Modern C++, however, is an abomination and has lost
    the point a long time ago.
    Matthias Buelow, Mar 19, 2009
  16. Zachary  Turner

    Michael Mol Guest

    There's a major difference between IQ and ability to learn a language--
    and that difference is motivation. The type of person you're warning
    about is the type of person who's not actually motivated to learn to
    use the tools available to them effectively.

    As far as choice goes, if they actually *have* a choice in the
    language they're going to use, then they should make a choice based on
    their project's requirements. There have to be at least 50 mature
    general-purpose languages out there, and hundreds more which are
    targeted to specific problem domains.
    As quantifiers go, "a lot" is a pretty poor punt. As I've used C++,
    I've discovered that a lot of things that I thought of as academic
    turned out to have very practical uses. But then, that's the way it
    normally goes, isn't it? Something has to be studied before it
    becomes practical.

    [ snip straw man anecdote ]
    90% of all users aren't competent enough to truly understand the
    language they're using, be it Haskell, PHP, C++, C, ANSI BASIC or a
    four-function calculator with an M+ button. And, again, it comes down
    to an issue of motivation and how much you care about effectively
    writing good code.

    (Google: "90% of everything is crap")
    Michael Mol, Mar 19, 2009
  17. Yet people use it to write elegant, efficient and easily maintainable

    Why do some people have the obsession that

    tons of features = you must understand all of them to use the language

    Juha Nieminen, Mar 19, 2009
  18. Zachary  Turner

    Noah Roberts Guest

    It's an abomination I tells you!!! It's too complicated!!! Really, it

    Don't expect me to expand on that, it's all I gots.
    Noah Roberts, Mar 19, 2009
  19. Zachary  Turner

    Kai-Uwe Bux Guest

    a) That you do not like the conclusion of an argument does not make it
    invalid :)

    b) You actually misrepresent what I said. All that follows is that
    complexity has drawbacks. Whether the advantages outweigh the costs is a
    different matter altogether. But what does not fly is pretending the costs
    do not exist. (And this is what you did in the part you snipped and that I
    responded to.)


    Kai-Uwe Bux
    Kai-Uwe Bux, Mar 19, 2009
  20. I'm suggesting that they should be honest about who their target
    audience is. If the intended audience is academia, they're free to do
    whatever they want with it. Make it as complicated and impractical as
    humanly possible. But if they're going to claim that it's a language
    for use in solving mainstream, practical problems, then that's what it
    needs to be. And currently, it's not anywhere close to that. It's no
    longer the best at anything really, except perhaps at interfacing with
    legacy C/C++ code. If you want to write code that's in a HLL and
    still close to the OS you can use D now. Indeed, Andrei Alexandrescu
    is even a big fan of D now. (I have no idea what his stance is on C++
    anymore, he could very well still love it). But what exactly *is* the
    compelling use case for C++ anymore? For all its complexity, it
    should at the very least offer a clear advantage in *something*, and I
    honestly don't think it does anymore, and furthermore that it's
    accelerating away from such a goal. The only possible advantage it
    might offer anymore is that its standard libraries are reasonably
    mature, but any language can achieve the same thing given enough time,
    and this still of course assumes that you can figure out how to use
    the standard libraries.

    I'm also noticing that you've sidestepped the real question in every
    single one of your responses, and instead chosen to respond with
    subtle suggestions that I might, perhaps, be too stupid to understand C
    ++'s awesomeoness. To which I would say that first of all, you should
    try to answer the real question (in particular, why should someone
    bother using a language for which the learning curve is unnecessarily
    high compared to the productivity curve, when you can achieve exactly
    the same things in other languages much simpler), and second of all,
    when you have to convince a large number of people (and believe me, I
    don't think I'm the only one) who have been proponents of C++ for a
    very long of C++'s long-term position in the world of programming
    languages, then perhaps it's time for some inner reflection. Instead
    of just denying everything people are saying without giving it some
    actual thought, think about what people are saying.
    Zachary Turner, Mar 19, 2009
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.