FeedaMail: Comments for Sutter’s Mill

	Comments for Sutter's Mill
	Comment on GotW #93 Solution: Auto Variables, Part 2 by ahbishop @khurshid: What compiler are you using? That code compiles and executes without issue using Clang 3.2.1 on 64-bit Linux. Read More » Comment on GotW #94 Special Edition: AAA Style (Almost Always Auto) by Jeff Harris @Bret Kuhns Yes, the examples are symmetric, but not necessarily in the ‘spirit’ of auto. The guideline in GotW 93 for using auto simply states to use auto w = getWidget() and say the compiler will choose the correct type. For a getWidget returning a reference, the type likely is not correct as it will either not compile (if type is not copyable) or be slow with a potentially unwanted copy (not move). Shouldn’t there be more qualifications on the guidelines that they hold for value returning expressions only? If a reference is returned, then auto& or const auto& is required. Read More » Comment on GotW #93 Solution: Auto Variables, Part 2 by Frederic Dumont About auto x { value } vs auto x = expr: in what sense are they semantically identical? The types are different (std::initializer_list vs type), so they cannot be interchangeable, can they? Read More » Comment on GotW #93 Solution: Auto Variables, Part 2 by Arne Mertz @Frederic no, they are not identical. x{value} is just an initialization of x. x would be an initializer_list, if you wrote auto x = {value}; note that here you have both = and {}. Read More » Comment on GotW #93 Solution: Auto Variables, Part 2 by Neil Re auto i = 0, how about a zero() non-member function akin to std::begin and std::end, like this: template <typename C> typename C::size_type zero(const C& c) { return 0; } for (auto i = zero(v); i < v.size(); ++i) {} Read More » Comment on GotW #93 Solution: Auto Variables, Part 2 by Frederic Dumont But Gotw 92 question 4 states the opposite. In auto a { val }; auto b = { val }; both a and b are said to have the same type initializer_list. The two compilers I have tried with (gcc 4.8 and clang 3.2) confirm this. Read More » Comment on GotW #94 Special Edition: AAA Style (Almost Always Auto) by Róbert Dávid @Jeff Harris: auto always gives you a reference/cv-stripped type. To keep them, you need to use decltype instead. The thing in C++11 is that you have to tell decltype what to deduce the type from: decltype(getWidget()) w = getWidget(); //w has type const Widget& C++14 gives you decltype(auto), and does exactly what you want here: decltype(auto) w = getWidget(); //w has type const Widget& Read More » Comment on GotW #94 Special Edition: AAA Style (Almost Always Auto) by Johan 3. When a function is modified to return a different data type, it may silently cause problems if auto was used. For example, if some return types are changed from integer to float or double: auto a = c.GetValue(); auto b = d.GetValue(); if( a == b ) { // Comparing integers are fine, but should not compare float numbers like this. } Unit tests might detect this, but anyway you need to be extra careful when using auto. Declaring a and b as integers should at least cause the compiler to show a warning about the conversion to int. Also, sometimes readability can suffer because you need to stop and think what the type is, instead of just reading the explicit type. However, when working with the standard library this is not an issue since most programmers knows it well. Read More » Comment on GotW #94 Special Edition: AAA Style (Almost Always Auto) by André Müller @Johan: Good point. All the more reason to use -Wfloat-equal. Apart from beeing explicit about conversions and symmetry I find the AAA style more pleasant to read. Variable names are always at the beginning of a line: auto a = type_name{args}; auto b = long_type_name{args}; auto ccc = even_longer_type_name::subtype_name{args}; vs. type_name a {args}; long_type_name bb{args}; even_longer_type_name::subtype_name ccc{args}; Read More » Comment on GotW #93 Solution: Auto Variables, Part 2 by Sebastian Redl > Second, some people like line 2′s syntax better but have to switch to line 1 to get access to explicit constructors. If the constructor is explicit, chances are that the = syntax is horribly misleading. Do you really think there’s a programmer who would like “vector v = 5;” to create a 5-element vector? I don’t. > By the way, if you've been wondering whether auto x { value }; would be more efficient than auto x = expr;, wonder no longer: They have identical semantics. Watch out, it’s the dreaded initializer_list deduction! In other words, they’re completely different things. Also, you might want to use expr *or* value, not mix them. > Prefer to use auto x = as_signed(integer_expr); or auto x = as_unsigned(integer_expr); to store the result of an integer computation that should be signed or unsigned. This doesn’t help much. The unexpected type conversion happens as part of integer_expr; all the “helper” does is afterwards cast it back. Yes, the behavior of unsigned to signed when not in range isn’t undefined, just implementation-defined, but that’s enough to make the code non-portable. > double f4 = f1 + f2; // … this might keep more bits of precision This is incredibly obscure and would definitely not pass code review from me. If you want higher precision, cast the inputs to double. If you don’t want higher resolution, assign the result to a float. Everything else is just a maintenance nightmare. Read More » Comment on GotW #93 Solution: Auto Variables, Part 2 by Herb Sutter @Frederic, @Sebastian: I stomped on the similar sentence in GotW #2 when Ville pointed it out, but it resurfaced. Stomped again, thanks. Read More » Comment on GotW #94 Special Edition: AAA Style (Almost Always Auto) by Sebastian Redl > While copy/move elision can probably optimize it, MSVC in particular is still bad in it, and misses quite a few cases Herb’s secret agenda: Teach programmers to use code MSVC is bad at (unsupported C++11 and 14 features, stuff that triggers bugs) to force the compiler team to fix everything. Hey Herb, can you write an article about how our source files should be UTF-8-encoded without a BOM, and we should use std::codecvt_utf8 to convert from our narrow string literals to wide strings? Read More » Comment on GotW #94 Special Edition: AAA Style (Almost Always Auto) by Herb Sutter @Sebastian: O:-) Read More »
	Delievered to you by Feedamail. Unsubscribe