Compilerfehler künstlich erzeugen

Registrierter Troll

MrMilk schrieb:

Leider ist mir noch einzweiter Fall eingefallen, den ich gerne mit Comilerfehlern abdecken möchte.

Dieser Code ist ein einziger Compilerfehler. Mission accomplished.

pumuckl schrieb:

Tobi_logoff schrieb:

Könntest du mir das erklären? Ich seh zur Loki version nur den Unterschied bool und int, in der eigentlichen Metafunktion.

Zum einen muss man in deinem Fall den Ausdruck zwischen dem struct-Namen und dem ::check() vergraben, da hätte zumindest noch ein Makro geholfen.
Zum zweiten hat das Loki-Beispiel den Vorteil, dass man eine Aussagekräftige Fehlermeldung dazupacken kann:
int main()
{
  S_StaticAssert<(1 < 2)>::check(); //kompiliert;
  S_StaticAssert<(1 > 2)>::check(); //kompiliert nicht; //line 30
  
  LOKI_STATIC_CHECK(1 < 2, argument_must_be_less_than_2);
  LOKI_STATIC_CHECK(1 > 2, argument_must_be_greater_than_2);
}
In function 'int main()':
Line 30: error: 'check' is not a member of 'S_StaticAssert<false>'

In function 'int main()':
Line 33: error: aggregate 'Loki::CompileTimeError<0> [b]ERROR_argument_must_be_greater_than_2[/b]' has incomplete type and cannot be defined
Ich sag ja nicht dass es völliger Blödsinn ist, der Ansatz ist der richtige. Es fehlen bloß ein paar Kleinigkeiten, und da es die schon fertig zu holen gibt, braucht man das Rad nicht neu erfinden.

Danke...
hätte schon gedacht ich sitze einem Fehler auf, den ich noch nicht gesehen habe.

MrMilk

DStefan schrieb:

Seltsames Beispiel. Und ein noch seltsameres main()

Uhh ja, da hast du recht.

Mir geht es nur darum, was passiert, wenn man etwas zuweisen möchte und der Templateparamter (heißt es so, bin mir da nicht sicher?) nicht der gleiche ist.

Ist dieses grundsätzlich nicht möglich oder muss man dann etwas bestimmtes machen...

Viele Grüße
MM

asc

ady schrieb:

Boost ist eklig fett.

Wo ist Boost bitteschön "fett"? Die Boost-Bibliotheken sind eine Sammlung von vielen einzelnen Bibliotheken, häufig verwendet man aber in einem Projekt davon nur eine Handvoll.

Bitsy

Dann will er wohl einen speziellen + Operator

pumuckl

MrMilk schrieb:

Mir geht es nur darum, was passiert, wenn man etwas zuweisen möchte und der Templateparamter (heißt es so, bin mir da nicht sicher?) nicht der gleiche ist.

Das hängt davon ab worum es geht. Wenn es sich z.B. um Vektoren (im Mathematischen Sinn) handelt und der Templateparameter die Zahl der Dimensionen angibt, dann kann man sie einfach nicht addieren. Wenns sich um etwas handelt, wo das Ergebnis einen neuen Templateparameter hat, muss man den entsprechend berechnen, bei deinen Parkhäusern würde ich (wenn auch unter Zahnschmerzen, weil das Beispiel haarsträubend ist) in etwa folgendes machen:

template <int n1, int n2>
parkhaus<n1+n2> operator+ (parkhaus<n1> const& lhs, parkhaus<n2> const& rhs)
{
  parkhaus<n1+n2> presult;
  presult.setAdresse( funnyAdressMix(lhs.getAdresse(), rhs.getAdresse() );
  presult.setParkPreis( (n1*lhs.getParkPreis() + n2*rhs.getParkPreis())/(n1+n2) );
  //und was auch immer die Semantik so einer sinnfreien Addition sein könnte ;)
};

Ich hab noch nie gesehen wie jemand Bauwerke addiert. Du?

MrMilk

Hallo Pumuckl,

na klar ist die Semantik nicht besonders gut gewählt. Eventuell wäre das Mischen von Flüssigkeiten besser gewesen Ist mit leider erst jetzt eingefallen.

Aber was du da programmierst hast, hatte ich auch vor. Für mich ist nun interessant, was passiert bei einer Zuweisung?

Muss ich dann immer ein neues Objekt deklarieren. Im Allgemeinen ist n1 + n2 ungleich n1.
Dann sofort ein Objekt Parkhaus<n1 + n2> neuespkh deklarieren? Das ganze nach p1 zuweisen sollte ja nicht klappen.

Viele Grüße
MM

pumuckl

MrMilk schrieb:

Dann sofort ein Objekt Parkhaus<n1 + n2> neuespkh deklarieren? Das ganze nach p1 zuweisen sollte ja nicht klappen.

Richtig. Templateparameter sind eben keine Eigenschaft, in der sich Objekte einer "Sorte" (d.h. eines Typs, einer Klasse) unterscheiden, sondern sie unterscheiden unterschiedliche "Sorten" (Typen/Klassen) voneinander.
Ob man jetzt Member oder Templateparameter nimmt ist eine Designfrage, die davon abhängt, was man damit modellieren will.

MrMilk

Super vielen Dank

Viele Grüße (und eine guten Mittag)
MM

pumuckl schrieb:

MrMilk schrieb:

Dann sofort ein Objekt Parkhaus<n1 + n2> neuespkh deklarieren? Das ganze nach p1 zuweisen sollte ja nicht klappen.

Richtig. Templateparameter sind eben keine Eigenschaft, in der sich Objekte einer "Sorte" (d.h. eines Typs, einer Klasse) unterscheiden, sondern sie unterscheiden unterschiedliche "Sorten" (Typen/Klassen) voneinander.
Ob man jetzt Member oder Templateparameter nimmt ist eine Designfrage, die davon abhängt, was man damit modellieren will.

Eigentlich ist die Entscheidung doch ganz einfach: will/muss ich es zur Laufzeit beeinflussen können? => Member

Nexus

pumuckl schrieb:

Zum zweiten hat das Loki-Beispiel den Vorteil, dass man eine Aussagekräftige Fehlermeldung dazupacken kann:

Recht coole Sache, sowas in der Art habe ich noch nie gesehen. Ist natürlich schon noch nicht ganz so Luxus wie static_assert , aber ein netter Workaround.

Hm, static_assert ist wohl eine der kleineren Neuerungen, auf die ich mich am meisten freue.

camper

BOOST_MPL_ASSERT_MSG hat eine vergleichbare Funktion, dort wird auch noch eine Typenliste in die Fehlermeldung eingearbeitet, was Sinn macht, da statische Asserts sich im häufig um irgendwelche Eigenschaften von Typen drehen.