I think the point is that you need to learn the basics of the language before learning the more complex parts (which strikes me as somewhat of a truism, actually), although I agree that that doesn't necessarily translate into learning C proper before seeing C++.

Maybe it's just in his opinion that you need to learn C before C++, because he believes its less easy to get lost in the syntax? In which case sure, thats a valid opinion to have if he has found that tactic works for him.

Generally however, I beg to differ but thats just me.

I believe it's best to learn C because you literally cannot understand what C++ is doing without learning C. Everything C++ does is just using C with some extra stuff on top. You can't understand how to manage objects in memory until you understand pointers. You can't learn how to write methods until you know how to write functions. You can't learn how to encapsulate data until you know how to use data. You can't expect to understand what a C++ object is at a machine level if you don't understand structs or arrays.

C++ is not a different language (conceptually). It's an extension to C. You can't learn to read and write before you learn the alphabet. Sure, using a std::string is way, way easier than using a C string. But you will never understand what the hell std::string is actually doing if you don't know what a C string is, how to use it, how it works, and why C does things the way it does it.

Yes, you can learn C++ first. I don't think you should. Most people I've met who learned C++ as a language separate from C never really learned what was going on at a low level and tended to treat C++ like it was just a more complicated Java, and their code quality suffered tremendously for it. C is _easy_ to learn, compared to C++, and there's really no point to jumping right into STL containers and templates and crap if you haven't even learned the fundamentals of C programming.

So your problem is with people who don't go back to learn the basics, not with people who start simpler and gradually build up.

I wouldn't expect a new programmer to know how objects work at the machine level. In fact I wouldn't want to teach any intro programming course that went into such detail straight away.

It's hard enough to learn programming conceptually without having to waste time on details that are only relevant later.

I think that what you are really objecting to is not learning the low-level aspects of C/C++, not so much the order in which they're learned. In other words, I think that your complaint would be (as expressed, at least) satisfied by somebody who started with C++ and std::strings, and later on learned the low-level details.

EDIT:

As a language, perhaps, in the mathematical sense, but not in the sense of actually getting things done. It's far harder to do very basic things in C than it is in C++, even if (especially if?) you don't understand all the behind-the-scenes details.

Well, when I went to university the program introduced C++ with no prior knowledge of C and the program worked just fine. In many cases, I had to go back and learn things to deal with legacy C code, (like better knowledge of c-strings), but if the alternative is someone learning C with no expectation of having to learn C++ I disagree with that proposal 100%.

edit:
I think the 'To C++ or not to C++' threads that pop up from time to time prove the problem with people never properly transitioning into the basic concepts that make C++ a more productive language. I think the question shouldn't even be discussed. It should have been their plan from the moment they picked up C to eventually move into C++.

edit:

And yes, I know there are still reasons for using exclusively C code. None of those reasons justify not learning C++, however.

I guess I will try to clarify some. To me achieving expertise in this language, not just knowing the basic constructs and how they interact- but being how to predict how they may or may not look in assembler, and being able to predict/assess performance to some degree and which optimizations are applied seems to me to be an integral part of the experience at this point. I could be wrong in that I am speculating based on what some of the authors of these books seem to know which I do not. To me at least just knowing the language constructs and the semantics of these constructs without understanding on some level how they are implemented is problematic to me. I think learning the language is one thing (assuming you avoid in C++ in particular some of the nastier corner cases and do not need to know everything) but achieving expertise in it on the level perhaps of some of the authors of these books is another.



Well I agree with you here in that alot of feature categories will get used but I am trying to master specific techniques and details. For example in a chapter of modern C++ design there is a discussion on typelists which is an example of static metaprogramming(other examples in the book are partial template specialization). I haven't seen outside of intentionally writing library code where techniques which involve complex interactions between templates/inheritance employing stuff like the template template parameters I mentioned are used much outside this domain. So what I am suggesting is to master these details it may be perhaps better to churn out some small exercise like projects where they occur rather than writing an application where they might or might not show up at all or constitute maybe a fraction of the resulting code.



