Re: On the use of namespaces to manage versions in C++
Re: On the use of namespaces to manage versions in C++
- Subject: Re: On the use of namespaces to manage versions in C++
- From: James Widman <email@hidden>
- Date: Tue, 6 Feb 2007 19:33:25 -0500
On Feb 3, 2007, at 7:31 PM, Steve Checkoway wrote:
On Feb 2, 2007, at 4:15 PM, James Widman wrote:
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
A good reason, but then Apple's gcc used #import when it was
deprecated in FSF gcc (a cursory glance at google tells me that it
might be undeprecated after a patch from Apple).
And yet, the reason I gave is still compelling. (:
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:
[snip]
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.
Why not just follow what cxxabi.h does? Everything is in namespace
__cxxabiv1 and then at the end of the header it has
namespace abi = __cxxabiv1;
If this ever changes, then older code will still link to the proper
version.
If you want to ensure that the users of your library can never re-
open your namespace in a version-independent way (and therefore, if
you also want to ensure that they can never (in a version-independent
way) declare partial or explicit specializations of your class
templates or explicit specializations of your function templates),
then I see nothing wrong with your suggestion. But the ADC article's
example did involve an explicit specialization of a library class
template from within user code.
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