4 ms·

The thing I hate most about C/C++ is how they overload the same keywords to mean different things. So the idea of: int x = void; is inherently wrong to me.

by steven2012 11y ago

The thing I hate most about C/C++ is how they overload the same keywords to mean different things. So the idea of: int x = void; is inherently wrong to me. Why not just create a new keyword with a clear and explicit meaning? That said, breaking changes are simply wrong. C/C++ is what it is, stop trying to make it into Java, Go or whatever. Trying to change it into a language that it's not is simply going to cause confusion and chaos, and kill the language. The things Meyer points out are all correct, but just because it's right doesn't mean it's right for the C++ community. Every language has it's own pluses and minuses and thinking you can squash all problems in all languages and make it "perfect" is a losing battle.

corysama 11y ago
> Why not just create a new keyword with a clear and explicit meaning? That said, breaking changes are simply wrong. Ummm... What is your suggestion for a new keyword that would not be a breaking change?
- theseoafs 11y ago
  I think the point that they're trying to make is that it's best to use a non-overloaded word for this kind of thing, but that that ship has sailed since C++ has been around for 30 years or whatever. So making no change is preferable.
- mikeash 11y ago
  The typical way to do this is to create a new keyword that starts with __, or _ and a capital letter. This is not a breaking change because this space is reserved for the language and implementations. You can then add a header that #defines something less ugly to these new keywords.
  - marvy 11y ago
    Like what C did with bool? Ick. Gross. Ugly. Me no like. I understand why they did that in this case: by the time they got around to fixing the lack of bool, they had to work around everyone else's workarounds! But that was an extreme case. Let's not do that more often than we must.
    - cpeterso 11y ago
      I assume the authors of the C standard expected developers to typedef their C project's existing bool or BOOL types to _Bool. There is also a stdbool.h header that defines macros for bool (_Bool), true (1), and false (0).
    - mikeash 11y ago
      I like it. It effectively adds a new keyword to the language that's only available if you include a header. The technique isn't pretty, but the result is pretty nice IMO.
      - marvy 11y ago
        But I don't want to include a header just to use bool. I'm willing to include a header for big things (like strcmp), but bool is such a small convenience that it should be available without an include, because otherwise it's less work to just use an int than to go to the top of the file and add an include. Plus, I think the idea of putting each keyword behind an include gets annoying if you do this for a significant fraction of your keywords. (It's neat that you can, but... should you?) For instance, imagine if throw, class, and protected were all behind separate includes?
Sanddancer 11y ago
Every language evolves, and syntax changes. Fortran is still used not as much for backwards compatibility as it is for adding features, deprecating features, etc, as the needs of the community change. Hell, even COBOL, as clunky as it is will add and remove features when standards are revised. Changing the language will not kill it, leaving it static will.
exDM69 11y ago
I agree that the use of the "void" keyword here is confusing. I wish it were more like LLVM IR, where things are more explicit and no values can be left uninitialized by accident. E.g. something like this would be nice (but requires breaking eggs): int x = zeroinitializer; void *ptr = zeroinitializer; int y = undefined; // explicitly undefined int z; // compile error int w = poison; // compiler error if w or &w is read from Additionally, I am not fond of C and C++ casts and their semantics which vary with the types being used (and can get really hairy when templates are added to the mix). I'd much rather see "casts" that are named after the semantics they use. E.g. uint16_t u16 = 1234; uint32_t u32 = zero_extend(u16); int16_t s16 = -342; int32_t s32 = sign_extend(s16); uint16_t bits = bitcast(s16); // must be same size float fp = 1.234; int32_t fpint = floattoint(fp); uint32_t fpbits = bitcast(fp); In the two examples above, all the semantics are explicit, there are no surprises at runtime and the compiler/static analyzer has much more power in catching problems. This, of course, isn't going to happen in C++ in any kind of backwards compatible way. I'm not sure these things can or should be fixed in C++, because of the amount of existing code and the fact that most projects would never upgrade because of the manual effort required in updating the code and merging it.

corysama 11y ago

> Why not just create a new keyword with a clear and explicit meaning? That said, breaking changes are simply wrong. Ummm... What is your suggestion for a new keyword that would not be a breaking change?

theseoafs 11y ago
I think the point that they're trying to make is that it's best to use a non-overloaded word for this kind of thing, but that that ship has sailed since C++ has been around for 30 years or whatever. So making no change is preferable.
mikeash 11y ago
The typical way to do this is to create a new keyword that starts with __, or _ and a capital letter. This is not a breaking change because this space is reserved for the language and implementations. You can then add a header that #defines something less ugly to these new keywords.
- marvy 11y ago
  Like what C did with bool? Ick. Gross. Ugly. Me no like. I understand why they did that in this case: by the time they got around to fixing the lack of bool, they had to work around everyone else's workarounds! But that was an extreme case. Let's not do that more often than we must.
  - cpeterso 11y ago
    I assume the authors of the C standard expected developers to typedef their C project's existing bool or BOOL types to _Bool. There is also a stdbool.h header that defines macros for bool (_Bool), true (1), and false (0).
  - mikeash 11y ago
    I like it. It effectively adds a new keyword to the language that's only available if you include a header. The technique isn't pretty, but the result is pretty nice IMO.
    - marvy 11y ago
      But I don't want to include a header just to use bool. I'm willing to include a header for big things (like strcmp), but bool is such a small convenience that it should be available without an include, because otherwise it's less work to just use an int than to go to the top of the file and add an include. Plus, I think the idea of putting each keyword behind an include gets annoying if you do this for a significant fraction of your keywords. (It's neat that you can, but... should you?) For instance, imagine if throw, class, and protected were all behind separate includes?

Sanddancer 11y ago

Every language evolves, and syntax changes. Fortran is still used not as much for backwards compatibility as it is for adding features, deprecating features, etc, as the needs of the community change. Hell, even COBOL, as clunky as it is will add and remove features when standards are revised. Changing the language will not kill it, leaving it static will.

exDM69 11y ago

I agree that the use of the "void" keyword here is confusing. I wish it were more like LLVM IR, where things are more explicit and no values can be left uninitialized by accident. E.g. something like this would be nice (but requires breaking eggs): int x = zeroinitializer; void *ptr = zeroinitializer; int y = undefined; // explicitly undefined int z; // compile error int w = poison; // compiler error if w or &w is read from Additionally, I am not fond of C and C++ casts and their semantics which vary with the types being used (and can get really hairy when templates are added to the mix). I'd much rather see "casts" that are named after the semantics they use. E.g. uint16_t u16 = 1234; uint32_t u32 = zero_extend(u16); int16_t s16 = -342; int32_t s32 = sign_extend(s16); uint16_t bits = bitcast(s16); // must be same size float fp = 1.234; int32_t fpint = floattoint(fp); uint32_t fpbits = bitcast(fp); In the two examples above, all the semantics are explicit, there are no surprises at runtime and the compiler/static analyzer has much more power in catching problems. This, of course, isn't going to happen in C++ in any kind of backwards compatible way. I'm not sure these things can or should be fixed in C++, because of the amount of existing code and the fact that most projects would never upgrade because of the manual effort required in updating the code and merging it.