10 Jun, 2009, Silenus wrote in the 1st comment:
Votes: 0
Hi,

I am curious if you are trying to develop expertise in this area what is the best way to go? I am mostly a hobbyist programmer at the moment and I am curious how best to learn how to apply the language to complex problems. C++ to me seems to be a rather complex language and I do not as of yet fully understand the runtime model of the language and how it maps to the machine. I have tried reading some books on the subject but I am not sure if they are particularly good ones (like Modern C++ design, Exceptional C++ and More Exceptional C++). Modern C++ Design doesnt for example give a full description of the rational behind some of the design decisions made and how those conclusions were reached there are also a number of claims in the book (I am sure the author is correct but I am curious how he reached his conclusions) which I am not sure how to verify. I.e. that standard heap allocators are not very efficient for managing small memory chunks.

My thoughts here were perhaps to study the STL library code or other libraries such as Loki but I was curious if there may be faster or quicker methods.

Thanks in advance.
10 Jun, 2009, David Haley wrote in the 2nd comment:
Votes: 0
The design goals for C++ were relatively simple: they wanted to add object-oriented programming (and a few other things) to C, but such that you only incurred performance penalties if you actually use the new features. This is why, for example, methods are not virtual by default. For many OOPers, methods are nothing but virtual, and so having to actually specify it is kind of confusing at first.

The answer to the allocator question is probably that it gets fragmented quickly. I'm not sure this is the kind of thing you should be worrying about when just learning the language, though.

I'm not aware of any "fast, quick" method other than just getting your hands dirty with it. Following books or materials from online college courses is what I would recommend.
10 Jun, 2009, Silenus wrote in the 3rd comment:
Votes: 0
Well my complaint concerning standard course materials is alot of times they tend to be a bit watered down these days(or perhaps there are very few advanced courses in programming). The difficulty I am having with the get your hands dirty approach is of course- get your hands dirty with what? I understand from the C++ object model book that different forms of inheritance w.r.t. virtual functions SI versus MI have different performance penalties and how also have notions such as virtual base classes of course. But through the course of a programming project or messing around with code you may or may not observe these differences since they may not arise in code.

Similarly with templates and static metaprogramming tricks. I would be rather surprised if most introductory courses cover these sorts of things but I suspect to develop expertise in the language you would be expected to know them and when to apply them. I at this point only know of them and perhaps the rudiments of how they should be applied but I am deeply unfamiliar with how a C++ compiler would convert this code into machine form. Also i recently encountered template template parameters which dont seem to be covered in most C++ language texts though they solve some problems in a nice way.
10 Jun, 2009, Tyche wrote in the 4th comment:
Votes: 0
If you are interested in theory, books and papers by the following two individuals is definitive of why C++ is the way it is today.
http://en.wikipedia.org/wiki/Bjarne_Stro...
http://en.wikipedia.org/wiki/Alexander_S...

…and I do not as of yet fully understand the runtime model of the language and how it maps to the machine.

There is none. The C++ specification doesn't address implementation. For instance, there's no requirement that an implementation even have a stack.
10 Jun, 2009, David Haley wrote in the 5th comment:
Votes: 0
Silenus said:
But through the course of a programming project or messing around with code you may or may not observe these differences since they may not arise in code.

And, well, you're also unlikely to care.

What are you trying to learn? How to write pretty good C++ code, or how to understand every last minute detail of the language?

Silenus said:
Similarly with templates and static metaprogramming tricks. I would be rather surprised if most introductory courses cover these sorts of things but I suspect to develop expertise in the language you would be expected to know them and when to apply them.

Templates were covered in the first C++ class where I went to school. Metaprogramming is a fairly esoteric topic and not necessarily used all that often. I definitely wouldn't worry about it while trying to learn the language.

Silenus said:
I at this point only know of them and perhaps the rudiments of how they should be applied but I am deeply unfamiliar with how a C++ compiler would convert this code into machine form

Well, learning C++ is extremely different from learning how compilers would work…

Anyhow, the translation to machine code is quite simple, in some sense. As soon as the template has been instantiated, machine code is generated for it just like any piece of code. The more interesting problem of metaprogramming for instance is how the compiler instantiates the template.

