Which book is better for C++14 : Effective Modern C++ or C++14 FAQs ?

[lin.q...@gmail.com]

I am trying to understand C++14 from these books :

Effective Modern C++ by Scott Meyers, and
C++14 FAQs by Chandra Shekhar Kumar

So far, I find the later book to a better one for C++14 whereas the first book is a generic one. But I do not see much of the reviews of the book C++14 FAQs on Amazon yet whereas the first book is highly rated, may be over rated ??

[woodb...@gmail.com]

I haven't read those books, but I'm not crazy about the title
"Effective Modern C++."

I'd change it to something like

Effective C++, 4th edition

That's how Bjarne Stroustrup has done it with "The C++
Programming Language, 4th edition." Scott doesn't "kill
the adjective" the way I wish he would.

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

[Victor Bazarov]

Scott's series are actually very useful regardless of how many reviews
they get. Some items from original Effective books may have been
obsoleted by new language developments, they are educational nonetheless
if you really want to understand C++.

All C++ books somewhat overlap, there is no avoiding that. However, to
answer the question you put in your subject line in one word, _yes_!

V
--
I do not respond to top-posted replies, please don't ask

[Öö Tiib]

On Tuesday, 14 April 2015 23:57:31 UTC+3, lin.q...@gmail.com wrote:
> I am trying to understand C++14 from these books :

C++ contains far more features and alternative possibilities
than anyone needs for writing software. Even after decades
of usage you may discover some unknown aspect of it. It
can't be picked up from few tutorials, manual and trial and
error; that would take lot of years. Since there is clear
market there are also *lot* of bad books about C++. I have
seen more bad books than good ones.

There is a decent community-maintained list/guide about
C++ books at stackowerflow:
http://stackoverflow.com/questions/388242/the-definitive-c-book-guide-and-list

Scott Meyers's book is in that list as for "Intermediates" so
some people have found it helpful. Chandra Shekhar Kumar's
book is not in that list so likely people have found it being
less helpful, less correct or less interesting than alternatives.

[Jorgen Grahn]

On Wed, 2015-04-15, Stefan Ram wrote:

> 嘱 Tiib <oot...@hot.ee> writes:
>>C++ contains far more features and alternative possibilities
>>than anyone needs for writing software.
>

> But one should not forget that most programmers do /not/
> write software, but /maintain/ existing software. Of course,
> in doing so, they write lines of code, but they also remove
> lines of code and read lines of code.
>
> A maintenance programmer cannot choose which features of the
> language the existing parts of the code use.

I'm not sure what your point is in relation to what Tiib writes, but
I've successfully removed use of C++ features from code during
maintenance. Some things are easier to fix than others ...
for example use of old C constructs like macros, old-style casts,
memcpy() etc.

/Jorgen

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

[Öö Tiib]

On Thursday, 16 April 2015 01:02:39 UTC+3, Stefan Ram wrote:
> 嘱 Tiib <oot...@hot.ee> writes:

> >C++ contains far more features and alternative possibilities
> >than anyone needs for writing software.
>

> But one should not forget that most programmers do /not/
> write software, but /maintain/ existing software. Of course,
> in doing so, they write lines of code, but they also remove
> lines of code and read lines of code.

So therefore "It can't be picked up from few tutorials, manual and
trial and error; that would take lot of years." (that you snipped)
applies. Or what was your point?

> A maintenance programmer cannot choose which features of the
> language the existing parts of the code use.

Maintenance programmer has to behave by coding standard of
project, by best practices, by what the environment (compiler,
platform and tools) supports/allows and by what the actual piece
of code under maintenance does. So that is a puzzle and good
books help to find the vital highlights in such a situation.
Besides, reading itself helps to learn to read and C++ programmer
has to read a lot. ;-)

For example I don't know decent books that teach to use
C++ that is stripped of exceptions, RTTI, major part of standard
library etc. and by MISRA C/MISRA C++ coding standards
compliance. Such goal-posts tend to move. So we have to learn
to read bad books too. Chandra Shekhar Kumar's book seems
unfortunate since it claims to be about bleeding edge C++14.
We should next to never use bleeding edge features in
maintenance project.

[Juha Nieminen]

Stefan Ram <r...@zedat.fu-berlin.de> wrote:
> But one should not forget that most programmers do /not/
> write software, but /maintain/ existing software. Of course,
> in doing so, they write lines of code, but they also remove
> lines of code and read lines of code.
>

> A maintenance programmer cannot choose which features of the
> language the existing parts of the code use.

If you don't know the tool you are using, then perhaps you should not
sell yourself as a "maintenance programmer" then?

--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---

[Öö Tiib]

On Thursday, 16 April 2015 14:07:28 UTC+3, Stefan Ram wrote:
> 嘱 Tiib <oot...@hot.ee> writes:
> >On Thursday, 16 April 2015 01:02:39 UTC+3, Stefan Ram wrote:
> >>Tiib <oot...@hot.ee> writes:
> >>>C++ contains far more features and alternative possibilities
> >>>than anyone needs for writing software.
> >>But one should not forget that most programmers do /not/
> >>write software, but /maintain/ existing software. Of course,
> >>in doing so, they write lines of code, but they also remove
> >>lines of code and read lines of code.
> >So therefore "It can't be picked up from few tutorials, manual and
> >trial and error; that would take lot of years." (that you snipped)
> >applies. Or what was your point?
>

> The point was to contrast your idea of a language
> for writing software with the idea of a language for
> reading software (readable source code).

The sentence that "C++ contains far more features and alternative
possibilities than anyone needs for writing software" does not
mean that "C++ is write-only language" It means that "Same little
thing may be written in C++ in number of alternative ways".

So if you argue with "my idea" that "C++ is write-only language"
then you apparently argue with idea that I did not have and with
a point that I did not make. Please avoid misrepresenting others.

[Öö Tiib]

> So, you believe, a maintenance programmer should avoid
> make_unique, and prefer unique_ptr( new ... ) instead?

Possibly. Only few months ago I helped a totally new project
where combo of 'shared_from_this()' and 'std::make_shared()'
of the library of the compiler used was defective and did
crash. Note that it was 2014. I think it was Peter Dimov who
added working 'shared_from_this()' to boost ~2003 and
'make_shared' ~2008.

So 'make_unique' may be easily unavailable even for a totally
new project started right now but I would then likely write
one myself or loan it from boost.

What I actually meant was that maintenance programmer should
make minimal changes needed for fixing the issue under hand.
She should continue using style what the code was using. For
example if maintained code used 'boost::scoped_ptr' then she
should not introduce usage of 'std::unique_ptr' instead.
Otherwise it may break unit tests, the subtle differences may
cause more defects and result is needless waste of effort of
her and the team over the putrid onion of program.

Sometimes code that is decades old is maintained. For example
just because currency in a country did change. Someone needs
it but few can pay ~$500K for a total rewrite of 1000 file
code-base. Even if they are eager to pay such money then why
not to do just $50K worth of fixes and enjoy the $450K? So
the maintainer of it should continue using the "C with classes"
style of it and fix only what became broken.

[sergei.na...@gmail.com]

IMHO, both complement each other and none is complete.