C++ diaries...

C++ diaries...

[Olivier Henley]

I have to share to stay healthy ... I probably came across this one already but my brain just shuts off some times over this kind of well ... absurdity ... for the lack of a better word. :)

In C++:

namespace Whatever {
    enum SocketType {Stream, DGram, Raw};
    enum ProtocolType {IP, IPV6, Raw};
}

Will not compile and give you this: 

Error C2365	'Whatever::ProtocolType::Raw': redefinition; previous definition was 'enumerator'. 

Now a small search on SO gives:

"You cannot have equal names in old c-style enums. If you have C++11 - you can use enum class, static constants in classes, different namespaces, or you can simply use different names."

🤦

Looks like I have to use the new, third or fourth or fifth or ..., handle "from the water tap to not get sulfuric acid"*.

Olivier

p.s: I was so amazed, I triple checked, it works properly in Ada.

*(copyright by Dmitry Kazakov and reproduced with no permission)

Re: C++ diaries...

[Olivier Henley]

... now changing my 'burning genuine enums' for new 'enum classes' is breaking old code at 52 spots (from that change uses of enums as integer based index becomes illegal and need to be 'static_casted' to work) ... so much for productivity.

Thank you for taking the time to read me.

Re: C++ diaries...

[Maciej Sobczak]

> ... now changing my 'burning genuine enums' for new 'enum classes' is breaking old code at 52 spots (from that change uses of enums as integer based index becomes illegal and need to be 'static_casted' to work) ... so much for productivity.

You would be much more productive if you used non-clashing constant names. Actually, that would be even faster than writing these posts here. :-D
And you might be more likely to stay in line with those coding standards that actually forbid enumeration overloading.

Which brings another question: what is the problem, actually? The fact that old enums don't support overloading, the fact that transitioning to new language features requires changes in old code or the fact that there are two kinds of enums in the first place? I agree that this third fact is somewhat cumbersome, but since there is no obligation to use the new one, it should not be a show stopper.

-- 
Maciej Sobczak * http://www.inspirel.com

Re: C++ diaries...

[Olivier Henley]

> You would be much more productive if you used non-clashing constant names.

There is nothing clashing here:

Whatever::SocketType::Raw 
Whatever::ProtocolType::Raw

Do the word 'Socket' and 'Protocol' looks like the same to you?

Ada gets it right and C++ is not 'looking straight' trying to sell me its an 'overloading' issue. 'Paths' or the 'chain' of 'named' 'spaces' are unequivocally different; easy breezy.

> You would be much more productive if you used non-clashing constant names.

I will not create something like Socket_Raw and Protocol_Raw to satisfy the original non sense ... oh damn I forgot its standard practice to do so in C++. I think I will take the time to change all enums to comply to that convention for the whole project. Good idea.

> And you might be more likely to stay in line with those coding standards that actually forbid enumeration overloading.

The original stuff is company wide and is not my creation in the first place.

> Which brings another question: what is the problem, actually? The fact that old enums don't support overloading, the fact that transitioning to new language features requires changes in old code or the fact that there are two kinds of enums in the first place? 

I already said so, all of the above. The thing, 'straight enums', should have worked properly day one. The concept of enum in C++ is arguably deceitful, wrong, broken, you name it. 

By the way, lets talk about C++ enums a tidy bit further. Can you get a string representation of your enums in C++ ... today 2019? 

This is a great Q&A:  

https://stackoverflow.com/questions/28828957/enum-to-string-in-modern-c11-c14-c17-and-future-c20 (Anyone, take the time to read it, its stand up comedy. Maybe there is an unknown disease that render people judgement-less...) 

>I agree that this third fact is somewhat cumbersome, but since there is no obligation to use the new one, it should not be a show stopper.

You know MenuetOS? They wrote a full fledge OS, graphics included, in ... FASM. So yeah, nothing is a show stopper... it's not a reason to deny a dubious endeavor when you cross one.

Olivier

Re: C++ diaries...

[Keith Thompson]

Olivier Henley <olivier.henley@gmail.com> writes:
[...]
> I already said so, all of the above. The thing, 'straight enums',
> should have worked properly day one. The concept of enum in C++ is
> arguably deceitful, wrong, broken, you name it.
[...]

