3 ms·

Those are practically a joke. "Don't dereference a possibly invalid pointer". Thanks, Bjarne. That hadn't crossed my mind, but I can imagine why you would write

by tgv 4y ago

Those are practically a joke. "Don't dereference a possibly invalid pointer". Thanks, Bjarne. That hadn't crossed my mind, but I can imagine why you would write that. The language simply can't stop it. These, on the other hand: "Don't return a T&&", "Don't use a variable for two unrelated purposes" (in the context provided), "Don't define a (C-style) variadic function" and many others can be excluded from the language. Yes, you can forbid reusing loop variables. It's in your hands, Bjarne. Remove these constructions from C++.

72deluxe 4y ago
But why remove them? What's wrong with declaring int i at the top of your function (like old-style C) and then using it throughout all loops in the function? You can't just cull old variadic functions because some old stuff won't work. It's easy to say "just get rid of it!" but that's never going to happen because it's backwards compatible. People really should be using parameter packs now instead of old variadics but I have worked with "developers" who hadn't a clue about them. The senior developers dismissed the new features as syntactic sugar and insisted on writing old-style code. They detested std::pair. They were unaware of move semantics. An rvalue reference was unknown. Lambdas were pointless to them. It also isn't in Bjarne's hands - it's the committee. He fought against various things (as I recall from his talks at cppcon) but they ended up in the language anyway.
- tgv 4y ago
  > What's wrong with declaring int i at the top of your function (like old-style C) and then using it throughout all loops in the function? Ask Stroustrup. It's his example, and in this case avoidable. > You can't just cull old variadic functions because some old stuff won't work. Yes, you can. They've removed quite a few features from older C++ versions. You can turn them back on, if you want. So for C++x24 or whatever, they could say: for loop variables are always local, C variadic is no longer permitted, etc., and use some compiler flag to re-enable it. > It also isn't in Bjarne's hands But that's probably the person with most influence on the language. And if he would propose a C++safer version, which deviates from the standard by eliminating as many bad practices as he sees fit, people would follow, and the two would probably merge at some point. But that won't happen, which makes the core guidelines a bit of a joke. "Here's an apple. Don't eat it."
  - 72deluxe 4y ago
    Good points. I myself would be happy to see va_args disappear but it'd require work from the maintainers of the compilers etc. which is unlikely to get support, I guess?
UncleMeat 4y ago
I especially love that piece of guidance because there isn't a good way of testing whether a pointer is invalid. Imagine I'm a function and I've got a pointer to some object. I know the object is owned by something else. Let's say I want to be extra safe and check whether the pointer is valid before accessing it. How do I do this? I cannot dereference it. I can't compare it against something useful. I could have a custom allocator that tracks the status of all allocated and freed regions of memory, cast my pointer to a void pointer, and check with the allocator (I think this isn't UB). But now I've also got to make sure that freed regions of memory are never reused for any reason. Thanks Bjarne.

by tgv 4y ago

72deluxe 4y ago

But why remove them? What's wrong with declaring int i at the top of your function (like old-style C) and then using it throughout all loops in the function? You can't just cull old variadic functions because some old stuff won't work. It's easy to say "just get rid of it!" but that's never going to happen because it's backwards compatible. People really should be using parameter packs now instead of old variadics but I have worked with "developers" who hadn't a clue about them. The senior developers dismissed the new features as syntactic sugar and insisted on writing old-style code. They detested std::pair. They were unaware of move semantics. An rvalue reference was unknown. Lambdas were pointless to them. It also isn't in Bjarne's hands - it's the committee. He fought against various things (as I recall from his talks at cppcon) but they ended up in the language anyway.

tgv 4y ago
> What's wrong with declaring int i at the top of your function (like old-style C) and then using it throughout all loops in the function? Ask Stroustrup. It's his example, and in this case avoidable. > You can't just cull old variadic functions because some old stuff won't work. Yes, you can. They've removed quite a few features from older C++ versions. You can turn them back on, if you want. So for C++x24 or whatever, they could say: for loop variables are always local, C variadic is no longer permitted, etc., and use some compiler flag to re-enable it. > It also isn't in Bjarne's hands But that's probably the person with most influence on the language. And if he would propose a C++safer version, which deviates from the standard by eliminating as many bad practices as he sees fit, people would follow, and the two would probably merge at some point. But that won't happen, which makes the core guidelines a bit of a joke. "Here's an apple. Don't eat it."
- 72deluxe 4y ago
  Good points. I myself would be happy to see va_args disappear but it'd require work from the maintainers of the compilers etc. which is unlikely to get support, I guess?

UncleMeat 4y ago

I especially love that piece of guidance because there isn't a good way of testing whether a pointer is invalid. Imagine I'm a function and I've got a pointer to some object. I know the object is owned by something else. Let's say I want to be extra safe and check whether the pointer is valid before accessing it. How do I do this? I cannot dereference it. I can't compare it against something useful. I could have a custom allocator that tracks the status of all allocated and freed regions of memory, cast my pointer to a void pointer, and check with the allocator (I think this isn't UB). But now I've also got to make sure that freed regions of memory are never reused for any reason. Thanks Bjarne.