Keep in mind that many metaprogramming tricks are just that: neat tricks.

Quote
Also i recently encountered template template parameters which dont seem to be covered in most C++ language texts though they solve some problems in a nice way.

I'm surprised at this, unless you're not using "template parameters" to mean what I think they mean. It's pretty hard to use a std::vector without parametrizing it, for instance… Anyhow, it works just like a function parameter, in some sense, except that everything happens at compile-time, not run-time.
10 Jun, 2009, Tyche wrote in the 6th comment:
Votes: 0
Silenus said:
…I am deeply unfamiliar with how a C++ compiler would convert this code into machine form.


It's a mystery to 98% of C/C++ programmers as well.
And yet they still claim C/C++ are "close" to the machine.
Neither C or C++ are any "closer" to the machine than Fortran, BASIC or COBOL.
10 Jun, 2009, Silenus wrote in the 7th comment:
Votes: 0
Well I did read design and evolution of C++ sometime ago though I have since forgotten what I have read. I guess what I was referring to was the C++ object model book though I am not sure if the description of how C++ is implemented there is specified by the object model. I have followed to some extent some of the books and papers written by Stroustrup but up to this point have only read one piece by Stepanov (I think some document related to the original STL implementation in college).
10 Jun, 2009, elanthis wrote in the 8th comment:
Votes: 0
What you're talking about is the usual issue of learning concepts versus learning practical uses. This is the fundamental problem with trying to learn any real skill in an academic setting. They can teach you every fact and every trick, but the one and only way to actually figure out what the hell you're doing is to just do it… over, and over, and over, and over.

This is one of the reasons why goofy little hobbyist games (be they MUDs or something in another genre) are so fun to work on. You aren't under a large amount of pressure to "do things right" the first time around, nor are you required to do things under a tight a schedule, so you can experiment with template metaprogramming or alternative object systems or whatever else you're interested in but have no need to use in "real" projects. :)

You can study libraries or other people's code all you want. You're not going to really learn anything if you're not writing code, but you're not going to learn anything if you just write code in isolation, either. Keep it in balance.

If you have any specific questions, there are a few people here who can either answer directly or point you in the right direction (like Tyche and David have already done).

(PS, the books you mentioned are in general considered to be exceptionally good, as is anything else by Scott Meyers – I know at least one well-respected, top-tier university that uses "have you read Scott Meyers" as a criteria for entering their grad-school computer science program. Don't take that to mean that he's the only source you should refer to, though, by any means. You might want to get Design and Evolution of C++ to answer your questions about rationale, and also peruse the papers in the C++ Working Group at http://www.open-std.org/jtc1/sc22/wg21/d...)
10 Jun, 2009, Silenus wrote in the 9th comment:
Votes: 0
By template template parameters I meant constructs like this-

template <typename T, template <typename> class Cont>

As for Fortran/COBOL etc being as low level as C/C++. Isnt the difference here that with void casts and certain other tricks you can manipulate more or less raw memory locations and also specify how things to some extent are layed out in memory. I remember leafing over the LLVM VMKit and finding comments in parts of the code indicating that the ordering of how the fields were declared was important and should not be modified.

As for Scott Meyers books. I know they come well recommended but sometimes I wonder a bit as to why. Alot of the recommendations he makes seem sometimes to be somewhat on the obvious side(again I read these along time ago but came back to them recently). There are some nice nuggets in the book however. I found a recent book C++ common knowledge to be a bit better presented.

Thanks everyone for the input.
10 Jun, 2009, Tyche wrote in the 10th comment:
Votes: 0
Silenus said:
As for Fortran/COBOL etc being as low level as C/C++. Isnt the difference here that with void casts and certain other tricks you can manipulate more or less raw memory locations and also specify how things to some extent are layed out in memory.


Okay, take COBOL and C for example:

struct c_struct {
char name [10]
int amount;
}
01 c-struct.
02 name pic x(10).
02 filler pic x(2).
02 amount pic s9(9) comp-5.

union rec {
int i;
char a [4];
double d
}
01 rec.
02 i pic s9(9) comp-5.
02 a pic x(4) redefines i.
02 d comp-1 redefines i.


char * x;
char y[10] = "hello";
x = strdup(y);

78 c-null value x"00".
01 y pic x(9) value "hello" & c-null.
01 x pointer.

procedure division.

call "strdup" using
by reference y,
returning x.


The last call is somewhat more complicated than above, as strdup() calling convention requires some additional
setup. Anyway, it illustrates that I can surely layout or map memory just like C and can handle both pointers to
functions and memory. Does that make COBOL a low-level language? ;-)
10 Jun, 2009, flumpy wrote in the 11th comment:
Votes: 0
Silenus said:
As for Fortran/COBOL etc being as low level as C/C++. Isnt the difference here that with void casts and certain other tricks you can manipulate more or less raw memory locations and also specify how things to some extent are layed out in memory.


