Hungarian notation vs. namespace

[Krice]

I'm using hungarian notation in enums, something like this:

enum Ground_Tile {gtDirt, gtWater, gtMountain};

I'm always told that it should be replaced with namespace.
But I feel it's pretty much the same, only namespace
would be Ground_Tile:irt I guess rather than gtDirt.

 

[Werner]

I'm using hungarian notation in enums, something like this:



enum Ground_Tile {gtDirt, gtWater, gtMountain};



I'm always told that it should be replaced with namespace.

But I feel it's pretty much the same, only namespace

would be Ground_Tile:irt I guess rather than gtDirt.

using C++11 style enumeration classes this is scoped:

enum class MyX{ MyY };

int main()
{
return int( MyX::MyY );
}

 

[Werner]

I'm using hungarian notation in enums, something like this:



enum Ground_Tile {gtDirt, gtWater, gtMountain};



I'm always told that it should be replaced with namespace.

But I feel it's pretty much the same, only namespace

would be Ground_Tile:irt I guess rather than gtDirt.

Alternatively, we've in the past used enumeration classes:

struct X
{
enum Value{ Y };
};

X::Y...

In my opinion using classes for enumerations provide
tighter scope than namespaces (provided better
encapsulation - localized change to literals, less
possibility of accidental re-definition, all literals
in one place, etc.).

 

[Fred Zwarts \(KVI\)]

"Werner" wrote in message

Alternatively, we've in the past used enumeration classes:

struct X
{
enum Value{ Y };
};

X::Y...

In my opinion using classes for enumerations provide
tighter scope than namespaces (provided better
encapsulation - localized change to literals, less
possibility of accidental re-definition, all literals
in one place, etc.).

I don't see the difference between a struct and a namespace here. A
namespace can be viewed as a struct (public access) with only static
members, and without the possibility to create an object (similar to a
struct with a private constructor).
So, if in your example the reserved word "struct" would be replaced with
"namespace", why would there suddenly be a less tighter scope, worse
encapsulation, etc.?

 

[Werner]

So, if in your example the reserved word "struct" would be replaced with

"namespace", why would there suddenly be a less tighter scope, worse

encapsulation, etc.?

With a struct, you are forced to define all your data in one
location. With a namespace you have the freedom to define it
anywhere (namespaces can be reopened). IMO for enumerated types
that relate to one another, one location is more beneficial.

Furthermore, classes scale better when using enumerated types in
templates:

struct MyGenericEnum
{
enum Value
{
Value0, ValueN
};
enum{ min = Value0, max = ValueN, size = ValueN+1
};

template <class EnumT>
void foo( typename EnumT::Value v )
{
for( int i = EnumT::min; i < EnumT::count; ++i )
{
//Get the picture???
}
}

Classes can be forward declared. By writing a little
general class, enumerations can be forward declared:

template <class T>
struct EnumForwarder
{
EnumForwarder( typename T::Value value = T::Value() )
: value_( value )
{
}

operator typename T::Value() const{ return value_; }

private:
typename T::Value value_;
};

class MyEnum;
void set( EnumForwarder<MyEnum> myEnum );

For reasons mentioned above, I prefer using the concept class
(the reserved word "struct" and "class") for this purpose.

Kind regards,

Werner

 

[Öö Tiib]

I'm using hungarian notation in enums, something like this:

enum Ground_Tile {gtDirt, gtWater, gtMountain};

I'm always told that it should be replaced with namespace.
But I feel it's pretty much the same, only namespace
would be Ground_Tile:irt I guess rather than gtDirt.

Namespaces are most flexible since the qualification can be made
to disappear entirely in context where it is clear what it is.
Qualification can be made abbreviated or partial in contexts
where that is enough and it can be kept fully qualified in
contexts where same abbreviated or partially qualified version
is not clear enough.

To take your example just 'Dirt' in one context dealing only
with ground tiles is fine enough. In context where we discuss
only tiles the 'ground:irt' and 'wall:irt' are clear enough.
The abbreviation 'gt:irt' might be good enough in context
where 'gt' is well known abbreviation of "ground tiles"
and is certainly not "girl talk" or "ground tactic". Far away
of such contexts the most safe representation would be to have
fully qualified names like 'tile::ground:irt'
or even 'game::gui::tile::ground:irt'.