Stylistic choices

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?

>>24
Don't you know that /prog/riders only write small toy programs that are at most 300 lines long?

Where did you get the idea that anyone here would write a 100Kb file anyway?

>>26
Toy programs tend to grow very fast. Imagine that could add couple of features, that would a couple of KB each.
Now multiply the process by days, add some useful abstraction with #define's and its no longer a toy.
In fact i have to restrain myself from growing my "toy programs" so they could be rewritten from scratch anytime i need a completed one with different algorithm/functionality, which would be painful to rewrite/throw away if it was a complete program(the abstraction would be moved to void.h instead).

>>27
Silly FrozenVoid, don't you ever split your toys into several files when they grow to be large?

>>28
Only header files. The program is always monolithic.

>>29
So you can never re-use a function from one program in another, they're all static?
Sounds like an odd way of coding.

>>30
I can export useful stuff to headers, like void.h
and use the header in another program like #include "VOID_[HEADERTYPE]_[FUNCTIONALITY].H"

>>31
KEKEKEKEKEKEKEKEKEKE

>>24

There shouldn't ever be a time where you don't know what namespace something is from. The using keyword should be used sparingly, and only in cases where other namespaces with the same variables will never be used.

>>29

There's a reason you have a linker you know. By only splitting up your code into a bunch of header files with a single source file, your compiler is effectively compiling a single giant mess of code. If you happen to make an error in one function, you have to recompile everything else from scratch. You should separate your source code so that you don't have to recompile the entire thing every time something needs to be changed.

>>33
I don't split my code this is counter-productive: my code is integrated, single-form procedural action which uses all parts of itself.
Splitting code is importing defective OOP shit from sepples, trying to make "Object Modules" from raw .C files and "Link the modules".
Suffice to say, my single file+headers always compiles fast(DMC is way faster than GCC btw), it doesn't need such OOP mess as thousands of tiny .c/.o files

>>34
Several different files for different stuff came long before OOP.
It's about making ravioli code instead of spaghetti code.

>>35
OOP is not a limited to languages.
This approach is OOP applied to design.

>>34

Splitting your code has nothing to do with OOP. Do you know why stdio.h only declares the printf function and doesn't define it? Because otherwise we'd have to compile the printf function every time we wanted to make a program that used it. If you consider every other function that is declared in that header, you'd find yourself compiling way more than you need to.

>>37
stdio.h is not a real header, its an interface to default library.
>we'd have to compile the printf function every time
Its in the C runtime.

>>38

>stdio.h is not a real header, it's an interface to default library

So you're saying there is not an stdio.h located in /usr/include on Unix and in C:/MinGW/include on Windows?

Oh, but who needs stdio.h anyways, when you can always
extern int printf(const char* str, ...);
If all you need is some basic formatted output.

>when you can always
Thats the point stdio.h is an empty shell to C runtime without any useful code you can compile.

>>40

Exactly, that's the purpose of a header file. To give you access to resources without actually having the resources.