POKE 47196, 201

http://en.wikipedia.org/wiki/PEEK_and_PO...
10 Jun, 2009, quixadhal wrote in the 12th comment:
Votes: 0
My instructor flat-out refused to teach pointers in COBOL. *grin*

Seriously though, COBOL is kindof a low-level language, when you think about it. Sure, it's meant to be English-like in terms of reading the source code and having it sound like you're speaking words instead of symbols…. but you do a lot of specific structuring of the data, knowing how the data will sit in memory or on disk. That is rather low-level, compared to something like Perl.

Not a bad thing, mind you. :)
10 Jun, 2009, flumpy wrote in the 13th comment:
Votes: 0
quixadhal said:
My instructor flat-out refused to teach pointers in COBOL. *grin*

Seriously though, COBOL is kindof a low-level language, when you think about it. Sure, it's meant to be English-like in terms of reading the source code and having it sound like you're speaking words instead of symbols…. but you do a lot of specific structuring of the data, knowing how the data will sit in memory or on disk. That is rather low-level, compared to something like Perl.

Not a bad thing, mind you. :)


To be honest, I think COBOL is entirely underated. When I was learning it, it felt so easy to manipulate files - like how you would expect to be able to. Compared with how I had been learning to do it in C++, it was a world apart but whilst still maintaining that feeling of having to know what the data was doing.

Nothing I've ever used since has ever given me the same ability with flat files.

Its almost a shame that databases made doing this kind of file manipulation almost obsolete. It was so *nice* to do.

I guess when you're talking about "high level" you really mean "without having to think (much) about memory and disk management", but I would expect in every language except a sandboxed one (like java) you would still be able to do anything you like with your computer's hardware.

And you only cannot do that with java because you are never sure what platform you will be on. I can still write byte code if I should wish…
10 Jun, 2009, Silenus wrote in the 14th comment:
Votes: 0
That is quite interesting I wasnt aware that COBOL was used in that fashion. So basically you can do systems level programming in something like COBOL as well as you could do it in C? I remember programming BASIC when I was rather young and vaguely remember PEEK/POKE now. Fortran I havent used though I have read some scientific Fortran code but most of this sort of code dont really contain stuff like that.

Well sorry for all the questions but I am quite the ignoramus :P. The thing that I dont understand is I expect that you do need a fair amount of understanding of how things are laid out in the machine to know how to do things well in any of these languages- but nowadays most books I find on C++ seem to gloss over these issues. Is it just assumed that you would know these sorts of things?
10 Jun, 2009, Runter wrote in the 15th comment:
Votes: 0
Silenus said:
Hi,

I am curious if you are trying to develop expertise in this area what is the best way to go? I am mostly a hobbyist programmer at the moment and I am curious how best to learn how to apply the language to complex problems. C++ to me seems to be a rather complex language and I do not as of yet fully understand the runtime model of the language and how it maps to the machine. I have tried reading some books on the subject but I am not sure if they are particularly good ones (like Modern C++ design, Exceptional C++ and More Exceptional C++). Modern C++ Design doesnt for example give a full description of the rational behind some of the design decisions made and how those conclusions were reached there are also a number of claims in the book (I am sure the author is correct but I am curious how he reached his conclusions) which I am not sure how to verify. I.e. that standard heap allocators are not very efficient for managing small memory chunks.

