Compilerfehler künstlich erzeugen

MrMilk

Vielen Dank. Ich habe mich für die Lösung von pumuckl entschieden (es gab viele Google treffer ). Insgesamt ist mein Problem, dass ich nur nach std Programmieren darf und alles was dort nicht enthalten ist, bringt mir ärger.

Leider ist mir noch einzweiter Fall eingefallen, den ich gerne mit Comilerfehlern abdecken möchte. Aber hier habe ich die Vermutung, dass man es nicht lösen kann:

template <int Groesse>
class Parkhaus
{
    public:
        Parkplatz()
        {
        }

    protected:
        Parkplatz<Groesse> Parkeinheiten;

}

void main (int, char*)[]
{
    Parkhaus<30> p1;
    Parkhaus<34> p2;

    //Geld wird investiert, Parkhäuser werden zusammen geführt

    p1 = p1 + p2; 
}

An dieser Stelle sehe ich noch ein gewaltiges Problem. Und zwar hat p1 nach der Vereinigung der Parkhäuser nun die Kapazität von 64 Parkplätzen. Die Addition der beiden Parkhäuser ist kein Problem. Mit Macros kann ich das Maximum auswerten und ein neues Objekt zurück geben. Aber kann ich dieses Objekt überhaupt zuweisen? Die Typen stimmen ja nicht mehr überein.

Oder liege ich komplett neben der Spur? Wie immer bin ich über jeden Tipp dankbar.

Viele Grüße
MM

DStefan

Seltsames Beispiel. Und ein noch seltsameres main()

Spricht irgendwas dagegen, die Anzahl der Parkeinheiten einfach als Parameter an den Ctor von Parkhaus zu übergeben?

Stefan.

Bitsy

Ich denke mal, dass in diesem Fall die einfache Addition der Größen das Problem ist. So einfach liegt der Fall nämlich nicht. Effektiv entstehen ja nicht mehr Parkplätze. Also müßte im gleichen Zug Parkhaus 2 seine Parkplätze einbüßen - worauf es dann zur Bauruine wird, oder was auch immer. Es könnte sich sogar selbst abreißen - besser wäre es jedoch, dies von Parkhaus 1 aus zu machen.

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.