I tend to prefer to use namespaces filled with constants, rather than using enums in most cases. For example using
namespace Element {
const uint8_t No_Element = 0;
const uint8_t Air = 1;
const uint8_t Water = 2;
const uint8_t Earth = 3;
const uint8_t Fire = 4;
};
instead of
enum Element {
No_Element, Air, Water, Earth, Fire
};
Is this bad practice?
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-12-13 3:46
using the #define sounds like better alternative, without any reliance on enum/class interface format
#define d #define
d No_Element 0
d Air 1
d Water 2
d Earth 3
d Fire 4
With namespaces, I don't have to undefine shit. I can have a namespace of elements, and a namespace of something else with members that have the same name. For example:
namespace Element {
const uint8_t Fire = 4;
};
namespace Attack_Damage {
const double Fire = 9.0;
};
Or some shit like that.
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-12-13 4:27
>>14
I never use #undef actually(only in extremely limited instances where the #define controls a global setting)
because i can use namespace in the name
#define ELEMENTS_EARTH 1
See the above is just like your namespace without any bloat
>>10 #define ... no abstraction
tell that to the people who define header only data structures int main (int argc, char ** argv) {
int i;
struct list l;
do { struct list * __s = (&l); __s->h = ((void *)0); __s->t = ((void *)0); __s->s = 0; } while (0);
while (--argc)
do { struct list * __s = (&l); list_type __e = (atoi(*++argv)); struct list_node * __n; __n = list_node_alloc(__e); if (__n == ((void *)0)) break; if (__s->s == 0) { __s->h = __s->t = __n; } else { __n->n = __s->h; __s->h->p = __n; __s->h = __n; } __s->s += 1; } while (0);
do { struct list_node * __n = (&l)->h; while (__n != ((void *)0)) { int n = __n->e; {
printf("%d!\n", n);
} __n = __n->n; } } while (0);
do { struct list * __s = (&l); struct list_node * __n = __s->h; struct list_node * __t; while (__n != ((void *)0)) { __t = __n; __n = __n->n; do { struct list_node * __s = (__t); ; free(__s); } while (0); } do { struct list * __s = (__s); __s->h = ((void *)0); __s->t = ((void *)0); __s->s = 0; } while (0); } while (0);
return 0;
}
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-12-13 4:46
>>16
The abstraction is not in the binary, it only in your mind.
Constants and classes are real binary objects.
How can you not grasp the difference?
Say I have a function where I only need the elements namespace and not the Attack_Damage namespace. I can
int8_t Damage_Multiplier(const uint8_t element) {
using namespace Elements;
// My code here, uninhibited by Elements::Fire shit
}
and outside, where I have to make the Elements and Attack_Damage namespaces play nicely, I can refer to them by Elements::Fire and Attack_Damage::Fire respectfully.
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-12-13 4:54
>>18
You can make mistakes in the Elements::Fire or Attack_Damage::Fire
You can confuse, change them accidentally, or transfer some Fire properties.
when you use the #define you have more verbose, but more more reliable constants which cannot be accidentally refered to,changed or substituted by something else without #undef or another #define.
>You can confuse, change them accidentally, or transfer some Fire properties.
Confusing them is pretty fucking hard when all you have to do is look at the top of the function definition to know which namespace it belongs to.
Also, change them? You can't change a fucking constant bro.
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-12-13 5:04
>>22
using namespace Elements;
all "constants" changed.
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-12-13 5:06
You don't accidentaly treat one namespace as another just because they share Fire?
Imagine a cryptic call to Fire in the middle of 100Kb file where you don't know which namespace it refers to
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-12-13 5:07
And thats why namespaces and similar defective Sepples shit like classes should not be used at all.