C Library nicht im namespace std;

Shade Of Mine

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

rüdiger

du könntest die Header ändern

namespace std
{
  #include <string.h>
}

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

namespace std
{
    #include <cmath>
};

Shade Of Mine

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

Gerard

wenn du deine includest so macht

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

muss du nicht extra die compiler mit #ifdef abfragen

SideWinder

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

Marc++us

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

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

Daniel E.

/* 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.

Gerard

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

Shade Of Mine

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!