Always Auto
Georgeanna Abson
Using auto together with as_signed or as_unsigned makes code more portable: the variable will both be large enough (thanks to auto) and preserve the required signedness on all platforms. Note that signed/unsigned conversions within integer_expr may still occur and so you may need additional finer-grained as_signed/as_unsigned casts within the expression for full portability.
We already ignore explicit and exact types much of the time, including with temporary objects, virtual functions, templates, and more. This is a feature, not a bug, because it makes our code less tightly coupled, and more generic, flexible, reusable, and future-proof.
Declaring variables using auto, whether or not we want to commit to a type, offers advantages for correctness, performance, maintainability, and robustness, as well as typing convenience. Furthermore, it is an example of how the C++ world is moving to a left-to-right declaration style everywhere, of the form
Finally, when you are working with an existing codebase, you cannot guarantee that it is exception-safe, or even that RAII was used. Both the age of the codebase and the understanding of the programmer factor into these. Incidentally, RAII alone does not guarantee strong exception-safety (you also need to consider patterns such as copy-and-swap).
@peter
Unfortunately every new feature is something else open to abuse/misuse, not totally sure a lot of new features are either warranted or sensible, auto being one of them, just more to go wrong and less compatible c++ code! Perhaps the working committees need to perhaps consider reducing the breadth of C++ rather than making it even more complex?
@Peter I hear you. I have been in the business for a long time too and I have seen my fair share of horrid upstream interfaces.
It seems to me that you are concerned about two things:
1) is my library efficiently returning types? Can I increase the efficiency in client code?
2) will it throw exceptions?
I would argue that (1) is intractable. Reading the documentation (or at least the interface declarations) of the library will tell you what types are being returned, whether they are intrinsic types, references or copies.
At this point whether you write auto or name a type in the client code is irrelevant unless you are planning to perform a conversion on the returned type. If I understand you correctly, you are considering a case like this:
regarding point 2, I am not sure I understand there to be a problem. The interface of get_a_thing() will indicate wether or not exceptions can be thrown. In any case, all your user code will be written in terms of RAII so it will at least be exception-safe. Any objects you use from the _thing_ library that do not use RAII can be wrapped in a unique_ptr (or shared_ptr) with a custom deleter, so they will be exception safe too.
I happen to agree that absurdly long types with nested namespaces are clumsy, hard on both writer and reader, and there are places where auto can only improve readability. (I suspect that the problem here originates with the way such namespaces grow up, but we are often in a position where we have to live with it now.) My concern is that there are also a great many places where it will be practically hazardous, where types being returned are not as the reader expects, and it will prove to be a particularly devastating weapon in the hands of the novice and the lazy coder.
@peter have to admit did like the idea of auto, one of my pet hates is the horrible typing you have to do sometimes. Maybe the real answer is an IDE function to pickup on what auto really is referring to and substitute the full text definition once the right side is known. Better still the code would be backwards with earlier compilers!
What are the performance implications of ? Will it throw?
What conclusions can we draw about the lifetime of result?
If one of those lines does throw an exception, will we have a memory leak?
Certainly, all these questions can be cleared up, if you have an IDE instead of a text editor, by hovering over . But when you have a page full of autos, having to repeatedly do this to understand what is going on is a pain, a retrogressive step.
Perhaps the local struct could even have a bool conversion operator for success or inherit one from another class. IIRC there are currently limits on local classes (no template members) so this might open up a whole other can of worms.
People already mentioned searchability, but that is only part of tool support. There are others. For example, ctags is a popular tool used with editors like Vim: I bet it does not support the new syntax well. Even compilers like VC 2012, which I currently use, do not support all the needed language features.
The standard C++ library tries hard to make as many aggregate types as are reasonable movable, but in user code I commonly come across, and write, there are often types which are neither copyable nor movable. There are a number of reasons for this: two types may be closely coupled as part of a single implementation, so objects of those types may hold references to each other. Trying to track which object happens to own some movable resource in such cases is often far more trouble (and introduces more inefficiency) than it is worth. Efficient movability also implies constructing the internal implementation data of aggregates on free store so the data can easily be moved by swapping pointers. However where efficiency is at a premium for objects likely to be constructed on the stack and unlikely to be moved, constructing things like arrays with known sizes at compile time may be desirable, and member arrays of aggregates (or std::array objects) can only be copied in linear time and not moved. In those cases you may want to prohibit copying/moving entirely. Users who in a particular case want to move and are willing to take the hit of allocation can call make_unique() for the unmovable type in user code where they really want to.
Lastly of course, prohibiting moving and copying may be necessary to enforce the thread-safe use of some objects at reasonable cost. And some objects cannot semantically properly support moving (the article mentions locks, but there are many others).
I personally prefer to use auto to declare local variables. But unfortunately there are some problems with auto and uniform initialization. Perhaps it is a good idea to shed some more light on these pitfalls:
Always use copy-initialization for variables declared with auto, i.e. auto x = expr; where expr is an expression. The point is, that a braced-init-list is NOT an expression. A corollary of this guidline is: Never write something like
Because of what Jeffrey Bosboom said, I think the my_vector_bool is a really bad example, since the following two code does something really different (and because the vector specialization already considered as a mistake).
The code sample you gave is very non-typical. That is generic, template-based code usually written by library implementers. I write code like that in my open-source project, but never at work. Code I write at work is full of types and except in a few corner cases such as declarations of iterators explicit types do improve reliability and robustness of code.
Does anyone (including these guys) have any idea where to find the setting these guys are talking about in 2010 pro? Their wording of templates makes it seem like it would be under the document settings but I can't find it. I'd like to have my workplanes set to auto-resize every time one is created autmatically. I'm kind of sick of setting every time I make a WP and I almost always need it to re-size.
Your right Bmiller I didn't notice that the assembly templates aren't set that way, but I've got mine fixed now. Cbenner is also correct though, I am looking for a way to get my newly created user workplanes to be set to Auto-Resize automatically. I've found a check box somewhere for virtually everything else I've needed except that.
I'm not sure on user planes, I think the original thread referred to origin planes in the older versions. I might be wrong. Hopefully, someone else can say definitively that user planes can/cannot be set this way.
Oops. That was rather idiotic of me. I found this post and got so excited that I actually came up with what I was looking for that it never ocurred to think that maybe it wasn't exactly what I was looking for.
Has this been solved? I would also like to default to auto-resize on my system without forcing all users at my company to do the same. I've looked through the Application Options and I don't see this option anywhere.
On the iPad version of Designer 2.1 if you are using the pencil tool and use auto-close the shape will fill regardless if you have use fill active or not. Even when my fill colour well in the colour panel is transparent, the shape always auto-closes and fills to black. This should just auto-close the shape without filling, unless the use fill toggle is active in which case it should fill the shape with the colour specified.
Update: I can sometimes get it to work as expected. It's difficult to reproduce, but once it happens it kinda sticks for a while. I think it might have something to do with a weird, and occasional disconnect between the colour panel colour wells, and the colour well associated with the pencil tool on the toolbar. I've had a number of oddities with the colour panel colour wells and colour toolbar colour wells not being in sync, or being unable to be set (it just jumps back to whatever colour was set before).
The issue "Pencil Tool's Auto Close should not fill the shape if Use Fill is unchecked" (REF: AF-2785) has been fixed by the developers in internal build "2.6.0.2551".
This fix should soon be available as a customer beta and is planned for inclusion in the next customer release.
Customer beta builds are announced here and you can participate by following these instructions.
If you still experience this problem once you are using that build version (or later) please reply to this thread including @Affinity Info Bot to notify us.