effective-c++

I am reading Effective modern C++ from Scott Meyers. Item 1 contains the following example: template<typename T> void f(T& param); // param is a reference int x = 27; // x is an int const int cx = x; // cx is a const int f(cx); // T is const int, // param's type is const int& In Item 3 appears the following example: Widget w; const Widget& cw = w; auto myWidget1 = cw; // auto type deduction: // myWidget1's type is Widget Based on Item 1 I expected myWidget1 's type to be const Widget . Am I missing something? In most cases auto follows the rules of template argument deduction: § 7.1.6.4 [dcl

In this chapter Scott Meyer mentioned a few technique to avoid header files dependency. The main goal is to avoid recompiling a cpp file if changes are limited to other included header files. My questions are: In my past projects I never paid attention to this rule. The compilation time is not short but it is not intolerable. It could have more to do with the scale (or the lack of) of my projects. How practical is this tip today given the advance in the compiler technology (e.g. clang)? Where can I find more examples of the use of this techniques? (e.g. Gnome or other OSS projects) P.S. I am

In Effective C++ (3rd edition), Scott Meyers, in Item 31, suggests that classes should have, on top of their classic Declaration (.h) and Definition (.cpp) files, a Forward Declaration Include File (fwd.h), which class that do not need the full definition can use, instead of forward declaring themselves. I somewhat see the case for it, but I really don't see this as a viable option... It seems very hard to maintain, rather overkill and hardly necessary. I can, however, see its use for template forward declarations, which are rather heavy. But for simple classes? It seems to be that it's a pain

Effective C++ by Scott Meyers tells in Chapter 5, Item 28 to avoid returning "handles" (pointers, references or iterators) to object internals and it definitely makes a good point. I.e. don't do this: class Family { public: Mother& GetMother() const; } because it destroys encapsulation and allows to alter private object members. Don't even do this: class Family { public: const Mother& GetMother() const; } because it can lead to "dangling handles", meaning that you keep a reference to a member of an object that is already destroyed. Now, my question is, are there any good alternatives? Imagine

int main( const int argc , const char[] const argv) As Effective C++ Item#3 states "Use const whenever possible", I start thinking "why not make these 'constant' parameters const "?. Is there any scenario in which the value of argc is modified in a program? In this case, history is a factor. C defined these inputs as "not constant", and compatibility with (a good portion of) existing C code was an early goal of C++. Some UNIX APIs, such as getopt , actually do manipulate argv[] , so it can't be made const for that reason also. (Aside: Interestingly, although getopt 's prototype suggests it won

While puzzling with some facts on class design, specifically whether the functions should be members or not, I looked into Effective c++ and found Item 23, namely, Prefer non-member non-friend functions to member functions. Reading that at first hand with the web browser example made some sense, however convenience functions( named the nonmember functions like this in the book) in that example change the state of the class, don't they? So, first question, should not they be members then? Reading a bit further, he considers the STL functions and indeed some functions which are not implemented