I have taken introductory courses in C and C++ and written code with both but TBH there is good deal I do not know about both languages. I am still uncomfortable with some of the distinctions presented in Expert C for example. When I took these courses the emphasis was often on how to use features and constructs in the language not on to what degree can you predict or learn to predict what the compiler will do with the code and how with a superscalar/pipelined processor with a cache hierarchy to best structure the code to get good performance. Or if you are working with multicores how to predict the effects of things like cc-NUMA. My impression is that to be a good C/C++ programmer you would need to know these details.

I think one shortcoming of alot of C++ courses is they spend alot of time on OOP and OOAD concepts without teaching enough machine details. I guess this has become the canonical way of teaching languages like C++ but to me it does seem to have its shortcoming because my knowledge of the above is in fact quite limited compared to the authors of these books(I am grateful also that they are willing to take the time out of their busy professional schedules to write down some of the stuff they have learned and convey them to others).

I guess you're just operating on a very different definition of "expertise" than I am. Perhaps I'm being immodest but I consider myself to be a fairly proficient C++ programmer at the least, and while I have a good understanding of the general principles of machine architecture, I know relatively little about the specifics of x86 assembler and how exactly a C++ program would translate into some exact assembler.

That said, I don't think that I actually need to in the vast majority of cases, because I'm not writing extremely high-performance inner-loops for graphics applications or other hyper-real-time applications. The kinds of applications – or more specifically, the places in those applications – where you truly need to squeeze out every last machine instruction are really relatively rare. Frankly, I don't fully understand why you think you need to either. I think that what you're talking about is expertise in a given architecture's assembler and how a compiler would target it, and it's somewhat orthogonal to fully understanding the semantics of C++.


To be honest, if somebody came to an introductory class expecting to learn things like that, while still learning C++, I'd tell them they needed to seriously readjust their learning goals.

Learning C++ is an entirely different affair from understanding pipelining or how a compiler would target one pipelining processor versus another.

I think there's really an awful lot being conflated into one question here. To be entirely honest, it kind of sounds to me like what you're really trying to learn is the meaning of Life, the Universe, and All Things Computer – you seem to want to have total mastery of not only the language, but also the compiler, the machine architecture, all the components of the system, and so forth. I don't think it makes sense to discuss all of those if the goal is just to learn C++. One thing at a time and all that. You cannot realistically expect to learn all of this at once. Just take your time and you'll end up making much more forward progress anyhow.


I would think that any university that teaches introductory C++ while expecting students to learn or understand pipelining and all that jazz is shooting itself in the face and hurting students far more than helping them. Just my opinion, although I'll throw out there that that's based on experience actually teaching this stuff to people.

Data General's BLIS/COBOL operating system was written in COBOL. IBM wrote much of the MVS operating system in PL/S which was an in house variant of PL/1. The main difference is that C was deliberately created for operating systems development.



You won't find any of these issues discussed in C or C++ books because they are high level languages which are portable to many machine architectures, operating systems and compilers. Your only control over the code generated is in choosing whatever compiler switches are available in any given implementation to give it hints as to which optimizations it should try and which architecture to target. It should be fairly obvious that no C or C++ class from beginning to intermediate to advanced is ever going to cover the code generated, because it's unknowable and thus unteachable.

