On the use of namespaces to manage versions in C++
On the use of namespaces to manage versions in C++
- Subject: On the use of namespaces to manage versions in C++
- From: James Widman <email@hidden>
- Date: Fri, 2 Feb 2007 19:15:29 -0500
Hi all,
I'm not sure if this is the right list, but it seems like subscribers
here would likely be on the ADC news list, and I want speak up about
one of the C++ "tips & tricks" listed in today's edition (ADC News
#475). See here:
http://developer.apple.com/technotes/tn2007/tn2185.html#TNTAG14
I question the legitimacy of encouraging developers to use the strong
namespace extension for two reasons:
1. The GCC documentation recommends against it; see here:
http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Strong-
Using.html#Strong-Using
2. We can get the same desired effects (namely, source compatibility
while changing the mangled names of library symbols for each version)
using only features from ISO C++98. Consider the following modified
version of the example from the above article:
namespace Acme{
const unsigned version = 0x010203f0;
// version 1.2.3 (following the tradition of sys.hexversion in
Python)
template <class T, unsigned vers=version>
class V; // One need not (and should not) specify the last argument
// explicitly. Also, forward-declare the primary template
// but never define it.
template <class T> class V<T>{};
template<unsigned vers=version> class A_;
template<> class A_<> {};
typedef A_<> A; // Ok, now we can refer to this plain class with a
// plain type name (instead of a template-id)
namespace _1 {
template <class T> void func1(T&) {}
template <class T> void func2(T&) {}
void g( A );
}
// Make versioned functions visible to ADL:
using _1::func1;
using _1::func2;
using _1::g;
}
// User code:
// Acme client
struct MyType {};
namespace Acme {
template <> class V<MyType> // Ok, this just works.
{};
} // Acme
int main() {
Acme::V<int> v_int;
func1(v_int);
Acme::func2(v_int);
Acme::V<MyType> v_mytype;
func1(v_mytype);
Acme::func2(v_mytype);
Acme::A a;
g(a);
return 0;
}
Yes, it's more verbose on the library side, but for that minor cost
you'll be able (or at least one step closer to being able) to use the
code with any compiler that conforms to the ISO C++ Standard -- and
not just GCC and the limited set of vendors that mimic GCC in this
way. And if you're writing a library interface, odds are that's not
something to be taken lightly.
James Widman
--
Gimpel Software
http://gimpel.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden