Sind die Namen der Include-Wächter der STD von C standardisiert?

MfG, EOutOfResources

Fritz und Susi!

Kla!

hustbaer schrieb:

Ne, nicht dass ich wüsste.

Wie wird dann überprüft, ob ein bestimmter Header schon geincluded (Partizip 1 von includen?) wurde?

Wie wird dann überprüft, ob ein bestimmter Header schon geincluded (Partizip 1 von includen?) wurde?

Man inkludiert ihn einfach und bei Bedarf springt der Include-Guard an (?)

PS: wenn du schon das deutsche Partizip bildest, dann bitte geincludet und nicht so ein Mischmasch.

Man inkludiert ihn einfach und bei Bedarf springt der Include-Guard an (?)

Und wenn ich eine Funktion oder eine Klasse nur dann anbiete, wenn ein bestimmter Header geincludet wurde?

• Die entsprechenden Funktonen in einen eigenen Header packen, welcher den abhängigen Header inkludiert und welchen der Nutzer nur bei Bedarf mit inkludiert. Sollten die Funktionen keine freien Funktionen sein, werden sie zu solchen gemacht.
  - oder -
• Wenn der Nutzer die Funktionen möchte, muss er ein Makro wie MEINE_LIB_USE_SPECIAL_FUNCTIONS definieren bevor er einen Bibliotheksheader inkludiert, nur bei Existens dieses Makros wird der abhängige Header inkludiert und die Funktionen zur Verfügung gestellt

Selbst wenn man die Namen der Inkludeguards wüsste, halte ich deinen Weg für schlecht. Ein zufällig inkludierter Header ändert dann plötzlich die Semantik des Programms bzw. es gibt keinen Bezug zwischen dem Header und der Bibliothek.
Als Nutzer muss ich dann womöglich bei dem Include einen Kommentar schreiben, dass ich das nur wegen LibX mache, ansonsten wird der eventuell mal später entfernt, weil ich daraus nichts nutze. Wenn die Library den braucht, muss sie ihn selbst inkludieren, wenn es optional ist, muss ich diese Entscheidung explizit treffen können (üblicherweise mit den oben genannten Möglichkeiten). Alles andere ist sehr wenig intuitiv (ich erinnere mich an SeppJs Kommentar zur Benutzbarkeit deiner Bibliothek).

Dazu kommt, dass es ausgesprochen schlechter Stil ist, wenn

#include "dein_header.hh"
#include <vector>

sich anders verhält als

#include <vector>
#include "dein_header.hh"

Jetzt stell dir mal vor, dein Header wird von anderen Headern eingebunden. Der erste bindet ihn ohne die spezielle Funktion ein, der zweite verlässt sich darauf, dass sie vorhanden ist. Werden beide hintereinander eingebunden, geht der zweite (wenn er nach dem ersten eingebunden wurde) kaputt.

Wer soll denn da durchfinden?

Sofern es keinen IOC++CC gibt, von dem ich noch nichts gehört habe oder du für ein neues Buch von Jürgen Wolf ("Programmierpraktik in C++"?) recherchierst, halte ich das für ein XY-Problem. Was ist es, das du wirklich vorhast?

Die zweite Methode spricht mich mehr an.
Vielen Dank

Die zweite Methode ist aber ganz schlimmer Unfug

ipsec schrieb:

PS: wenn du schon das deutsche Partizip bildest, dann bitte geincludet und nicht so ein Mischmasch.

Inkludifiziert

Jürgen Wolf

*würg*

seldon schrieb:

Was ist es, das du wirklich vorhast?

Einen (auf meinen Container spezifischen) Allokator anbieten, der die Speicherverwaltung von C unterstützt. Und den braucht man eben nur, wenn man zuvor mit malloc , calloc oder realloc gearbeitet hat.

Btw, "die Speicherverwaltung von C unterstützt" ist eine etwas vage Beschreibung.

Na dann hast du dir hoffentlich schon eine portable Methode herausgesucht, um zu unterscheiden, ob ein Pointer vom globalen ::operator new(), einer klassenspezifischen Überladung oder von malloc() reserviert wurde

Der Allokator befreit nur was er auch selbst (oder eine andere Instanz mit der selben Methode) reserviert hat.

CStoll schrieb:

Na dann hast du dir hoffentlich schon eine portable Methode herausgesucht, um zu unterscheiden, ob ein Pointer vom globalen ::operator new(), einer klassenspezifischen Überladung oder von malloc() reserviert wurde

Der Allokator befreit nur was er auch selbst reserviert hat.

Dann brauchst du dich doch auch nicht darum kümmern, wie andere Leute ihren Speicher angefordert haben.
(btw, nur wenn jemand die <cstdlib> eingebunden hat, heißt das noch lange nicht, daß er die malloc()-Familie verwendet)

Und warum soll ich nich einfach "dein_allocator.h" inkludieren dürfen, wenn ich deinen Allokator will?

Das darfst du ja. Wenn der Allokator aus "dein_allocator.h" eben nicht nur new und new[] unterstützen soll, dann schreibst du eben:

#include <cstdlib>
#include "dein_allocator.h"

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?

CStoll schrieb:

nur wenn jemand die <cstdlib> eingebunden hat, heißt das noch lange nicht, daß er die malloc()-Familie verwendet

Klar.

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

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?

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.

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

Machen das nicht die Allokatoren?

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)

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).

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

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

• 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.