The concept of enum in C++ is not what you wanted it to be.

C's enum types are derived directly from C's.  In C, which does not
support overloading of identifiers, enumeration constants are of type
int.  For example:

    enum color { red, green, blue };

defined "enum color" as a discrete type, and "blue" as a constant
equivalent to a literal 2.  C++ tightens this up slightly by making
the constants be of the enum type (mostly, I think, to allow the
constants to be used with overloaded functions), but they're still
freely assignable to and from integer types.

More recently, C++ added a new "enum class" feature which is closer to
what you want enums to be -- but the older form goes back to the 1980s,
and there are uncounted lines of code depending on it.

Making C enums strongly typed from the beginning would have caused
problems *in the environment in which the language was defined
and used*.  Changing them in an incompatible way would have broken
existing code.  Ada was designed with a different philosophy.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

Re: C++ diaries...

[Olivier Henley]

On Friday, June 7, 2019 at 2:22:44 PM UTC-4, Keith Thompson wrote:
> The concept of enum in C++ is not what you wanted it to be.

> C's enum types are derived directly from C's.  In C, which does not
> support overloading of identifiers, enumeration constants are of type
> int.  For example:
> 
>     enum color { red, green, blue };
> 
> defined "enum color" as a discrete type, and "blue" as a constant
> equivalent to a literal 2.  C++ tightens this up slightly by making
> the constants be of the enum type (mostly, I think, to allow the
> constants to be used with overloaded functions), but they're still
> freely assignable to and from integer types.

> More recently, C++ added a new "enum class" feature which is closer to
> what you want enums to be -- but the older form goes back to the 1980s,
> and there are uncounted lines of code depending on it.

> Making C enums strongly typed from the beginning would have caused
> problems *in the environment in which the language was defined
> and used*.  Changing them in an incompatible way would have broken
> existing code.  

> Ada was designed with a different philosophy.

I know all this.

These facts do not absolve an absurd design and all the man hours it cost for decades. 

Life is short sir. I say we should struggle for better ways than accepting 'absurdly clashing identifiers' ... as a status quo of design. 

Re: C++ diaries...

[Keith Thompson]

Keith Thompson <kst-u@mib.org> writes:
> Olivier Henley <olivier.henley@gmail.com> writes:
> [...]
>> I already said so, all of the above. The thing, 'straight enums',
>> should have worked properly day one. The concept of enum in C++ is
>> arguably deceitful, wrong, broken, you name it.
> [...]
>
> The concept of enum in C++ is not what you wanted it to be.
>
> C's enum types are derived directly from C's.  In C, which does not

Typo, I meant to say that C++'s enum types are derived directly from C's.

> support overloading of identifiers, enumeration constants are of type
> int.  For example:
>
>     enum color { red, green, blue };
>
> defined "enum color" as a discrete type, and "blue" as a constant
> equivalent to a literal 2.  C++ tightens this up slightly by making
> the constants be of the enum type (mostly, I think, to allow the
> constants to be used with overloaded functions), but they're still
> freely assignable to and from integer types.

Correction, C++ doesn't allow implicit conversion from an integer type
to an enum type.  (C does.)

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

Re: C++ diaries...

[Lucretia]

On Friday, 7 June 2019 18:55:14 UTC+1, Olivier Henley  wrote:
> > You would be much more productive if you used non-clashing constant names.
> 
> There is nothing clashing here:
> 
> Whatever::SocketType::Raw 
> Whatever::ProtocolType::Raw
> 
> Do the word 'Socket' and 'Protocol' looks like the same to you?

The clash is because in C and C++ the identifiers in the enum are essentially global, if each enum was in a separate namespace, it would work.

This is what happens when people "design" crap languages.

Re: C++ diaries...

[Olivier Henley]

> The clash is because in C and C++ the identifiers in the enum are essentially global, if each enum was in a separate namespace, it would work. 

Yes. But they read as namespace, class, enum or enum choice: 

Whatever::Another::Thing

Whatever is a namespace, or a class?
Another is a namespace, a class or an enum?
Thing is a namespace, a class, an enum or an enum choice?

All this make up for some heavily 'booby-trapped' semantic.

> This is what happens when people "design" crap languages.

I could not agree more.