| ||||
| Comment on GotW #93 Solution: Auto Variables, Part 2 by jlehrer
@JohnSmith – pet peeve, it is not true that “on 64-bit Windows long is still 32-bit”. It may be that on some compiler that you are using that is true, but that is not a requirement of Windows. As long as they follow the standard, different compilers on the same OS may have different type sizes. Read More » Comment on GotW #93 Solution: Auto Variables, Part 2 by Adrian
for( auto i = 0L; i < v.size(); i += 2 ) Noooo! Now you’re comparing a signed type to an unsigned type. Worse, on an LLP64 system, i will be 32 bits and v.size() will be 64 bits. This forces you to disable useful compiler warnings. This is one of those cases you shouldn’t use auto. Just use std::size_t. It’s clear and correct and it won’t force you to disable compiler warnings that might be useful in other parts of your code. If there’s a chance v will grow so large that i += 2 could overflow, then you have to deal with that explicitly. Read More »Comment on GotW #93 Solution: Auto Variables, Part 2 by Martin Ba
Following up on @Tom “c-style cast vs. static_cast” and @Herb’s answer “Actually those are function-style casts, and for a non-aggregate type will call a constructor etc” — this really deserves some more info. I believe … = int(expr); is 100% exactly the same as … = (int)expr; so this is a c-style cast, meaning potential unsafe casting, or doesn’t it? That is: int ans = 42; int* p = &ans; auto val1 = int(p); // compiles, loosing data if sizeof(ptr) GRT sizeof(int) - which may or may not be what we want auto val2 = static_cast<int>(p); // doesn't compile, conversion not allowed via static_castRead More » Comment on GotW #94 Special Edition: AAA Style (Almost Always Auto) by Adrian
In #1, the assertion would be even stronger to put it at the end of the function rather than inside the then clause. That way it becomes a true post condition–the container must contain something if it contains a value equal to v. This post condition also works as a form of documentation. A stronger post condition would be to assert that the container contains the value: template <typename Container, typename Value> bool Contains(const Container & c, const Value & v) { using std::begin; using std::end; return std::find(begin(c), end(c), v) != end(c); } template <typename Container, typename Value> void AppendIfUnique(Container & c, const Value & v) { if (!Contains(c, v)) c.emplace_back(v); assert(Contains(c, v)); // Post condition (barring exceptions) } Read More » Comment on GotW #94 Special Edition: AAA Style (Almost Always Auto) by Johannes Schaub (litb)
6) There will be a problem with “long long{init}”. If “type” consists of multiple parts like that, “long long x{init}” must be used, or the type name needs to be aliased such as “auto x = std::common_type_t{init}”. Read More »Comment on GotW #93 Solution: Auto Variables, Part 2 by Herb Sutter
@Juraj: IIUC it’s implementation-defined, not undefined. From 4.7/2-3 [conv.integral]: 2 If the destination type is unsigned, the resulting value is the least unsigned integer congruent to the source Comment on GotW #93 Solution: Auto Variables, Part 2 by Herb Sutter
@Adrian: There are problems if you use an unsigned loop variable, and different problems if you use a signed one. This is one of those cases that’s just problematic. Because of these issues, I once asked Bjarne if he felt that container.size() should have returned signed values, and IIRC he agreed. Of course, that wouldn’t be consequence-free either — you couldn’t have a container of chars bigger than half the address space, but that doesn’t matter on 64 bits today and might never matter, depending on whether we ever get a machine with RAM greater than 2^63 bytes — wasn’t there an urban legend that Bill Gates said 9.2 billion GB should be enough for anyone? Read More »Comment on GotW #93 Solution: Auto Variables, Part 2 by Herb Sutter
@Tom, @Martin: Yup, I just realized I accidentally wrote ( ) instead of { } — that should address at least the narrowing issues. My fingers mostly have the habit of writing { } committed to muscle memory now, but that one slipped by. Fixed, thanks. Read More »Comment on GotW #94 Special Edition: AAA Style (Almost Always Auto) by Herb Sutter
@Adrian: I had the assertion outside in my original code, and I agree it’s better there. Lightly edited the question to do that. Read More »Comment on GotW #94 Special Edition: AAA Style (Almost Always Auto) by Róbert Dávid
4b: Pleeeeheheheeeeeaaase don’t. If you want a given type, declare the variable with that type. Don’t declare a type-deduced variable initialized by a value converted to the given type, it’s just dumb. I know you want to suggest that it is self-documenting that there is a conversion. But it equally documents this if you use type x = init; only when you want conversion, and auto x = init; if you don’t. Or if you really-really want to document it, use type x = type{init}; but that’s redundant. Using auto x = type{init}; also might involve a move-construction. While copy/move elision can probably optimize it, MSVC in particular is still bad in it, and misses quite a few cases (in the range of 5-10% – not lot, but nothing guarantees this 5% won’t be in your performance-critical code). Also, in debug mode you don’t have copy elision at all, resulting in different behaviour than release mode – noone wants that. This way feels like Maslow’s hammer: we now have a super new tool since C++11, auto. It is awesome and stuff, but we still don’t need to use everywhere. It should raise the red flag if you need to write something incredibly verbose, that you should not use it after all. Read More »Comment on GotW #94 Special Edition: AAA Style (Almost Always Auto) by Jeff Harris
3: With a standard ‘getter’ function, e.g. const Widget& getWidget(), the use of auto w = getWidget() will deduce a type of Widget for w. The code will attempt to create a copy of Widget which may be slow or not allowed if Widget is not copyable. Traditionally, you’d declare const Widget& w = getWidget() which avoids any copies and is fast. Is there a version of auto that will attempt to preserve the cv and reference qualifications on the deduced type vs. following the template rules of the current auto? The use of auto& works for the getWidget() case but fails if getWidget returns a Widget by value and not const reference. const auto& is required in that case. It seems as if the caller still needs to be as aware of the exact return type of getWidget when using auto as when not using auto. Read More »Comment on GotW #94 Special Edition: AAA Style (Almost Always Auto) by Sil
Herb, Microsoft, and you in particular, has done a tremendous job of supporting the c++ community. Nowadays clang and gcc++ have next to 100% c++ 11 support and beyond. When can we expect a better support in visual c++? Read More »Comment on GotW #94 Special Edition: AAA Style (Almost Always Auto) by Herb Sutter
@Sil: Thanks, and in less than two weeks I’ll be giving a talk at Build that covers this. In the meantime, your example does compile with VC++ Nov 2012 CTP — here’s a link to where you can try that sample online: http://rise4fun.com/Vcpp/KjO . Read More »Comment on GotW #92 Solution: Auto Variables, Part 1 by monamimani
@Leo Sorry for being late to reply. It still doesn’t make sense to me and I’ll point out to that the template argument deduction rule doesn’t either. To me the type of cir it a reference to a int the type of cir is not a int. Ref to int a and int are 2 different types. Then it confuses me that the deduced type it not int&. Read More » | ||||
| ||||
Saturday, June 15, 2013
FeedaMail: Comments for Sutter’s Mill
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment