3. [Erledigt] _MAX_FNAME bei C++0x

[Erledigt] _MAX_FNAME bei C++0x

  • M

    Hallo Leute

    Ich steh leider mal wieder vor einem Problem was ich nicht ganz verstehe. Und zwar hab ich, da ich es letztens im Forum gelesen habe, denn g++ von Version 3.4.5 auf 4.5.0 upgedated. Ich habe folgenden Code:

    #include <cstdlib>
using namespace std;

int main() {
   char cFName[ _MAX_PATH ];
   cout << cFName << endl;
   return 0;
}

    Wenn ich das ganze unter CodeBlocks übersetzte ohne weitere Parameter funktioniert alles. Wenn ich aber den hacken für "C++0x ISO" Option (-std=c++0x) setzte bekomme ich folgende Fehlermeldung:

    5 | error: '_MAX_FNAME' was not declared in this scope

    Ich hab das ganze schon debugged und weiß das es an der Definierung des Symbols "__STRICT_ANSI__" liegt. Und zwar wird wenn das Symbol defniert ist wird kein _MAX_PATH defniert. Gibt es jetzt dann eine andere Möglichkeit auser ein "undefined __STRICT_ANSI__" vor den Include zu schreiben? Oder existiert jetzt derweilen eine Funktion, hab leider bei Google und hier im Forum nichts gefunden.

    Mfg marco

    0
  • ?

    _MAX_PATH habe ich noch nie gesehen. Es gibt im Standard (von C geerbt) ein Makro FILENAME_MAX; dafür brauchst du <cstdio>.

    0
  • M

    seldon schrieb:

    _MAX_PATH habe ich noch nie gesehen. Es gibt im Standard (von C geerbt) ein Makro FILENAME_MAX; dafür brauchst du <cstdio>.

    Vielen Dank aber das hilft mir nur zum Teil. Und zwar gibt ea der Stelle genau 4 Defines:
    _MAX_PATH
    _MAX_FNAME
    _MAX_DIR
    _MAX_EXT

    Werden häufig für _splitpath benutzt, welches er jetzt auch nicht mehr findet wie ich es grad sehe 😞

    Bin mal nochmal Google befragen.

    Mfg marco

    0
  • ?

    Das sind scheinbar Microsoft-Erweiterungen (und _splitpath ist überholt durch _splitpath_s). Eventuell gibt's ein #define, um das DOS/WinApi wieder reinzuholen, oder vielleicht hast du mit windows.h, dos.h oder conio.h Glück.

    Ansonsten definiert der gcc __STRICT_ANSI__ laut manpage, wenn -ansi als Parameter übergeben wurde, also -std=c++98. Du könntest es auch mal mit -std=gnu++0x statt -std=c++0x versuchen.

    0
  • U

    #include <windows.h>
    !?
    klingt zumindest so, als ob es api-zeugs wäre und du das include vergessen hättest...

    <ot>
    boar... drecks flood-prtection... als ob da 5sekunden post-verbot nicht reichen würden -.-'
    </ot>

    0
  • M

    unskilled schrieb:

    #include <windows.h>
    !?
    klingt zumindest so, als ob es api-zeugs wäre und du das include vergessen hättest...

    <ot>
    boar... drecks flood-prtection... als ob da 5sekunden post-verbot nicht reichen würden -.-'
    </ot>

    Nein windows.h ist es nicht, das ganze ist _nur_ in der stdlib.h bzw cstdlib definiert, habs komplette include-Verzeichnis danach suchen lassen.

    Und _splithpath_s finde ich keiner meiner Header 😞 ich hab grad bischen bei Google geschaut und da hab ich eine tchar.h mit den entsprechenden header gefunden aber die sind vom w64 MinGW-Projekt. Werd mal dies runterladen und schauen wies funktionerit.

    Das mit den gnu++0x parameter werd ich mal noch probieren, muss nur schauen ob ichs per Hand oder per CodeBlocks aktiviere kann.

    Mfg marco

    0
  • ?

    Ich habe von _MAX_PATH auch noch nie etwas gehört. Es scheint irgendeine Erweiterung zu sein, die Du per -std=c++0x ausschaltest. Du kannst es ja mal mit -std=gnu++0x probieren. Wenn Du die Option nicht mit angibst, arbeitet der GCC auch im gnu++98 -Modus und nicht im c++98 -Modus.

    0
  • M

    Hallo

    So ich hab nochmal nachgeschaut, es war nicht der Paremter "-std=c++0x" sonder der Parameter "-ansi". Hab ihn nur nicht gefunden da der Text in CodeBlocks so lang war: "In C mode, support all ISO C90 programs. In C++ mode, remove GNU extensions that conflict with ISO C++ [-ansi]". Deaktiviert und ich konnte es wieder übersetzten.

    Jetzt aber die Frage woher bekomme ich nen MinGW der auch _splitpath_s versteht?

    Und an dennen die die Funktion benutzten woher nehmt ihr eure Initialwerte für die Varaiblen?

    Mfg marco

    0

  • _MAX_PATH is Windows/MSVC spezifisch. Hat mit Standard C++ nix zu tun.

    0
  • M

    hustbaer schrieb:

    _MAX_PATH is Windows/MSVC spezifisch. Hat mit Standard C++ nix zu tun.

    Ja stimmt, da hab ich mich auch verschrieben sollte eigentlich _MAX_FNAME heißen. Da ich mit meinen MinGW g++ 4.5 keine Version von _splitpath_s gefunden hab, hab ich mir jetzt den MinGW64 geholt der hat eine dieser Formen drin. Aber könnte mir bitte einer mal einen Beispielaufruf und die Includes für _xplitpath_s posten, bring des irgendwie nicht zum laufen.

    Das weiteste wie ich gekommen bin ist, das er dann zwar die Definition findet aber der Linker es nicht linken kann und mit dieser Fehlermeldung abbricht:

    undefined reference to `__imp__splitpath_s'

    Mfg marco

    0
  • K

    Jetzt aber die Frage woher bekomme ich nen MinGW der auch _splitpath_s versteht?

    Wie du siehst, macht die Verwendung von Compiler spezifischen Sachen durchaus Probleme. Benutze sie nicht!

    int main() {
   char cFName[ _MAX_PATH ];
   cout << cFName << endl;
   return 0;
}

    ...
    Und an dennen die die Funktion benutzten woher nehmt ihr eure Initialwerte für die Varaiblen?

    Wie waere es, wenn du einfach die Standardmittel von C++ benutzt. In diesem Fall ist std::string zu empfehlen.

    0
  • M

    knivil schrieb:

    ...
    Wie waere es, wenn du einfach die Standardmittel von C++ benutzt. In diesem Fall ist std::string zu empfehlen.

    Würde ich ja gern wenn du mir noch sagst welche splitpath-Funktion ich dann da aufrufe. Wichtig es sollte Betriebssystem-unabhängig bleiben, weil selber nach dem letzten / oder \ suchen und alles dahinter ist die Datei, auf die Idee bin ich auch schon gekommen. Aber beim Laufwerk-Suche wirds dann schon schwerer.

    Mfg marco

    0
  • B

    Dann schau dir doch mal boost::filesystem an.

    0
  • ?

    Betriebssystemunabhängig wirst du mit splitpath sowieso nicht, egal in welcher Variante - und wenn du dir um Laufwerksbuchstaben Gedanken machen musst, wird das damit eh nichts, denn außerhalb von Windows gibt es die höchst selten.

    0
  • M

    @Braunstein: Danke werd ich mir mal anschauen

    @seldon: Okay geb ich dir recht, hab nochmal nachgeschaut weil ich mir sicher war die Funktion gibt es auch unter Linux. Werde dann woll doch bei boost bleiben.

    Danke nochmal an alle.

    Mfg Marco

    0
  • K

    Würde ich ja gern wenn du mir noch sagst welche splitpath-Funktion ich dann da aufrufe.

    So kompliziert kann es nun auch nicht sein, die Funktion fuer std::string selbst zu implementieren.

    0
Anmelden zum Antworten