C++ Books for new C++ Programmer (who is experienced in C and Python)

[Chicken Mcnuggets]

I'm currently learning C++ from the following books:

The C++ Programming Language 4th Edition
The C++ Standard Library 2nd Edition

and am thinking about buying:

Effective C++ 3rd Edition
More Effective C++ 1st Edition
Effective Modern C++ 1st Edition.

Are these books worth getting? I've read some good things about them and
they seem to come highly recommended. Or are there any other books I
should be looking at instead?

Anything that will increase my skill at C++ is what I am after. I have a
project I am working on which I'd really like to get finished using C++
and I want to make sure I'm not making any mistakes with it.

[Jorgen Grahn]

On Sun, 2014-11-23, Chicken Mcnuggets wrote:
> I'm currently learning C++ from the following books:
>
> The C++ Programming Language 4th Edition
> The C++ Standard Library 2nd Edition
>
> and am thinking about buying:
>
> Effective C++ 3rd Edition
> More Effective C++ 1st Edition
> Effective Modern C++ 1st Edition.
>
> Are these books worth getting? I've read some good things about them and
> they seem to come highly recommended. Or are there any other books I
> should be looking at instead?

I can't comment -- TC++PL is the only book I've really read. I do
agree you need another book to really grasp the standard library, and
grasping the standard library is crucial.

> Anything that will increase my skill at C++ is what I am after. I have a
> project I am working on which I'd really like to get finished using C++
> and I want to make sure I'm not making any mistakes with it.

Mostly because I'm curious: what things are you comfortable with now,
and which areas do you find problematic? When you're programming in
C++, I mean.

I can imagine knowing Python being a problem: it's in some ways the
opposite of C++, and in other ways quite similar.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Chicken Mcnuggets]

On 23/11/14 08:54, Jorgen Grahn wrote:
>
> Mostly because I'm curious: what things are you comfortable with now,
> and which areas do you find problematic? When you're programming in
> C++, I mean.
>

The big problem area for me with C++ is templates and how to incorporate
them into my code (and whether I should do or if I should use another
solution instead). I guess the problem is I've never used something like
C++ template system. From what I have read they are Turing complete so
theoretically I should be able to make really good use of them but I'm
stumped on when and how.

To be fair I haven't read the detailed section on them in The C++
Programming Language yet but yeah, that is my main problem area.

[Jorgen Grahn]

On Sun, 2014-11-23, Chicken Mcnuggets wrote:

> On 23/11/14 08:54, Jorgen Grahn wrote:
>>
>> Mostly because I'm curious: what things are you comfortable with now,
>> and which areas do you find problematic? When you're programming in
>> C++, I mean.
>>
>
> The big problem area for me with C++ is templates and how to incorporate
> them into my code (and whether I should do or if I should use another
> solution instead). I guess the problem is I've never used something like
> C++ template system.

The way I use them is I look for repetition and duplication in my code
-- two functions that are the same but operate on two different types,
or call different helper functions. Or a function which takes a
vector<Foo> but really just needs a [begin, end) pair of iterators to
Foo. Then I rewrite it with a template.

It helps if you already structure your code so similar things are done
in similar ways, and similar things have similar names. E.g. much of
the standard library would be useless if there weren't common patterns
in the naming and behavior of different containers and iterators. But
you may be familiar with that idea from Python already ...

> From what I have read they are Turing complete so
> theoretically I should be able to make really good use of them but I'm
> stumped on when and how.

That's the metaprogramming aspect of templates. It's probably useful
some of the time (definitely useful for library writers), but don't
let it stand in the way of everyday template usage.

> To be fair I haven't read the detailed section on them in The C++
> Programming Language yet but yeah, that is my main problem area.

Are you referring to the section on metaprogramming? Again, I
recommend using templates, but skipping TMP.

[Wouter van Ooijen]

Jorgen Grahn schreef op 23-Nov-14 10:55 AM:

