Why C is vastly superior to C++

Discussion in 'C++' started by jacob navia, Jun 28, 2011.

  1. jacob navia

    jacob navia Guest

    Memory footprint. C++ uses up a LOT of memory.

    :)
    jacob navia, Jun 28, 2011
    #1
    1. Advertising

  2. jacob navia

    jacob navia Guest

    Le 28/06/11 14:12, jacob navia a écrit :
    > Memory footprint. C++ uses up a LOT of memory.
    >
    > :)


    Attention TROLL message!!!

    :)
    jacob navia, Jun 28, 2011
    #2
    1. Advertising

  3. jacob navia

    Noah Roberts Guest

    On 6/28/2011 5:12 AM, jacob navia wrote:
    > Memory footprint. C++ uses up a LOT of memory.
    >
    > :)


    That's because it's incremented. Higher value integers use up more memory.
    Noah Roberts, Jun 28, 2011
    #3
  4. jacob navia

    jacob navia Guest

    Le 28/06/11 19:02, Noah Roberts a écrit :
    > On 6/28/2011 5:12 AM, jacob navia wrote:
    >> Memory footprint. C++ uses up a LOT of memory.
    >>
    >> :)

    >
    > That's because it's incremented. Higher value integers use up more memory.


    Yes. But my memory is not extensible.
    Last time I tried I told my surgeon:

    Doctor, doctor!

    What's up again jacob?

    I need a memory extension, my brain is full!

    Why?
    You have been studying again the C++ specs?

    Yes, I just wanted to know how the function call works
    but it was several dozens of pages of stuff, with a
    topological sort of the classes involved, with all those
    template specializations that go nuts when I forget a >... etc.

    Then I just noticed that as I read
    page 12 I was forgetting what was in page one and also
    the name of my wife...

    Terrible! I need a bigger brain!!!

    Well, jacob... I can't do anything for you but...
    Why don't you learn a simpler language, like C?
    It uses much less memory.

    You see?

    The doctor told me so.
    jacob navia, Jun 28, 2011
    #4
  5. jacob navia <> wrote:
    > Memory footprint. C++ uses up a LOT of memory.


    I haven't noticed such a difference.

    (In fact, there are many cases where C consumes more memory than the
    equivalent C++ version because often C++ allows the compiler to perform
    optimizations that the C compiler cannot do.)
    Juha Nieminen, Jun 29, 2011
    #5
  6. jacob navia

    jacob navia Guest

    Le 29/06/11 22:20, Juha Nieminen a écrit :
    > jacob navia<> wrote:
    >> Memory footprint. C++ uses up a LOT of memory.

    >
    > I haven't noticed such a difference.
    >
    > (In fact, there are many cases where C consumes more memory than the
    > equivalent C++ version because often C++ allows the compiler to perform
    > optimizations that the C compiler cannot do.)


    Sure, but I was speaking about HUMAN memory, who cares about computer
    memory when you can buy megabytes for a dime a dozen?

    The problem with my brain is that its memory is not extensible. Trying
    to understand and memorize the specifications for overloaded function
    calls in the C++ specs goes for PAGES AND PAGES, impossible for a brain
    to swallow and digest that without a severe indigestion.

    There arrives a point (that C++ has already passed beyond) where
    there is no brain in the world, not even the one of Stroustrup,
    that is able to understand 100% of the language. See the "concepts"
    debacle.

    This means that in practice NO ONE understands the language he/she is
    using in full. The language has become something beyond the capabilities
    of mere people and only a compiler can understand it.

    I have seen more and more posts where somebody asks here:

    "Why doesn't this compile"?

    And the answers are:

    o Compiles in MSVC
    o Doesn't compile in gcc
    o Comeau accepts it...

    without ANYBODY even trying to argue about WHY the construct
    in question is right or wrong. Nobody knows any more.

    Everybody knows what I am speaking about yet this doesn't seem to be
    seen as a problem and the committee keeps adding and adding features
    (lambdas, etc) without any person trying to stop that trend, as if
    "progress" in software construction implies always MORE complexity
    and MORE complexity without any limit.

    Well there are limits, and those limits are set by our brain. In the
    last resort, mere PEOPLE are using this language, and they just are
    now unable to understand ALL the implications of what they are
    doing when they write any serious program.

    The consequences are that C++ software is "brittle", in the sense that
    a small change somewhere, that everybody thought it would be harmless
    produces a whole series of catastrophes in other, unrelated parts
    of the software.

    It is not time to reflect about this problem?

    Thanks for your input.

    jacob
    jacob navia, Jun 29, 2011
    #6
  7. jacob navia

    Ian Collins Guest

    On 06/30/11 09:04 AM, jacob navia wrote:
    >
    > Well there are limits, and those limits are set by our brain. In the
    > last resort, mere PEOPLE are using this language, and they just are
    > now unable to understand ALL the implications of what they are
    > doing when they write any serious program.


    I have coached a number of C development teams int C++. The first thing
    we do before committing to a project is a agree the language subset
    everyone in the team is happy with and initially stick to that. Over
    time as the team's experience grows, so does the language subset they use.

    One team was happy just to use C++ as a better C, no OO, just function
    overloading, references, proper const and a few other features (I'm sure
    you are familiar with these features!). Another was happy to jump in
    boots first and use the kitchen sink. Others chose a middle ground.

    So reflecting on your agenda, C++ can and is used as C with the features
    you are keen to add. It works well in that space which is why you meet
    so much opposition when proposing additions to C.

    > The consequences are that C++ software is "brittle", in the sense that
    > a small change somewhere, that everybody thought it would be harmless
    > produces a whole series of catastrophes in other, unrelated parts
    > of the software.


    Not if it has a decent testing framework.

    > It is not time to reflect about this problem?


    In nigh on 20 years of developing C++ code and development teams, I
    haven't found this to be a problem.

    --
    Ian Collins
    Ian Collins, Jun 29, 2011
    #7
  8. jacob navia <> wrote:
    > The problem with my brain is that its memory is not extensible. Trying
    > to understand and memorize the specifications for overloaded function
    > calls in the C++ specs goes for PAGES AND PAGES, impossible for a brain
    > to swallow and digest that without a severe indigestion.


    C isn't all that much better in this regard. C parsers may be significantly
    simpler to create than full-fledged C++ parsers, but that doesn't necessarily
    mean that *programming* in C is any simpler or easier than in C++.

    When developing large projects in C you usually need to use paradigms and
    coding conventions that exist solely because of what C lacks (iow. they are
    unnecessary in C++ and most other languages). In other words, you are
    mostly just changing your brain capacity usage from learning language
    features to learning coding conventions and strict guidelines that should
    be unnecessary. In a way, you could say that most large projects use a
    "megalanguage" on top of C, and any person who wants to participate in the
    development of that project needs to learn it.

    > The consequences are that C++ software is "brittle", in the sense that
    > a small change somewhere, that everybody thought it would be harmless
    > produces a whole series of catastrophes in other, unrelated parts
    > of the software.


    I don't think C is much better in this regard.
    Juha Nieminen, Jun 30, 2011
    #8
  9. jacob navia

    Jorgen Grahn Guest

    On Thu, 2011-06-30, Juha Nieminen wrote:
    > jacob navia <> wrote:
    >> The problem with my brain is that its memory is not extensible. Trying
    >> to understand and memorize the specifications for overloaded function
    >> calls in the C++ specs goes for PAGES AND PAGES, impossible for a brain
    >> to swallow and digest that without a severe indigestion.

    >
    > C isn't all that much better in this regard. C parsers may be significantly
    > simpler to create than full-fledged C++ parsers, but that doesn't necessarily
    > mean that *programming* in C is any simpler or easier than in C++.
    >
    > When developing large projects in C you usually need to use paradigms and
    > coding conventions that exist solely because of what C lacks (iow. they are
    > unnecessary in C++ and most other languages). In other words, you are
    > mostly just changing your brain capacity usage from learning language
    > features to learning coding conventions and strict guidelines that should
    > be unnecessary. In a way, you could say that most large projects use a
    > "megalanguage" on top of C, and any person who wants to participate in the
    > development of that project needs to learn it.


    Precisely. Compared to C, C++ moves complexity /from/ N program to 1
    language, so I don't have to learn N different partial solutions to
    the same problem.

    (Other languages like Python do so even more of course, but none of
    the popular ones stay close to C in terms of library support and
    performance, for the times you need that.)

    You could replace s/CommonLisp/C++/ in Greenspuns Tenth Rule Of
    Programming:

    "Any sufficiently complicated C or Fortran program contains an
    ad-hoc, informally-specified, bug-ridden, slow implementation of
    half of CommonLisp."

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
    Jorgen Grahn, Jun 30, 2011
    #9
  10. jacob navia

    Jorgen Grahn Guest

    On Wed, 2011-06-29, jacob navia wrote:
    ....

    > There arrives a point (that C++ has already passed beyond) where
    > there is no brain in the world, not even the one of Stroustrup,
    > that is able to understand 100% of the language.


    That doesn't worry me -- I don't understand all of any other language
    either. What matters to me is that I can write my programs, make them
    work, make them reasonably elegant, and be sure that they don't just
    /accidentally/ work.

    > See the "concepts"
    > debacle.


    They aren't part of the language -- if I understand correctly, because
    they were not properly understood.

    > This means that in practice NO ONE understands the language he/she is
    > using in full. The language has become something beyond the capabilities
    > of mere people and only a compiler can understand it.
    >
    > I have seen more and more posts where somebody asks here:
    >
    > "Why doesn't this compile"?
    >
    > And the answers are:
    >
    > o Compiles in MSVC
    > o Doesn't compile in gcc
    > o Comeau accepts it...
    >
    > without ANYBODY even trying to argue about WHY the construct
    > in question is right or wrong.


    I've seen those threads. IIRC the interesting ones usually concern
    name lookup, or heavy template stuff. Call me lazy, but as long as
    there's no doubt what the code would do /if it compiled/, I don't
    worry too much.

    > Nobody knows any more.


    Or noone here can be bothered to decipher every piece of problem code
    posted.

    > Everybody knows what I am speaking about yet this doesn't seem to be
    > seen as a problem and the committee keeps adding and adding features
    > (lambdas, etc) without any person trying to stop that trend, as if
    > "progress" in software construction implies always MORE complexity
    > and MORE complexity without any limit.


    I never understood that oft-repeated complaint. C++ has stood still
    since the mid-1990s. Every other language I use (except C) has grown
    immensely during that period. Why can't we have some badly needed
    features, when we have waited patiently for over fifteen years?

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
    Jorgen Grahn, Jun 30, 2011
    #10
  11. jacob navia

    jacob navia Guest

    Le 30/06/11 08:10, Jorgen Grahn a écrit :
    > On Thu, 2011-06-30, Juha Nieminen wrote:
    >> jacob navia<> wrote:
    >>> The problem with my brain is that its memory is not extensible. Trying
    >>> to understand and memorize the specifications for overloaded function
    >>> calls in the C++ specs goes for PAGES AND PAGES, impossible for a brain
    >>> to swallow and digest that without a severe indigestion.

    >>
    >> C isn't all that much better in this regard. C parsers may be significantly
    >> simpler to create than full-fledged C++ parsers, but that doesn't necessarily
    >> mean that *programming* in C is any simpler or easier than in C++.
    >>
    >> When developing large projects in C you usually need to use paradigms and
    >> coding conventions that exist solely because of what C lacks (iow. they are
    >> unnecessary in C++ and most other languages). In other words, you are
    >> mostly just changing your brain capacity usage from learning language
    >> features to learning coding conventions and strict guidelines that should
    >> be unnecessary. In a way, you could say that most large projects use a
    >> "megalanguage" on top of C, and any person who wants to participate in the
    >> development of that project needs to learn it.

    >
    > Precisely. Compared to C, C++ moves complexity /from/ N program to 1
    > language, so I don't have to learn N different partial solutions to
    > the same problem.
    >



    Yes, you have a point here (You and Mr Nieminen). That is a weak point
    in C. I am trying to address this within the C community, with
    relatively lack of success.

    In this sense, the problems with those features is not that they exist,
    but that their usage is extremely complicated and hard to follow.

    Templates are an example of that. They are both great when they work,
    incomprehensible when they don't. You have then, to memorize a series
    of "gotchas" and template conventions that make the subject
    extremely obscure and memory consuming.

    Metaprogramming should be done at compile time within a specific
    meta-language, designed to do that. This has been done with extremely
    hard to follow templates like IF and others, that approach the
    metalanguage goal without EXPLICITELY having a meta-language.

    All the memory required to memorize the hacks needed now would be
    unnecessary if we would have a simple functional language where
    we describe templates with parameter checking, etc etc. A meta-language
    would (again) "move complexity /from/ N programs to 1 language"

    jacob
    jacob navia, Jun 30, 2011
    #11
  12. jacob navia

    Ian Collins Guest

    On 06/30/11 06:42 PM, jacob navia wrote:
    > Le 30/06/11 08:10, Jorgen Grahn a écrit :
    >> On Thu, 2011-06-30, Juha Nieminen wrote:
    >>> jacob navia<> wrote:
    >>>> The problem with my brain is that its memory is not extensible. Trying
    >>>> to understand and memorize the specifications for overloaded function
    >>>> calls in the C++ specs goes for PAGES AND PAGES, impossible for a brain
    >>>> to swallow and digest that without a severe indigestion.
    >>>
    >>> C isn't all that much better in this regard. C parsers may be significantly
    >>> simpler to create than full-fledged C++ parsers, but that doesn't necessarily
    >>> mean that *programming* in C is any simpler or easier than in C++.
    >>>
    >>> When developing large projects in C you usually need to use paradigms and
    >>> coding conventions that exist solely because of what C lacks (iow. they are
    >>> unnecessary in C++ and most other languages). In other words, you are
    >>> mostly just changing your brain capacity usage from learning language
    >>> features to learning coding conventions and strict guidelines that should
    >>> be unnecessary. In a way, you could say that most large projects use a
    >>> "megalanguage" on top of C, and any person who wants to participate in the
    >>> development of that project needs to learn it.

    >>
    >> Precisely. Compared to C, C++ moves complexity /from/ N program to 1
    >> language, so I don't have to learn N different partial solutions to
    >> the same problem.

    >
    > Yes, you have a point here (You and Mr Nieminen). That is a weak point
    > in C. I am trying to address this within the C community, with
    > relatively lack of success.
    >
    > In this sense, the problems with those features is not that they exist,
    > but that their usage is extremely complicated and hard to follow.
    >
    > Templates are an example of that. They are both great when they work,
    > incomprehensible when they don't. You have then, to memorize a series
    > of "gotchas" and template conventions that make the subject
    > extremely obscure and memory consuming.


    Not really, no. Most programmers get most of their exposure to
    templates through the standard library and they don't find it obscure.
    The excellent book Accelerated C++ launches straight into the standard
    library in its first chapter.

    > Metaprogramming should be done at compile time within a specific
    > meta-language, designed to do that. This has been done with extremely
    > hard to follow templates like IF and others, that approach the
    > metalanguage goal without EXPLICITELY having a meta-language.


    Metaprogramming is really a corner case, the majority of programmers
    will never have to use it. Difficulties with metaprogramming are as
    much conceptual as they are practical, it does require a competency
    different mind set.

    > All the memory required to memorize the hacks needed now would be
    > unnecessary if we would have a simple functional language where
    > we describe templates with parameter checking, etc etc.


    Care to define one? I'm not aware of any "hacks" required to use templates.

    --
    Ian Collins
    Ian Collins, Jun 30, 2011
    #12
  13. jacob navia <> wrote:
    > All the memory required to memorize the hacks needed now would be
    > unnecessary if we would have a simple functional language where
    > we describe templates with parameter checking, etc etc. A meta-language
    > would (again) "move complexity /from/ N programs to 1 language"


    If you want that kind of flexibility and expressive power, you could
    move to lisp or haskell. However, in practice the C-family of OO languages
    (including C++, Java and C#) have the best support in most systems, so
    you are pretty much stuck. (Also, the highly functional language require
    a rather different mindset than imperative OO languages, which makes the
    learning curve rather steep.)
    Juha Nieminen, Jun 30, 2011
    #13
  14. jacob navia

    Jorgen Grahn Guest

    Templates (was Re: Why C is vastly superior to C++)

    On Thu, 2011-06-30, Ian Collins wrote:
    > On 06/30/11 06:42 PM, jacob navia wrote:

    ....
    >> In this sense, the problems with those features is not that they exist,
    >> but that their usage is extremely complicated and hard to follow.
    >>
    >> Templates are an example of that. They are both great when they work,
    >> incomprehensible when they don't. You have then, to memorize a series
    >> of "gotchas" and template conventions that make the subject
    >> extremely obscure and memory consuming.

    >
    > Not really, no. Most programmers get most of their exposure to
    > templates through the standard library and they don't find it obscure.


    I think though that to use C++ effectively you need to be able to
    write new template code; it's not one of those features you can
    happily ignore. They aren't just for people designing libraries, and
    you don't have to be into template metaprogramming to use them.

    I don't find templates that hard to grasp; I think of them as
    macros without the nasty surprises.

    Understanding /how/ and /where/ they can be useful is trickier though.
    I hope the best C++ literature out there teaches that, but I've not
    read enough of it.

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
    Jorgen Grahn, Jun 30, 2011
    #14
  15. Re: Templates (was Re: Why C is vastly superior to C++)

    Jorgen Grahn <> wrote:
    > I think though that to use C++ effectively you need to be able to
    > write new template code; it's not one of those features you can
    > happily ignore. They aren't just for people designing libraries, and
    > you don't have to be into template metaprogramming to use them.


    The vast majority of templated code required in practical projects is
    quite simplistic. Basically as "better macros" (ie. more type-safe, etc).
    It's much rarer to need the *actual* metaprogramming capabilities of C++
    templates (such as overloading, specialization, recursive template
    definitions, tricks related to conditional template instantiation,
    SFINAE tricks, etc.)

    In other words, in practical programs it's rare to need the more
    complex aspects of templates.
    Juha Nieminen, Jun 30, 2011
    #15
  16. jacob navia

    Noah Roberts Guest

    On 6/29/2011 2:04 PM, jacob navia wrote:
    > Le 29/06/11 22:20, Juha Nieminen a écrit :
    >> jacob navia<> wrote:
    >>> Memory footprint. C++ uses up a LOT of memory.

    >>
    >> I haven't noticed such a difference.
    >>
    >> (In fact, there are many cases where C consumes more memory than the
    >> equivalent C++ version because often C++ allows the compiler to perform
    >> optimizations that the C compiler cannot do.)

    >
    > Sure, but I was speaking about HUMAN memory, who cares about computer
    > memory when you can buy megabytes for a dime a dozen?
    >
    > The problem with my brain is that its memory is not extensible.


    Actually, I believe this is false. There are very few places in the
    human brain where you actually grow new neurons upon reaching adulthood,
    memory being one of those places. I'm not a neural scientist, but I
    read a lot and as I understand it this is the facts of the brain.
    Noah Roberts, Jun 30, 2011
    #16
  17. jacob navia

    BGB Guest

    On 6/30/2011 3:45 AM, Juha Nieminen wrote:
    > jacob navia<> wrote:
    >> All the memory required to memorize the hacks needed now would be
    >> unnecessary if we would have a simple functional language where
    >> we describe templates with parameter checking, etc etc. A meta-language
    >> would (again) "move complexity /from/ N programs to 1 language"

    >
    > If you want that kind of flexibility and expressive power, you could
    > move to lisp or haskell. However, in practice the C-family of OO languages
    > (including C++, Java and C#) have the best support in most systems, so
    > you are pretty much stuck. (Also, the highly functional language require
    > a rather different mindset than imperative OO languages, which makes the
    > learning curve rather steep.)



    one can partly build a Lisp-like environment on top of C or C++, say,
    via implementing a GC and a dynamic typesystem, and a lot of special
    purpose functions and macros to do various operations (such as
    car/cdr/cadr/cdddar/..., composing lists, ...).

    but then one may find that C++ may not offer much advantage over doing
    the same things in C, but C++ is harder to process via tools (say,
    writing a parser and special-purpose code-transformation or
    code-analysis logic), giving C an advantage for this use case...

    granted, one can use Lisp, but this has other drawbacks (and even in a
    pure syntax sense, Lisp is not that much better than crufted-over C WRT
    readability or usability).

    yes, one can also build a general purpose "apply" and closures and
    similar as well...


    granted, I have a custom script language, which does a lot of this a
    little cleaner, and I may gradually start migrating to this (it has
    existed a long time, but I hadn't been using it for much, as for much of
    its life prior to last-year, its C-interop was fairly poor, requiring
    lots of boilerplate, and a major usage of a lot of my fancy
    code-processing stuff is in reducing the total amount of boilerplate).

    another more common, and much older, use case (and tool), is that of
    automatically writing headers (because having to keep source files and
    headers in-sync was kind of a pain, requiring much copy/pasting of
    declarations and so on...). this tool partly supports C++, but will fail
    hard if namespaces are being used (it is not namespace-aware, and this
    would not be an entirely trivial addition).

    additionally, I may, eventually, start adding bits and pieces of C++
    support to the tools, but as is all of this is already a bit complex,
    and I have more important things to work on.


    or such...
    BGB, Jul 1, 2011
    #17
  18. jacob navia

    MikeP Guest

    Re: Templates (was Re: Why C is vastly superior to C++)

    Jorgen Grahn wrote:

    > I don't find templates that hard to grasp; I think of them as
    > macros without the nasty surprises.


    Unfortunately, they do not make the preprocessor obsolete. (But this may
    be because of the uncohesiveness of C++ features).
    MikeP, Jul 1, 2011
    #18
  19. jacob navia

    MikeP Guest

    Re: Templates (was Re: Why C is vastly superior to C++)

    Juha Nieminen wrote:
    > Jorgen Grahn <> wrote:
    >> I think though that to use C++ effectively you need to be able to
    >> write new template code; it's not one of those features you can
    >> happily ignore. They aren't just for people designing libraries, and
    >> you don't have to be into template metaprogramming to use them.

    >
    > The vast majority of templated code required in practical projects is
    > quite simplistic. Basically as "better macros" (ie. more type-safe,
    > etc). It's much rarer to need the *actual* metaprogramming
    > capabilities of C++ templates (such as overloading, specialization,
    > recursive template definitions, tricks related to conditional
    > template instantiation, SFINAE tricks, etc.)
    >
    > In other words, in practical programs it's rare to need the more
    > complex aspects of templates.


    I'll further that by saying that is is GOOD to AVOID those things if at
    all possible.
    MikeP, Jul 1, 2011
    #19
  20. jacob navia

    Goran Guest

    On Jun 28, 2:12 pm, jacob navia <> wrote:
    > Memory footprint. C++ uses up a LOT of memory.
    >
    > :)


    Well, yes, but so does remembering/understaning C++ features
    implemented in C code ;-).

    And, most likely, several times, in most slightly differing ways and
    in a suboptimal manner compared to a solution built-in in C++
    language.

    Vaguely related series of articles: http://lwn.net/Articles/444910/

    Goran.
    Goran, Jul 1, 2011
    #20
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. John Sedlak
    Replies:
    6
    Views:
    354
    John Sedlak
    Nov 4, 2003
  2. vnssoftware
    Replies:
    9
    Views:
    354
    Douwe
    Aug 27, 2003
  3. Mr. SweatyFinger
    Replies:
    2
    Views:
    1,807
    Smokey Grindel
    Dec 2, 2006
  4. Öö Tiib
    Replies:
    11
    Views:
    473
    Öö Tiib
    May 20, 2010
  5. Lynn McGuire

    Why C++ is vastly superior to C

    Lynn McGuire, May 16, 2011, in forum: C++
    Replies:
    230
    Views:
    3,935
Loading...

Share This Page