enum - wer hat Recht? Compiler oder Buch ;)

[volkard]

würde nicht

m = Tage(m+1)

reichen?

[Fireflow[off]]

Das gibt imo kein Sinn so etwas zu machen bei enums. Denn man kann auch sowas machen:

enum myEnum { a, b = 123, c };

Also kann es auf jeden Fall generell nicht gehen.

Gruß

[volkard]

Fireflow[off] schrieb:

Das gibt imo kein Sinn so etwas zu machen bei enums. Denn man kann auch sowas machen:

enum myEnum { a, b = 123, c };

Also kann es auf jeden Fall generell nicht gehen.
Gruß

genau deswegen geht es nicht ohne cast. der cast ist meine botschaft an den compiler "vertrauen sie mir, ich weiß, was ich tue".

[groovemaster]

CompilerIstImRecht schrieb:

size_t für den Fall, dass enum größer ist als int

Was aber praktisch unwahrscheinlich ist.

It is implementation-defined which integral type is used as the underlying type for an enumeration except that the underlying type shall not be larger than int unless the value of an enumerator cannot fit in an int or unsigned int.

Was im konkreten Fall bedeuten würde, int kann nicht den Wert 6 darstellen. Und dann bringt size_t wohl auch nichts mehr.

[Vertexwahn]

Der Autor ist der Meinung das ein Destruktor die Überladung des Bit-Komplement-Operators darstellt - ich wunder mich gerade warum das Buch schon in der 6. Auflage erschienen ist - bei uns wurde es sogar in der C++ Vorlesung empfohlen...

[ROFLMAO!!!!!!!!!!!1]

LOL!

[Vertexwahn]

das geilste was ich bisher im Buch gesehen habe:

#include <iostream>
using namespace std;

template<int N>
class Fakultaet
{
public:
enum{value = N*Fakultaet<N-1>::value};
};

template<>
class Fakultaet<0>
{
public:
enum{value = 1};
};

int main()
{
const int x = Fakultaet<6>::value;
cout << x <<endl;
cin.get();
return 0;
}

[volkard]

Vertexwahn schrieb:

das geilste was ich bisher im Buch gesehen habe:

#include <iostream>
using namespace std;

template<int N>
class Fakultaet
{
public:
enum{value = N*Fakultaet<N-1>::value};
};

template<>
class Fakultaet<0>
{
public:
enum{value = 1};
};

int main()
{
const int x = Fakultaet<6>::value;
cout << x <<endl;
cin.get();
return 0;
}

wo ist daran das problem?
könnte breymann sein, der sich an metaprogrammierung wagt, obwohl das buch für anfänger ist.

[otze]

Was der Bauer nicht kennt, das frisst er net :p

[Bashar]

Vertexwahn schrieb:

Der Autor ist der Meinung das ein Destruktor die Überladung des Bit-Komplement-Operators darstellt

Kannst du mal das exakte Zitat angeben? Wenn er nämlich von Überladung des ~-Zeichens sprechen sollte, hätte er recht.

[Vertexwahn]

Überladung des ~-Zeichens sprechen sollte, hätte er recht.

tut er aber nicht - zu faul jetzt zu zitieren - er schreibt ausdrücklich der ~Operator wird überladen

[Any]

Vertexwahn schrieb:

Überladung des ~-Zeichens sprechen sollte, hätte er recht.

tut er aber nicht - zu faul jetzt zu zitieren - er schreibt ausdrücklich der ~Operator wird überladen

[Vertexwahn]

wo ist daran das problem?

nirgends, bis auf das fehlende template<>, das ich ergänzt habe und der zu kurz geratenen Erklärung

[groovemaster]

Vertexwahn schrieb:

er schreibt ausdrücklich der ~Operator wird überladen

Und dein Problem damit ist genau was? Ist doch vollkommen iO.

[Vertexwahn]

#include <iostream>
using namespace std;

class A
{
public:
	~A()
	{
		cout<<"ich bin die Ueberladung des ~-Zeichens"<<endl;
	}

	void operator~()
	{
		cout<<"ich bin der ueberladene ~-Operator"<<endl;
	}
};

int main()
{
	{
		A objekt;
		~objekt;
	}
	cin.get();
}

[groovemaster]

Das Beispiel steht so im Buch und der Autor spricht in diesem Zusammenhang von der Überladung des ~ Operators?

[Vertexwahn]

Das Beispiel steht nicht im Buch - der Autor spricht von der Überladung des ~ Operators - nicht von der Überladung des ~-Zeichens, aber das ist jetzt nur unsinnige Haarspalterei

[groovemaster]

Vertexwahn schrieb:

Das Beispiel steht nicht im Buch - der Autor spricht von der Überladung des ~ Operators - nicht von der Überladung des ~-Zeichens, aber das ist jetzt nur unsinnige Haarspalterei

Nein. Der Autor hat vollkommen Recht. ~ ist ein Operator, genauer gesagt ein unärer Operator. Siehe dazu ISO/IEC 14882:2003(E) - 5.3.1 Unary operators.

[Vertexwahn]

~ ist ein Operator, genauer gesagt ein unärer Operator.

das bestreitet auch niemand

[groovemaster]

Nunja, es kam aber so rüber, dass dich das stören würde.

Vertexwahn schrieb:

der Autor spricht von der Überladung des ~ Operators - nicht von der Überladung des ~-Zeichens