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

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

  1. Then C is also "dynamic", given that:

    int i = 0; i++;

    can generate a potentially infinite number of different machine code
    output, depending on compiler, architecture, and even compiler options.
    Mainstream dialects have always had assignment and destructive operations.
     
    Matthias Buelow, Mar 24, 2009
    #61
    1. Advertisements

  2. Zachary  Turner

    bonchbonch Guest

    Trolls are often a one-way mouthpiece; they love to rant but hate to
    listen. Please, continue whining about other people whining while
    your programming language sinks further into obscurity.
     
    bonchbonch, Mar 24, 2009
    #62
    1. Advertisements

  3. Zachary  Turner

    Noah Roberts Guest

    join him
     
    Noah Roberts, Mar 24, 2009
    #63
  4. Zachary  Turner

    Michael Mol Guest

    Michael Mol, Mar 24, 2009
    #64
  5. Yes, master nitcpicker.
     
    Juha Nieminen, Mar 25, 2009
    #65
  6. Zachary  Turner

    Noah Roberts Guest

    Gad! Troll central in these here parts.
     
    Noah Roberts, Mar 25, 2009
    #66
  7. Zachary  Turner

    Tony Guest

    "My code" huh? What do you know about "my code"? Hmm? Do tell. Well then
    STFU!
     
    Tony, Mar 27, 2009
    #67
  8. What does he know? You told him: "The solution is to not use the std
    library".

    If you are indeed not using the std library, I wouldn't really like to
    maintain your code.
     
    Juha Nieminen, Mar 27, 2009
    #68
  9. Zachary  Turner

    Noah Roberts Guest

    Had to work under a guy like this once; no std library, no stl, no
    exceptions. Eventually he sort of gave up ever getting anything done
    and quit. Best thing that ever happened to the team.
     
    Noah Roberts, Mar 27, 2009
    #69
  10. Zachary  Turner

    Ian Collins Guest

    In many different ways!
     
    Ian Collins, Mar 27, 2009
    #70
  11. Zachary  Turner

    Tony Guest

    (Aside: I don't mean it when I say "STFU" (it means I was out partying and
    am all cocky). I'm in reality, quite mild-mannered).

    "Not using the std library" is only a solution if on is able to create or
    procure an alternative.
    I feel the same way about code that uses the std library. So it goes both
    ways. "Progress" (a subject term perhaps, so in quotes) in library design
    has been hindered by the std library. Don't "get my drift" wrong: I think
    C++ is the best thing out there. I just think it is quite far from the
    ideal.

    Tony
     
    Tony, Mar 29, 2009
    #71
  12. Zachary  Turner

    Tony Guest

    Sounds like you were an experiment wondering if you could rise to the
    challenge.

    Tony
     
    Tony, Mar 29, 2009
    #72
  13. As flexible as a brick that lands on your head, yes.
     
    Matthias Buelow, Mar 31, 2009
    #73
  14. Zachary  Turner

    Tony Guest

    C++ is great. C++ is good. Let us thank it for our food.
     
    Tony, Apr 3, 2009
    #74
  15. Zachary  Turner

    Jerry Coffin Guest

    [ ... overload resolution: ]
    Quite the opposite: compiler writers need to implement these rules. A
    normal programmer only really needs to know one incredibly simple rule:
    if it matters in the least which of a set of overloaded functions gets
    called under any circumstance, then you shouldn't be using overloading
    in the first place.

    The whole point of overloading is to provide a set of functions that do
    the same thing, but for different input types. As long as they all
    really do the same thing, it doesn't matter a bit which one of them gets
    selected for any given call.

    The only time you care which one is called is if they DON'T do the same
    thing -- and in that case, the first step is to decide whether 1) you
    have a bug in the set of overloaded functions, or 2) your design was
    wrong, and you're using overloading when you really shouldn't have in
    the first place.
    Again, that's simply not true. The maintainence programmer is faced with
    the same two possibilities as above: either he doesn't care at all which
    of the functions gets used, or he fixed the fact that overloading was
    being abused in the first place.

    [ ... ]
    Yes and no. A class allows you to define a set of characteristics of a
    type. Inheritance allows you to state (in essence) that a new type has
    (at least) the characteristics of some existing type.

    In this case, however, we're interested in allowing usage of ANY type
    that has a set of characteristics. In some cases separate types come
    about more or less by accident (e.g. different libraries in use). In
    other cases we have things that support similar operations, but we still
    definitely want them to be different types (e.g. the numeric types in C
    or C++).

    Now, it's (sort of) true that you can accomplish most of the same things
    with inheritance IF you use it pervasively. For example, quite a few
    things that will be done with Concepts in C++ could be done with
    inheritance in something like Smalltalk, where everything is an instance
    of some class. Even there, however, it's difficult to apply well -- in
    particular, you frequently end up having to use types much closer to the
    root of the whole tree than you'd like. In the process, you end up
    allowing a lot of types that you didn't really want to allow.

    Looking at it from a slightly different direction, programming languages
    are following the same path that databases did decades ago. Databases
    progressed from the hierarchical model to the network model and finally
    to the relational model. Single inheritance implements the hiearachical
    model. Multiple inheritance implements the network model. Concepts
    implement the relational model.
     
    Jerry Coffin, Apr 3, 2009
    #75
  16. Zachary  Turner

    Jerry Coffin Guest

    [ ... ]
    Not so. If you use inheritance, you quickly end up with something
    virtually indistinguishable from Smalltalk. In particular, your type
    checking ends being done at run-time rather than at compile time.

    The problem is fairly simple: inheritance means selecting a type far
    enough up the tree that it's an ancestor of EVERY type you might care to
    work with. Unfortunately, that almost inevitably includes a lot of other
    types you don't want to work with.

    You also end up really warping the inheritance tree to make this work.

    Consider for example, sorting collections of objects. We can compare
    strings, so we want to support sorting collections of strings. We can
    also compare integers, so we want to support sorting collections of
    strings. To support that, we have to apply 'sort' to some common
    ancestor of both 'string' and 'integer' -- so far so good.

    Now we run into rather a problem though: contrary to your earlier
    statement, floating point numbers really canNOT be sorted. In
    particular, sorting (at least as normally implemented) requires that if
    !(a<b) && !(b<a) then (b==a). A floating point NaN violates that
    requirement -- a NaN doesn't compare equal to another NaN, and generally
    doesn't even compare equal to itself!

    Since we want to allow assignment from integer to floating point, but
    not the reverse, floating point should be an ancestor of integer. We've
    already seen, however, that string needs to descend from something that
    is NOT an ancestor of floating point -- ergo, floating point ends up as
    a base of both string and integer. This allows something we really DON'T
    want though -- an implicit conversion from any string to floating point.

    The alternative is for string and integer to be only distantly related
    (sensible) and do the sorting on some abstract type near the root of the
    tree that's an ancestor of integer, floating point AND string, and then
    check at run time to ensure against attempting to sort things like
    floating point numbers that can't be sorted.
    Quite the contrary. 30+ years of experience with using inheritance has
    shown that while it models some relationships quite well, there are many
    other relationships it models quite poorly.

    Inheritance requires us to specify similarity in an all or nothing
    fashion. Specifically, a derived object shares ALL the characteristics
    of its base. If there is too much difference to allow that, then we
    can't use inheritance, which prevents us from taking advantage of ANY
    similarity.

    Concepts allow us to specify the exact degree of similarity between
    types necessary for a particular operation. There's no need to create a
    new type specifically to encapsulate the similarity needed for this
    particular operation, and there's no need to operate on excessivly
    abstract objects, and then do run-time checks to ensure that the objects
    really do support the operations we care about. Likewise, we don't end
    up with unwanted implicit conversions just because SOME operations imply
    a relationship that doesn't work otherwise.
     
    Jerry Coffin, Apr 3, 2009
    #76
  17. Zachary  Turner

    jacob navia Guest

    YES!

    What a SUBSTANTIVE argument

    C++ right or wrong!
     
    jacob navia, Apr 3, 2009
    #77
  18. Zachary  Turner

    James Kanze Guest

     
    James Kanze, Apr 4, 2009
    #78
  19. Zachary  Turner

    Jerry Coffin Guest

    [ ... ]
    Right -- but these are things to know about overloading, not really
    about overload _resolution_. There are definitely some rules of thumb
    that are handy to know about overloading -- but you don't really have to
    know _any_ of the overload resolution rules to know how to do
    overloading perfectly reasonably. In fact, most of the time you can do
    overloading perfectly reasonably without knowing many rules at all.

    When you get down to it, the only rule I've seen people getting confused
    about with respect to actual overload resolution is that when a scope is
    found to contain at least one instance of the right name, no further
    searching of outer scopes is conducted -- only names in that scope are
    considered for overload resolution.

    If you want to get really technical, that rule isn't really about
    overload resolution per se either. Overload resolution only _starts_
    after that search is conducted, and more than one candidate is found.
     
    Jerry Coffin, Apr 5, 2009
    #79
  20. Zachary  Turner

    James Kanze Guest

     
    James Kanze, Apr 5, 2009
    #80
    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.