Modern C++ auto
-
Is this just me? I am starting to see the "auto" keyword abuse growing to an extraordinary proportions. Reminds me of the "var" type in JavaScript or "void*" in C/C++. The program, where all variables are declared as void*, would be considered atrocious, yet auto seems to be littered like an empty beer cans nowadays.
-
Is this just me? I am starting to see the "auto" keyword abuse growing to an extraordinary proportions. Reminds me of the "var" type in JavaScript or "void*" in C/C++. The program, where all variables are declared as void*, would be considered atrocious, yet auto seems to be littered like an empty beer cans nowadays.
I would not call it abuse and it doesn't even remotely resemble void* declarations. With auto the compiler figure out the appropriate type to use and gives you an error if it can't. A void* declaration has no type so it is a completely different thing.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
-
Is this just me? I am starting to see the "auto" keyword abuse growing to an extraordinary proportions. Reminds me of the "var" type in JavaScript or "void*" in C/C++. The program, where all variables are declared as void*, would be considered atrocious, yet auto seems to be littered like an empty beer cans nowadays.
It's laziness: same as
varin C#. Yes, you need it (in C# you can't do Linq without it, pretty much) but when all you ever see isvar x = 666;
var y = "Hello World";
var z = DoSomething(x, y);It's just the coder* saying "I can't be bothered to think about it - you work it out for yourself" :sigh: * Note that I didn't use "developer" here
Sent from my Amstrad PC 1640 Never throw anything away, Griff Bad command or file name. Bad, bad command! Sit! Stay! Staaaay... AntiTwitter: @DalekDave is now a follower!
-
It's laziness: same as
varin C#. Yes, you need it (in C# you can't do Linq without it, pretty much) but when all you ever see isvar x = 666;
var y = "Hello World";
var z = DoSomething(x, y);It's just the coder* saying "I can't be bothered to think about it - you work it out for yourself" :sigh: * Note that I didn't use "developer" here
Sent from my Amstrad PC 1640 Never throw anything away, Griff Bad command or file name. Bad, bad command! Sit! Stay! Staaaay... AntiTwitter: @DalekDave is now a follower!
At first glance
vardoes seem lazy, I use it regularly while working on a large codebase with a lot of 'technical debt'. I use it quite a lot in my professional code development having been encouraged to do so. There again I work in an environment where comments are frowned upon, the thinking being that well written code should not have to be documented - a philosophy which I don't agree with. I think the use ofvarfits in with this 'no comments' philosophy as it is not explicitly stated what the type of the variable is and you have to figure it out with intellisense or by inspecting the method's return type.“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
-
Is this just me? I am starting to see the "auto" keyword abuse growing to an extraordinary proportions. Reminds me of the "var" type in JavaScript or "void*" in C/C++. The program, where all variables are declared as void*, would be considered atrocious, yet auto seems to be littered like an empty beer cans nowadays.
varin Javascript relates to scope rather than the type of the object. I think you may be referring to C# Scope is perhaps the one thing in Javascript that gives me a taste of what hell might be like.“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
-
Is this just me? I am starting to see the "auto" keyword abuse growing to an extraordinary proportions. Reminds me of the "var" type in JavaScript or "void*" in C/C++. The program, where all variables are declared as void*, would be considered atrocious, yet auto seems to be littered like an empty beer cans nowadays.
auto is abused for simple POD types. When you start using more advanced C++ idioms (templates, lambdas...) , it can be a soul saving tool.
I'd rather be phishing!
-
Is this just me? I am starting to see the "auto" keyword abuse growing to an extraordinary proportions. Reminds me of the "var" type in JavaScript or "void*" in C/C++. The program, where all variables are declared as void*, would be considered atrocious, yet auto seems to be littered like an empty beer cans nowadays.
It is getting stupid, but then again much of modern C++ is some sort of attempt to try to make it into exactly what it really isn't. It's like we've been infected with people whose idea of software is a javsascript web site. When you are righting serious code that you will have to support and upgrade over decades, being as explicit as you can is always a good thing. You'll write it once, but you'll have to read and modify it many, many times. Auto makes it way too to make silent mistakes during modifications, because it just takes on whatever you assign it. If the type you wrongly assign is syntactically similar enough, and that's not hard to happen given how much people do with operators and other templates and such, it will just silently change the code. If you explicitly indicate the type, you have to screw up two different ways as once, which just makes it that much less likely to happen silently.
Explorans limites defectum
-
I would not call it abuse and it doesn't even remotely resemble void* declarations. With auto the compiler figure out the appropriate type to use and gives you an error if it can't. A void* declaration has no type so it is a completely different thing.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
Rick York wrote:
With auto the compiler knows exactly the appropriate type to use and gives you an error if it can't figure it out.
If it "knows exactly", how can it not "figure it out"? Sounds like a chick/egg scenario to me.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013 -
auto is abused for simple POD types. When you start using more advanced C++ idioms (templates, lambdas...) , it can be a soul saving tool.
I'd rather be phishing!
This. A thousand times this!
autois a huge benefit for iterators and such. Do you really want to be typing outstd::vector::iterator...whenautocan save you time and typing? You would twist your fingers and brain up remembering the correct syntax for more complex structures, such as maps. Don't use it for your data definitions, but use the hell out of it everywhere else! You will save a huge amount of time. And it will be easy to tell the intent by the way it is used:auto it = someVector.begin(); -
Is this just me? I am starting to see the "auto" keyword abuse growing to an extraordinary proportions. Reminds me of the "var" type in JavaScript or "void*" in C/C++. The program, where all variables are declared as void*, would be considered atrocious, yet auto seems to be littered like an empty beer cans nowadays.
I'm tellin ya, every time I read stuff on r/cpp, I start to suspect more and more that Russia is putting stupid pills in our water. I mean there are people now arguing for stuff that was so utterly bad in the 1980s that pretty much an entire industry switched to OOP to get rid of it. And they are arguing for this stuff like it's some sort of modern, magic hipster technology to fix all of the evils of OOP.
Explorans limites defectum
-
Is this just me? I am starting to see the "auto" keyword abuse growing to an extraordinary proportions. Reminds me of the "var" type in JavaScript or "void*" in C/C++. The program, where all variables are declared as void*, would be considered atrocious, yet auto seems to be littered like an empty beer cans nowadays.
That is very representative of society today : thinking lazy, being lazy. With the consequences we know...
-
Rick York wrote:
With auto the compiler knows exactly the appropriate type to use and gives you an error if it can't figure it out.
If it "knows exactly", how can it not "figure it out"? Sounds like a chick/egg scenario to me.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013If it knows exactly what the type should be, it'll substitute the appropriate type. If it doesn't know exactly what the type should be, it knows exactly that it doesn't know what the type should be. How's that a chicken/egg-scenario? Either the compiler knows the type or it doesn't. That's the beginning of the causality chain. If the compiler doesn't know the type, it throws you an error. That's the end of the causality chain.
-
At first glance
vardoes seem lazy, I use it regularly while working on a large codebase with a lot of 'technical debt'. I use it quite a lot in my professional code development having been encouraged to do so. There again I work in an environment where comments are frowned upon, the thinking being that well written code should not have to be documented - a philosophy which I don't agree with. I think the use ofvarfits in with this 'no comments' philosophy as it is not explicitly stated what the type of the variable is and you have to figure it out with intellisense or by inspecting the method's return type.“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
If your code has a lot of 'technical debt' it is probably not well written code, and thus arguing if well written code should be documented commented or not is irrelevant for that particular case. --- I agree with a lot of the philosophy you don't like... I have been anti-comment and pro
varfor a long time. I believe comments should not say what (names are for that) or how (instructions are for that)... yet, I think comments that explain why and for what are good. At the end the motivation for having less comments is that comments are not checked, and could be forgotten in refactoring, and thus there is a risk that they will be outdated... sure, we can argue dicipline, yet we use strictly typed languages for a reason. Thus, instead we want to express what we would have said in comments in code. With that siad, I can tell you that usingvaras an extension of a no-comments philosophy is retrograde. The idea is to make the code express as much as it can (so it is explicit, that is what they mean by well written code, please do not confuse with verbose), so that we do not have things to communicate in comments... from that point of view,varis counterproductive. Let us be clear,varis not dynamic typing. Yes, names can help with knowing the type※... yet, no, I am not advocating for hungarian notation either. So how can I be anti-comment and provarif they are at odds? I belive in the use ofvaras a way to protect the code from reasons to change. Same goes forauto. And yeah, I use it virtually everywhere. It eases refactoring (If I change the return type, usingautoavoids a maintenance ripple of updating types everywhere the code is used), thus increases maintainability. Addendum: You know what, I do realize it goes both ways, because if I did a poor job and returned something bad, auto will not complain. Although, I would expect it to break where we actually try to use the value. If the code follows the robustness principle ("Be conservative in what you send, be liberal in what you accept"), we will not be usingautofor the return type, instead the return type should be as specific as posible (without breaking encapsulation, if any). On the other hand, we want to assign the return value to a variable, and the return type is probably much more specific than you actually need in client code. In that situation we pro -
If it knows exactly what the type should be, it'll substitute the appropriate type. If it doesn't know exactly what the type should be, it knows exactly that it doesn't know what the type should be. How's that a chicken/egg-scenario? Either the compiler knows the type or it doesn't. That's the beginning of the causality chain. If the compiler doesn't know the type, it throws you an error. That's the end of the causality chain.
The compiler knows. The developer doesn't (necessarily).
-
The compiler knows. The developer doesn't (necessarily).
That's pretty much the point. In most cases, namely when the type doesn't matter as long as it works, the developer doesn't need to know. In edge cases, such as auto i=1 where i is required to be, let's say, an unsigned value somewhere later down the line, the developer can still forego the auto and make it a unsigned int i=1 or at least an auto i=static_cast1. An example from my own work: I've been using API functions like GetTickCount quite a lot and instead of looking up the exact return type, a simple auto s=GetTickCount does the job. API functions returning some value are documented as "Returns 0 if the operation succeeded", in that case, a if 0==s is still enough, I don't need to know the type.
-
Is this just me? I am starting to see the "auto" keyword abuse growing to an extraordinary proportions. Reminds me of the "var" type in JavaScript or "void*" in C/C++. The program, where all variables are declared as void*, would be considered atrocious, yet auto seems to be littered like an empty beer cans nowadays.
The use of auto is not laziness, nor is it abusive. It is correct and idiomatic modern C++. Bjarne Stroustrup and most members of the ISO C++ standardization committee actively advocate for its use, to the point where AAA - Almost Always Auto - has become a common mantra. The simple fact is that, most of the time, the compiler is smarter than you, and understands your code on a level that you never could. Allowing the compiler to determine the type automatically, as often as possible, allows for optimizations that may not be possible if you coerce an explicit type. People who reject evolutionary features of C++ are the same sort of people who would reject fuel injection on cars, because they learned how to drive a car with a carburetor, so everyone else should be fine with it. Technology advances. Try to keep up, or be left behind.
-
Is this just me? I am starting to see the "auto" keyword abuse growing to an extraordinary proportions. Reminds me of the "var" type in JavaScript or "void*" in C/C++. The program, where all variables are declared as void*, would be considered atrocious, yet auto seems to be littered like an empty beer cans nowadays.
I agree it can be easily abused. It is especially true if you are maintaining someone else's code. Yes, it's great for templated iterators and such, but it can also throw more work onto someone else down the road, which I consider rude or lazy. Say I need to add some functionality. I see
auto foo = SomeFunctionReturningObjOrRef(bar);
foo.SomeMethod(blah);Great. That's really easy for the original dev, and really easy for the compiler. Wonderful. Now I need to add some code. What the heck is a "foo"? What members does it have? What methods are available? Is it a base class, or a derived class that has the functions I need? The dev who wrote the code knew, but didn't bother to declare it. The compiler knows, and I suppose I can just try
foo.SomeMethodIHopeTheObjectHas();
And see if I get a compilation error. And hope that it really is the right type and not a base class or derived class of the one I expect... But practically speaking I have to do the work the original dev didn't do and look up
SomeFunctionReturningObjOrRef()
and see what it does, and what it returns so I can be sure I'm getting the right type or that it supports the methods I need, and I don't actually want to be using "bar" or something else or upcast or downcast etc.
-
That's pretty much the point. In most cases, namely when the type doesn't matter as long as it works, the developer doesn't need to know. In edge cases, such as auto i=1 where i is required to be, let's say, an unsigned value somewhere later down the line, the developer can still forego the auto and make it a unsigned int i=1 or at least an auto i=static_cast1. An example from my own work: I've been using API functions like GetTickCount quite a lot and instead of looking up the exact return type, a simple auto s=GetTickCount does the job. API functions returning some value are documented as "Returns 0 if the operation succeeded", in that case, a if 0==s is still enough, I don't need to know the type.
Even "auto i=1" can be made explicit with "auto i=1U".
-
I agree it can be easily abused. It is especially true if you are maintaining someone else's code. Yes, it's great for templated iterators and such, but it can also throw more work onto someone else down the road, which I consider rude or lazy. Say I need to add some functionality. I see
auto foo = SomeFunctionReturningObjOrRef(bar);
foo.SomeMethod(blah);Great. That's really easy for the original dev, and really easy for the compiler. Wonderful. Now I need to add some code. What the heck is a "foo"? What members does it have? What methods are available? Is it a base class, or a derived class that has the functions I need? The dev who wrote the code knew, but didn't bother to declare it. The compiler knows, and I suppose I can just try
foo.SomeMethodIHopeTheObjectHas();
And see if I get a compilation error. And hope that it really is the right type and not a base class or derived class of the one I expect... But practically speaking I have to do the work the original dev didn't do and look up
SomeFunctionReturningObjOrRef()
and see what it does, and what it returns so I can be sure I'm getting the right type or that it supports the methods I need, and I don't actually want to be using "bar" or something else or upcast or downcast etc.
I usually do "all that work" by hovering the mouse over the function call and seeing what the IDE shows as the prototype of the function. There is no guesswork involved.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
-
The use of auto is not laziness, nor is it abusive. It is correct and idiomatic modern C++. Bjarne Stroustrup and most members of the ISO C++ standardization committee actively advocate for its use, to the point where AAA - Almost Always Auto - has become a common mantra. The simple fact is that, most of the time, the compiler is smarter than you, and understands your code on a level that you never could. Allowing the compiler to determine the type automatically, as often as possible, allows for optimizations that may not be possible if you coerce an explicit type. People who reject evolutionary features of C++ are the same sort of people who would reject fuel injection on cars, because they learned how to drive a car with a carburetor, so everyone else should be fine with it. Technology advances. Try to keep up, or be left behind.
Andy Hoffmeyer wrote:
The simple fact is that, most of the time, the compiler is smarter than you, and understands your code on a level that you never could. Allowing the compiler to determine the type automatically, as often as possible, allows for optimizations that may not be possible if you coerce an explicit type.
So, by that logic if I was using an IDE with good intellisense and hovered over a variable declared initially with auto, which showed me what the omniscient compiler will decide the type should be, and then explicitly declared the variable to be that exact type it would somehow break the multi-dimensional optimization the compiler would perform. Are you seriously saying that or did I misread your comment??
