6 ms·

If you would like to do something significant within a months' time, learning C++ by reading a book is the worst possible course of action. Start by following

by palish 19y ago

If you would like to do something significant within a months' time, learning C++ by reading a book is the worst possible course of action. Start by following along with some basic C++ tutorials. Once you're comfy enough, start implementing your own small applications. (Write a program to accept a sentence from the user and print it out. Then write a function that takes two strings and returns true if the two strings are anagrams. Keep thinking up small apps.) It is my opinion that you must avoid learning STL and Boost if you want to be productive within a month. Both libraries have enough quirks that it takes a significant amount of time and experience to use them correctly. For example, you don't need the std::vector or std::list containers. Simply allocate a sufficiently large array to hold your items, then allocate a larger array when the first one fills up. A std::map container (a dictionary) is also not needed if you're tracking a small number of items. Simply loop through all items until you find the one you're looking for. Basically, start actually writing code as quickly as possible. If you feel like you're burning too much time trying to understand one tutorial, move on to another one. But make sure at the end of each day that you can look back and say, "I wrote a lot of apps today and I feel like I learned a lot." Most importantly, don't be afraid to throw your old code away once you have a better understanding of how best to solve the problem. Implementing components as quickly as possible is the key to productivity. Rewriting your old code is the key to not making a mess. Contact me at palish@gmail.com if you have any questions along the way. I'd be happy to help. I'm a self-taught graphics programmer, so I can relate to how scary C++ can seem at first. Try to implement each application in the simplest possible way.

kashif 19y ago
Hey thanks...
- deleted 19y ago
  [deleted]
lacker 19y ago
I have to disagree with your advice to avoid vector and map. If you're used to python, you probably have a very list- and dict-centric method of programming, and you are probably not very familiar with explicit memory management. vector and map are pretty simple and correspond closely to the python list and dict classes. In fact, I would recommend that new c++ programmers used to scripting languages avoid using "new" entirely. With vectors and maps this shouldn't be too hard.
- palish 19y ago
  It would be both counterproductive and a premature optimization to learn C++ by first learning the STL containers. The only container that the C++ newcomer needs to learn is the dynamically allocated array. The statement "vector and map are pretty simple" just isn't true. STL and Boost have a lot of subtleties: 1) It is important to write STL code in the correct style. STL containers should be typedef'd before they are used and an iterator shouldn't be used directly to access an item (otherwise debugging becomes more difficult and your code becomes harder to read). For example, typedef std::list< Puppy > PuppyContainer; PuppyContainer puppies; for( PuppyContainer::iterator it = puppies.begin(); it != puppies.end(); ++it ) { Puppy* puppy = *it; // do something with your puppy } ... rather than ... std::list< Puppy > PuppyContainer; for( std::list< Puppy >::iterator it = puppies.begin(); it != puppies.end(); ++it ) { // do something with *it } 2) STL frequently allocates memory. Those allocations are also hidden from you, so it is easy to misunderstand the true cost of frequently using STL containers. Even a simple operation like acquiring an iterator can cause an allocation. I work at a game company. In their game's code base, the pervasiveness of STL has been attributed to millions of micro-allocations every frame of their game. (A micro-allocation is an allocation of under 128 bytes.) The result is hopelessly fragmented memory, which means that: - A relatively small 10MB allocation can cause a crash even when there is clearly more than 10MB free memory. - A lot of code runs slowly because almost none of the code can take advantage of the CPU cache. 3) Using STL can add code complexity and make your code harder to read. Which of these is easier for a newcomer to understand? for( size_t i = 0; i < _numPuppies; ++i ) if( _puppies[ i ].ID() == finding ) { /* do something with that puppy */ break; } ... or ... PuppyContainer::iterator it = _puppies.find( finding ); if( it != _puppies.end() ) { Puppy* puppy = it->second; /* do something with that puppy */ } The second example isn't intuitively easy to write unless you're already familiar with std::map. Check out my Radix Sort example. I could have used a couple std::vectors, but the result is equivalent and simple: http://dl.getdropbox.com/u/315/programming/exaples/radix_sort_example.cpp http://dl.getdropbox.com/u/315/programming/exaples/radix_sor... 4) It takes a lot of time to learn every facet of the C++ language. And the more you learn, the more other people can't read what you write because of your advanced knowledge. (Try understanding boost/bind.hpp.) 5) Most importantly, most design problems are architectural and not structural. As long as your code works and is reasonably clean and well-commented, it is good and safe code. It is more important to master a subset of C++ than to have a working knowledge of the entire language.
