Enums hierarchy and organization in C++

[zdravko.monov]

Hi!
I am trying to get several parameters in functions as enum variables.
Consider this:

namespace Layout
{
enum type
{
DOT, NEATO, FDP, TWOPI, CIRCO
};
}

A function signature would look like this:

void render(Layout:: type L);

And a typical invocation could be:

G.render(Layout ::NEATO).;

This looks really OOP and elegant. However, I am unsure whethere this
design pattern is the "de facto" standard one in modern C++. I wonder
how does one organize the enums to separate different enum items in a
nice way?

[Andrew Kerr]

zd***********@g mail.com wrote:

void render(Layout:: type L);

And a typical invocation could be:

G.render(Layout ::NEATO).;

This looks really OOP and elegant. However, I am unsure whethere this
design pattern is the "de facto" standard one in modern C++.

I wonder
how does one organize the enums to separate different enum items in a
nice way?

You've certainly nailed it. If C supported the concept of namespaces,
the declaration of an enum would place elements of the enumeration in
its namespace. Since it doesn't, doing it explicitly on your own is
perfectly legitimate and shouldn't surprise anyone.

With regard to whether it is a "de facto standard," I would go with no
it is not yet standard C++ style, but you should use namespaces anyway
and perhaps help that come about. It's quite a sensible style preference.

Other OOP languages that were designed without C compatibility in mind
(e.g. Java, C#) bring the enumerations into their own namespace as you
have done.

// C#
//
enum Layout {
DOT, NEATO, FDP, TWOPI, CIRCO
};

void Render(Layout type);

Render(Layout.N EATO);

--
Andrew Kerr

[Pascal J. Bourguignon]

zd***********@g mail.com writes:

Hi!
I am trying to get several parameters in functions as enum variables.
Consider this:

namespace Layout
{
enum type
{
DOT, NEATO, FDP, TWOPI, CIRCO
};
}

A function signature would look like this:

void render(Layout:: type L);

And a typical invocation could be:

G.render(Layout ::NEATO).;

This looks really OOP and elegant. However, I am unsure whethere this
design pattern is the "de facto" standard one in modern C++. I wonder
how does one organize the enums to separate different enum items in a
nice way?

If I had my say, I would write:

namespace Layout{
namespace type{
enum type{
DOT, NEATO, FDP, TWOPI, CIRCO };}}

so we can add:

namespace Layout{
namespace type{
enum type{
DOT, NEATO, FDP, TWOPI, CIRCO };}
namespace form{
enum type{
DOT, CIRCLE, TRIANGLE, SQUARE, PENTAGON, POLYGON };}}

and no problem with Layout::type::D OT vs. Layout::form::D OT.

--
__Pascal Bourguignon__

[Stefan Naewe]

On 5/30/2008 10:54 PM, zd***********@g mail.com wrote:

Hi!
I am trying to get several parameters in functions as enum variables.
Consider this:

namespace Layout
{
enum type
{
DOT, NEATO, FDP, TWOPI, CIRCO
};
}

A function signature would look like this:

void render(Layout:: type L);

And a typical invocation could be:

G.render(Layout ::NEATO).;

This looks really OOP and elegant. However, I am unsure whethere this
design pattern is the "de facto" standard one in modern C++. I wonder
how does one organize the enums to separate different enum items in a
nice way?

Wouldn't make a real OOP approach make more sense?
What about creating classes for DOT, NEATO, etc. ?

(Hhmm, where did I read "never switch on type codes"...Can't remember)
S.
--
Stefan Naewe stefan dot naewe at atlas-elektronik dot com
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html

[Paavo Helde]

zd***********@g mail.com kirjutas:

Hi!
I am trying to get several parameters in functions as enum variables.
Consider this:

namespace Layout
{
enum type
{
DOT, NEATO, FDP, TWOPI, CIRCO
};
}

A function signature would look like this:

void render(Layout:: type L);

And a typical invocation could be:

G.render(Layout ::NEATO).;

This looks really OOP and elegant. However, I am unsure whethere this
design pattern is the "de facto" standard one in modern C++. I wonder
how does one organize the enums to separate different enum items in a
nice way?

Namespaces are fine. Another commonly used approach is to encapsulate the
enum into some class, which achieves visually the same effect. This
allows for finer access control and binds the enum more tightly with the
class. As std::ios_base is a class I would think this approach is more
"standard" than namespaces. It seems in Boost libraries both approaches
are used, whichever is more appropriate to the case at hand.

In case of namespaces, there should be more or less one namespace per
enum. If there are lots of other stuff in the same namespace, the client
code may want to apply "using namespace ...", thus destroying the enum
encapsulation. Of course, such enum namespaces would be nested ones
usually.

Another note: by many guidelines, all-caps identifiers are reserved for
preprocessor macros only. I would use some other style for enum
constants.

Best regards
Paavo