FeedaMail: Comments for Sutter’s Mill

	Comments for Sutter's Mill
	(Sponsor this newsletter) Comment on GotW #94 Solution: AAA Style (Almost Always Auto) by Alex Turbov I’m curious, how it is supposed to use auto for classes w/o copy/move constructors? For example if it contains std::atomic type and the only constructor with some parameters. Read More » Comment on GotW #7a: Minimizing Compile-Time Dependencies, Part 1 by Paul Omta Guru question #2. * Replace iostream and ostream include with an include of iosfwd. I forgot where I read this, but this neat trick avoids including the heavy iostream header. * Remove c.h and e.h, as previously stated. These can be replaced with forward declarations. * d.h and list includes can be removed if one uses Herb’s own Private Implementation Pattern, but from the wording of the question, this seems out of scope of the question. It would require a change in the class itself. Read More » Comment on GotW #94 Solution: AAA Style (Almost Always Auto) by Ralph Tandetzky Some feedback from the trenches: I love auto. I use it all the time. It’s convenient. It simplifies refactoring. It’s useful in templated and non-templated code as well. Im using the auto x = init; type of initialization all the time. However, I tried the auto x = type{init}; syntax for a while and find it slightly less convenient compared to type x = init . I find it more pragmatic to use this in order to say “I wanna commit to a specific type” while possibly getting a conversion operation there. It avoids the restriction to use movable types only (which can be quite a challenge outside the standard library). Whenever I do not need to commit to a specific type I **prefer** to use auto . I’m not a great fan of saying “always” here. Most of the time I use auto , I’m actually using const auto which gives me a bunch of single static assignments in my code. This is nice, because I can use a const variable as an equivalent to the expression on the right hand side and it makes the code very easy to reason about. At the same time I don’t need to care about the type of the right hand side. These two keywords are an awesome combination! One more thing: I found it quite annoying to get compiler warnings when I write stuff like this: for ( auto i = 0; i < v.size(); ++i ) {...} It warns me that I get a comparison between a signed and an unsigned type. This is one of the places where I prefer to write size_t instead of auto . Thanks for the many insightful posts. Keep it up! Read More » Comment on GotW #94 Solution: AAA Style (Almost Always Auto) by Cassio Neri On “auto x = init; [...] It [...] guarantees that no implicit conversions [...] will occur.” Well, array-to-pointer and function-to-pointer conversions might occur. These conversions are, surely, efficient (loosely speaking they are “compile-time conversions”) and, I believe, no other conversion might occur. int a[3] = {}; a = nullptr; // invalid: type of a is int[3] auto b = a; b = nullptr; // OK : type of b is int* auto& c = a; c = nullptr; // invalid: type of c is int(&)[3] // ... void f(); f = nullptr; // invalid: type of f is void() auto g = f; g = nullptr; // OK : type of g is void(*)() auto& h = f; h = nullptr; // invalid: type of h is void(&)() I think it’s also worth mentionning that qualifications are not preserved (especially because they are often mistaken as conversions): int const i = 0; // or "auto const i = 0;" :-) i = 1; // invalid: i is const auto j = i; j = 1; // OK : j is not const auto const k = i; k = 1: // invalid: k is const Read More »
	(Sponsor this newsletter)
	Delievered to you by Feedamail. Unsubscribe