Modern C++ auto
-
You're performing a good bit of mental gymnastics to arrive at that interpretation of what I said. Clearly, if you know the exact type that would be deduced, there would be no penalty for explicitly using it.
But you always DO know the type, well 99.9999% of the time. So clearly there's no penalty. So how exactly does the compiler know more than us, particularly enough to risk the potential silent bugs that auto could introduce?
Explorans limites defectum
-
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?"
Really the above isn't the issue. The issue is this:
auto whatever = GetSomething()
while (somecondition)
whatever++;In a large code base, there are probably a hundred or more things that would be syntactically compatible with that, so that accidentally changing GetSomething(), either manually or via search and replace, such that it returned one of those types, would create a completely silent error. Is it going to happen every day? No, obviously not. But that's not the point. The point is that, this:
FailureCounter& failCnt = GetFailCounter();
while (somecondition)
failCnt++;is just far less likely to be subject to such a silent error because you have to make two parallel errors for that to happen. You are expressing your intent to the compiler by using an explicit type, which is the only way the compiler can know if your intent is not being followed. And how much extra work did that take to get the extra safety? Almost nothing.
Explorans limites defectum
-
But you always DO know the type, well 99.9999% of the time. So clearly there's no penalty. So how exactly does the compiler know more than us, particularly enough to risk the potential silent bugs that auto could introduce?
Explorans limites defectum
Can you give an example of such silent bugs? In fact, I think the ISO C++ committee would probably be interested in hearing about these bugs so they could address them in the next release.
-
Can you give an example of such silent bugs? In fact, I think the ISO C++ committee would probably be interested in hearing about these bugs so they could address them in the next release.
I gave one below and I'm sure that they know about them and they cannot address this, because it's fundamental to why auto is dangerous.
auto whatever = GetSomething()
while (somecondition)
whatever++;If you accidentally change the right side to anything that provides a ++ operator (anything that is syntactically valid for the loop), the compiler will never know that's wrong, because you are not providing the compiler with information about your intent. The compiler is only being given SYNTACTICAL guidance when you use auto, not SEMANTIC guidance, which is what it needs to help you in this situation. If you provide the actual type, then you are telling the compiler what your intent is, i.e. semantic information, and so you have to make two parallel errors in most cases for this to silently cause a bug. Otherwise, you won't know until you somehow realize that something isn't getting incremented as it should be which could have most likely been caught at compile time with explicit typing.
Explorans limites defectum
-
I gave one below and I'm sure that they know about them and they cannot address this, because it's fundamental to why auto is dangerous.
auto whatever = GetSomething()
while (somecondition)
whatever++;If you accidentally change the right side to anything that provides a ++ operator (anything that is syntactically valid for the loop), the compiler will never know that's wrong, because you are not providing the compiler with information about your intent. The compiler is only being given SYNTACTICAL guidance when you use auto, not SEMANTIC guidance, which is what it needs to help you in this situation. If you provide the actual type, then you are telling the compiler what your intent is, i.e. semantic information, and so you have to make two parallel errors in most cases for this to silently cause a bug. Otherwise, you won't know until you somehow realize that something isn't getting incremented as it should be which could have most likely been caught at compile time with explicit typing.
Explorans limites defectum
That sounds like your API has issues. Functions are interface contracts and if you don't know that function's return type changed, then the interface has been broken. That's outside the scope of language keywords, in my opinion.
-
That sounds like your API has issues. Functions are interface contracts and if you don't know that function's return type changed, then the interface has been broken. That's outside the scope of language keywords, in my opinion.
So you are saying only one class in the entire code base can have a ++ operator? Or a += operator? or an add() method or a push() method?
Explorans limites defectum
-
So you are saying only one class in the entire code base can have a ++ operator? Or a += operator? or an add() method or a push() method?
Explorans limites defectum
I never said anything even close to that. I am saying if the maintainer of the GetSomething() function changes the return type without informing the consumer, that's a major problem that has nothing to do with language features.
-
I never said anything even close to that. I am saying if the maintainer of the GetSomething() function changes the return type without informing the consumer, that's a major problem that has nothing to do with language features.
So you are saying that mistakes shouldn't happen? Of course GetSomething()'s return could be changed by accident, and that would get caught also. But the more likely scenario is that someone accidentally changes the call, either by editing the wrong thing, or by search and replace, so that something besides GetSomething() is being called. Either of those things would become silent failures that could be taken care of by using an explicit type. Are they going to happen every day? No, they won't. But it's those type of silent errors that are the killers. Those are the ones that suddenly six months later the code stops working in the field and no one understands why.
Explorans limites defectum
-
Really the above isn't the issue. The issue is this:
auto whatever = GetSomething()
while (somecondition)
whatever++;In a large code base, there are probably a hundred or more things that would be syntactically compatible with that, so that accidentally changing GetSomething(), either manually or via search and replace, such that it returned one of those types, would create a completely silent error. Is it going to happen every day? No, obviously not. But that's not the point. The point is that, this:
FailureCounter& failCnt = GetFailCounter();
while (somecondition)
failCnt++;is just far less likely to be subject to such a silent error because you have to make two parallel errors for that to happen. You are expressing your intent to the compiler by using an explicit type, which is the only way the compiler can know if your intent is not being followed. And how much extra work did that take to get the extra safety? Almost nothing.
Explorans limites defectum
I always use the highest warning level available and set warnings to be failures and I have done this for many years. Since the auto keyboard has been available I have never seen a compiler allow anything through that could cause a failure.
"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?"
-
I always use the highest warning level available and set warnings to be failures and I have done this for many years. Since the auto keyboard has been available I have never seen a compiler allow anything through that could cause a failure.
"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?"
There's nothing to warn about in the scenario I indicated. It's a completely valid program, just the wrong one.
Explorans limites defectum
-
That sounds like your API has issues. Functions are interface contracts and if you don't know that function's return type changed, then the interface has been broken. That's outside the scope of language keywords, in my opinion.
but if memory serves, there was a call into SharePoint API that if there was a single result found it returned a string. If multiple results, returned an array of string. Found out the hard way to check the type of return before using the result(s).
_______________________________________________________________ Ah don't lean on me man, cause you can't afford the ticket
-
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.
So are you saying that you don't want a self-driving auto?
I wanna be a eunuchs developer! Pass me a bread knife!
-
So you are saying that mistakes shouldn't happen? Of course GetSomething()'s return could be changed by accident, and that would get caught also. But the more likely scenario is that someone accidentally changes the call, either by editing the wrong thing, or by search and replace, so that something besides GetSomething() is being called. Either of those things would become silent failures that could be taken care of by using an explicit type. Are they going to happen every day? No, they won't. But it's those type of silent errors that are the killers. Those are the ones that suddenly six months later the code stops working in the field and no one understands why.
Explorans limites defectum
I don’t believe a useful language feature is “bad” if it doesn’t catch edge cases that are the result of not following SOLID principles.
-
I don’t believe a useful language feature is “bad” if it doesn’t catch edge cases that are the result of not following SOLID principles.
That isn't the result of anything but the fact that accidents can happen, and if you tell the compiler what you intend, you can catch a lot of them.
Explorans limites defectum
-
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!
For no particular reason, I've adopted var in the case of your third example, but not the first two. I *always* use an explicit type for native/built-in types like string or int...but when it comes to classes (assuming your DoSomething() returns a class rather than a native type), I'll use var...especially when I might not even do anything with it other than forward it to somebody else (ie, I might not even need to look at any of its properties or members).