My thoughts here were perhaps to study the STL library code or other libraries such as Loki but I was curious if there may be faster or quicker methods.

Thanks in advance.


Something I found many years ago about myself is that I learn best by applying things I read immediately. You might try finding some good books/tutorials and start reading a little bit/writing code and repeating. It has worked for me through about 8 different languages now.
10 Jun, 2009, Silenus wrote in the 16th comment:
Votes: 0
Thanks. It's just a concern of mine that for most projects I dream up most of the skills I would like to master per C++ may not appear in the program i am working on without severe contortions. Perhaps I am a bit obtuse but I find C++ quite difficult. This may be because there are still some gaps in my knowledge which has forced me to go through alot of basic CS topics all over again and to do things with C++ well especially for a deep knowledge of the subject I really need to have a good understanding of the machine level. However most C++ books focus heavily on OOP/OOAD.

How things map down to machine code also seems hard to predict :/. I guess what I will do is just write short snippets or exercise type projects to master individual areas as I proceed through the books.
10 Jun, 2009, elanthis wrote in the 17th comment:
Votes: 0
Silenus said:
Thanks. It's just a concern of mine that for most projects I dream up most of the skills I would like to master per C++ may not appear in the program i am working on without severe contortions.


Hardly. Almost every C++ feature will end up getting used in any large program, although the degree to which it's used may vary. Templates for example are used every time you use the STL, and it's not _too_ uncommon to define your own container types.

Quote
Perhaps I am a bit obtuse but I find C++ quite difficult. This may be because there are still some gaps in my knowledge which has forced me to go through alot of basic CS topics all over again and to do things with C++ well especially for a deep knowledge of the subject I really need to have a good understanding of the machine level.


Do you know C? And I don't mean syntax and basics; do you really know C, and all its associated topics? If not, you'll never understand C++. Get a very firm working grasp on C and C++ becomes a piece of cake, because all C++ is is a bunch of syntactic sugar over C… which is really just a bunch of syntactic sugar over assembler. This is why I highly dissuade people from learning C++ first: it's just not possible to actually learn C++ first, because C++ isn't really a separate language conceptually, it's just a set of extensions over C.

Quote
How things map down to machine code also seems hard to predict :/


The generalities are easy to predict, especially if you go and learn C first and understand how that works. The specifics of the machine code generation are absolutely impossible to predict, because the specific machine code output is highly dependent on the compiler, optimization settings, and so on. The resulting output may not look like a direct mapping of your original code because modern CPUs are quite complex and compilers pull off a lot of tricks to get better performance; tricks that no human is expected to be able to do by hand.
10 Jun, 2009, flumpy wrote in the 18th comment:
Votes: 0
elanthis said:
Do you know C? And I don't mean syntax and basics; do you really know C, and all its associated topics? If not, you'll never understand C++.


I guess you don't mean that you can't learn C concepts in C++.. it's perfectly feasible to ignore all of the ++ bits of C++ and concentrate learning how to program that way.

I learnt programming in BASIC, then in C++ (and then other languages after) … never did me any harm.
10 Jun, 2009, David Haley wrote in the 19th comment:
Votes: 0
elanthis said:
it's just not possible to actually learn C++ first, because C++ isn't really a separate language conceptually, it's just a set of extensions over C.

Well, it depends on where you are. For people just learning to program, I believe this statement to be false for empirical reasons – several schools teach the concepts together successfully.

Silenus said:
How things map down to machine code also seems hard to predict :/. I guess what I will do is just write short snippets or exercise type projects to master individual areas as I proceed through the books.

I still don't understand exactly what your goal is here. There's a big difference between learning C and C++, and learning what kind of machine code is generated. I think it's obvious by now that you are at least curious about it, but I'm trying to understand if you think it's somehow integral to learning C++ as a language.
10 Jun, 2009, Runter wrote in the 20th comment:
Votes: 0
I kinda disagree with the assertion you have to learn C before C++. I've seen successful programs teaching C++ as a singular language. I'm sure it can work just fine both ways, actually.
0.0/54