By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
454,382 Members | 1,688 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 454,382 IT Pros & Developers. It's quick & easy.

Ätzendes Naspace-Problem

P: n/a
Ich habe das ein Problem mit C++-Namespaces. Und zwar habe ich in einer
Library von mir einen Datentypen UWORD der folgendermaßen definiert ist:

namespace ns_OClasses
{
#if defined(_MSC_VER) && defined(_M_IX86)
...
typedef unsigned short UWORD; // <-------------
...
#else
#warning OClasses::UWORD
#endif
}

Diesen Typen benutze ich zum Teil in weiteren Headern in Klassen des
selben Namespaces, und man denkt sich erstmal, daß das kein weiteres
Problem wäre.
#Inkludiert man aber einen Header der einen Typen mit gleichem Namen
global deklariert, dann knallt wenn ich meine beiden Header darauf
inkludiere, denn der Compiler meint dann, daß der Typ doppeldeutig
ist. Hat mich echt gewundert, daß der lokalere Typ keinen Vorrang
vor dem globaleren hat wie es bei der Absufung von lokalen, Membern
und globalen Variablen analog ist; naja, ist auf jeden Fall so.
Das Problem habe ich in meinem Fall durch eine explizite Namespace
-Qualifikation umgangen, aber gelöst habe ich es nicht und mir fällt
auch keine wirkliche Lösung ein. Es besteht also immer die Möglich-
keit, daß man Bibltiotheken einbindet die in der gennannten Art mit
eigenen in Konflikt stehen und am schlimmsten sieht es aus, wenn ich
weder die eine noch die andere Bibliothek selbst geschrieben habe.
Gibt's da vielleicht irgendein C++-Merkmal das ich übersehen habe
und das dieses Problem löst? Oder ist vielleicht ein "stärkeres"
using für das künftige C++0x in Aussicht?
Nov 6 '05 #1
Share this Question
Share on Google+
1 Reply


P: n/a
Sorry; wrong newsgroup.
Should have been de.comp.lang.iso-c++.
Nov 6 '05 #2

This discussion thread is closed

Replies have been disabled for this discussion.