5. C Library nicht im namespace std;

C Library nicht im namespace std;

  • S

    Hallo Leute!

    Wie macht ihr es, wenn ich ein C++ Programm habt, dass ihr portabel gestalten wollt, doch ihr verwendet Funktionen aus der C Library.

    Theoretisch sollten diese ja im namespace std; zu finden sein... Doch viele Compiler (darunter VC++, DMC++,...) haben das nicht. Dort besteht ja zB die datei cstring aus:

    #ifndef bla
    #include "string.h"
    #endif

    Bisher hab ich mir so geholfen:

    #ifdef _MSC_VER || __DMC__
    #define CLib
    #else
    #define CLib std
    #endif

    Aber das kanns ja nicht sein, oder doch?

    Sagt mal, wie ihr das Problem loest...

    0
  • R

    du könntest die Header ändern

    namespace std
{
  #include <string.h>
}
    0
  • ?

    Ja das geht schon.
    Bei VC mache ich auch immer das hier:

    namespace std
{
    #include <cmath>
};
    0
  • S

    schoen und gut, aber ob ich jetzt
    namespace std {
    oder
    #define CLib

    schreib ist im Grunde auch schon egal...

    Wisst ihr echt keine andere Moeglichkeit als alle Compiler mit ifdef abzufragen?

    Sollte ich vielleicht dem User die Verantwortung darueber geben! Wenn sein Compiler die C Library nicht in std hat, dann muss er irgendein Makro definieren...?

    Ich kann mir kaum vorstellen, dass es da nicht irgendeine elegante Loesung gibt...

    0
  • G

    wenn du deine includest so macht

    namespace std
{
    #include <math.h>
    #include <time.h>
}

    muss du nicht extra die compiler mit #ifdef abfragen

    0
  • S

    Wenn du sowieso "using namespace std;" drunterschreibst -> einfach <iostream> includen bzw. eine leere Headerdatei <std> die nur folgenden Code beinhaltet:

    namespace std {}

    Wenn du "using namespace std;" nicht verwendest kannst du entweder dem User die Verantwortung übertragen (gar nix schreiben, oder namespace std rund um deine Header schreiben - erstes hilft niemandem, zweites hilft nur dir).

    Oder du kannst dem User deine Versionen der Header mitliefern (was imho dämlich ist).

    Also bleiben dir doch wieder nur die Makros...

    MfG SideWinder

    0
  • M

    Sides Lösung ist nicht gut, da man in eigenen Headern ja keine Namespaces öffnen soll... ich denke mal, daß die Idee von Dimah am sinnvollsten ist.

    Es ist aber denkbar, daß es dadurch Folgefehler gibt...

    0
  • S

    Naja, dann bleib ich wohl bei meiner Methode 😞

    Dimahs Methode gefaellt mir irgendwie nicht so gut.

    Denn angenommen meine Library wird in einem anderen Projekt verwendet. Meine Library macht dann zB

    namespace std {
    #include <cstdio>
    }

    Aber der User verwendet cstdio auch in seinem Programm. Er denkt aber nicht an Portierbarkeit und lebt damit, dass die C Library nicht im namespace std liegt. Er schreibt:

    #inlcude "my_lib.h"
    #include <cstdio>

    Nun haben wir den Salat -> printf und Konsorten ist im namespace std und der arme User bekommt Fehler die er nicht versteht...

    0
  • D
     

    /* C++-Header hier einbinden oder einen Namespace "std" von Hand kreiren: */
namespace std {}

namespace old {
#  include <cstdio>
#  include <cctype>
/* usw usf */
   using namespace std;
}

old::printf (BLA);

    Bleibt noch die Frage, was passiert, wenn man eine kaputte Bibliothek wie die des GCC 2.95.* hat, wo isspace als Macro implementiert ist (also `std::isspace' einen Compilerfehler verursacht). Bleibt also wieder nur ein `using namespace Bla'
    Wenn die Funktionen auch noch C-Linkage haben, dann wird es ganz lecker ... 😞 Und wenn der Compiler keine Namespaces kennt, wird das alles fast schon wieder elegant. 😉

    Das gehöhrt alles zur Sammlung: 0x3ff Tricks wie man in C++ doch programmieren kann. 😉

    0
  • G

    Original erstellt von Shade Of Mine:
    **Naja, dann bleib ich wohl bei meiner Methode 😞

    Dimahs Methode gefaellt mir irgendwie nicht so gut.

    Denn angenommen meine Library wird in einem anderen Projekt verwendet. Meine Library macht dann zB

    namespace std {
    #include <cstdio>
    }

    Aber der User verwendet cstdio auch in seinem Programm. Er denkt aber nicht an Portierbarkeit und lebt damit, dass die C Library nicht im namespace std liegt. Er schreibt:

    #inlcude "my_lib.h"
    #include <cstdio>

    Nun haben wir den Salat -> printf und Konsorten ist im namespace std und der arme User bekommt Fehler die er nicht versteht...**

    aus der boost lib:
    Boost.Compatibilty library

    // This file is automatically generated. Do not edit.
// ['../../../libs/compatibility/generate_cpp_c_headers.py']
// Mon Apr 16 15:16:00 2001 ('PST', 'PDT')

#ifndef __CTIME_HEADER
#define __CTIME_HEADER

#include <time.h>

namespace std {
  using ::size_t;
  using ::clock_t;
  using ::time_t;
  using ::tm;
  using ::asctime;
  using ::clock;
  using ::difftime;
  using ::localtime;
  using ::strftime;
  using ::ctime;
  using ::gmtime;
  using ::mktime;
  using ::time;
}

#endif // CTIME_HEADER

    das bedient beide seiten, außer das alles in globalen namespace leigt und in std, aber so gesehen ist das das kleiner übel

    ahja kläre mich mal auf was das mit der '#define CLib' ist

    0
  • S

    Original erstellt von Dimah:
    ahja kläre mich mal auf was das mit der '#define CLib' ist

    Tja, das ist wohl die primitiv-Variante 🙂
    Die Methode von boost ist besser, basiert aber auf der selben Idee wie mein CLib.

    Ich dachte mir, wenn die C-Library nicht im namespace std ist, dann ist sie im globalen Bereich. Also ::funktion() muss funktionieren. Sollte sie aber im namespace std sein, dann brauch ich ein std::funktion()

    Also muss ich std irgendwie Ein- und Ausschalten koennen 🙂
    Deshalb bekommen Compiler, die die C-Library nicht im namespace std haben ein
    #define CLib
    und die anderen ein
    #define CLib std

    Angewendet wirds dann total einfach:
    Clib::funktion()

    Aber die using-Methode ist natuerlich um laengen besser!

    0
Anmelden zum Antworten