ambs (22) [Avatar] Offline
#1
While I understand this is not an introductory book to C++, I find that sometimes some simple things are explained, and some more complex are presented without detail.

I confess I can't follow half of the section 3.1.1. Although not a C++ programmer, I have good knowledge in other languages like C, C#, Perl, from which most concepts can easily be mapped. But, for example, the second line of listing 3.4 is just "magical"... those parenthesis have some meaning that I do not feel as "common" as one might think.

HTH smilie

EDIT: as kind of related, probably it would help to explain the second line of Listing 3.6. -- at least a simple number and explanation bellow, like the others.
Ivan Cukic (99) [Avatar] Offline
#2
The parentheses are a bit magical, I agree. I do think that some kind of additional material could be provided. I'm not sure I'd be allowed to add an appendix to the book to explain some C++ things that I don't consider the part of the main topic, but that might be useful for people who don't know all the features of C++.

At least, I will probably be able to make that an online thing.
clemons (6) [Avatar] Offline
#3
I think at the very least giving a name to the language feature you're using enables the reader to research it on his or her own.
Ivan Cukic (99) [Avatar] Offline
#4
Yes, that is a good "at least" option.
Hans-J. Schmid (16) [Avatar] Offline
#5
Hi Ivan,

will you make additions to the appendix? Some topics have a title but no content. The appendix so far is really great. Brief and helpful discussions of the topics.

Kind regards,
Hans-J.
Ivan Cukic (99) [Avatar] Offline
#6
Hi Hans,

Appendices were never really planned - never a part of ToC. I was thinking to add them to the book if there is any room left.

They were never approved to be put into the MEAP pdf - it was an oversight of the people who prepare MEAPs.

I will probably post them gradually to my blog as a part of my regular C++-related ramblings once the book gets out.
626729 (1) [Avatar] Offline
#7
I think we can use also here a little bit more modern way for type representation:
Instead:
typedef decltype(ask)* function_ptr; 

using function_ptr = decltype(ask)*;

Since this book concerns mostly modern C++. There is advice to use alias over typedef because even if in that particular example they are doing the same. Alias can be templarized what makes it more powerful.
Ivan Cukic (99) [Avatar] Offline
#8
@626729

Yes, of course, using is always preferred to a typedef. The reason I left it with a typedef is to communicate it is a more C thing than a C++ thing, esp. since it is used for the 'evil' variant of the function object - a class that casts to a function pointer.

I'll have to rethink the reasoning when (if) the book gets updated to 2nd edition and to C++2something