Re: Learning C++ Memory Management
"Curt Welch" <curt@kcwc.com> wrote in message
news:20090214141627.306$Qw@newsreader.com...
"Tony" <tony@my.net> wrote:
"James Kanze" <james.kanze@gmail.com> wrote in message
news:26154b1a-f7bc-4758-8906-fd01f840dd95@h20g2000yqn.googlegroups.com...
On Feb 14, 8:50 am, "Tony" <t...@my.net> wrote:
"James Kanze" <james.ka...@gmail.com> wrote in message
news:b29e95c7-661a-4012-9f6d-b8013a56713a@e18g2000yqo.googlegroups.com.
..
Curt Welch wrote:
Get TC++PL and maybe "Accelerated C++" by Koenig and Moo,
and you're going to be set until you read and comprehend
those books (it might take you a few months).
If he's looking to understand under the hood, I don't think
that the Koenig and Moo will be what he's looking for.
That doesn't read like you intended it to for most people I think.
"I can only see one way of reading it (but maybe there are too
many negations in the formulation). The Koenig and Moo teaches
programming, not how the compiler works. It explicitly deals
with higher level abstractions: you learn to use std::vector,
and iterators, rather than pointers and raw memory. While IMHO,
this is what is important, and certainly what you should start
with, the orginal poster explicitly said he was looking for
something else."
At first glance, it seemed (to me) that the OP was looking for things
like "concrete C++ data type" and "bitwise copy" and the like, which I
don't consider low level. After actually _reading_ the OP's post, I think
one thing he's asking for is a tome of some sort that describes all the
compiler activities that occur with class objects whether concrete or
not. Anyways, given that, I found more than one way to grok your comment.
I think there are chapters in "Accelerated C++" that may give _some_
insight to _some_ issues to the OP, but I think the info he is looking
for isn't compiled in a single place (but I haven't been looking for such
info either to know whether it is or not).
Tony
Yeah, I don't need exact compiler bit for bit implementation details, I
just need to know all the abstractions required to write C++ code
correctly. However, since C and C++ are languages extremely close to the
hardware, the abstractions required end up being nearly compiler specific
details becuase most the compiler specific details end up being exposed to
the programmer (as though the sizeof operator, and unlimited pointer
manipulation).
For someone just starting in C++, most the specifics can be, and typically
are, left out. But to really know the language, you need to understand
all
the specifics. I was getting frustrated by the books I was reading not
giving me enough details for my taste.
For example, when you simply declare:
SomeObject x;
It was not clear to me if x was the memory for the object, of if, like
with
Java, the variable was really a pointer to the object with the object
allocated automatically on the heap. That's the type of detail the C++
books don't start out talking about, but which I, as a long time C
programmer, want to know first off. You can read a few chapters of a
typical C++ book and still have no clue whether "SomeObject x" was
allocating a pointer on the stack or allocating the object itself on the
stack. I eventually figured out it was allocating the object on the
stack,
but that you can declare pointers and allocate memory yourself using new
etc.
The key to being able to understand the above immediately (when coming from
the world of C) is to realize that C++ was NOT developed as a
new/from-the-ground-up language like Java (pretty much) was. The behavior of
the above should be "kinda" obvious: that it is a stack object "like any
other built-in type" that C offers. The problem you had, I think, was that
you had TOO MUCH knowledge of the other languages and you "over-thought".
Had you had ONLY knowledge of C, it would have been easier to make the
correct assumptions.
But the same sort of confusion was happening for me with the automatic
calls to constructors and destructors. The answer is that it does most of
what it needs to do automagically so C++ books don't start out talking
about it.
I think the answer is there in the books, but it gets glossed-over. The
casually throw out concepts like "concrete data type", "first-class objects"
and don't dwell on or give insight to the behind-the-scenes compiler
activities. You're right, there should be a few sections in a chapter about
that stuff. For me, that kind of information was first presented to me in
Coplien's "Advanced C++" where he establishes that "concrete data type"
means the "orthodox canonical form" that consists of a default constructor,
a copy constructor, a destructor and an assignment operator. Over the years,
I've just gotten what knowledge that builds on that from a myriad of places
(and I do take most of it for granted unless something weird starts
happening and I find myself in the debugger).
Guess what the following does:
class MyObject
{
int val;
public:
MyObject(){}
~MyObject(){}
MyObject& MyObject(const MyObject& obj){ val = obj.val; }
MyObject& operator=(const MyObject& obj) { if(&obj != this) val =
obj.val; return *this; }
MyObject(int v){ val = v; };
};
MyObject obj() = 39;
You might think that the default constructor and then the assignment
operator is called. Tracing that with a debugger shows that the overloaded
constructor with the int argument is called .
That by the way is perhaps the best recommendation: experiment with the
compiler/debugger and watch what happens!
[snipped relevant, but long, similar example issues]
It's just going to take some time for me to pick all this up. Mostly,
it's
just climbing a learning curve that requires writing a lot of code no
matter what books you are using. The TC++PL book I'm sure will help
however and that's the type of advice I was looking for when I posted.
There's just so much reference material available on C++ these days it's
hard to know where to turn without some advice.
A debugger will probably be your best friend for awhile: it's quicker to
just watch what happens than reading about it, but surely the literature or
other info sources will answer any questions about why it works as it does.
Answers to thornier issues can be gotten from the many gurus who post in
this NG. Oh yea, don't forget about the c.l.c++ FAQ and googling past posts,
for issues you may be encountering, in the C++ newsgroups, as they are
another majorly good source of info and chances are someone has asked the
question a number of times before.
Good Luck!
Tony