2 ms·
Surely it would still mirror use if the operators were applied to the type, rather than the identifier? Preferring 'char ٭arr[X]' over '٭char[X] arr' seems arb
by contravariant 10y ago
Surely it would still mirror use if the operators were applied to the type, rather than the identifier?
Preferring 'char ٭arr[X]' over '٭char[X] arr' seems arbitrary to me. I see no reason the 'declaration mirror use' principle can differentiate between the two.
Personally I prefer the latter since it makes it easy to separate the type from the identifier.
- bluetomcat 10y ago> Surely it would still mirror use if the operators were applied to the type, rather than the identifier? The "type" is actually a list of storage class specifiers (static, extern, auto, register, typedef, _Thread_local), type qualifiers (const, volatile, restrict) and type specifiers (int, char, float, double, signed, unsigned, long, short, void). Imagine the soup of keywords that would have to be at the deepest level of the expression: static const volatile unsigned char *arr[X]; // vs *static const volatile unsigned char[X] arr;
- Nullabillity 10y agostatic, const, and volatile modify the variable itself, not what values it's legal for it to contain. So the outcome should be: static const volatile *unsigned char[X] arr; Or, because signedness should be a property of the type, not an arbitrary modifier: static const volatile *char[X] arr;
- fredmorcos 10y ago'char ٭arr[X]' over '٭char[X] arr' What is this dirt after char and before char? This wouldn't even compile.
- bluetomcat 10y agoHN converts asterisks to italics and I too couldn't find a way to escape them, except when surrounded by backticks `*`. Not a C-friendly discussion forum :-)