Unikanie "magic numbers", enum class, plain enum i const.

Mam prosty program i chcę żeby było jasne, w którym indeksie co się znajduję. W internecie zwykły enum jest przedstawiany jako zło. Czy zawsze powinni się forsować enum class?
Przykładowy kod:

enum Figury1		// 1.
{
	krol = 0,
	krolowa = 1
};

enum class Figury2	// 2.
{
	krol = 0,
	krolowa = 1
};
class Foo {};

int main()
{
	Foo tab[2];
	tab[Figury1::krol] = Foo();								 // 1.
	tab[static_cast<int>(Figury2::krolowa)] = Foo();   // 2.
}

Drugi problem to stałe, w jaki sposób je definiować, żeby nie zabierały niepotrzebnie miejsca na stosie?
Przykładowy kod:

class Foo
{
private:
	const int y = 213;				// 1.
	static const int z = 213;		// 2.
	void initialize()
	{
		const int x = 213;			// 3.
		static const int q = 213;	// 4.
		// jakis kod w którym jest 213
	}
public:
	Foo()
	{
		for (int i = 0; i < 1000; ++i)
			initialize();
	}
};

int main()
{
	Foo tab[10000];
}

enum class jest lepsze bo:

• przestrzeń nazw jest pod większą kontrolą, stare enumy często zamykano w klasie, albo stosowano jakieś prefiksy, by objeść ten problem
• mają silniejsze typowanie, nie ma cichej konwersji z/do typu całkowitego
• można stosować forward declaration zmniejszając narzuty budowania podczas modyfikowania możliwych wartości enum class

W C i C++ obowiązuje zasada "AS IF" (tak jak). Efekt jest taki, że najczęściej stałe nie mają fizycznej reprezentacji w pamięci (na stosie), ale są częścią kodu maszynowego (tak jakbyś pisał je jako magic numbers).
Zresztą C++ jest projektowany z zasadą "zero cost" - jeśli coś jest niepotrzebne to kompilator to usuwa.

leto napisał(a):]

Drugi problem to stałe, w jaki sposób je definiować, żeby nie zabierały niepotrzebnie miejsca na stosie?

Najlepiej/najczytelniej deklarowac stale jako stale (constexpr), a nie jako niezmienne wartosci ktore nie musza byc znane w trakcie kompilacji (const).