c++.de :: C Library nicht im namespace std;

Shade Of Mine Moderator 18:09:00 08.08.2002 Titel:

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 Moderator 18:21:00 08.08.2002 Titel:

du könntest die Header ändern

C++:
namespace std { #include <string.h> }

deleted_2013_01_05 Mitglied 19:14:00 08.08.2002 Titel:

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

C++:
namespace std { #include <cmath> };

Shade Of Mine Moderator 19:56:00 08.08.2002 Titel:

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 Mitglied 20:14:00 08.08.2002 Titel:

wenn du deine includest so macht

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

muss du nicht extra die compiler mit #ifdef abfragen

SideWinder Moderator 20:15:00 08.08.2002 Titel:

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

C++:
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 Moderator(S) 20:18:00 08.08.2002 Titel:

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 Moderator 20:26:00 08.08.2002 Titel:

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. Mitglied 20:29:00 08.08.2002 Titel:

C++:
1 2 3 4 5 6 7 8 9 10 11	/* 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 Mitglied 17:34:00 20.08.2002 Titel:

Zitat:

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

C++:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26	// 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