|
Not a book but it's free... W3 schools C++ Tutorial[^] takes you though the basics and lets you interactively try things out.
|
|
|
|
|
I read the list of reccomendations and did not see this one. "C++ How To Program: Introducing Object-Oriented Design with the UML" by Deitel & Deitel. Easy to read, well organized and covers the things likely to be used in basic object oriented C++ programming. Others mentioned that I would second are "Effective C++", PluralSight training and "Thinking in C++", although the last one is rather basic.
|
|
|
|
|
Having learned it this way, I always recommend Stroustrup's "C++ Programming Language". Read it cover to cover. Yes it will take a while, but its worth it. Then after perhaps a year of C++ experience, pick up Scott Meyer's "Effective C++", both editions. And/or his more recent variants of the same thing.
C++ takes a long time to learn to use properly. I've been coding in C++ nearly 30 years now, and I'm still learning stuff. Though I'd like to think I'm and effective C++ coder 
|
|
|
|
|
|
Both just a couple of cheap knockoffs of "C".
Ravings en masse^ |
---|
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Both C# and Java see so much further, because they stand on the shoulders of C!
Get me coffee and no one gets hurt!
|
|
|
|
|
Alas, they seem to spend too much time looking down and contemplating their own navals. The lucky ones see belly-button LINT.
(The rest of the time just awaiting the next upgrade and amazing new features they could never have done without)
Ravings en masse^ |
---|
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Or expensive knockoffs of C++, which is an expensive knockoff of C.
|
|
|
|
|
|
All programming languages are just variations on the theme we know as "assembly language".
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
All products in the store are just variations on the theme we know as "atoms".
|
|
|
|
|
From my perspective, that it doesn't let you control things the way C++ does, particularly memory. Other than that, I don't have any issues with it, although I don't know it very well.
|
|
|
|
|
In (very) special cases: Sure. In those cases, you might as well go to assembly language.
I learned 30+ years ago that trying to outsmart an optimizing compiler is futile. In my student days, we thought it crazy to write an OS in a "high" level language - but Unix did succeed, and performance was not an issue. So we abandoned assembly. Not entirely; there are cases for assembly because that is the only possible way to get access to certain hardware functions. But going assembly for performance reasons has no place in the third millennium.
Today, the same goes for memory. It is almost as difficult to outsmart automatic memory management by "clever" use of malloc/free as to outsmart a compiler - in particular because you have no insight in actual memory fragmentation. The risk of memory leaks is much larger; too many programmers do not master their own memory use as well as they believe (or, they are not enforcing the programming discipline as they should).
Again: There are (very) extreme cases where the cost of garbage collection is unacceptable. Usually, memory fragmentation is then unacceptable as well. So you manage your objects e.g. in a static array, dimensioned for a worst case. (I was programming one such C solution - malloc was not accepted by our coding standards. C++ new would have been rejected as well, so the case for C++ was not very strong.)
Analogy: When I talk with extreme HiFi buffs, I must admit that 24 bit samples at 96 kHz does have its place, in a professional studio where a sound recording may go through many generations of various processing, mixing etc. for an end result of unknown sample width and frequency. But that is is the studio. It doesn't mean that the music I listen to on my stereo benefits from being in 96/24 format.
Similarly: If you write a physical level driver for a 10 Gbps network interface, you probably cannot tolerate GC delays. But for 99.999% of all code written, GC without memory leaks is a lot better than dubious "private" memory management.
|
|
|
|
|
Special cases or not, there's no way I'd go to assembler and give up all the things that an OO language like C++ provides. And the special cases I'm thinking of aren't a question of trying to outsmart anything.
One of them, in serious production code, was morphing an object to a sibling class in the inheritance hierarchy by changing its vptr . The objects' memory came from a pool of blocks, not the heap, so objects from both classes fit into the same block. No deep copying, no worries about stale pointers to the object, just abracadabra, and its behavior is now what's needed.
|
|
|
|
|
Your example is no different that code I saw implemented, where the sort order, leveraged the same code by the program MOVING the appropriate "Branch If >=" vs "Branch If <=" to X bytes forward on the execution pointer.
I remember reading that code over and over. Utterly confused. I had NEVER SEEN a move to a relative offset from the SP (Stack Pointer). It was already coded for the the ASCENDING sort, if they are overwriting that address, if it is ascending, it made no sense (ah, but the code broke when he was wrong on the pointer location, LOL)...
Anyways, I would EITHER shoot or beat a programmer for that kind of optimization. The C solution, of using a pointer to a function() that returned the appropriate sorting value induced HUGE functionality benefits, cleaner code and tons more flexibility. Almost pure elegance, IMO.
The code has 3 consumers. The Current Developer, The Compiler, and the Next Developer. The last one being the most important!
|
|
|
|
|
I also like the "pointer to the comparison function" design.
The fourth consumer of code is the customer, and our customers were demanding when it came to performance. The scenario in question occurred with sufficient frequency that no one objected to the design. The code in question called a MorphTo function, which was a giveaway as to what was going on.
|
|
|
|
|
Quote: I learned 30+ years ago that trying to outsmart an optimizing compiler is futile.
Indoctrination. Processors have been built to prove this point for a long time. Cache penalties, pipeline penalties, millions of addressing modes... Just take a true RISC processor and you are rid of most of that. Now a child can be just as good as the compiler, leaving only the thing that compilers are notoriously bad at and that's choosing the algorithm.
trønderen wrote: But for 99.999% of all code written, GC without memory leaks is a lot better than dubious "private" memory management.
Maybe, but developers who run into such a problem and know nothing about memory management are helpless 100% of the time.
Watching 'team leaders', 'architects' and who knows what other titles they had given themselves camp around a server and trying magical chanting and sacrificing virgins to fix a memory overflow is a sad sight. But I was able to motivate them with lots of good natured humor, which they took as biting sarcasm.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
It's like the ongoing dispute between Nikon and Canon users as to which is best.
They are both excellent cameras it's just a matter of preference...but Nikon is way better.
|
|
|
|
|
You realize this thread is not about cameras?
Sorry - just messing with you!
Get me coffee and no one gets hurt!
|
|
|
|
|
|
|
Nikon is unusable.
Pentax is the only true path.
|
|
|
|
|
Nay brother let me lead you to the true path of enlightenment. Nikon shall set you free and with your purchase of a new lens you shall receive the blessing of the shutter gods.
|
|
|
|
|
Uuuhhh...
I have no lenses younger than about twenty years -- and some closer to seventy.
My latest camera purchase is a Kodak Vigilant Six-20 (circa 1940).
Lately I've been playing with a 4x5 monorail camera from the '60s.
I say again, Nikon is unusable -- except maybe by wrong-handed practitioners (like my brother).
Having said that, Nikon does make good point-and-shoot cameras, my wife is on her third.
|
|
|
|
|
I give...
|
|
|
|