This is exactly the sort of hint/suggestion/warning that a programming language guide might make which is provably true at the time of writing in most cases (and most of the authors I've read make with qualifications). Perhaps later on becomes less true or even false, and sometimes persists for a long time ever after as myth.

I guess I have to clarify a bit further then. I think that though often in a standard curriculum you tend to partition things into to boxes these "boxes" in practice are somewhat artificial. I suspect to be a good C++ programmer you will have to have some understanding of machine architecture and the ability/knowledge of how to interrogate the system and see what it is doing. It also isnt about need- alot of times what is minimally needed to do something is quite different than what it takes to do something well. I guess this is a very general point.



Perhaps. Obviously there is some hyperbole in here but I will stick to your main point as best as I can understand it. I think I am talking about expert level C++ programming not just learning the most common features of the language (learning all of C++ I still feel takes a significant effort compared to say C. I can write a C compatible grammar quite quickly but doing this just for C++ would take extreme effort and many months. If syntax is any measure of overall language complexity and it may not be I would say that most people unless maybe you are a guru class C++ programmer really have fully learned all aspects of the language and even then the understanding of these features and their implications are continuously changing. I believe most schools try to teach C++ in a semester to people with no background at all but I suspect to even know the language passably well could take years. So doing things somewhat concurrently seems appropriate here.

I also dont think I said anything about learning all this at once- but I am looking for guidance w.r.t what materials would I need to cover to reach a target even if its most likely months or years down the road and how best to accomplish it. The flipside of taking your time without setting yourself targets is that you may just end up doing things like running through chores and not learn a single thing.

Also for conflating things- this is somewhat deliberate. I am trying to ask a big question :D.

As for introductory courses not covering enough machine architecture. I feel that the problem here is you often have two audiences for people taking introductory courses in lang X. People who are learning there first language where I could understand where your concerns might be and people who already know a number of languages to some extent (I dont claim to be that proficient in any of the languages I know) and what to understand since C is used for OS type stuff why this is the case, what benefits it brings and how its employed in this capacity. I suspect you might be talking about the first group whereas alot of us fall into the second group.



If this is the case- for me it might be extremely problematic- I speculate (based on what little I know which may not be very much) that it may be possible to some extent to incorporate some examples of how a process is typically organized and how the memory is laid out etc.

I guess they only can put so much content into a book but it would be nice if these sorts of things were substantiated or justified so you could see the context and make a judgement call as to whether it was still relevant.

I think this discussion is crossing several different topics, and there is some confusion about what Silenus' goals are. Until we understand, we are never going to be able to help him.

"Computer science is no more about computers than astronomy is about telescopes." - Edsger Dijkstra

In astronomy, there are red dwarfs, gas giants, planets, stars, black holes, dark matter, telescopes, etc etc etc.

In computer science there are algorithms (many, many types), OO programming, memory models, business oriented design, systems programming, analytical programming, embedded systems, etc etc etc.

A language is the tip of the iceburg. C is largely completely useless in the business world, because modelling with it is complicated and frustrating. Java is useful in many situations but the language and the JVM have to be tailored to suit the needs of the platform (no matter what sun might have you believe). I can no more program effectively in a J2ME environment than I can a C++ one, and I have many years programming with Java.

What this means is: what do YOU want to study? How do you want to "become an expert"? What are your goals? Why do you program in the first place?

Example:

I program because I enjoy to make something that makes other people able to do their job, and although enjoyable is a little boring after a while. However, I love the thrill of fixing a live issue. But I am happiest when I am pootling about coding my mud engine because I can do whatever I like without any pressure…

I need to learn how to model business ideas, because thats where I work, and I need to learn how to profile the performance of large applications and learn how best to make them work together. But I want to learn how to program a mud, because thats what I love.

All three areas are entirely different. The first one I have to be an expert in. The second I have to try because that will advance my career (perhaps). The third is for fun because I love it.

What about you?

This might be my fault a bit since it's still all a bit nebulous in my mind. I am sort of at the crossroads at the moment and trying to make decisions about various things and assessing my interest in them. For example I was considering pursuing a PhD degree in Computer Science recently and decided against it because of my age and the amount of time it would take to get through the program. So I have been gradually trying to move from a more theoretical academic view of thing to one which is more in line with practice. The difference are obviously quite marked. Doing theoretical stuff involves a fair amount of mathematics with only a limited emphasis on actual software development.

Obviously Computer Science practiced in academia is an exceedingly large are and so is doing programming in practice. Most individuals end up specializing in certain areas and generally know less about others. Academically I am currently somewhat interested in three areas, Compilers, Parallel algorithms and Natural Language Processing. Doing good implementation work in the first two areas and my interest in muds as well as the chinese game of wei-chi and the latest breakthroughs in that area have led me to desire to master C/C++ since most projects in these areas are written in languages like these because they are rather close to the hardware(muds being the exception here but lpmud drivers are generally written in C).

My goals-

1) being able to hack/develop and modify things like existing lpmud servers or develop my own and make modifications to frameworks such as LLVM in order to enhance them.
2) be able to understand and optimize parallel codes and develop applications on frameworks such as MPI/OpenMP/PThreads etc.
3) A firm understanding of the implications practically of some of the constructs that go into parallel languages such as ZPL/the Galois System etc.
4) Learn more about systems level programming (I think this stuff is neat but I dont know much about it).
5) Be able to develop compilers backends for different architectures.