scott_s 19y ago
I disagree. Avoid native arrays; only use them when absolutely necessary. They are error prone and primitive. The STL data structures and algorithms are powerful, and are the best way to write a small amount of code that accomplishes a lot. What you're suggesting will result in complicated, buggy code to achieve simple tasks. Getting all of the details of the STL right is tricky and takes time, but using the simplest features is still the fastest way to write good C++ code. Since he already knows Python, it's mostly a matter of mapping the concepts from one language to another. I can't stress this enough. If you find yourself thinking, "Hmmmm, I need a list of these," use std::list. If you find yourself thinking "Hmmm, I need a structure that maps these values to those values," use std::map. When learning a new language, I think it's best to start using that language's idioms right away. C++ is no exception.
timr 19y ago
I'm piling on: this is (some of) the worst possible advice for learning C++. It may take a little bit longer to learn how to use the STL container classes, but the time is well-spent, and you can't make a legitimate claim of "knowing" C++ until you're comfortable with them. They're part of the language! Bjarne Stroustrup wrote a good paper on learning C++ as its own language. I highly recommend it: http://www.research.att.com/~bs/new_learning.pdf http://www.research.att.com/~bs/new_learning.pdf
- palish 19y ago
  My advice is the worst possible advice, ever? The advice was based on being a professional C++ programmer for the last 3 years and a C++ tinkerer for 5 years before that. I thought there was some merit to it. If it was really that horrible, I apologize.
  - timr 19y ago
    It's was bad advice. Whether or not it was the "worst possible" advice...well, okay, I'm guilty of exaggeration for effect. There are probably worse ways of learning. Mea culpa. The reason that your advice was so bad, was that you were encouraging someone to lunge headlong into the worst parts of C++ programming, while simultaneously warning them off of the best parts of the language. I've been a C++ programmer since the mid-90s. I learned the language before the STL (or the 1998 standard), and I know from hard experience that C++ with STL is a very different (and far more productive) tool than C++ without STL. In other words, I learned it the way that you suggested, and I know from experience that's the wrong way to do it. (Note: I have edited the original comment to be slightly less extreme.)
aggieben 19y ago
Actually, I disagree quite strongly with this. Start writing applications using STL and boost immediately (or in your case, the STL plus the Symbian APIs). Both libraries have enough quirks that it takes a significant amount of time and experience to use them correctly. For example, you don't need the std::vector or std::list containers. Simply allocate a sufficiently large array to hold your items, then allocate a larger array when the first one fills up. This is how we ended up with so much crappy C++ code in the 90s. sigh. Yes, you do need std::vector and std::list. Those are the very first two data structures you should learn. If you're using int[] instead of std::vector<int>, there'd better be a good reason. Similarly if you're using char * instead of std::string. Learn to use iterators, and learn to use <algorithm>. Don't be afraid of streams, either. I think doing it any other way is just wasting time and making it harder to actually become proficient in C++, rather than just using the C++ compiler to give you C with a tiny bit of syntactic sugar. IMHO, it's much better to learn the ins and outs of STL as you use it, not by putting off using it until you master it all (what kind of logic is that, anyway?). I.e., it's way better to start off using a std::vector exactly as you would an array and learn it as you go than to put off using std::vector entirely until you understand the default allocator and operator overloading.
- palish 19y ago
  You can't use an std::vector exactly as you would an array. There are quirks to every STL container, and it is easy to get burned once per quirk. Here is an example: // create a list of numbers. static const int kNumNumbers = 10; int numbers[ kNumNumbers ]; for( int i = 0; i < kNumNumbers; ++i ) numbers[ i ] = i; // do something useful with those numbers. ... // zero-out the list. memset( numbers, 0, sizeof( int ) * kNumNumbers ); ... versus ... // create a list of numbers. std::vector< int > numbers; for( int i = 0; i < 10; ++i ) numbers.push_back( i ); // do something useful with those numbers. ... // zero-out the list. memset( &numbers, 0, sizeof( int ) * numbers.size() ); The second example is evil. Can you spot the bug? My point was, kashif wanted to be productive in C++ within a month. It is not reasonable to expect him to become familiar with all of the STL and Boost quirks within a month. He has a better chance of accomplishing something by using C++ as C plus constructors than by using C++ as a high-level language. The latter requires expertise and a large time investment.

