3 ms·

OK I'll bite. 1 - knowing this is 100% useless information, in reality I have a compiler to tell me that. 2 - Seriously? new/delete in 2018? In very rare case

OK I'll bite. 1 - knowing this is 100% useless information, in reality I have a compiler to tell me that. 2 - Seriously? new/delete in 2018? In very rare cases when I need a raw pointer I call unique_ptr::release(). 5 The question is so-so but the answer's wrong. Iterators don't need to point anywhere. You can make an iterator generating values instead of referencing container. Not necessarily a good idea but still. 6 Same. Just because it's not specified in C++ standard doesn't mean it's bad, or should be avoided. E.g. const uint32_t n = 11; printf( "Eleven: %d\n", n ); is UB but the code is 100% fine to my standards. Stuff like OpenMP or intrinsics is not specified either, does it mean we should avoid them? 8-9 IMO template metaprogramming should be avoided. If you want your template data structure to behave differently for pointers and non-pointers, expose another template argument for that, there's too many corner cases like handles (technically pointers, logically values) and smart pointers (the opposite). 10 I don't think the sorted vector listed in "possible answer" is a max heap. Conclusion: if the OP claims the questions are "Proven", I'm curious about provement methodology.

gpderetta 8y ago
> 1 - knowing this is 100% useless information, in reality I have a compiler to tell me that. A clever compiler might tell you that adding std::move will make the code compile. But if you do not understand what std::move does it will lead to more bugs as you might not expect the ptr to suddenly be empty in main.
- Const-me 8y ago
  I agree with what you're saying but they aren't asking what it does. They're asking "What happens when?" giving code that doesn't compile. Nothing happens.
MaxBarraclough 8y ago
> is UB but the code is 100% fine to my standards Strongly disagree - I'd never let that through code-review. When living in C/C++ land, we should be extremely aware of the differences between the integer types, and handle their conversions carefully and explicitly. Given that the "%d" format-specifier maps to `int`, not to `int32_t` (let alone `uint32_t`), that code really could wreck things if your platform has an `int` type which isn't 32 bit - https://stackoverflow.com/a/3168293/ https://stackoverflow.com/a/3168293/
- Const-me 8y ago
  About int vs sint32, why exactly you should be aware about the differences? The only cases when I encounter these differences, they look like broken C++ compiler: https://stackoverflow.com/q/50552347/126995 https://stackoverflow.com/q/50552347/126995 Similar about %d and unsigned. Technically UB, practically works fine in 100% of cases. If you ask “but how do you know it works?” I’ll answer “because I read assembly”.
  - MaxBarraclough 8y ago
    > why exactly you should be aware about the differences? Because they aren't assured to be the same. They might happen to be the same on your current platform. C++ isn't like Java. It's the programmer's job to be very aware of these sorts of platform-specific points of variation. I don't see why you'd deliberately write undefined behaviour when there's no benefit to doing so. This isn't a purely academic concern - I've seen a malformed printf call wreak absolute havoc, presumably because it was stripping too much or too little data off the stack. Was a nightmare to track it down. I don't want to think about which particular families of dangerous type-based mistakes are permissible in my codebase -- I'd rather write code which is correct. > The only cases when I encounter these differences, they look like broken C++ compiler If you write dangerous, non-portable code that invokes UB, you may well find that it works on plenty of real-world platforms. Your code is still wrong. For the specific case of assuming that `int` is 32-bit, you'll probably get away with this sort of clumsiness, yes, but 'ILP64' targets exist, even if they're rare. Additionally, using `int` as a dangerous alias for `int32_t` is not expressive when it comes to readability. > Technically UB, practically works fine in 100% of cases UB can bite you in bizarre, unpredictable, intermittent ways, especially with optimising compilers. Why argue that a bad habit isn't that bad, when you could just avoid doing it? > If you ask “but how do you know it works?” I’ll answer “because I read assembly”. That's a very fragile assurance of correctness. Unless you explicitly embed that assembly code, the compiler is free to generate different code at any point in future. Can you guarantee that you'll never change or upgrade your compiler, tweak its flags, or target another platform? Can you guarantee the optimiser will never change its mind and generate different code for that function?

gpderetta 8y ago

> 1 - knowing this is 100% useless information, in reality I have a compiler to tell me that. A clever compiler might tell you that adding std::move will make the code compile. But if you do not understand what std::move does it will lead to more bugs as you might not expect the ptr to suddenly be empty in main.

Const-me 8y ago
I agree with what you're saying but they aren't asking what it does. They're asking "What happens when?" giving code that doesn't compile. Nothing happens.

MaxBarraclough 8y ago

> is UB but the code is 100% fine to my standards Strongly disagree - I'd never let that through code-review. When living in C/C++ land, we should be extremely aware of the differences between the integer types, and handle their conversions carefully and explicitly. Given that the "%d" format-specifier maps to `int`, not to `int32_t` (let alone `uint32_t`), that code really could wreck things if your platform has an `int` type which isn't 32 bit - https://stackoverflow.com/a/3168293/ https://stackoverflow.com/a/3168293/

Const-me 8y ago
About int vs sint32, why exactly you should be aware about the differences? The only cases when I encounter these differences, they look like broken C++ compiler: https://stackoverflow.com/q/50552347/126995 https://stackoverflow.com/q/50552347/126995 Similar about %d and unsigned. Technically UB, practically works fine in 100% of cases. If you ask “but how do you know it works?” I’ll answer “because I read assembly”.
- MaxBarraclough 8y ago
  > why exactly you should be aware about the differences? Because they aren't assured to be the same. They might happen to be the same on your current platform. C++ isn't like Java. It's the programmer's job to be very aware of these sorts of platform-specific points of variation. I don't see why you'd deliberately write undefined behaviour when there's no benefit to doing so. This isn't a purely academic concern - I've seen a malformed printf call wreak absolute havoc, presumably because it was stripping too much or too little data off the stack. Was a nightmare to track it down. I don't want to think about which particular families of dangerous type-based mistakes are permissible in my codebase -- I'd rather write code which is correct. > The only cases when I encounter these differences, they look like broken C++ compiler If you write dangerous, non-portable code that invokes UB, you may well find that it works on plenty of real-world platforms. Your code is still wrong. For the specific case of assuming that `int` is 32-bit, you'll probably get away with this sort of clumsiness, yes, but 'ILP64' targets exist, even if they're rare. Additionally, using `int` as a dangerous alias for `int32_t` is not expressive when it comes to readability. > Technically UB, practically works fine in 100% of cases UB can bite you in bizarre, unpredictable, intermittent ways, especially with optimising compilers. Why argue that a bad habit isn't that bad, when you could just avoid doing it? > If you ask “but how do you know it works?” I’ll answer “because I read assembly”. That's a very fragile assurance of correctness. Unless you explicitly embed that assembly code, the compiler is free to generate different code at any point in future. Can you guarantee that you'll never change or upgrade your compiler, tweak its flags, or target another platform? Can you guarantee the optimiser will never change its mind and generate different code for that function?