I am currently primarily a hobby programmer who likes implementing various things to test ideas and primarily for the intellectual challenges. At some point I might consider changing into this area as a career but I really feel that presents some challenges given my age. Regardless I would like to deveop a skill set where I can tackle some of the above with some proficiency.

I think that in the end of the day, you're expecting to find a guide or book that will explain all of these topics neatly and concisely, whereas in practice, this is the kind of stuff that people go to college for and learn about over several years. I also think you have something of a misconception of what C++ programmers actually do, based on statements like the following:

Yes, I'll concede that understanding the general concepts of machine architecture are helpful. But for the vast majority of code, you don't really have to care what the specifics of your platform are. You start caring when writing extremely performance sensitive code, the kind of code where a few extra instructions per loop will actually matter. Think a bit about how often that actually occurs today. Heck, think about how often that occurred ten years ago.

But really, you very rarely actually "[talk to] the system" to "see what it is doing" – you just write your code and let it all do its thing.


Well, typically intro classes are teaching programming using C++ as a base, and you go on to take many, many more courses that (albeit implicitly) teach you much more about programming. Nobody in their right mind comes out of a single class thinking they're a proficient programmer.


But very few courses actually target the second group, so most materials directed toward learning C++ will tend to assume that you're learning to program, hence why you don't get bombarded with all the detail there is to know.

—–

To answer your question, at least in the form I'm starting to understand it, I don't think that there is any source. You'll have to learn about all the topics separately and then put it together in your head. Keep in mind that each of these topics typically requires several courses or more to start truly understanding.
Several classes are usually "epiphany moments" for students, as a lot of things start to click. Where I went to school, Operating Systems and Compilers were such classes for many people, as by then you had already built a wide base of independent topics, but those two courses force you to put a lot of things together.

The best advice I can give is to just start doing stuff. I think you're setting the bar far, far too high for yourself, and it feels like you don't want to even get started until you have a handle on everything. Just jump into it, learn about things over here, write code over there, put things together, watch them break, fix them, rinse, wash and repeat. And then do it over again for good measure. I'm not trying to be facetious, and as evidence I'll put up that several other people have said the same thing. The best way to learn this stuff is to just do it. It will come with time, and it's not really realistic to think otherwise.

AFAICR a phd course is about 5 years? How old are you if you dont mind me asking?

Get hacking then! No time like the present.
I won't pretend to understand what those things are. But again, get started with something small and work up. Read books where you can, take the knowledge to help you solve the problems you face.



Ok well, find some technical manuscripts of a few different (simple) chip and board architectures, read them, buy an old z80 or x86 processor based machine to begin with and learn how to program on it using a couple of different languages. Try writing an OS with C to start with, see how the bios hooks in and try to imitate a DOS or Unix kernal. Keep it all really simple, and build up from there. You can't learn how to write a compiler if you don't understand the machine language of the platform you are working on, so study that. The z80 processor and the x86 processor are odd chip architectures, but pretty straight forward. Keep in mind the computer is actually very very simple, its all 0's and 1's after all, its how to represent more complicated things with 0's and 1's that is the trick.

You can get to the complex stuff by starting simple. It will all come as you start building.

Yeah I feel this is somewhat unfortunate though. Though I do have an undergraduate degree in computer science I feel that having some of these details presented may be beneficial though this does not tend to be the way the curriculum is organized. This leaves alot of individuals in a bit of a bind. As for all the details there is to know I think that you wont even get to this even if you have a phd. It is more a point about the selection of details. (I know this is a standard phrase educators employ sometimes sort of like the know it all phrase you employed before and both entail a certain amount of hyperbole).



Oh I am in my mid 30's now- so I am guessing I will likely be over 40 upon completion and then have to do a year of postdoc work. I was talking to someone recently who felt I was reasonably qualified to do this (he was hunting for a phd student). I pointed out there were significant gaps in my understanding but he felt given what I did know I could probably learn the rest on my own perhaps with a bit of help.