by palish 19y ago

kashif 19y ago

Hey thanks...

deleted 19y ago
[deleted]

lacker 19y ago

I have to disagree with your advice to avoid vector and map. If you're used to python, you probably have a very list- and dict-centric method of programming, and you are probably not very familiar with explicit memory management. vector and map are pretty simple and correspond closely to the python list and dict classes. In fact, I would recommend that new c++ programmers used to scripting languages avoid using "new" entirely. With vectors and maps this shouldn't be too hard.

palish 19y ago
It would be both counterproductive and a premature optimization to learn C++ by first learning the STL containers. The only container that the C++ newcomer needs to learn is the dynamically allocated array. The statement "vector and map are pretty simple" just isn't true. STL and Boost have a lot of subtleties: 1) It is important to write STL code in the correct style. STL containers should be typedef'd before they are used and an iterator shouldn't be used directly to access an item (otherwise debugging becomes more difficult and your code becomes harder to read). For example, typedef std::list< Puppy > PuppyContainer; PuppyContainer puppies; for( PuppyContainer::iterator it = puppies.begin(); it != puppies.end(); ++it ) { Puppy* puppy = *it; // do something with your puppy } ... rather than ... std::list< Puppy > PuppyContainer; for( std::list< Puppy >::iterator it = puppies.begin(); it != puppies.end(); ++it ) { // do something with *it } 2) STL frequently allocates memory. Those allocations are also hidden from you, so it is easy to misunderstand the true cost of frequently using STL containers. Even a simple operation like acquiring an iterator can cause an allocation. I work at a game company. In their game's code base, the pervasiveness of STL has been attributed to millions of micro-allocations every frame of their game. (A micro-allocation is an allocation of under 128 bytes.) The result is hopelessly fragmented memory, which means that: - A relatively small 10MB allocation can cause a crash even when there is clearly more than 10MB free memory. - A lot of code runs slowly because almost none of the code can take advantage of the CPU cache. 3) Using STL can add code complexity and make your code harder to read. Which of these is easier for a newcomer to understand? for( size_t i = 0; i < _numPuppies; ++i ) if( _puppies[ i ].ID() == finding ) { /* do something with that puppy */ break; } ... or ... PuppyContainer::iterator it = _puppies.find( finding ); if( it != _puppies.end() ) { Puppy* puppy = it->second; /* do something with that puppy */ } The second example isn't intuitively easy to write unless you're already familiar with std::map. Check out my Radix Sort example. I could have used a couple std::vectors, but the result is equivalent and simple: http://dl.getdropbox.com/u/315/programming/exaples/radix_sort_example.cpp http://dl.getdropbox.com/u/315/programming/exaples/radix_sor... 4) It takes a lot of time to learn every facet of the C++ language. And the more you learn, the more other people can't read what you write because of your advanced knowledge. (Try understanding boost/bind.hpp.) 5) Most importantly, most design problems are architectural and not structural. As long as your code works and is reasonably clean and well-commented, it is good and safe code. It is more important to master a subset of C++ than to have a working knowledge of the entire language.

scott_s 19y ago

