3. Include-Wächter-Namen

Include-Wächter-Namen

  • ?

    Du willst das Verhalten einer Klasse von übersetzungseinheitsspezifischen Details abhängig machen? Ich sehe Linkeralbträume voraus.

    Was spricht dagegen, am Anfang des Allokatorheaders <cstdlib> einzubinden und die malloc-Variante unabhängig davon zu deklarieren, ob sie nachher benutzt wird?

    0
  • E

    seldon schrieb:

    Du willst das Verhalten einer Klasse von übersetzungseinheitsspezifischen Details abhängig machen?

    Was daran ist übersetzungseinheitsspezifisch?

    seldon schrieb:

    Was spricht dagegen, am Anfang des Allokatorheaders <cstdlib> einzubinden und die malloc-Variante unabhängig davon zu deklarieren, ob sie nachher benutzt wird?

    Ja, direkt eigentlich nichts, aber ist das nicht ein schlechter Stil?

    0
  • C

    EOutOfResources schrieb:

    CStoll schrieb:

    Dann brauchst du dich doch auch nicht darum kümmern, wie andere Leute ihren Speicher angefordert haben.

    Aha! Du denkst, dass ich den Allokator als Template implentiert habe und dass der Nutzer die Methode als Klassenobjekt übergibt, oder?

    Nicht unbedingt.
    Aber wenn du den Container schreibst, kannst du auch selber festlegen, wie er seinen Speicher anfordert - und die dazu passende Freigabefunktion verwenden. Da ist es egal, ob jemand anderes an anderer Stelle nun mit malloc(), new oder irgendwelchen systemspezifischen Funktionen seinen Speicher anfordert.

    0
  • E

    CStoll schrieb:

    Aber wenn du den Container schreibst, kannst du auch selber festlegen, wie er seinen Speicher anfordert

    Machen das nicht die Allokatoren?

    0
  • C

    EOutOfResources schrieb:

    CStoll schrieb:

    Aber wenn du den Container schreibst, kannst du auch selber festlegen, wie er seinen Speicher anfordert

    Machen das nicht die Allokatoren?

    Oder so - wichtig ist jedenfalls nur, daß die Speicherreservierung deines Allokators zu seiner eigenen Speicherfreigabe passt.

    EOutOfResources schrieb:

    seldon schrieb:

    Du willst das Verhalten einer Klasse von übersetzungseinheitsspezifischen Details abhängig machen?

    Was daran ist übersetzungseinheitsspezifisch?

    Klasse 1 verwendet nur deinen Header -> der Allokator nutzt new/delete.
    Klasse 2 bindet <cstdlib> und Klasse 2 ein -> der Allokator verwendet malloc()/free()
    Wenn jetzt beide zusammen in einem Programm genutzt werden, hast du inkonsistentes Verhalten - und spätestens wenn Klasse 1 versucht einen Container zu zerstören, den Klasse 2 erzeugt hat, kracht es. (wenn das überhaupt durch den Linker kommt)

    0
  • E

    CStoll schrieb:

    und spätestens wenn Klasse 1 versucht einen Container zu zerstören, den Klasse 2 erzeugt hat, kracht es. (wenn das überhaupt durch den Linker kommt)

    Der Allokator ist ein Template-Argument der Containers (wie bei der STD).

    0
  • S

    Du wirfst immer nur sinnlose fetzen hin die zusammen keinen Sinn ergeben.

    Generell klingt die Idee absolut grottig, aber es ist schwer zu sagen weil du ja keinen Ton verraetst.

    0
  • C

    Ich glaube, so langsam habe ich den Überblick verloren, was du überhaupt vorhast. Kannst du nochmal den Teil ab "der die Speicherverwaltung von C unterstützt" erläutern?

    (PS: Wenn ich mir deine letzten Threads so ansehe - du scheinst etwas zu kompliziert zu denken :D)

    0
  • E

    Mein eigener Container erwartet als zweites Template-Argument einen Allokator. Und ich implentiere zwei Standard-Allokatoren, new / delete und malloc / free . Es kann ein beliebiger Typ als Allokator an den Container übergeben werden (der die Bestimmungen erfüllt). Der Allokator, welcher malloc und free benutzt, ist natürlich nur benutzbar, wenn der Header <cstdlib> inkludiert wurde (logisch, oder?). Nun könnte ich folgende Schritte unternehmen:

    • Der Allokator ist nur definiert, wenn <cstdlib> bereits inkludiert wurde (meine eigentliche Idee).
    • Der Allokator ist immer definiert, denn <cstdlib> wird im Allokator-Header inkludiert.
    • Der Allokator ist nur definiert, wenn ein bestimmtes Makro definiert ist (z.B. LIB_USE_MALLOC) und dann wird dann ggf <cstdlib> inkludieret.
    0
  • C

    Ich wäre für Variante 2. Alternativ könntest du die Definition des malloc-Allokators auch in einen eigenen Header auslagern (inklusive des #include <cstdlib>), den der Nutzer bei Bedarf einbinden kann.

    0
  • C

    Hör mal das ist eigentlich kein Problem. Die zweite Variante ist üblich!
    Und niemand der deine Lib verwenden wird, hätte wahrscheinlich ein Problem das
    cstdlib eingebunden ist!

    0
  • S

    EOutOfResources schrieb:

    Der Allokator ist nur definiert, wenn <cstdlib> bereits inkludiert wurde (meine eigentliche Idee).

    Schwachsinn.

    Der Allokator ist immer definiert, denn <cstdlib> wird im Allokator-Header inkludiert.

    So macht es jeder.

    Der Allokator ist nur definiert, wenn ein bestimmtes Makro definiert ist (z.B. LIB_USE_MALLOC) und dann wird dann ggf <cstdlib> inkludieret.

    Macht nur sinn wenn ein #include<cstdlib> schwerwiegende folgen haette.
    Sowas macht man, wenn man fuer ein feature zB boost braucht. Dann benutzt man so ein define um das feature zu aktivieren wenn boost vorhanden ist.

    Dazu muss es sich aber schon um etwas richtig fettes handeln, sonst inkludet man einfach.

    0
  • E

    Der dritte Beitrag in diesem Thread ist zu beachten.

    0
  • Mod

    EOutOfResources schrieb:

    Der dritte Beitrag in diesem Thread ist zu beachten.

    😕 Sag doch mal ein paar mehr als ein paar Stichworte. Es ist extrem schwer, mit dir zu kommunizieren.

    0
  • S

    EOutOfResources schrieb:

    Der dritte Beitrag in diesem Thread ist zu beachten.

    Tatsächlich, vielen Dank!

    Frage am Rande: Ich dachte, auf Vector, List usw. könne ich auch zugreifen, wenn ich "stdlib.h" inkludiere statt "vector". Wieso funktioniert das nicht? Was liefert mir stdlib.h denn allein (ohne weitere includes)?

    Ja, in der Tat. Jetzt ist mir alles klar.

    In den ersten 3 Beitraege geht es um namespaces...

    0
  • E

    SeppJ schrieb:

    Sag doch mal ein paar mehr als ein paar Stichworte.

    Der Threadstarter ging davon aus, dass <cstdlib> standardmässig <vector> inkludiert. Wenn ich nun <cstdlib> immer inkludiere, kann auch gedacht werden, dass das Standard ist.

    0
  • S

    EOutOfResources schrieb:

    SeppJ schrieb:

    Sag doch mal ein paar mehr als ein paar Stichworte.

    Der Threadstarter ging davon aus, dass <cstdlib> standardmässig <vector> inkludiert. Wenn ich nun <cstdlib> immer inkludiere, kann auch gedacht werden, dass das Standard ist.

    Selten so einen Bloedsinn gehoert.

    0
  • N

    EOutOfResources schrieb:

    Wenn ich nun <cstdlib> immer inkludiere, kann auch gedacht werden, dass das Standard ist.

    Dass was Standard ist? Kannst du dich nicht genauer ausdrücken? Oder verwirrt mich tatsächlich nur deine Logik?

    0
  • E

    Vergesst es! Meine Frage wurde beantwortet.

    0

  • Ich weiss nicht, das sind doch alles keine Probleme.
    Wenn ich irgendwo <foo.h> inkludifiziere, und dann std::string verwende, und irgendwann geht's nimmer weil <foo.h> geändert wurde, dann schreib' ich halt mein #include <string> dazu, und die Sache ist gegessen.
    Über sowas macht man sich keinen Kopf.

    Stell sicher dass alle deine Header-Files "alleine" inkludiert werden können, und inkludier in Header-Files nicht lauter Unsinn den du nicht brauchst. Um den Rest kümmert sich der Anwender-Programmierer.

    0
Anmelden zum Antworten