![]() |
Book on C++11.
Hi,
Is there a book on C++11 ? 2nd edition of "Thinking in c++" was published on 2000. Is there any new edition of this book coming in near future with C++11? Sincerely, Srinivas |
Re: Book on C++11.
On Saturday, June 16, 2012 6:38:58 AM UTC-5, Srinivas Nayak wrote:
> Hi, > > Is there a book on C++11 ? > > 2nd edition of "Thinking in c++" was published on 2000. > Is there any new edition of this book coming in near future with C++11? > > Sincerely, > Srinivas I have a related question. Should I bother learning c++ 11 if I'm learning C++ to get in to the programming field. Will big C++ 03 projects continue to hire or is C++11 suddenly in demand? I'm considering just picking up the books in the FAQ because they're cheap and effective, despite being outdated by the new standard. |
Re: Book on C++11.
jjtf wrote:
> On Saturday, June 16, 2012 6:38:58 AM UTC-5, Srinivas Nayak wrote: >> Hi, >> >> Is there a book on C++11 ? >> >> 2nd edition of "Thinking in c++" was published on 2000. >> Is there any new edition of this book coming in near future with C++11? >> >> Sincerely, >> Srinivas > > I have a related question. > > Should I bother learning c++ 11 if I'm learning C++ to get in to the programming > field. > Will big C++ 03 projects continue to hire or is C++11 suddenly in demand? The answer probably most depends on your timing for entering the market. Right now, a mid-to-big size company I work for does not use C++11 or asks C++11-specific questions at the interviews. You would not miss a point saying you have not had a chance to work in C++11. Some awareness about useful C++11 features (just being able to legibly explain what's good about them) might be a (really small) "plus". I speculate this will stay so for a couple of years; then this might start gradually change. Smaller companies may start using C++11 faster. The keyword here is "start": tons of 1998- and 2003- compliant code are probably bound to be written for many years and to stay around and to be maintained for decades. > I'm considering just picking up the books in the FAQ because they're cheap and effective, despite being outdated by the new standard. What I pay most attention to are the focus, software design, problem solving and practical coding skills and common sense. I bet you won't waste your time concentrating on these instead of syntactic peculiarities you have never used -- just be honest and upfront about it during your interviews. For the books, apart from generally solid FAQ recommendations, "Thinking in..." should be just fine; for something more C++-ish and modern (not yet 11-ish), try "Modern C++ Design" by Andrei Alecsandrescu -- just do not jump into applying Loki to all seemingly appropriate problems without giving it a good second (or third) thought. Also, IMHO reading an important piece of source code (e.g. that of a modern version of C++ Standard Library) can be more instructive than reading a good book. -HTH Pavel |
Re: Book on C++11.
On Sun, 2012-06-17, Pavel wrote:
> jjtf wrote: .... >> I have a related question. >> >> Should I bother learning c++ 11 if I'm learning C++ to get in to the programming >> field. Will big C++ 03 projects continue to hire or is C++11 suddenly in demand? > The answer probably most depends on your timing for entering the market. Right > now, a mid-to-big size company I work for does not use C++11 or asks > C++11-specific questions at the interviews. You would not miss a point saying > you have not had a chance to work in C++11. Some awareness about useful C++11 > features (just being able to legibly explain what's good about them) might be a > (really small) "plus". I'd think it would be a real plus, but only because it shows you're keeping up with what's happening. On the other hand lots of people are doing that -- C++11 got lots of media attention. > What I pay most attention to are the focus, software design, problem solving and > practical coding skills and common sense. I bet you won't waste your time > concentrating on these instead of syntactic peculiarities you have never used -- > just be honest and upfront about it during your interviews. Good advice. .... > Also, IMHO reading an important piece of source code (e.g. that of a modern > version of C++ Standard Library) can be more instructive than reading a good book. You need to do both. Not sure reading the STL is the best thing you can do though -- general-purpose libraries are very unlike the code you'll spend most of your time reading and writing. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
Re: Book on C++11.
Jorgen Grahn wrote:
> On Sun, 2012-06-17, Pavel wrote: >> jjtf wrote: > ... >>> I have a related question. >>> >>> Should I bother learning c++ 11 if I'm learning C++ to get in to the programming >>> field. Will big C++ 03 projects continue to hire or is C++11 suddenly in demand? > >> The answer probably most depends on your timing for entering the market. Right >> now, a mid-to-big size company I work for does not use C++11 or asks >> C++11-specific questions at the interviews. You would not miss a point saying >> you have not had a chance to work in C++11. Some awareness about useful C++11 >> features (just being able to legibly explain what's good about them) might be a >> (really small) "plus". > > I'd think it would be a real plus, but only because it shows you're > keeping up with what's happening. On the other hand lots of people are > doing that -- C++11 got lots of media attention. > >> What I pay most attention to are the focus, software design, problem solving and >> practical coding skills and common sense. I bet you won't waste your time >> concentrating on these instead of syntactic peculiarities you have never used -- >> just be honest and upfront about it during your interviews. > > Good advice. > > ... >> Also, IMHO reading an important piece of source code (e.g. that of a modern >> version of C++ Standard Library) can be more instructive than reading a good book. > > You need to do both. Not sure reading the STL is the best thing you > can do though -- general-purpose libraries are very unlike the code > you'll spend most of your time reading and writing. Yes, the domain one will work for will probably be different but this does not make this code less instructive. In my experience, the source code of STL in particular is one of the best exposures of non-obvious issues one would face to efficiently implement seemingly straightforward specifications in C++. STL API is relatively simple but an efficient implementation uses many more standard C++ features and implementation-specific extensions than typical small-scale STL client code (let alone a collection of examples). Carefully studying why this or that feature was used helps understand why those more complex features were defined as they were and where they were either insufficient or inconvenient enough for the library author to use extensions. A modern version may also give an idea how new C++11 features can be useful (e.g. see usage of GNU __alignof__ extension in GNU STL that can be replaced by the standard alignof operator in C++11). The added advantage of reading STL code is deeper understanding STL specs. The reader would probably have some initial idea and, as s/he oceeds, s/he will learn the details s/he will apply when using STL later and get an idea why the specs are what they are. > > /Jorgen > -Pavel |
Re: Book on C++11.
On Sun, 2012-06-17, Pavel wrote:
> Jorgen Grahn wrote: >> On Sun, 2012-06-17, Pavel wrote: >>> Also, IMHO reading an important piece of source code (e.g. that of a modern >>> version of C++ Standard Library) can be more instructive than reading a good book. >> >> You need to do both. Not sure reading the STL is the best thing you >> can do though -- general-purpose libraries are very unlike the code >> you'll spend most of your time reading and writing. > Yes, the domain one will work for will probably be different but this does not > make this code less instructive. In my experience, the source code of STL in > particular is one of the best exposures of non-obvious issues one would face to > efficiently implement seemingly straightforward specifications in C++. I agree reading it is useful. But you don't get this from it: the mapping from a concrete typical real-world problem into a (probably object-oriented) design, and the mapping of that into C++ code. STL *does* solve a real-world problem, but an unusual one: to provide efficient general-purpose containers and algorithms which will suit almost all needs. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
Re: Book on C++11.
Jorgen Grahn wrote:
> On Sun, 2012-06-17, Pavel wrote: >> Jorgen Grahn wrote: >>> On Sun, 2012-06-17, Pavel wrote: >>>> Also, IMHO reading an important piece of source code (e.g. that of a modern >>>> version of C++ Standard Library) can be more instructive than reading a good book. >>> >>> You need to do both. Not sure reading the STL is the best thing you >>> can do though -- general-purpose libraries are very unlike the code >>> you'll spend most of your time reading and writing. > >> Yes, the domain one will work for will probably be different but this does not >> make this code less instructive. In my experience, the source code of STL in >> particular is one of the best exposures of non-obvious issues one would face to >> efficiently implement seemingly straightforward specifications in C++. > > I agree reading it is useful. But you don't get this from it: the > mapping from a concrete typical real-world problem into a (probably > object-oriented) design, and the mapping of that into C++ code. Oh, yes, I most certainly agree STL does not provide much insights to OOA&D-in-C++. Some other Standard C++ Library facilities, like streambuf hierarchy, do more of it -- but I am far from calling streambuf a good OOA&D example. IMO the main benefit from Standard Library code reading is learning the language features and their application to low-level problems rather than developing one's design-at-large skills. STL, however, provides an example of good design as an additional benefit even though it does not use many OO techniques. I have to admit I don't really know whether STL is technically OO or not: on one hand, it has classes and achieves main goals of a good OO design, such as loose coupling and high cohesion; on the other, it does not use virtual functions, is-a type of inheritance etc. I am not crazy about pigeon-holing so I won't lose my sleep about this question. > > STL *does* solve a real-world problem, but an unusual one: to provide > efficient general-purpose containers and algorithms which will suit > almost all needs. > > /Jorgen > -Pavel |
Re: Book on C++11.
jjtf wrote:
> I have a related question. > > Should I bother learning c++ 11 if I'm learning C++ to get in to the > programming field. Will big C++ 03 projects continue to hire or is C++11 > suddenly in demand? It should be pointed out that C++11 is essentially a superset of C++03. This means that learning C++11 is essentially the same thing as learning C++03 along with a number of additional features. So, there is no reason to place yourself in a spot where you believe you should pick one or the other. In practical terms, it's probably a good idea to focus on C++03, simply because it's something that you need to do anyway (being a subset of C++11), and as it is expected that it will take some time before C++11-compliant compilers have become widely adopted. In addition, there is obviously more software out there that doesn't use C++11 features than the one that does. Nevertheless, some C++11 features are terribly easy to pick up, and some were even already available through non-standard components. This means that there is essentially no excuse to avoid learning them. For example, range-based for loops, nullptr and using >> in nested templates definitions are picked up without any problem, as is using override and final in member function declarations. Even if you don't use C++11's std::tuple and std::array, there is always boost's version. So, in short, although it might be preferable to focus for now on C++11's C++03 subset, you are doing yourself a disservice if you intentionally avoid getting acquainted with the C++11 goodies. Rui Maciel |
Re: Book on C++11.
Pavel wrote:
> Also, IMHO reading an important piece of source code (e.g. that of a > modern version of C++ Standard Library) can be more instructive than > reading a good book. That really depends on the source code and the reader's background. For example, if a reader isn't acquainted with design patterns then, when reading source code where design patterns are implemented, some details will either appear terribly convoluted or even won't even be noticed at all. And let's not even talk about template metaprogramming. Some of the stuff out there, even the basic stuff, tends to be a bit mind-blowing if a reader doesn't know what he is looking at. Rui Maciel |
Re: Book on C++11.
Rui Maciel wrote:
> Pavel wrote: > >> Also, IMHO reading an important piece of source code (e.g. that of a >> modern version of C++ Standard Library) can be more instructive than >> reading a good book. > > That really depends on the source code and the reader's background. For > example, if a reader isn't acquainted with design patterns then, when > reading source code where design patterns are implemented, some details will > either appear terribly convoluted or even won't even be noticed at all. And > let's not even talk about template metaprogramming. Some of the stuff out > there, even the basic stuff, tends to be a bit mind-blowing if a reader > doesn't know what he is looking at. True. One reason I believe the C++ Standard Library code is worth reading is exactly that the reader would now what he is looking at because the purpose of every exposed API feature is well-documented and it has to be well understood by the learner anyway. That is, even if he does not know some of it, it's never waste of his time to read more of the Standard Library specs and learn. > > > Rui Maciel > -Pavel |
| All times are GMT. The time now is 02:24 AM. |
Powered by vBulletin®. Copyright ©2000 - 2013, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.