I disagree. Avoid native arrays; only use them when absolutely necessary. They are error prone and primitive. The STL data structures and algorithms are powerful, and are the best way to write a small amount of code that accomplishes a lot. What you're suggesting will result in complicated, buggy code to achieve simple tasks. Getting all of the details of the STL right is tricky and takes time, but using the simplest features is still the fastest way to write good C++ code. Since he already knows Python, it's mostly a matter of mapping the concepts from one language to another. I can't stress this enough. If you find yourself thinking, "Hmmmm, I need a list of these," use std::list. If you find yourself thinking "Hmmm, I need a structure that maps these values to those values," use std::map. When learning a new language, I think it's best to start using that language's idioms right away. C++ is no exception.

timr 19y ago

I'm piling on: this is (some of) the worst possible advice for learning C++. It may take a little bit longer to learn how to use the STL container classes, but the time is well-spent, and you can't make a legitimate claim of "knowing" C++ until you're comfortable with them. They're part of the language! Bjarne Stroustrup wrote a good paper on learning C++ as its own language. I highly recommend it: http://www.research.att.com/~bs/new_learning.pdf http://www.research.att.com/~bs/new_learning.pdf

palish 19y ago
My advice is the worst possible advice, ever? The advice was based on being a professional C++ programmer for the last 3 years and a C++ tinkerer for 5 years before that. I thought there was some merit to it. If it was really that horrible, I apologize.
- timr 19y ago
  It's was bad advice. Whether or not it was the "worst possible" advice...well, okay, I'm guilty of exaggeration for effect. There are probably worse ways of learning. Mea culpa. The reason that your advice was so bad, was that you were encouraging someone to lunge headlong into the worst parts of C++ programming, while simultaneously warning them off of the best parts of the language. I've been a C++ programmer since the mid-90s. I learned the language before the STL (or the 1998 standard), and I know from hard experience that C++ with STL is a very different (and far more productive) tool than C++ without STL. In other words, I learned it the way that you suggested, and I know from experience that's the wrong way to do it. (Note: I have edited the original comment to be slightly less extreme.)

aggieben 19y ago

Actually, I disagree quite strongly with this. Start writing applications using STL and boost immediately (or in your case, the STL plus the Symbian APIs). Both libraries have enough quirks that it takes a significant amount of time and experience to use them correctly. For example, you don't need the std::vector or std::list containers. Simply allocate a sufficiently large array to hold your items, then allocate a larger array when the first one fills up. This is how we ended up with so much crappy C++ code in the 90s. sigh. Yes, you do need std::vector and std::list. Those are the very first two data structures you should learn. If you're using int[] instead of std::vector<int>, there'd better be a good reason. Similarly if you're using char * instead of std::string. Learn to use iterators, and learn to use <algorithm>. Don't be afraid of streams, either. I think doing it any other way is just wasting time and making it harder to actually become proficient in C++, rather than just using the C++ compiler to give you C with a tiny bit of syntactic sugar. IMHO, it's much better to learn the ins and outs of STL as you use it, not by putting off using it until you master it all (what kind of logic is that, anyway?). I.e., it's way better to start off using a std::vector exactly as you would an array and learn it as you go than to put off using std::vector entirely until you understand the default allocator and operator overloading.

palish 19y ago
You can't use an std::vector exactly as you would an array. There are quirks to every STL container, and it is easy to get burned once per quirk. Here is an example: // create a list of numbers. static const int kNumNumbers = 10; int numbers[ kNumNumbers ]; for( int i = 0; i < kNumNumbers; ++i ) numbers[ i ] = i; // do something useful with those numbers. ... // zero-out the list. memset( numbers, 0, sizeof( int ) * kNumNumbers ); ... versus ... // create a list of numbers. std::vector< int > numbers; for( int i = 0; i < 10; ++i ) numbers.push_back( i ); // do something useful with those numbers. ... // zero-out the list. memset( &numbers, 0, sizeof( int ) * numbers.size() ); The second example is evil. Can you spot the bug? My point was, kashif wanted to be productive in C++ within a month. It is not reasonable to expect him to become familiar with all of the STL and Boost quirks within a month. He has a better chance of accomplishing something by using C++ as C plus constructors than by using C++ as a high-level language. The latter requires expertise and a large time investment.