#include <string> wird nicht erkannt

[nman]

Aeron24 schrieb:

Also, ich habe die extra eingefügt, da dass vollständige Projekt immer mal wieder strings in verschiedenen .cpp dateien nutzt . An dieser stelle überprüfe ich, ob mein string.h nicht bereits früher mal includiert worden ist. Und normalerweise funktioniert das auch ;-).

Ah, du hast also selbst eine string.h geschrieben? Dann packst du die Include-Guards an den Anfang und das Ende deiner eigenen string.h, nicht um das "#include "string.h". Include-Guards sind genau dafür gut, dass du dir beim includen keine Sorgen darum machen musst.

Aber selbst wenn ich ganz normal

#include <string>

oder auch

#include "string.h"

will es nicht funktionieren. Zumindest nicht in meiner neuen cpp. In der Main macht es keine Probleme.

Du hast hoffentlich um das #include nicht irgendwelche #ifdefs herum, oder?

[manni66]

Entscheidend ist, was der Compiler sagt, nicht das unterkringeln von Intellisense. Also, was sagt der Compiler?

[Aeron24]

Das ist nicht meine eigene string.h. Die string.h die ich includiere, ist bereits so vorgefertigt.
Und programmiert ist es halt genauso, wie in meinem ersten Beitrag.

#ifndef _string
#define _string
#include "string.h"
#endif

Und aufeinmal funktioniert es, obwohl ich rein gar nichts geändert habe. Vielleicht hat mir da VS2013 einen Streich gespielt. Sonst kann ich es gerade nicht wirklich nachvollziehen.

[nman]

Aeron24 schrieb:

Das ist nicht meine eigene string.h. Die string.h die ich includiere, ist bereits so vorgefertigt.

Und diese string.h im Projekt inkludiert <string>? Oder wie kommt der Compiler sonst daran heran?

Und programmiert ist es halt genauso, wie in meinem ersten Beitrag.

#ifndef _string
#define _string
#include "string.h"
#endif

So verwendet man Include-Guards aber nicht.

// mein_header.h
#ifndef MEIN_HEADER_H
#define MEIN_HEADER_H

/*
    furchtbar viel Code hier
*/

#endif MEIN_HEADER_H

// mein_programm.cpp
#include "mein_header.h"

int main() {
}

[daddy_felix]

Aeron24 schrieb:

Und aufeinmal funktioniert es, obwohl ich rein gar nichts geändert habe. Vielleicht hat mir da VS2013 einen Streich gespielt. Sonst kann ich es gerade nicht wirklich nachvollziehen.

Hast du wirklich kompiliert oder nur auf die "rote Unterkringelung" geachtet?

[Fuchs aus dem Wald]

Hat deine string Klasse auch den namensraum "std" ?
Sonst würde ich es mal mit

String_klasse meine_klasse;
meine_klasse::string

probieren!

[Fytch]

Fuchs aus dem Wald schrieb:

Hat deine string Klasse auch den namensraum "std" ?

gar nicht erlaubt. ausserdem kann ein typ keinen namensbereich haben. lediglich in einem sein kann er.

Fuchs aus dem Wald schrieb:

Sonst würde ich es mal mit

String_klasse meine_klasse;
meine_klasse::string

probieren!

dir ist schon bewusst dass dein listing unsinnig ist? meine_klasse ist eine instanz vom typ String_klasse (damit ist der bezeichner der instanz schonmal irreführend). damit instanz :: bezeichner sinn ergibt, muss der bezeichner von einem statischen member stammen. ergibt wiederum wenig sinn.

@te:
include-guards (also das konstrukt mit #ifdef etc.) gehört in den betroffenen header rein (das ist bei den stl-headern schon gemacht). d.h., dass du ganz gemütlich inkludieren kannst ohne etwas befürchten zu müssen.
dir scheint der unterschied zwischen "" und <> nicht so ganz klar zu sein:
bei "" wird im ordner nach der datei gesucht, indem auch die datei ist von der aus inkludiert wird.
bei <> wird in den standard-verzeichnissen (die du beim compiler definieren kannst) nachgeschaut.

wenn du also std::string aus der standard-bibliothek willst, dann schreibst du #include <string> OHNE .h und OHNE eigene include-guards.

[Fuchs aus dem Wald]

asfdlol schrieb:

[dir ist schon bewusst dass dein listing unsinnig ist? meine_klasse ist eine instanz vom typ String_klasse (damit ist der bezeichner der instanz schonmal irreführend). damit instanz :: bezeichner sinn ergibt, muss der bezeichner von einem statischen member stammen. ergibt wiederum wenig sinn.

Die ist schon klar das ich nur mal drauf hinweisen wollte, wie unsinnig es sein kann wenn man seine Klassen gleich den der Standard Bibliothek benennt?

[Fytch]

Fuchs aus dem Wald schrieb:

asfdlol schrieb:

[dir ist schon bewusst dass dein listing unsinnig ist? meine_klasse ist eine instanz vom typ String_klasse (damit ist der bezeichner der instanz schonmal irreführend). damit instanz :: bezeichner sinn ergibt, muss der bezeichner von einem statischen member stammen. ergibt wiederum wenig sinn.

Die ist schon klar das ich nur mal drauf hinweisen wollte, wie unsinnig es sein kann wenn man seine Klassen gleich den der Standard Bibliothek benennt?

ist nicht unsinnig.

[Fuchs aus dem Wald]

asfdlol schrieb:

ist nicht unsinnig.

[Aeron24]

Ich bedanke mich für die vielen und schnellen Antworten ;-). Und anscheinend werde ich mir wohl die Sache mit den Guards nochmal etwas genauer ansehen müssen :/, da happert es noch ein bisschen mit dem Verständnis.
Ich wünsche euch allen ein wunderschönes Wochenende und danke nochmals