"enum class" in C++03

[YaronCT]

Hi,

In C++11 we could define e.g.:

Code: Select all

enum class HorizAlignment { LEFT, CENTRE, RIGHT };
enum class VertAlignment { TOP, CENTRE, RIGHT };

This won't compile in C++03, and this won't either:

Code: Select all

enum HorizAlignment { LEFT, CENTRE, RIGHT };
enum VertAlignment { TOP, CENTRE, RIGHT };

Because "CENTRE" is defined twice! We could, of course, do:

Code: Select all

enum HorizAlignment { HORIZ_ALIGNMENT_LEFT, HORIZ_ALIGNMENT_CENTRE, HORIZ_ALIGNMENT_RIGHT };
enum VertAlignment { VERT_ALIGNMENT_TOP, VERT_ALIGNMENT_CENTRE, VERT_ALIGNMENT_RIGHT };

But that's not very pretty. Now, in my own code (outside CEGUI) I use the following hack:

Code: Select all

struct HorizAlignment { enum { LEFT, CENTRE, RIGHT }; };
struct VertAlignment { enum { TOP, CENTRE, RIGHT }; };

And then I can refer it like in C++11, as e.g. "HorizAlignment::CENTRE" or "VertAlignment::CENTRE".

And my question is: If I add a new enum to the "v0-8" or "v0" branches (which use C++03), do u have any objection if I use this hack in CEGUI code? Then when merging to "default" branch I'll just change it to "enum class" without "struct".

[Ident]

Do you mean HorizontalAlignment from Element.h?

The values are HA_LEFT, HA_RIGHT, HA_CENTRE. All CEGUI enums are prepended by two letters of abbreviation by convention. I think this is a good way of doing that as it helps with autocomplete and I use the same convention in my own projects (sometimes with 3 letters). Using the enum name as qualifier afaik is not recommended by the standard or at least VS gives a warning.

How is your hack benefitial? It requires adding the struct name as qualifier everytime.

[YaronCT]

I was not referring to a specific enum, I just gave an example. Let me try to explain myself more clearly.

Using C++11's new "enum class" feature, if u define:

Code: Select all

enum class HorizAlignment { LEFT, CENTRE, RIGHT };
enum class VertAlignment { TOP, CENTRE, RIGHT };

you must refer to its values as e.g. "HorizAlignment::LEFT" (rather than just "LEFT"), and it compiles without a warning. In C++03 u don't have "enum class", and if u define:

Code: Select all

enum HorizAlignment { LEFT, CENTRE, RIGHT };
enum VertAlignment { TOP, CENTRE, RIGHT };

you'll get an error because "CENTER" is considered to be defined twice. That's due to the fact that enum values live in the scope where the enum is defined. However, what u can do in C++03 is the follwing hack, using auxiliary structures:

Code: Select all

struct HorizAlignment { enum { LEFT, CENTRE, RIGHT }; };
struct VertAlignment { enum { TOP, CENTRE, RIGHT }; };

Now u won't get an error because the first "CENTRE" is defined in the scope of the "HorizAlignment" structure (not enum), whereas the second "CENTRE" is defined in the scope of the "VertAlignment" structure. In this case u must refer to the enum values as e.g. "HorizAlignment::LEFT", not just "LEFT". The later won't compile, and the former will compile without a warning, because we're not using the enum name as qualifier, but the structure's name. And there's no problem with the fact that "CENTER" is defined twice, because it's in different scopes, and must be refered to as "HorizAlignment::CENTRE" or "VertAlignment::CENTRE".

And my question is: If I add a new enum to the "v0-8" or "v0" branches (which use C++03), do u have any objection if I use this auxiliary structure hack in CEGUI code?

[Ident]

I am not a big fan of changing the coding convention in a patching-branch. What is the specific enum you want to introduce? It might depend on the case really.

Also how would you code this in c++11 then? By going for HorizontalAlignment::CENTRE via the enum class? We would have to first decide how this should be done in default branch in the future. Because if we do not change it there, then there is absolutely no reason to introduce what you said in v0-8.

[YaronCT]

I am not a big fan of changing the coding convention in a patching-branch. What is the specific enum you want to introduce? It might depend on the case really.

Well I'll just use it and let u review it when I open a PR. Then u can c it.

Also how would you code this in c++11 then? By going for HorizontalAlignment::CENTRE via the enum class? We would have to first decide how this should be done in default branch in the future. Because if we do not change it there, then there is absolutely no reason to introduce what you said in v0-8.

Of course I'd use "HorizontalAlignment::CENTRE" via the enum class. Surely u have no objection for using enum class this way for new enums in the "default" branch?

[Ident]

Of course I'd use "HorizontalAlignment::CENTRE" via the enum class. Surely u have no objection for using enum class this way for new enums in the "default" branch?

This has to be discussed and decided not by me but by the entire development team. After all this is a relevant change to the coding convention AND it would have to be changed for ALL existing enums. I will send out an e-mail.

[YaronCT]

Ok, thanx. Feel free to cc me...

[YaronCT]

scoping is not the only advantage of enum classes. They're also strongly typed, which means they can't be implicitly converted to and integer type and therefore can't be compared to a value of another enum or enum class without explicit convertion.

http://www.cprogramming.com/c++11/c++11 ... class.html

[Ident]

I have actually seen the article you linked, I think it was the first Google result

So far everyone is in favour, I am waiting for Paul's response.

The downside is, we need to change all prefixes for all enums in default then. Or at least, someone will.

[YaronCT]

A fairy has whispered me that eventually it'll be me who has to do it. That should b my proper punishment for bringing this up

[Ident]

Well I didn't say it has to be you and to be honest I think this is not that much work.

Btw. I am working on the String class still from time to time, and I make full char, char32_t, char*, char32_t*, std::string, std::ustring support for all functions, operators and constructors like they are described in basic_string but for all of the above types. You dont wanna know how many functions i wrote... lol. Total monkey job but it needs to be done.

In any case, it doesnt matter who does the enum change, worst case no one wants to do it and then I will do it.

[YaronCT]

j.k. it's really no problem if I'll do it eventually. The string stuff is definitely more dirty work, I agree

[Ident]

Yea, for example for the operator+ it ended up being 29 overloads if i calculated correctly. The same was true for most functions And the standard library provides a lot of functions

I still am not very keen on writing unit tests for this

[YaronCT]

I used to work in a company where regression tests were the whole essence of its existence. It was a 20 million line undocumented source code for a single program. Whenever any of us wanted to change something - he'd just try some change hoping for good. Every night we ran 2000 very long tests (which required several strong computers), and the next day start fixing the problems found in the tests. If we stopped running the regression tests for no more than a week the program would become totally unusable.

I don't imply anything for CEGUI (it's a bit smaller project...)

[Ident]

Yea, i am not saying it wouldn't be useful, or that nobody should do them, quite the opposite actually: It is a pity we didn't have any for String so far. I might go for it but no promises are made, especially since some functions require multiple tests per overload. So that would multiply even further. Brrrr. I might do them only for frequently used functionality though.