I second that. I use templates a lot, but no metaprogramming. If you
need compile-time calculations use constexpr.

But for me it is important to understand SFINAE and how to use it to
select between alternative template specializations.

Wouter

>
> /Jorgen
>

[Chicken Mcnuggets]

Cool, thanks for the tips. I read a bit about SFINAE but my knowledge of
templates isn't really good enough at the moment to grasp what it is all
about. I'll do some more reading and come back to it.

My big problem at the moment is writing C++ code as if it were C code so
I have a tendency to use the C standard library more than the C++
standard library. I guess this is just down to ignorance of the C++
standard library and is considered poor practice for C++ code. I
certainly want to rewrite bits of my code to take full advantage of C++.

On the other hand some "bad practices" in C++ I have read about such as
using C style arrays and raw pointers rather than references seem to
make some things a little lighter when a full on C++ solution might add
extra overhead. Is it really considered that bad to have these things in
your code? The project I am working on is going to be open source, am I
going to turn off C++ programmers if I have to much C style stuff in the
code even if it is abstracted away behind classes?

[JiiPee]

But that depends on how effiecient/speed -crucial code it is. Most of my
code I have done it does not matter a bit if there is one cycle more
than using a C-version or more simple structure. So then it is better to
always use C++ structures/ways. It's a trade off between a good code
structure and efficiency. Plus many times C++ code is surely faster than
similar C- structure done by a programmer (I guess std::vector being one
of them compared to dynamic C-arrays ... not sure about this though but
my understanding). So I guess we would like to see an example where you
think C would be better.
But yes, if I find that some C-array or bitmask is faster than C++
and I have to loop it 10000000 times a second, then of course I use
C-type of version.

But I have understood (and its in the books as well) that do not try to
optimize too much first. And optimize only if it gives significant
difference after *tests*.

> The project I am working on is going to be open source, am I going to
> turn off C++ programmers if I have to much C style stuff in the code
> even if it is abstracted away behind classes?

I would personally not mix C and C++ styles. Its good to have same style
everywhere imo. But again, if its a *proven* clear efficiency issue,
then I would use C.

And yes, I do not like to see C code if I know it can be done with C++
as well :). Just my taste :).

[Richard Damon]

The first thing to note is that just because you can do something,
doesn't mean you should. Templates allow you to implement some very
powerful techniques, but when not used well can make you code an
unreadable mess.

My opinion is that the more complicated the meta-programming, the
simpler the interface should be (and the better the documentation should
be).

Templates are very good at providing generic operations that can be done
to a wide variety of types (that meet a common interface).

[Jorgen Grahn]

On Sun, 2014-11-23, Chicken Mcnuggets wrote:

...

> My big problem at the moment is writing C++ code as if it were C code so
> I have a tendency to use the C standard library more than the C++
> standard library. I guess this is just down to ignorance of the C++
> standard library and is considered poor practice for C++ code.

Depends on which part of the library you're talking about. The most
important parts of the C++ library don't exist in C: the containers
and algorithms.

> I certainly want to rewrite bits of my code to take full advantage of C++.
>
> On the other hand some "bad practices" in C++ I have read about such as
> using C style arrays and raw pointers rather than references seem to
> make some things a little lighter when a full on C++ solution might add
> extra overhead.

There's no performance penalty for references or std::array. For
other things ... one of the revelations I had when I started using C++
was when I realized that:

(a) A lot of the containers (string, vector, map ...) imply dynamic memory
allocation, when in C I would have used an array and hoped it
would be large enough.
(b) I could never or almost never see this cause any practical problems!

It's worth it.

> Is it really considered that bad to have these things in
> your code?

It depends ... they /do/ have their uses, but not where C++ has better
alternatives.

> The project I am working on is going to be open source, am I
> going to turn off C++ programmers if I have to much C style stuff in the
> code even if it is abstracted away behind classes?

