J
jacob navia
Memory footprint. C++ uses up a LOT of memory.
J
jacob navia
Le 28/06/11 14:12, jacob navia a écrit :
Attention TROLL message!!!
Memory footprint. C++ uses up a LOT of memory.
Attention TROLL message!!!
N
Noah Roberts
Memory footprint. C++ uses up a LOT of memory.
That's because it's incremented. Higher value integers use up more memory.
J
jacob navia
Le 28/06/11 19:02, Noah Roberts a écrit :
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.
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.
J
Juha Nieminen
jacob navia said:
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.)
J
jacob navia
Le 29/06/11 22:20, Juha Nieminen a écrit :
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
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
I
Ian Collins
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.
Not if it has a decent testing framework.
In nigh on 20 years of developing C++ code and development teams, I
haven't found this to be a problem.
J
Juha Nieminen
jacob navia said:
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.
I don't think C is much better in this regard.
J
Jorgen Grahn
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
J
Jorgen Grahn
.
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.
They aren't part of the language -- if I understand correctly, because
they were not properly understood.
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.
Or noone here can be bothered to decipher every piece of problem code
posted.
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
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.
They aren't part of the language -- if I understand correctly, because
they were not properly understood.
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.
Or noone here can be bothered to decipher every piece of problem code
posted.
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
J
jacob navia
Le 30/06/11 08:10, Jorgen Grahn a écrit :
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
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
I
Ian Collins
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 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.
Care to define one? I'm not aware of any "hacks" required to use templates.
J
Juha Nieminen
jacob navia said:
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.)
J
Jorgen Grahn
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
J
Juha Nieminen
Jorgen Grahn said:
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.
N
Noah Roberts
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.
B
BGB
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...
M
MikeP
Jorgen said:
Unfortunately, they do not make the preprocessor obsolete. (But this may
be because of the uncohesiveness of C++ features).
M
MikeP
Juha said:
I'll further that by saying that is is GOOD to AVOID those things if at
all possible.
G
Goran
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.