- Forum
- General C++ Programming
- Recommended book for good C++ structure
Recommended book for good C++ structure
Hello C++ betters,
I wanted to ask your opinion on what you think is a very good book for further education (or even a web-site or other resource) for further learning about practical application structuring of good C++ programming.
In short, I am an engineer and have been out of C++ programming for a little while which might as well be 100 years in today's terms. Knowing this, I know conventions have changed a little for the C++ community and there are very good efficient ways of doing EVERYTHING.
So where I'm going with this is==> is there a good reference that the guru's here recommend that I could read or visit that demonstrate the best practices for good C++ programming and overall program layout and structuring. The one thing about C++ is that it is so dang powerful and that the users have SO MANY choices of doing things - that I figured there has to be a book or resource that pretty much lays out how best practices for structuring programs and what recommendations for containers, data handling, strong type security, overloading, over-riding, polymorphism, single inheritance vs. multiple inheritance etc. goes.
Does this request make sense? Or is it just too broad and generalized? To put it bluntly==> a "how to manual" with today's best practices for C++ program writing for those of us who are NOT Computer Science or Computer Engineers but still need to use the language's power for research or robotics etc...
Thank you for your help people!
Xanadu
I wanted to ask your opinion on what you think is a very good book for further education (or even a web-site or other resource) for further learning about practical application structuring of good C++ programming.
In short, I am an engineer and have been out of C++ programming for a little while which might as well be 100 years in today's terms. Knowing this, I know conventions have changed a little for the C++ community and there are very good efficient ways of doing EVERYTHING.
So where I'm going with this is==> is there a good reference that the guru's here recommend that I could read or visit that demonstrate the best practices for good C++ programming and overall program layout and structuring. The one thing about C++ is that it is so dang powerful and that the users have SO MANY choices of doing things - that I figured there has to be a book or resource that pretty much lays out how best practices for structuring programs and what recommendations for containers, data handling, strong type security, overloading, over-riding, polymorphism, single inheritance vs. multiple inheritance etc. goes.
Does this request make sense? Or is it just too broad and generalized? To put it bluntly==> a "how to manual" with today's best practices for C++ program writing for those of us who are NOT Computer Science or Computer Engineers but still need to use the language's power for research or robotics etc...
Thank you for your help people!
Xanadu
Take a look at The Definitive C++ Book Guide and List:
https://stackoverflow.com/questions/388242/the-definitive-c-book-guide-and-list/388282#388282
These links from the guide would be relevant, I think:
The C++ Core Guidelines http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#main
and the (slightly older) The C++ Super-FAQ https://isocpp.org/faq
https://stackoverflow.com/questions/388242/the-definitive-c-book-guide-and-list/388282#388282
| Xanadu4ever wrote: |
|---|
| a "how to manual" with today's best practices for C++ program writing |
The C++ Core Guidelines http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#main
and the (slightly older) The C++ Super-FAQ https://isocpp.org/faq
Last edited on
Thanks Cubbi,
I suppose I should probably have known you were definitely going to send me somethign with Stroustrup as the author/contributor .... (as well you should have since it is probably very appropriate!)
Thank you for this compilation...... looks all inclusive and gives a lot of information.
Xanadu
I suppose I should probably have known you were definitely going to send me somethign with Stroustrup as the author/contributor .... (as well you should have since it is probably very appropriate!)
Thank you for this compilation...... looks all inclusive and gives a lot of information.
Xanadu
| I wanted to ask your opinion on what you think is a very good book for further education |
Books, multiple.
https://isocpp.org/wiki/faq/how-to-learn-cpp#buy-several-books
http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines
Another Stroustrup property.
His "C++ Principles and Practice" are particularly relevant to your question.
Herb Sutter's works are likewise good choices.
"Effective Modern C++" and related works by Scott Meyers are good choices.
Many works by Andrei Alexandrescu are worth reading.
Josuttis "The C++ Standard Library - A Tutorial and Reference" is worthy of some time.
Many of the Boost libraries are also good to examine (and use). After all, from Boost came shared_ptr. Stroustrup has some caution about Boost. Alexandrescu's text from about 2001 issues some warnings about the design of shared_ptr (though it doesn't mention it specifically - he favored policy design in his smart pointers, and prohibited any member functions as they can confuse the consumers of the smart pointer).
I'm a 50 something developer, where C++ is my primary language of choice. While I have been constantly focused on software development since the late 70's (as a kid), I've had the luxury of remaining current all this time. However, at each major epoch (C++11 for example), even those of us writing in C++ daily will had the very same experience you present (of catching up).
It is not so difficult if your C/C++ is not so rusty that you feel unsure of basic application targets.
Depending on how long it's been, a few observations which may date from the 80's forward:
- Use smart pointers, stl containers. std::shared_ptr has been overused (where, now, std::unique_ptr is often more appropriate, and std::scoped_ptr should be considered - also, revisit std::weak_ptr and why it's there).
- Remind yourself how C++ sort (from algorithm) can be faster than C's qsort function (that is, how providing more information to the compiler allows it to optimize/inline better).
- Don't concern yourself with many of the 'cute' solutions that aren't clear.
- Templates were, once, very heavy (back when 64 mega bytes - not giga bytes - was $1,000). They are no longer quite the burden. Use them when you need them and practice them.
- In C, the old built in types 'int' and 'float' exhibit object behavior. This isn't widely mentioned, but if you consider assembler, where the programmer must select the appropriate standard operation instructions (+,-,*,/), in C the compiler does that automatically - and 'understands' the relationship between the two when mixing floats and ints in simple expressions. This association between appropriate methods (functions) and the type (the object) are central to object oriented thought. C's int and double exhibit a number of the behavior of objects in this respect, including the fact that this 'knowledge' is hidden from the programmer. They may not be considered objects from a C++ language perspective (they're not implemented as classes for example), but I'm attempting to say that 'objects' come to us from outside the language. We don't use trig to solve chemical equations, or drive a bicycle the way we drive a car. This notion of associating methods with things is at the heart of human thought about reality.
- Stroustrup's usually right ;)
- If you didn't catch this little history, there was a thing called auto_ptr, and you may find it referenced in texts. It is an error. Replaced with std::unique_ptr and std::scoped_ptr.
- Finally, we have the definition that a reference to a reference is a reference. You'll see && in code now, so too you'll find it discussed in the listed works. It's important, and fairly easy.
- std::unique_ptr allows moves, denies copies. For old hands this was a bit of a study and reorientation. It's all good.
- In C++, we use the C# var, but spell it auto ;)...auto's good, but auto leaves you a bit disoriented. Use it, but know that it isn't required or always better (just usually).
- Types get complicated. Use typedefs liberally to shorten the burden (some old hands had to be convinced).
It won't take that long to become current.
I just realized I'm late for an appointment....more to exchange if you like.....
Another Stroustrup property.
His "C++ Principles and Practice" are particularly relevant to your question.
Herb Sutter's works are likewise good choices.
"Effective Modern C++" and related works by Scott Meyers are good choices.
Many works by Andrei Alexandrescu are worth reading.
Josuttis "The C++ Standard Library - A Tutorial and Reference" is worthy of some time.
Many of the Boost libraries are also good to examine (and use). After all, from Boost came shared_ptr. Stroustrup has some caution about Boost. Alexandrescu's text from about 2001 issues some warnings about the design of shared_ptr (though it doesn't mention it specifically - he favored policy design in his smart pointers, and prohibited any member functions as they can confuse the consumers of the smart pointer).
I'm a 50 something developer, where C++ is my primary language of choice. While I have been constantly focused on software development since the late 70's (as a kid), I've had the luxury of remaining current all this time. However, at each major epoch (C++11 for example), even those of us writing in C++ daily will had the very same experience you present (of catching up).
It is not so difficult if your C/C++ is not so rusty that you feel unsure of basic application targets.
Depending on how long it's been, a few observations which may date from the 80's forward:
- Use smart pointers, stl containers. std::shared_ptr has been overused (where, now, std::unique_ptr is often more appropriate, and std::scoped_ptr should be considered - also, revisit std::weak_ptr and why it's there).
- Remind yourself how C++ sort (from algorithm) can be faster than C's qsort function (that is, how providing more information to the compiler allows it to optimize/inline better).
- Don't concern yourself with many of the 'cute' solutions that aren't clear.
- Templates were, once, very heavy (back when 64 mega bytes - not giga bytes - was $1,000). They are no longer quite the burden. Use them when you need them and practice them.
- In C, the old built in types 'int' and 'float' exhibit object behavior. This isn't widely mentioned, but if you consider assembler, where the programmer must select the appropriate standard operation instructions (+,-,*,/), in C the compiler does that automatically - and 'understands' the relationship between the two when mixing floats and ints in simple expressions. This association between appropriate methods (functions) and the type (the object) are central to object oriented thought. C's int and double exhibit a number of the behavior of objects in this respect, including the fact that this 'knowledge' is hidden from the programmer. They may not be considered objects from a C++ language perspective (they're not implemented as classes for example), but I'm attempting to say that 'objects' come to us from outside the language. We don't use trig to solve chemical equations, or drive a bicycle the way we drive a car. This notion of associating methods with things is at the heart of human thought about reality.
- Stroustrup's usually right ;)
- If you didn't catch this little history, there was a thing called auto_ptr, and you may find it referenced in texts. It is an error. Replaced with std::unique_ptr and std::scoped_ptr.
- Finally, we have the definition that a reference to a reference is a reference. You'll see && in code now, so too you'll find it discussed in the listed works. It's important, and fairly easy.
- std::unique_ptr allows moves, denies copies. For old hands this was a bit of a study and reorientation. It's all good.
- In C++, we use the C# var, but spell it auto ;)...auto's good, but auto leaves you a bit disoriented. Use it, but know that it isn't required or always better (just usually).
- Types get complicated. Use typedefs liberally to shorten the burden (some old hands had to be convinced).
It won't take that long to become current.
I just realized I'm late for an appointment....more to exchange if you like.....
Last edited on
| After all, from Boost came shared_ptr |
Niccolo,
Thank you for the personal pointers (pun definitely intended! LOL) about the "main takeaways" since the 80's! It is helpful to hear from someone who has literally lived the "whole epoch" of C/C++ and has seen how it has evolved and become even more powerful with each passing year.
So with that said..... What I'm hearing is thus==>
1.) Use SMART and not "RAW" pointers and the different 'flavors' and appropriate usage for them.
2.) Use the STL and all of its containers and features because a lot of really smart people put
a really large amount of thought and effort into making C++ life easier for the rest of us and I'd have to be a moron to try to reinvent the wheel all the time.
3.) Use the <algorithm> header because it is powerful and sorting is needed for lots of containers for lots of computing applications
4.) 'Cute' solutions are just that ==> convoluted, not elegant and confuse the hell out of the rest of the people that are forced to try to interpret them - so DON'T use cute crap
5.) Objects and OO programming is natural to human existence even though you gave an example of how fundamental types can almost be thought of as objects in their own right?? [Did I hear you correctly??]
6.) Stroustup = "the Architect" (listen and obey!)
7.) I'm reading about "auto_ptr" RIGHT THIS SECOND!! LOL! Thank you for the up-dated info - I will (from this point on-ward) look for "unique_ptr" and "scoped_ptr" instead of "auto_ptr" and figure out what the SAM's book I'm reading right now has lied to me about!!!
8.) Read about "unique_ptr" and reorient my mind on its usage and constraints
9.) I will definitely explore this multiple-reference idea..... strange but intriguing!!!
10.) C#??? Are you making a reference to that OTHER language??
How did I do on the comprehension??? If I confused something or transposed an idea - please let me know.... I take it the links you guys provided [see above] have the explanations to 'unique_ptr', multiple references and the other advise you supplied??
Xanadu
Thank you for the personal pointers (pun definitely intended! LOL) about the "main takeaways" since the 80's! It is helpful to hear from someone who has literally lived the "whole epoch" of C/C++ and has seen how it has evolved and become even more powerful with each passing year.
So with that said..... What I'm hearing is thus==>
1.) Use SMART and not "RAW" pointers and the different 'flavors' and appropriate usage for them.
2.) Use the STL and all of its containers and features because a lot of really smart people put
a really large amount of thought and effort into making C++ life easier for the rest of us and I'd have to be a moron to try to reinvent the wheel all the time.
3.) Use the <algorithm> header because it is powerful and sorting is needed for lots of containers for lots of computing applications
4.) 'Cute' solutions are just that ==> convoluted, not elegant and confuse the hell out of the rest of the people that are forced to try to interpret them - so DON'T use cute crap
5.) Objects and OO programming is natural to human existence even though you gave an example of how fundamental types can almost be thought of as objects in their own right?? [Did I hear you correctly??]
6.) Stroustup = "the Architect" (listen and obey!)
7.) I'm reading about "auto_ptr" RIGHT THIS SECOND!! LOL! Thank you for the up-dated info - I will (from this point on-ward) look for "unique_ptr" and "scoped_ptr" instead of "auto_ptr" and figure out what the SAM's book I'm reading right now has lied to me about!!!
8.) Read about "unique_ptr" and reorient my mind on its usage and constraints
9.) I will definitely explore this multiple-reference idea..... strange but intriguing!!!
10.) C#??? Are you making a reference to that OTHER language??
How did I do on the comprehension??? If I confused something or transposed an idea - please let me know.... I take it the links you guys provided [see above] have the explanations to 'unique_ptr', multiple references and the other advise you supplied??
Xanadu
@Xanadue4ever,
That was fun!
10....that OTHER language! Love it!
5....yep! Fundamental types exhibit an association between their type an the appropriate operations used upon them, even in C, which is one of the main themes of object behavior. You got it. It can start some arguments, sure, and it isn't widely recognized, but it does serve to highlight something about what objects are to think about this point, and in some of the formal literature you'll find a definition of object you would conclude applies.
You might use a knife to loosen a screw, but you probably don't use a screwdriver to slice a cake. Without objects we actually end up making mistakes like slicing cake with a greasy screwdriver.
Another version of this that gets students laughing is the "camping in the woods" anecdote. No toilet paper. Be careful which leaf you use instead! If only we knew how to tell poison ivy from a simple vine.
3...Yes...and one thing I might have forgotten. In algorithm there is some legacy. The new C++ "for" loop constructs ( ex: for( auto i : c ) ) do something similar to what the std::for_each algorithm does. std::for_each is older than the new "for" loops, and so there's overlap. You can favor the new "for" loop form in new code as you prefer...for_each can work on less than the full container. This is but one example of the "more than one way to do something" throughout the language and the libraries.
Oh, if that SAM's book is not out of date, then maybe there's a lie there, but I hope it's just out of date ;)
Funny....great post!
@Cubbi - point taken.
Way back in the 90's when templates were new, most of us first used them to fashion naive smart pointers (often reference counted).
Then we discovered we had to save up another $2,000 to by RAM so the compiler could breathe!
I think my workstation at that time was extremely well equipped with 16 Mbytes (not Gbytes) of RAM. Visual C++ 4.2 choked. Borland's compiler could muddle through, but the disk drive was BUSY.
We used a little something hardly discussed now called explicit template instantiation to push template code into specific translation units just so we could cope. To do that we "invented" a little extension type called "inl", pushing all template member functions there, and not inside the class declaration.
That was fun!
10....that OTHER language! Love it!
5....yep! Fundamental types exhibit an association between their type an the appropriate operations used upon them, even in C, which is one of the main themes of object behavior. You got it. It can start some arguments, sure, and it isn't widely recognized, but it does serve to highlight something about what objects are to think about this point, and in some of the formal literature you'll find a definition of object you would conclude applies.
You might use a knife to loosen a screw, but you probably don't use a screwdriver to slice a cake. Without objects we actually end up making mistakes like slicing cake with a greasy screwdriver.
Another version of this that gets students laughing is the "camping in the woods" anecdote. No toilet paper. Be careful which leaf you use instead! If only we knew how to tell poison ivy from a simple vine.
3...Yes...and one thing I might have forgotten. In algorithm there is some legacy. The new C++ "for" loop constructs ( ex: for( auto i : c ) ) do something similar to what the std::for_each algorithm does. std::for_each is older than the new "for" loops, and so there's overlap. You can favor the new "for" loop form in new code as you prefer...for_each can work on less than the full container. This is but one example of the "more than one way to do something" throughout the language and the libraries.
Oh, if that SAM's book is not out of date, then maybe there's a lie there, but I hope it's just out of date ;)
Funny....great post!
@Cubbi - point taken.
Way back in the 90's when templates were new, most of us first used them to fashion naive smart pointers (often reference counted).
Then we discovered we had to save up another $2,000 to by RAM so the compiler could breathe!
I think my workstation at that time was extremely well equipped with 16 Mbytes (not Gbytes) of RAM. Visual C++ 4.2 choked. Borland's compiler could muddle through, but the disk drive was BUSY.
We used a little something hardly discussed now called explicit template instantiation to push template code into specific translation units just so we could cope. To do that we "invented" a little extension type called "inl", pushing all template member functions there, and not inside the class declaration.
Last edited on
So Niccolo and Cubbi,
Do you guys recommend any exercises to start working on (on this site or others or whatever..) or just use those in my SAM's book I have for the moment?
I definitely am going to plan on getting some of those BOOKS you both recommended and have already been doing the "Stroustrup Tour" of C++ just to get his take on the best practices that are concurrent. Started part #1 so far
Now, I just have to start putting this all to good use and practicing it to break the rust off. There is rust!! I am using CodeBlocks at the moment (good IDE and environment? Recommend another???) and just want to start working on exercises to get my mind working in the right direction.
Niccolo, I definitely agree with you that getting one's mind to start thinking about HOW to use objects to represent real life "things" and then the member methods to serve as the "actions" for those things is very hard at times. Like all engineers we have the tendency to REALLY OVER THINK stuff at times and I am no exception - so when I'm trying to think of the paradigm to create to represent a robot, or a mechanism, or what have you...…. I try breaking it down into small "things" like sensors, motors, etc. and the associated data that will naturally belong to those items and then assemble all these small things into bigger things that represent the system.
Is this correct? Am I approaching this the right way or is this too rigid and have to start thinking about it in another fashion??
Again thank you both for the great advise so far and I am drinking it in..... from the fire hose.
Xanadu
Do you guys recommend any exercises to start working on (on this site or others or whatever..) or just use those in my SAM's book I have for the moment?
I definitely am going to plan on getting some of those BOOKS you both recommended and have already been doing the "Stroustrup Tour" of C++ just to get his take on the best practices that are concurrent. Started part #1 so far
Now, I just have to start putting this all to good use and practicing it to break the rust off. There is rust!! I am using CodeBlocks at the moment (good IDE and environment? Recommend another???) and just want to start working on exercises to get my mind working in the right direction.
Niccolo, I definitely agree with you that getting one's mind to start thinking about HOW to use objects to represent real life "things" and then the member methods to serve as the "actions" for those things is very hard at times. Like all engineers we have the tendency to REALLY OVER THINK stuff at times and I am no exception - so when I'm trying to think of the paradigm to create to represent a robot, or a mechanism, or what have you...…. I try breaking it down into small "things" like sensors, motors, etc. and the associated data that will naturally belong to those items and then assemble all these small things into bigger things that represent the system.
Is this correct? Am I approaching this the right way or is this too rigid and have to start thinking about it in another fashion??
Again thank you both for the great advise so far and I am drinking it in..... from the fire hose.
Xanadu
1) try not to use pointers too much. I came in here much like you, from engineering (as a coder/support, I am not an eng) knowing pre y2k C++ and having avoided the early STL due to performance snafus. I still have a long way to go. Back when we used pointers all over the place; now you use stl containers to hide as much of that as possible. You need one now and then, so your 1 is correct, but as an addendum to it, avoid pointers.
3) algorithm does a lot more than sort, but it only does a *very* few tasks in the grand scheme. Learn what is in it, and use its 'way of doing things' as a model when you have to roll your own something that isn't in there.
4). This is very, very subjective. To understand that, give me an engineering definition that I can use to identify whether a wad of code is 'cute' or not. Much of the modern c++ is actually kinda tight, cute, and unreadable. Heavy usage of 'auto' + ranged for loops + built in tools can make even a simple thing hard to follow, even if its the 'right' thing to do and correct use of tools. You will see what I mean. There is a fine line between the old convoluted c code contest crap, using tools correctly, and writing slow/poor code that does the work explicitly so a novice can read it. Finding that balance is very tricky now.
5.) Ok, this one is for us engineerish coder types. I call out a design pattern OSO: objects for the sake of objects. Over use of classes and inheritance and OOP tools can make as big a mess as using it well can be beautiful. There is nothing in the world wrong with a standalone function that accepts a vector of doubles and does some engineering stuff on it. And the reverse is true as well: use objects where objects make things better. They usually do, but in math heavy code, using objects for everything may not be your best bet. Design takes a lot of practice and experience. Don't be afraid to ask if you are torn between some options.
6.) Question everything. At the very least, you will learn the why along with the what :)
7.) most books have things that are either outdated or flat out wrong. Some more than others. I would throw away any book older than 2017 or at the very least shelf it for emergency reference only.
10.) There are a number of 'children of C++' / 'grandchildren of C' languages that you may want to work in someday. C# is just one of them. The common root will make it easy to hack around in these but each one has its own deep stuff + syntax subtleties that is very different from c++. At least you can read and modify them fairly easily, with some google in the mix.
11) As an engineer, make friends with <complex> type ASAP. It isn't shown in books, examples, or general code very much, and its used all the time in some engineering areas. Depending on your background, you may also have to remind yourself often that <vectors> are not vectors (there are a few other unfortunate math garbles in c++ as well).
3) algorithm does a lot more than sort, but it only does a *very* few tasks in the grand scheme. Learn what is in it, and use its 'way of doing things' as a model when you have to roll your own something that isn't in there.
4). This is very, very subjective. To understand that, give me an engineering definition that I can use to identify whether a wad of code is 'cute' or not. Much of the modern c++ is actually kinda tight, cute, and unreadable. Heavy usage of 'auto' + ranged for loops + built in tools can make even a simple thing hard to follow, even if its the 'right' thing to do and correct use of tools. You will see what I mean. There is a fine line between the old convoluted c code contest crap, using tools correctly, and writing slow/poor code that does the work explicitly so a novice can read it. Finding that balance is very tricky now.
5.) Ok, this one is for us engineerish coder types. I call out a design pattern OSO: objects for the sake of objects. Over use of classes and inheritance and OOP tools can make as big a mess as using it well can be beautiful. There is nothing in the world wrong with a standalone function that accepts a vector of doubles and does some engineering stuff on it. And the reverse is true as well: use objects where objects make things better. They usually do, but in math heavy code, using objects for everything may not be your best bet. Design takes a lot of practice and experience. Don't be afraid to ask if you are torn between some options.
6.) Question everything. At the very least, you will learn the why along with the what :)
7.) most books have things that are either outdated or flat out wrong. Some more than others. I would throw away any book older than 2017 or at the very least shelf it for emergency reference only.
10.) There are a number of 'children of C++' / 'grandchildren of C' languages that you may want to work in someday. C# is just one of them. The common root will make it easy to hack around in these but each one has its own deep stuff + syntax subtleties that is very different from c++. At least you can read and modify them fairly easily, with some google in the mix.
11) As an engineer, make friends with <complex> type ASAP. It isn't shown in books, examples, or general code very much, and its used all the time in some engineering areas. Depending on your background, you may also have to remind yourself often that <vectors> are not vectors (there are a few other unfortunate math garbles in c++ as well).
Last edited on
Jonnin,
You have hit on exactly what "worries" me at times..... making sure I can use C++ in the way we engineers need it and find that "balance" you were referring to. I know the software guys have a little different view of what they NEED to do at times and also HOW they are going to do it to make sure portability, scalability, security, etc. are implemented..... for us it isn't always those things we have to worry about so much {but they are definitely present folks!!!}
Niccolo and Cubbi have definitely started me down the road I need to travel and that is what I am going to start focusing on but if YOU [Jonnin] as an engineer have some BOOKS or references or any other type of aid that you think would help with "real time processors" and gathering data from sensors and obviously processing that data and moving it around to the "data consumers" inside and outside the system would definitely be helpful too!
Your point about "Heavy usage of 'auto' + ranged for loops + built in tools can make even a simple thing hard to follow, even if its the 'right' thing to do and correct use of tools." Is exactly what worries me!! Like you said, finding that correct balance seems a little intimidating right now - being truthful. Other engineers will have to use and also troubleshoot and look at this code and it will be around for a WHILE - so as you know it has to be elegant AND bullet proof - and like you also said - even the easy stuff makes you question if you even understand what the hell is going on at any one time or if anyone else is going to be able to follow along why you did whatever it is you did and actually agree that was probably the best way to do it at the moment!
It comes down to that old adage for all of us geek types with a lot of these projects==> "Just because you CAN do [use] something doesn't necessarily mean you SHOULD do [use] that part of the STL, or method, or what have you.
Do you have any suggested practice exercises or resources you suggest I quickly try to get into to make sure I can get my head and my @$$ wired together pretty quickly from an engineering perspective?
Again thank you guys! This is some solid direction and advise which I intend to follow quickly!
Xanadu
You have hit on exactly what "worries" me at times..... making sure I can use C++ in the way we engineers need it and find that "balance" you were referring to. I know the software guys have a little different view of what they NEED to do at times and also HOW they are going to do it to make sure portability, scalability, security, etc. are implemented..... for us it isn't always those things we have to worry about so much {but they are definitely present folks!!!}
Niccolo and Cubbi have definitely started me down the road I need to travel and that is what I am going to start focusing on but if YOU [Jonnin] as an engineer have some BOOKS or references or any other type of aid that you think would help with "real time processors" and gathering data from sensors and obviously processing that data and moving it around to the "data consumers" inside and outside the system would definitely be helpful too!
Your point about "Heavy usage of 'auto' + ranged for loops + built in tools can make even a simple thing hard to follow, even if its the 'right' thing to do and correct use of tools." Is exactly what worries me!! Like you said, finding that correct balance seems a little intimidating right now - being truthful. Other engineers will have to use and also troubleshoot and look at this code and it will be around for a WHILE - so as you know it has to be elegant AND bullet proof - and like you also said - even the easy stuff makes you question if you even understand what the hell is going on at any one time or if anyone else is going to be able to follow along why you did whatever it is you did and actually agree that was probably the best way to do it at the moment!
It comes down to that old adage for all of us geek types with a lot of these projects==> "Just because you CAN do [use] something doesn't necessarily mean you SHOULD do [use] that part of the STL, or method, or what have you.
Do you have any suggested practice exercises or resources you suggest I quickly try to get into to make sure I can get my head and my @$$ wired together pretty quickly from an engineering perspective?
Again thank you guys! This is some solid direction and advise which I intend to follow quickly!
Xanadu
@xanadu - I don't have a lot experience with CodeBlocks. If I recall, you can apply various compilers, but I can't be sure. In Windows it is tough to exceed the results of Visual Studio CE, especially the debugger. On MAC I find XCode looks beautiful but isn't really comfortable. Eclipse or IntelliJ are reasonable for MAC or Linux, but what really matters is the compiler (first) and the debugger (second). I type fast, so the editor's keyboard features are important to me, and good support for multi-monitor usage, which is why I prefer VS CE.
Microsoft's compiler is ok, not the best optimizer, fairly compliant with standards, but targeting Windows automatically requires extensions of all compilers to process the windows header files. LLVM/Clang is better at optimized output, usually a tad ahead of Microsoft on compliance, and is supported on VS CE as an easy "official" install, even to target Linux development.
GCC seems to me an academic exercise. It's a good compiler, a tad behind LLVM on optimization, but is usually first to support new C++ standards. Don't install it just because of that, though.
I've been volunteering to teach robotic programming at a club the high school (where my son just graduated). He was a member of the club when I realized the teacher was a very good mechanical engineer but had zero training in computers (doesn't even use a spreadsheet, can't print an image from an email). This will be my third year. They use Vex EDR.
I bring this up because one project (or exercise) was to write the control software for a holonomic drive (the wheels are all at 45 degree angles with rollers - the bot can drive in any direction without turning). There is a naive bit of code on the 'net for this, but it has no finesse. We realized soon we needed "snap to angle", because there are no detents on the controller, so we snap to the major axis (45's and 90's). To do that we needed trig. Take the X/Y input, calculate the angle, snap the angle, take the length as the speed - and then apply a curve to the speed so the center 3rd is less sensitive (for accurate control), while the latter half is "full power". One student with a kind of OCD about math could not stop thinking about this code to understand it. As a project, it was wonderful.
Another was software for a simple one joint arm. The kids didn't know what they were supposed to do with this "sin/cos/atan things", but here was an arm to be used in a competition. The needed to transform a height into an angle for a single joint.
Then, later, we made a 3 joint arm (shoulder, elbow, wrist - claw). There we have inverse kinematics at play. We need to think in terms of 2d coordinates (the objective for the claw), but our control is only the angles of the joints. This brings up the law of cosines, law of sines and some other basic trig thinking. At first, with the freshmen and sophomores, it was too much. The juniors and seniors, however, discovered why they bothered suffering through algebra and trig because of it.
Another, through a forum request on a game programming site, was a simple self driving bot. A unicycle is to drive itself through a set of waypoints. Using PID to control steering, the bot drives in a way similar to someone on a unicycle. The PID algorithm (widely available on the 'net) is deceptively simple, and touchy to tune, but the result is a good "exercise".
@jonnin brings up some really good points.
#5, for example. Notice that the <algorithm> library is mostly non-member functions. There are very good design reasons for that, and it does NOT mean they are non-oop. Non-member functions may well be part of object behavior, but do not always have to be part of a class.
To be clear, sort is a template function. It adapts to the types fed to it, and takes in an object as a parameter which describes the comparison operation in a way that promotes emitting that as inline code.
Overloaded operators are another example. There are operators written within a class, but friend operators are written as non-member functions which accept and adapt to types appropriately outside the context of class membership (and can define behavior of relationship between types).
If I have a hammer, but I have a screw, can I adapt the hammer's behavior to the use of the screw? If not, the compiler (mixing metaphor and programming) should complain. If I have a knife that can work to turn a screw, there may be some adaptation to handling the knife which may do the job.
Who hasn't turned the screwdriver "the other way" to pound on a nail?
Sometimes "classes for the sake of classes" denies us that creative option. That's why <algorithm> is largely non member functions.
If I have a vector2 and a vector3, is there any relationship of addition that works? I may well have situations where I could add a vector2's x/y to a vector3's x/y, assuming the Z plane is adjusted elsewhere. If the result type is a vector2, I suppose one could just assume the vector3's Z should be ignored, but it makes a little less sense than if the result is a vector3.
I can establish the relationships through either overloading the operators, to define who these operations should be assumed, or I can deny them altogether and force the consumer of the code to choose.
Either way, operator overloads can easily apply a scalar to either vector2's and vector3's, as long as the result is a matching vector type.
Much of that may not involve class member functions, some of it may. In all cases, though, the focus of attention isn't so much "classes for the sake of classes" but of defining relationships and selecting methods based on type (attributes of reality).
In another "int and float might be objects" analogy, consider the family of "fopen/fwrite/fread/fclose" from C. They all require a FILE * (or fopen returns one). There is a weak association of the type (FILE *) and these functions. You can't really use these functions without a FILE *, and can't meaningfully substitute anything else. The FILE * itself is a structure. This collection exhibits the association of types and methods which, if you squint and believe a bit, resembles the notion of a class. It just isn't bound together with class syntax.
Imagine how different the family of fwrite/fread might have been if early C had merely allowed function overloads. We might have avoided the "void *" concept in this family.
@jonnin #4 - the "classic" example from Stroustrup was Boost's lambda library, applicable before C++ included lambdas.
A counter example, though, of "good use of cuteness" is Eigen. This is a linear algebra library supporting n dimensions. To oversimplify, A = B * C * D, where these are not built in types but some appropriate combination(s) of vectors and/or matrices. The result of B * C may not be any kind of expected matrix or vector, but of AN INSTRUCTION. The "=" takes this INSTRUCTION type (may be a chain of instructions and parameters) to perform an optimization for the actual calculation. This means the "*" here isn't executed before the "=". The calculation of "*" is done within the "=" operator function as a result of processing the instructions. The result can be a runtime optimized way of performing the work.
Oh, and another thing....
Jonnin's point about the std::vector NOT being a linear algebra construct, but of a container. Here we witness the notion that the name is to be interpreted such that the type is understood by context of usage. The namespace helps separate them in code, but to the mind we understand that std::vector is an entirely different thing, with different purposes and methods, than the vector2 or vector3 representing an offset to a point on a graph. Humans naturally handle this well, but noticing it so as to express it in a language takes a bit more thought and explication.
So a std::vector< vector2 > isn't actually confusing, per se. It does highlight that "objects" have relationships that aren't just about classes, but about how we think of things.
Microsoft's compiler is ok, not the best optimizer, fairly compliant with standards, but targeting Windows automatically requires extensions of all compilers to process the windows header files. LLVM/Clang is better at optimized output, usually a tad ahead of Microsoft on compliance, and is supported on VS CE as an easy "official" install, even to target Linux development.
GCC seems to me an academic exercise. It's a good compiler, a tad behind LLVM on optimization, but is usually first to support new C++ standards. Don't install it just because of that, though.
I've been volunteering to teach robotic programming at a club the high school (where my son just graduated). He was a member of the club when I realized the teacher was a very good mechanical engineer but had zero training in computers (doesn't even use a spreadsheet, can't print an image from an email). This will be my third year. They use Vex EDR.
I bring this up because one project (or exercise) was to write the control software for a holonomic drive (the wheels are all at 45 degree angles with rollers - the bot can drive in any direction without turning). There is a naive bit of code on the 'net for this, but it has no finesse. We realized soon we needed "snap to angle", because there are no detents on the controller, so we snap to the major axis (45's and 90's). To do that we needed trig. Take the X/Y input, calculate the angle, snap the angle, take the length as the speed - and then apply a curve to the speed so the center 3rd is less sensitive (for accurate control), while the latter half is "full power". One student with a kind of OCD about math could not stop thinking about this code to understand it. As a project, it was wonderful.
Another was software for a simple one joint arm. The kids didn't know what they were supposed to do with this "sin/cos/atan things", but here was an arm to be used in a competition. The needed to transform a height into an angle for a single joint.
Then, later, we made a 3 joint arm (shoulder, elbow, wrist - claw). There we have inverse kinematics at play. We need to think in terms of 2d coordinates (the objective for the claw), but our control is only the angles of the joints. This brings up the law of cosines, law of sines and some other basic trig thinking. At first, with the freshmen and sophomores, it was too much. The juniors and seniors, however, discovered why they bothered suffering through algebra and trig because of it.
Another, through a forum request on a game programming site, was a simple self driving bot. A unicycle is to drive itself through a set of waypoints. Using PID to control steering, the bot drives in a way similar to someone on a unicycle. The PID algorithm (widely available on the 'net) is deceptively simple, and touchy to tune, but the result is a good "exercise".
@jonnin brings up some really good points.
#5, for example. Notice that the <algorithm> library is mostly non-member functions. There are very good design reasons for that, and it does NOT mean they are non-oop. Non-member functions may well be part of object behavior, but do not always have to be part of a class.
To be clear, sort is a template function. It adapts to the types fed to it, and takes in an object as a parameter which describes the comparison operation in a way that promotes emitting that as inline code.
Overloaded operators are another example. There are operators written within a class, but friend operators are written as non-member functions which accept and adapt to types appropriately outside the context of class membership (and can define behavior of relationship between types).
If I have a hammer, but I have a screw, can I adapt the hammer's behavior to the use of the screw? If not, the compiler (mixing metaphor and programming) should complain. If I have a knife that can work to turn a screw, there may be some adaptation to handling the knife which may do the job.
Who hasn't turned the screwdriver "the other way" to pound on a nail?
Sometimes "classes for the sake of classes" denies us that creative option. That's why <algorithm> is largely non member functions.
If I have a vector2 and a vector3, is there any relationship of addition that works? I may well have situations where I could add a vector2's x/y to a vector3's x/y, assuming the Z plane is adjusted elsewhere. If the result type is a vector2, I suppose one could just assume the vector3's Z should be ignored, but it makes a little less sense than if the result is a vector3.
I can establish the relationships through either overloading the operators, to define who these operations should be assumed, or I can deny them altogether and force the consumer of the code to choose.
Either way, operator overloads can easily apply a scalar to either vector2's and vector3's, as long as the result is a matching vector type.
Much of that may not involve class member functions, some of it may. In all cases, though, the focus of attention isn't so much "classes for the sake of classes" but of defining relationships and selecting methods based on type (attributes of reality).
In another "int and float might be objects" analogy, consider the family of "fopen/fwrite/fread/fclose" from C. They all require a FILE * (or fopen returns one). There is a weak association of the type (FILE *) and these functions. You can't really use these functions without a FILE *, and can't meaningfully substitute anything else. The FILE * itself is a structure. This collection exhibits the association of types and methods which, if you squint and believe a bit, resembles the notion of a class. It just isn't bound together with class syntax.
Imagine how different the family of fwrite/fread might have been if early C had merely allowed function overloads. We might have avoided the "void *" concept in this family.
@jonnin #4 - the "classic" example from Stroustrup was Boost's lambda library, applicable before C++ included lambdas.
A counter example, though, of "good use of cuteness" is Eigen. This is a linear algebra library supporting n dimensions. To oversimplify, A = B * C * D, where these are not built in types but some appropriate combination(s) of vectors and/or matrices. The result of B * C may not be any kind of expected matrix or vector, but of AN INSTRUCTION. The "=" takes this INSTRUCTION type (may be a chain of instructions and parameters) to perform an optimization for the actual calculation. This means the "*" here isn't executed before the "=". The calculation of "*" is done within the "=" operator function as a result of processing the instructions. The result can be a runtime optimized way of performing the work.
Oh, and another thing....
Jonnin's point about the std::vector NOT being a linear algebra construct, but of a container. Here we witness the notion that the name is to be interpreted such that the type is understood by context of usage. The namespace helps separate them in code, but to the mind we understand that std::vector is an entirely different thing, with different purposes and methods, than the vector2 or vector3 representing an offset to a point on a graph. Humans naturally handle this well, but noticing it so as to express it in a language takes a bit more thought and explication.
So a std::vector< vector2 > isn't actually confusing, per se. It does highlight that "objects" have relationships that aren't just about classes, but about how we think of things.
Last edited on
As I said I am not an engineer, I just supported a team of them for about 2 decades (aerospace and mechanical areas). Mostly doing controls/linear algebra, and that being 'turn this into code'.
You are asking the right questions, but they don't have simple answers. I have moved on; my books are older than young coders now.
take real time... your hardware matters: is this a phone? An embedded processor like aurdino? A PC? A 16+ cpu (with 4 times that in cores) cruncher? Or take talking to consumers... could be simple UDP flow, could be generation of a web page on the fly, could be a queue (software, not data structure), could be a service (small specialized I/O programs), and many more. These are large topics on their own, whether flavored by c++ or no.
As for code that will have a lifespan … we have comments. if the code ends up being a bit more to read than the audience can chew on, but its the right way to code it, put a few comments in there. Its not your job to teach c++ to the reader but it won't hurt to put a some googleable keywords in there eg //this is the c++ vector erase-remove idiom if your audience is a bunch of engineers that only know basic c++ . I would say DO NOT avoid a tool just because it is complex, just be sure to give a little help to the readers.
No exercises here. Do you know what you need to solve in code? Solve that problem -- or a small part of it. Maybe you need to FFT a vector, or run statistics over a 2-d array for correlations, or solve some awful differential equation or something..? Find something practical that is likely to show up in the problems you plan on solving with c++ and try to solve some of them. What do you do... maybe you make airplanes, maybe you need a plane class that inherits engines and flaps and landing gear classes and those have their own parts and stuff all the way down to some code that calls vectors of doubles or complex to compute forces or angles or whatever... bring a problem you know well to the language and try to express it (so your work here isn't solving the problem, you know how to do that, the work is expressing that in code, which you are learning).
You are asking the right questions, but they don't have simple answers. I have moved on; my books are older than young coders now.
take real time... your hardware matters: is this a phone? An embedded processor like aurdino? A PC? A 16+ cpu (with 4 times that in cores) cruncher? Or take talking to consumers... could be simple UDP flow, could be generation of a web page on the fly, could be a queue (software, not data structure), could be a service (small specialized I/O programs), and many more. These are large topics on their own, whether flavored by c++ or no.
As for code that will have a lifespan … we have comments. if the code ends up being a bit more to read than the audience can chew on, but its the right way to code it, put a few comments in there. Its not your job to teach c++ to the reader but it won't hurt to put a some googleable keywords in there eg //this is the c++ vector erase-remove idiom if your audience is a bunch of engineers that only know basic c++ . I would say DO NOT avoid a tool just because it is complex, just be sure to give a little help to the readers.
No exercises here. Do you know what you need to solve in code? Solve that problem -- or a small part of it. Maybe you need to FFT a vector, or run statistics over a 2-d array for correlations, or solve some awful differential equation or something..? Find something practical that is likely to show up in the problems you plan on solving with c++ and try to solve some of them. What do you do... maybe you make airplanes, maybe you need a plane class that inherits engines and flaps and landing gear classes and those have their own parts and stuff all the way down to some code that calls vectors of doubles or complex to compute forces or angles or whatever... bring a problem you know well to the language and try to express it (so your work here isn't solving the problem, you know how to do that, the work is expressing that in code, which you are learning).
Wow gentlemen.... definitely fire hose time!
I ANTICIPATE the processors we're going to use are going to be anything from microprocessors (Texas Instruments, Microchip, Arduino? ) to full fledged RTOS CPU's in chasses or maybe NVIDIA's or perhaps something like a Raspberry PI - and maybe all of them together. I already know they want to port a LOT if not all of these diagnostics to phones which I have NEVER programmed for phones or anything like that before. I have done RTOS chasses and microprocessors (embedded systems) mainly but it has been about 5 years!!
Most of these solutions are for military aircraft and therefore will have to not only meet MIL spec conditions but also FAA and other countries' FAA equivalent specifications and ll the headaches that come with that crap.
I will take your advise and try to pick up some of these books (I'm old school - I like things that don't take batteries) and just start solving some of these problems. I will take you up on your suggestion Niccolo and see if I can just ditch the CodeBlocks and get into LLVM/Clang and start using that instead.
I'm going to keep going through Stroustrup's tour and just see where I need to focus and I suppose just start practicing.
Again, you guys are a wealth of information..... so much so that I think I'm drowning already!! LOL. But I will conquer nonetheless.
Xanadu
I ANTICIPATE the processors we're going to use are going to be anything from microprocessors (Texas Instruments, Microchip, Arduino? ) to full fledged RTOS CPU's in chasses or maybe NVIDIA's or perhaps something like a Raspberry PI - and maybe all of them together. I already know they want to port a LOT if not all of these diagnostics to phones which I have NEVER programmed for phones or anything like that before. I have done RTOS chasses and microprocessors (embedded systems) mainly but it has been about 5 years!!
Most of these solutions are for military aircraft and therefore will have to not only meet MIL spec conditions but also FAA and other countries' FAA equivalent specifications and ll the headaches that come with that crap.
I will take your advise and try to pick up some of these books (I'm old school - I like things that don't take batteries) and just start solving some of these problems. I will take you up on your suggestion Niccolo and see if I can just ditch the CodeBlocks and get into LLVM/Clang and start using that instead.
I'm going to keep going through Stroustrup's tour and just see where I need to focus and I suppose just start practicing.
Again, you guys are a wealth of information..... so much so that I think I'm drowning already!! LOL. But I will conquer nonetheless.
Xanadu
OOOO! Flight!
I supposed you've been instructed to follow JSF++? Stroustrup was largely part of defining that coding standard.
Programming for phones is as much about configuring an IDE and "make" files (they have various ones from CMake to Gradle) as it is the actual software. Android focuses on Java, but with Visual Studio and Xamarin it is possible to use C#. However, Android does support C++ using the NDK (Native Development Toolkit), such that you can largely write a C++ application for Android. Once the IDE and build environment is working, the rest is the same C++ used everywhere else, though of course display and interface is it's own thing.
For Android I do suggest Android Studio for ease of setup. If you want to debug without using a device, I can recommend MEMU. Android's development system does have AVD (Android virtual device), which do emulate an Android device in Windows (or MAC or Linux), but it has always been a bit touchy. MEMU is an Android VM intended for users to play Android Games loaded from the Play Store, so it is much better at being Android than the AVD's. The "Studio" can operate MEMU like it's a physical device (based on an X86 platform).
At this point 99.9% of anything embedded or elsewhere will by ARM of some flavor or X86, and you really need not know the difference for the most part. They're faster with more RAM, but about the same as 5 years ago.
Have you tried a static code analyzer? There's one built in to Visual Studio CE that's reasonable. It will review code and comment way beyond compiler warnings, to the extent of being...humbling, to put it mildly. It does, however, make you aware of practical points you might not have time to find in books. Quite accelerating, but a bit daunting at first.
I'm a firm believer and practitioner of Pascal's excuse. I paraphrase, "I didn't have time to write a short post, so I wrote a long one."
I supposed you've been instructed to follow JSF++? Stroustrup was largely part of defining that coding standard.
Programming for phones is as much about configuring an IDE and "make" files (they have various ones from CMake to Gradle) as it is the actual software. Android focuses on Java, but with Visual Studio and Xamarin it is possible to use C#. However, Android does support C++ using the NDK (Native Development Toolkit), such that you can largely write a C++ application for Android. Once the IDE and build environment is working, the rest is the same C++ used everywhere else, though of course display and interface is it's own thing.
For Android I do suggest Android Studio for ease of setup. If you want to debug without using a device, I can recommend MEMU. Android's development system does have AVD (Android virtual device), which do emulate an Android device in Windows (or MAC or Linux), but it has always been a bit touchy. MEMU is an Android VM intended for users to play Android Games loaded from the Play Store, so it is much better at being Android than the AVD's. The "Studio" can operate MEMU like it's a physical device (based on an X86 platform).
At this point 99.9% of anything embedded or elsewhere will by ARM of some flavor or X86, and you really need not know the difference for the most part. They're faster with more RAM, but about the same as 5 years ago.
Have you tried a static code analyzer? There's one built in to Visual Studio CE that's reasonable. It will review code and comment way beyond compiler warnings, to the extent of being...humbling, to put it mildly. It does, however, make you aware of practical points you might not have time to find in books. Quite accelerating, but a bit daunting at first.
I'm a firm believer and practitioner of Pascal's excuse. I paraphrase, "I didn't have time to write a short post, so I wrote a long one."
Last edited on
So gentlemen,
You gave me a ton of advise and it's all very good.... but let me ask you this==> Of all the books and resources you gave in the links...… What are the one or two books or resources I need to look at right now if I need to bring myself up to concurrent speed rather quickly and gain proficiency fairly quickly??
Of the list you guys gave, what is the one "thing" I need to buy or start reading right now for the quickest up-take back into the C++ fold?
Ideas suggestions? Is it Stroustrup, Sutter, Meyer.... all of the above? Just use the links to the isocpp?? If it is all of the above is there a hierarchy order of importance which I should note?
Just trying to boil this down into the highest return on investment in the shortest amount of time and then keep building on that until I am less ignorant.
Xanadu
You gave me a ton of advise and it's all very good.... but let me ask you this==> Of all the books and resources you gave in the links...… What are the one or two books or resources I need to look at right now if I need to bring myself up to concurrent speed rather quickly and gain proficiency fairly quickly??
Of the list you guys gave, what is the one "thing" I need to buy or start reading right now for the quickest up-take back into the C++ fold?
Ideas suggestions? Is it Stroustrup, Sutter, Meyer.... all of the above? Just use the links to the isocpp?? If it is all of the above is there a hierarchy order of importance which I should note?
Just trying to boil this down into the highest return on investment in the shortest amount of time and then keep building on that until I am less ignorant.
Xanadu
Stroustrup's C++ Principles and Practice would be my first suggestion for someone in need of a zero to upper intermediate knowledge of C++, and it is used by Stroustrup as a textbook for teaching through that level, while it is not so simple and boring that more experienced developers would find it too elementary, especially after the first two chapters or so.
The second would probably be Josuttis on the C++ Standard library, a tutorial and reference. This is the rest of the story, from smart pointers and containers to algorithms.
Then the Meyer on Effective C++.
That's the progression that makes the most sense to me on investment vs return, and one book at a time makes sense.
The second would probably be Josuttis on the C++ Standard library, a tutorial and reference. This is the rest of the story, from smart pointers and containers to algorithms.
Then the Meyer on Effective C++.
That's the progression that makes the most sense to me on investment vs return, and one book at a time makes sense.
Then the Meyer on Effective C++.
watch the versions, he has been making this series long enough that I have a set of them!
watch the versions, he has been making this series long enough that I have a set of them!
You bro's are alright!
Thank you gentlemen! Looks like I'm buying Stroustrup, Josuttis and Meyer right up front! Jonnin you said get the LATEST Meyer is what I think you're implying correct? What number is he up to now?
Again, I am very grateful that you both would take the time to point me in the direction for the most efficient learning since it appears I will have to come up to speed rather quickly and have a good idea of how to proceed.
Amazon book buy here I come!
Xanadu
Thank you gentlemen! Looks like I'm buying Stroustrup, Josuttis and Meyer right up front! Jonnin you said get the LATEST Meyer is what I think you're implying correct? What number is he up to now?
Again, I am very grateful that you both would take the time to point me in the direction for the most efficient learning since it appears I will have to come up to speed rather quickly and have a good idea of how to proceed.
Amazon book buy here I come!
Xanadu
BOOM!
Stroustrup, Meyers and Josuttis inbound! I think I'm going to be busy reading and coding for a little while trying to get back on top of all of this.
So don't be surprised if you see some questions bout this in the very near future.
Thank you again for your direction and help!
Xanadu
Stroustrup, Meyers and Josuttis inbound! I think I'm going to be busy reading and coding for a little while trying to get back on top of all of this.
So don't be surprised if you see some questions bout this in the very near future.
Thank you again for your direction and help!
Xanadu
Topic archived. No new replies allowed.