Personally I can tolerate almost anything, if it's encapsulated in a
small class or function, and if that class or function as a whole
behaves normally (is exception-safe, has well-defined states, can be
copied if it makes sense, cannot be copied if it doesn't, and so on).
That's one of the main reasons classes exist.

Speaking of small classes: one of the common beginner's mistakes seems
to be to design a few big classes. IME you gain a lot more from
designing the many small, short-lived objects. Try to do that.

[Paavo Helde]

Chicken Mcnuggets <chi...@mcnuggets.com> wrote in
news:aBlcw.754984$9R5.3...@fx29.am4:

>
> On the other hand some "bad practices" in C++ I have read about such
> as using C style arrays and raw pointers rather than references seem
> to make some things a little lighter when a full on C++ solution might
> add extra overhead. Is it really considered that bad to have these
> things in your code?

Yes it is bad. And the overhead you are talking about is not there. The
most time-consuming part with arrays is dynamic allocation and
deallocation, which you have to do in C as well if the desired size of
the data is not known at compile time, and if it is known, then you can
use std::array or boost::array in C++ as well, with zero overhead. So
see, no overhead. All iterator and operator[] access is optimized away by
compilers (assuming an optimized build of course, which you have to do in
C as well anyway if performance is critical).

> The project I am working on is going to be open
> source, am I going to turn off C++ programmers if I have to much C
> style stuff in the code even if it is abstracted away behind classes?

Probably yes. If there is any kind of code review involved you will have
hard time explaining why you use cumbersome and error-prone hand-made
solutions instead of standard containers. For example, are you sure you
can make your classes properly exception-safe in the first try? And have
you properly implemented move constructors for taking advantages of C++11
performance improvements related to move semantics? If you use standard
containers, such issues are handled mostly automatically.

Cheers
Paavo

[woodb...@gmail.com]

I don't find much use for ::std::list, ::std::set or ::std::map.
::std::vector is OK. I use ::std::deque rarely, but wish there
were a better alternative. I use Boost containers sometimes also.


Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net

[Mr Flibble]

That is an idiotic thing to say Brian. All the containers are equally
useful so if you are using std::vector for everything then you are doing
it wrong.

/Flibble

[JiiPee]

On 23/11/2014 17:27, woodb...@gmail.com wrote:

yes, list and sets I don't see need to use, but map is good for making
quick code if mapping needs to be done. vector is very fast so its used
a lot. But there are problems where set is also perfect.... we just have
not done those projects maybe.

[JiiPee]

The top C++ lecturers, including Bjarne, they keep saying that vector is
better than list, even in list -type of problems. Basically what they
say is that "Don't use lists, use vectors." Its propably also better in
other things, I mean more efficient. But obviously if efficiency is not
required then those slower ones can be better option as they describe
the problem better.

The problem with list for example is that it scatters the objects all
around the memory space and its slow to access individual items compared
to vector, if iterating (which we do most of the time normally).

[Jorgen Grahn]

On Sun, 2014-11-23, woodb...@gmail.com wrote:
> On Sunday, November 23, 2014 11:03:06 AM UTC-6, Paavo Helde wrote:
>> Chicken Mcnuggets <chi...@mcnuggets.com> wrote in
>> news:aBlcw.754984$9R5.3...@fx29.am4:

...

>> > The project I am working on is going to be open
>> > source, am I going to turn off C++ programmers if I have to much C
>> > style stuff in the code even if it is abstracted away behind classes?
>>
>> Probably yes. If there is any kind of code review involved you will have
>> hard time explaining why you use cumbersome and error-prone hand-made
>> solutions instead of standard containers. For example, are you sure you
>> can make your classes properly exception-safe in the first try? And have
>> you properly implemented move constructors for taking advantages of C++11
>> performance improvements related to move semantics? If you use standard
>> containers, such issues are handled mostly automatically.
>>
>
> I don't find much use for ::std::list, ::std::set or ::std::map.
> ::std::vector is OK.

I think it's fair to the OP to explain that you're unusual in your
dislike for some of the standard containers (and in how you spell
their names).

At least std::map/std::unordered_map sees heavy use, in the situations
where a Python programmer would use a dict, and a Perl programmer
would use a hash.

[JiiPee]

yes, I can see use for all of them except list the which I still have
not figured any use, as vector can do all what it is doing? What can the
list do the vector can not?

[Chicken Mcnuggets]

As a Python programmer I use lists all the time. I don't know (yet)
whether C++ has the same features as Python for lists but list
comprehensions in Python allow you to do some really powerful things in
1 line of code.

I'm hoping you can do the same sort of thing in C++ since I use them all
the time.

std::map also sounds useful as it appears to essentially be a dictionary
in Python which I also use all the time.

[Chicken Mcnuggets]

No one has commented on these books. I'm hovering over the buy button on
Amazon but £80 for all three is quite a bit of cash and would like to
know if they are still recommended or not.

[woodb...@gmail.com]

On Sunday, November 23, 2014 11:45:15 AM UTC-6, Jorgen Grahn wrote:
> On Sun, 2014-11-23, woodb...@gmail.com wrote:
> > On Sunday, November 23, 2014 11:03:06 AM UTC-6, Paavo Helde wrote:
> >> Chicken Mcnuggets <chi...@mcnuggets.com> wrote in
> >> news:aBlcw.754984$9R5.3...@fx29.am4:
> ...
> >> > The project I am working on is going to be open
> >> > source, am I going to turn off C++ programmers if I have to much C
> >> > style stuff in the code even if it is abstracted away behind classes?
> >>
> >> Probably yes. If there is any kind of code review involved you will have
> >> hard time explaining why you use cumbersome and error-prone hand-made
> >> solutions instead of standard containers. For example, are you sure you
> >> can make your classes properly exception-safe in the first try? And have
> >> you properly implemented move constructors for taking advantages of C++11
> >> performance improvements related to move semantics? If you use standard
> >> containers, such issues are handled mostly automatically.
> >>
> >
> > I don't find much use for ::std::list, ::std::set or ::std::map.
> > ::std::vector is OK.
>
> I think it's fair to the OP to explain that you're unusual in your
> dislike for some of the standard containers

I'm not the only one. We discussed recently how
Chandler Carruth has similar views.

> (and in how you spell
> their names).
>


> At least std::map/std::unordered_map sees heavy use, in the situations
> where a Python programmer would use a dict, and a Perl programmer
> would use a hash.
>

I'd consider a Boost intrusive container or
::boost::multi_index. I'm not sure why multi_index
wasn't added to the standard years ago. Some of what
gets added isn't very good and some of what's left
out is good. Go figure.


Brian
Ebenezer Enterprises - America needs a doctor, STAT.
Ben Carson for President.

http://webEbenezer.net

[Ian Collins]

woodb...@gmail.com wrote:
>
> I don't find much use for ::std::list, ::std::set or ::std::map.
> ::std::vector is OK. I use ::std::deque rarely, but wish there
> were a better alternative. I use Boost containers sometimes also.

What's the origin of this recent odd habit of prepending std with
superfluous colons?

--
Ian Collins

[Richard Damon]

If guards against having a std namespace inside the namespace you code
is in. By using ::std it MUST be the globally defined and reserved for
the standard/implementation namespace.

I would probably reject any code at review the defined a std namespace
inside of a namespace as asking for problems, but is legal.

[Jorgen Grahn]

On Sun, 2014-11-23, woodb...@gmail.com wrote:
> On Sunday, November 23, 2014 11:45:15 AM UTC-6, Jorgen Grahn wrote:
>> On Sun, 2014-11-23, woodb...@gmail.com wrote:
>> > On Sunday, November 23, 2014 11:03:06 AM UTC-6, Paavo Helde wrote:
>> >> Chicken Mcnuggets <chi...@mcnuggets.com> wrote in
>> >> news:aBlcw.754984$9R5.3...@fx29.am4:
>> ...
>> >> > The project I am working on is going to be open
>> >> > source, am I going to turn off C++ programmers if I have to much C
>> >> > style stuff in the code even if it is abstracted away behind classes?
>> >>
>> >> Probably yes. If there is any kind of code review involved you will have
>> >> hard time explaining why you use cumbersome and error-prone hand-made
>> >> solutions instead of standard containers. For example, are you sure you
>> >> can make your classes properly exception-safe in the first try? And have
>> >> you properly implemented move constructors for taking advantages of C++11
>> >> performance improvements related to move semantics? If you use standard
>> >> containers, such issues are handled mostly automatically.
>> >>
>> >
>> > I don't find much use for ::std::list, ::std::set or ::std::map.
>> > ::std::vector is OK.
>>
>> I think it's fair to the OP to explain that you're unusual in your
>> dislike for some of the standard containers
>
> I'm not the only one. We discussed recently how
> Chandler Carruth has similar views.

Didn't mean to imply you're unique -- but I think it's fair to say
you're in a very small minority.

[Ian Collins]

Richard Damon wrote:
> On 11/23/14, 2:52 PM, Ian Collins wrote:
>> woodb...@gmail.com wrote:
>>>
>>> I don't find much use for ::std::list, ::std::set or ::std::map.
>>> ::std::vector is OK. I use ::std::deque rarely, but wish there
>>> were a better alternative. I use Boost containers sometimes also.
>>
>> What's the origin of this recent odd habit of prepending std with
>> superfluous colons?
>>
>
> If guards against having a std namespace inside the namespace you code
> is in. By using ::std it MUST be the globally defined and reserved for
> the standard/implementation namespace.

I know what it does, but I still consider it unnecessary clutter.

> I would probably reject any code at review the defined a std namespace
> inside of a namespace as asking for problems, but is legal.

Legal, but stupid!

--
Ian Collins

[Jorgen Grahn]

On Sun, 2014-11-23, Chicken Mcnuggets wrote:

...

> As a Python programmer I use lists all the time. I don't know (yet)
> whether C++ has the same features as Python for lists but list
> comprehensions in Python allow you to do some really powerful things in
> 1 line of code.

Then you want a combination of std::vector, the standard algorithms
and perhaps C++11 lambdas. It probably won't end up quite as concise
as a Python list comprehension, but you can still get a clear message
through to the reader.

> I'm hoping you can do the same sort of thing in C++ since I use them all
> the time.
>
> std::map also sounds useful as it appears to essentially be a dictionary
> in Python which I also use all the time.

It's more or less the same thing, but ordered. std::unordered_map is
a bit closer to the Python concept, and generally a bit faster.

[Öö Tiib]

'std::list' has 'splice' member function that transfers part of list into
other list. 'std::list' is extremely efficient for that 'splice'.
If you have a problem for what best algorithm involves lot of transferring
sub-sequences between sequence containers then 'std::list' is among winners
and hard to beat. Such problems are rare and 'std::list' is not that good
for most other things so it should not be the first choice of container.

[woodb...@gmail.com]

It's a safeguard against ignorant and/or malicious users.

Brian
Ebenezer Enterprises - An ounce of prevention is worth
more than a pound of cure.

http://webEbenezer.net

[Öö Tiib]

I have read two of these. Good books, worth reading, not too dry. May save
you some time if you want to really learn C++.

[JiiPee]

Yes true. So one have to check what kind of situation it is to know what
is best for each case. Sometimes its vector sometimes list.

[JiiPee]

On 23/11/2014 19:52, Ian Collins wrote:
> woodb...@gmail.com wrote:
>>
>> I don't find much use for ::std::list, ::std::set or ::std::map.

The use is if there is a big junk of data needs to be moved around, list
is much faster then.

[Richard]

[Please do not mail me a copy of your followup]

Chicken Mcnuggets <chi...@mcnuggets.com> spake the secret code
<E%gcw.970413$ZX5.2...@fx32.am4> thusly:

>and am thinking about buying:
>
>Effective C++ 3rd Edition

Here's my review:
<http://legalizeadulthood.wordpress.com/2009/09/09/effective-c-3rd-edition-by-scott-meyers/>

Recommended.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

[Richard]

[Please do not mail me a copy of your followup]

Chicken Mcnuggets <chi...@mcnuggets.com> spake the secret code

<wrhcw.822436$Au1.2...@fx36.am4> thusly:

>On 23/11/14 08:54, Jorgen Grahn wrote:
>>
>> Mostly because I'm curious: what things are you comfortable with now,
>> and which areas do you find problematic? When you're programming in
>> C++, I mean.
>>
>
>The big problem area for me with C++ is templates and how to incorporate
>them into my code (and whether I should do or if I should use another
>solution instead).

You should be consuming the template container classes from the C++
library and resource handle classes like unique_ptr<T> and shared_ptr<T>.

After that, only if you have duplication in your code where the
duplication varies only in the types involved and not the expressions
should you then consider adding your own templates to your code base.

This would be using 'static polymorphism' via templates to eliminate
duplication instead of 'dynamic polymorphism' via virtual member
functions and pointers to base classes to eliminate duplication.

The most important thing when extending your code is to maintain
readability and expressiveness. Templates can introduce a whole bunch
of syntactic noise and reduce readability and expressiveness. If I
had to give up readability to eliminate duplication, I might just keep
the duplication (and I *abhor* duplication).

[Jorgen Grahn]

On Mon, 2014-11-24, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> Chicken Mcnuggets <chi...@mcnuggets.com> spake the secret code
> <wrhcw.822436$Au1.2...@fx36.am4> thusly:

...

>>The big problem area for me with C++ is templates and how to incorporate
>>them into my code (and whether I should do or if I should use another
>>solution instead).
>
> You should be consuming the template container classes from the C++
> library and resource handle classes like unique_ptr<T> and shared_ptr<T>.
>
> After that, only if you have duplication in your code where the
> duplication varies only in the types involved and not the expressions
> should you then consider adding your own templates to your code base.
>
> This would be using 'static polymorphism' via templates to eliminate
> duplication instead of 'dynamic polymorphism' via virtual member
> functions and pointers to base classes to eliminate duplication.
>
> The most important thing when extending your code is to maintain
> readability and expressiveness. Templates can introduce a whole bunch
> of syntactic noise and reduce readability and expressiveness. If I
> had to give up readability to eliminate duplication, I might just keep
> the duplication (and I *abhor* duplication).

Fair enough, but templates can just as well make the code /more/
readable. Saying the same thing many times in slightly different ways
can (like you say) be really distracting.

I suppose being able to see what's esentially "the same thing" is the
key to using templates this way. Here too the OP's Python background
can help, since he's used to duck typing.

[Richard]

[Please do not mail me a copy of your followup]

Jorgen Grahn <grahn...@snipabacken.se> spake the secret code
<slrnm77e4f.1...@frailea.sa.invalid> thusly:

>On Mon, 2014-11-24, Richard wrote:
>>
>> The most important thing when extending your code is to maintain
>> readability and expressiveness. Templates can introduce a whole bunch
>> of syntactic noise and reduce readability and expressiveness. If I
>> had to give up readability to eliminate duplication, I might just keep
>> the duplication (and I *abhor* duplication).
>
>Fair enough, but templates can just as well make the code /more/
>readable. Saying the same thing many times in slightly different ways
>can (like you say) be really distracting.

Agreed. As others on this thread have said, don't use language
features just for the sake of using them. Use language features to
enhance the readability and expressiveness of your code.