Good advice. I have been sort of jumping back and forth between writing code (though nothing worth releasing) and reading through textbook materials and finding short programs I can write which I can use to test my understanding of various things. Thanks.

I don't think 40 is very old for the type of jobs a PhD is likely to open up. I'm just about 40 myself and only have a BS, of course I live in Unemploymentville (Michigan) at the moment, so I may not have good advice to give. *grin*

I found that I learned programming on my own, from hobbies ranging from my first AD&D character generator (in BASIC, on the C64), and from work. The years I spent in college taught me to think differently, and enough fundamental theory to know why quicksort > bubble sort.

As for languages though.. don't sweat it. Learn what you want, or what you expect to need for work. I learned such amazingly useful langauges as ADA, Fortran, COBOL/RPG, and Pascal in school. Yeah, even the US government has stopped using ADA, and we know the speed government agencies adopt to change.

I would suggest using C++, and approaching it as C++. If you get yourself bogged down in the bit-level stuff when you don't have any reason to be there, you'll just never feel like you know how anything works at all. I'm a C programmer, and after spending a few years at work doing Perl, I absolutely LOATHE the way C handles (or fails to handle) strings. Guess what? MUD programming is 95% string manipulation!

If you want to just write a MUD, pick a newer language like Ruby, Python, Lua, and let it handle all the dirty work for you. If you want to learn C++ because it's used in the job market, go for that. If you want to write a compiler, I'd still argue against using C, since C++ would make it easier to parse the source code. :)

Well, if it's about the selection of details, it would perhaps be beneficial for you to do precisely that and select your details. So far it's felt like you've wanted to know it all, from the highest reaches of template metaprogramming (which really has nothing to do with the machine) to the lowest levels of the most efficient assembler generation possible to squeeze out every cycle of a modern pipelining processor. It's hard for me to narrow down your selection based on what you've asked about so far. :smile:

By the way, it's worth noting that a PhD won't give you total breadth in computer science. Sure, you'll take breadth courses, but really it's like the undergrad experience at a higher level. Most of your time (60%+) during the five-year process will be spent on a very particular field of research.

Also by the way, I don't think a PhD would open many jobs outside of academia that a master's or experience/competence wouldn't. So unless you want to do research, the PhD is not really all that helpful for industry jobs. This is speaking for software development, at least – different fields have different requirements. Obviously to do something like medical research, having the PhD in medicine helps a great deal (it might even be a requirement at many places, I don't know).

I guess the you maybe be conflating two different statements I have made about different things. One was about what I hope to achieve and trying to find some help with respects to what details will get me there and one about the state of the structure of the curriculum and currently and the particular ordering of courses. The point I was however trying to make here is this. The organization of any curriculum involves compromises and even if subfields in computer science you can find topics which crosscut the curriculum and some things which arent part of the field because the training involved maybe substantially longer than four years.

Anyow I am not sure how this relates to my clarification on goals that flumpy requested post since I think it narrows down to some degree what my aims are and from that I am essentially asking which details are important to know and which are not. Which is I think the gist of this thread. I am asking essentially on some level which topics are relevant in this area.

As for your remarks concerning PhDs and industry I have heard this before so yes I am aware of it. Actually the individual with whom I was discussing the PhD said more or less the same thing.

In an alternative universe BASIC is used instead; it's standardized and is fiddled with by enough people to generate efficient machine code on many architectures. And C is some discarded language rotting on a shelf. It's simply a historical accident. There's nothing magical about C.

I have no use for university, but I'd be shocked if they didn't teach computer architecture courses anymore. A simple google search confirms universities do and many architectures ranging from RISC to x86.



If you are writing a compiler to execute on a real or virtual machine code, whatever the language you write it in is mostly irrelevant (obviously it has to available on the machine first). Unless of course you want to optimize the compile cycle. Perl will parse source files and output machine code just as easily as C/C++, perhaps even easier. And once you have a language you can rewrite the compiler in the new language you created.

If you are complaining strictly about what's available in university courses, well then the only thing I can suggest is grab the architecture guide, the operating system guide, an assembler and start writing code.