6 ms·

If the code compiles without error on the new type, then there is a good chance that there is no need to worry about it (unless, say, the developer changed "int

If the code compiles without error on the new type, then there is a good chance that there is no need to worry about it (unless, say, the developer changed "int foo()" to "short foo()"). And if you use "x" in some way that isn't allowed by the new type, you will still get a compiler error; although the error will be on the line where you use x and not on the line where you declare x. The compilers I've used (Visual C++, GCC and Clang) will tell you where x was declared in the error message.

roel_v 12y ago
"If the code compiles without error on the new type, then there is a good chance that there is no need to worry about it" Yeah well I'd rather not rely on 'chance' - if I would, I wouldn't be using C++.
- EvenThisAcronym 12y ago
  I think you've been using a different C++ than I have, then. Numerous implicit (read: invisible and unexpected) conversion in C++ account for a large swathe of bugs. Sure, it's deterministic as to which function is called, but throwing a die is deterministic as well, as long as you know about every variable that affects the roll.
  - roel_v 12y ago
    ? I can't even remember the last time I've seen a bug that came from implicit casting, apart from there being compiler warnings that will tell you about them. I don't see how one can reasonably argue that type conversion is like 'rolling a die' - well yeah, if you use auto all over, it can be, which is my whole point. Next thing we'll need unit tests just to make sure a type change in place A doesn't make part B fall over - just like in scripting languages. Judicious use of auto to make iterators less painful to type; OK. 'auto' for types in templates where you don't know the type yet - that's a genuinely useful case (although there aren't that many cases where it's useful). 'auto' for every type just because that way you don't have to think about types - recipe for disaster and source of unexpected bugs, imo.

roel_v 12y ago

"If the code compiles without error on the new type, then there is a good chance that there is no need to worry about it" Yeah well I'd rather not rely on 'chance' - if I would, I wouldn't be using C++.

EvenThisAcronym 12y ago
I think you've been using a different C++ than I have, then. Numerous implicit (read: invisible and unexpected) conversion in C++ account for a large swathe of bugs. Sure, it's deterministic as to which function is called, but throwing a die is deterministic as well, as long as you know about every variable that affects the roll.
- roel_v 12y ago
  ? I can't even remember the last time I've seen a bug that came from implicit casting, apart from there being compiler warnings that will tell you about them. I don't see how one can reasonably argue that type conversion is like 'rolling a die' - well yeah, if you use auto all over, it can be, which is my whole point. Next thing we'll need unit tests just to make sure a type change in place A doesn't make part B fall over - just like in scripting languages. Judicious use of auto to make iterators less painful to type; OK. 'auto' for types in templates where you don't know the type yet - that's a genuinely useful case (although there aren't that many cases where it's useful). 'auto' for every type just because that way you don't have to think about types - recipe for disaster and source of unexpected bugs, imo.