Two alined_storage classes in the CVS
With the recent addition of TR1 aligned_storage to Boost.TT, there's a nasty collision with a class named exactly the same and living in boost/aligned_storage.hpp (this class is a spin-off from Boost.Variant, IIRC.) I think this has been discussed some months ago, but with no resolution to the best of my knowledge. Apart from the symbol clash, these two classes do not provide the same functionality, so I guess it'd be sensible to rename the older aligned_storage to something else. Ideas? Joaquín M López Muñoz Telefónica, Invstigación y Desarrollo
Since these are in different namespaces, can this not be just ignored? Is it worth spending any time on? Robert Ramey JOAQUIN LOPEZ MU?Z wrote:
With the recent addition of TR1 aligned_storage to Boost.TT, there's a nasty collision with a class named exactly the same and living in boost/aligned_storage.hpp (this class is a spin-off from Boost.Variant, IIRC.) I think this has been discussed some months ago, but with no resolution to the best of my knowledge.
Apart from the symbol clash, these two classes do not provide the same functionality, so I guess it'd be sensible to rename the older aligned_storage to something else. Ideas?
Joaquín M López Muñoz Telefónica, Invstigación y Desarrollo
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Hello Robert, RR> Since these are in different namespaces, can this not be just RR> ignored? Is it worth spending any time on? RR> RR> Robert Ramey Maybe I have something missed, but in my boost sources both aligned_storages are in the same namespace. And indeed I had to remove the new one in order to my code with boost::variant could be compiled. Revisions of aligned_storage.hpp files that I have are: boost/aligned_storage.hpp 1.8 boost/type_traits/aligned_storage.hpp 1.2 RR> RR> JOAQUIN LOPEZ MU?Z wrote: RR>
With the recent addition of TR1 aligned_storage to Boost.TT, there's a nasty collision with a class named exactly the same and living in boost/aligned_storage.hpp (this class is a spin-off from Boost.Variant, IIRC.) I think this has been discussed some months ago, but with no resolution to the best of my knowledge. Apart from the symbol clash, these two classes do not provide the same functionality, so I guess it'd be sensible to rename the older aligned_storage to something else. Ideas?
JoaquМn M LСpez MuЯoz TelefСnica, InvstigaciСn y Desarrollo _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost RR> _______________________________________________ RR> Unsubscribe & other changes: RR> http://lists.boost.org/mailman/listinfo.cgi/boost
-- Vyacheslav E. Andrejev System Architect, Excelsior, LLC
With the recent addition of TR1 aligned_storage to Boost.TT, there's a nasty collision with a class named exactly the same and living in boost/aligned_storage.hpp (this class is a spin-off from Boost.Variant, IIRC.) I think this has been discussed some months ago, but with no resolution to the best of my knowledge.
Apart from the symbol clash, these two classes do not provide the same functionality, so I guess it'd be sensible to rename the older aligned_storage to something else. Ideas?
Darn, normally I'd say that the older version has priority over the name, however in this case since aligned_storage is part of the TR, I'm leaning toward agreeing that we should rename the old version. I notice that the old version isn't documented anywhere, but I also note from the mailing list that at least one person is using it in his/her own code. So I'm not sure how best to handle this, Eric, any thoughts? John.
John Maddock ha escrito:
With the recent addition of TR1 aligned_storage to Boost.TT, there's a nasty collision with a class named exactly the same and living in boost/aligned_storage.hpp (this class is a spin-off from Boost.Variant, IIRC.) I think this has been discussed some months ago, but with no resolution to the best of my knowledge.
Apart from the symbol clash, these two classes do not provide the same functionality, so I guess it'd be sensible to rename the older aligned_storage to something else. Ideas?
Darn, normally I'd say that the older version has priority over the name, however in this case since aligned_storage is part of the TR, I'm leaning toward agreeing that we should rename the old version.
I think this is the only reasonable option.
I notice that the old version isn't documented anywhere, but I also note from the mailing list that at least one person is using it in his/her own code.
I did a grep and it is used by multi_index, serialization and variant. Boost.Optional uses and internal version cut&pasted from boost/aligned_storage.hpp, and Boost.Python uses a class named with the same name (differente namespace) but with a seemingly different implementation tecnhique. So, apparently there's only three libraries to be updated. As for the name, I like the "aligned_buffer" proposal by Jonathan. HTH Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
So I'm not sure how best to handle this, Eric, any thoughts? John.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Joaquín Mª López Muñoz wrote:
John Maddock ha escrito:
With the recent addition of TR1 aligned_storage to Boost.TT, there's a nasty collision with a class named exactly the same and living in boost/aligned_storage.hpp (this class is a spin-off from Boost.Variant, IIRC.) I think this has been discussed some months ago, but with no resolution to the best of my knowledge.
Apart from the symbol clash, these two classes do not provide the same functionality, so I guess it'd be sensible to rename the older aligned_storage to something else. Ideas?
Darn, normally I'd say that the older version has priority over the name, however in this case since aligned_storage is part of the TR, I'm leaning toward agreeing that we should rename the old version.
I think this is the only reasonable option.
In my opinion, the older version needs to be removed entirely and the libraries should be updated to use the TR1 version of aligned_storage.
Peter Dimov ha escrito:
Joaquín Mª López Muñoz wrote:
John Maddock ha escrito:
With the recent addition of TR1 aligned_storage to Boost.TT, there's a nasty collision with a class named exactly the same and living in boost/aligned_storage.hpp (this class is a spin-off from Boost.Variant, IIRC.) I think this has been discussed some months ago, but with no resolution to the best of my knowledge.
Apart from the symbol clash, these two classes do not provide the same functionality, so I guess it'd be sensible to rename the older aligned_storage to something else. Ideas?
Darn, normally I'd say that the older version has priority over the name, however in this case since aligned_storage is part of the TR, I'm leaning toward agreeing that we should rename the old version.
I think this is the only reasonable option.
In my opinion, the older version needs to be removed entirely and the libraries should be updated to use the TR1 version of aligned_storage.
The problem is that the older aligned_storage provides a different functionality than the std::tr1 (it gives you uninitialized aligned stack space.) It is a mere accident that both classes are named the same IMHO. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Joaquín Mª López Muñoz wrote:
Peter Dimov ha escrito:
In my opinion, the older version needs to be removed entirely and the libraries should be updated to use the TR1 version of aligned_storage.
The problem is that the older aligned_storage provides a different functionality than the std::tr1 (it gives you uninitialized aligned stack space.) It is a mere accident that both classes are named the same IMHO.
I think that the two classes provide the same functionality (albeit in a slightly different way) and I don't believe that this is accidental.
"Peter Dimov" <pdimov@mmltd.net> writes:
Joaquín Mª López Muñoz wrote:
John Maddock ha escrito:
With the recent addition of TR1 aligned_storage to Boost.TT, there's a nasty collision with a class named exactly the same and living in boost/aligned_storage.hpp (this class is a spin-off from Boost.Variant, IIRC.) I think this has been discussed some months ago, but with no resolution to the best of my knowledge.
Apart from the symbol clash, these two classes do not provide the same functionality, so I guess it'd be sensible to rename the older aligned_storage to something else. Ideas?
Darn, normally I'd say that the older version has priority over the name, however in this case since aligned_storage is part of the TR, I'm leaning toward agreeing that we should rename the old version.
I think this is the only reasonable option.
In my opinion, the older version needs to be removed entirely and the libraries should be updated to use the TR1 version of aligned_storage.
There was a good reason Boost.Python was using a different implementation, so that could be a very bad idea. Unfortunately I don't remember the details. -- Dave Abrahams Boost Consulting www.boost-consulting.com
In my opinion, the older version needs to be removed entirely and the libraries should be updated to use the TR1 version of aligned_storage.
I wondered about that as well, in fact I started testing a possible fix, only to realise half way through that it's more or less trivial to patch the "old" aligned_storage to make it conform to the TR (just needs a ::type typedef member), I'm testing that now, but expect to see the new version disappear from cvs shortly. John.
John Maddock wrote:
In my opinion, the older version needs to be removed entirely and the libraries should be updated to use the TR1 version of aligned_storage.
I wondered about that as well, in fact I started testing a possible fix, only to realise half way through that it's more or less trivial to patch the "old" aligned_storage to make it conform to the TR (just needs a ::type typedef member), I'm testing that now, but expect to see the new version disappear from cvs shortly.
This would indeed solve our short-term problem, but by promoting a nonstandard aligned_storage, aren't we doing our users a disservice by making it harder for them to migrate to the "real" aligned_storage?
This would indeed solve our short-term problem, but by promoting a nonstandard aligned_storage, aren't we doing our users a disservice by making it harder for them to migrate to the "real" aligned_storage?
It's non-standard only in the sense that it supports some "extra" features that aren't present in the TR, I admit users could end up using these features inadvertently though. For now I just want to get the tests running again. I guess in the long run I agree with you, but I'd like to hear from the authors of aligned_storage: it wouldn't be fair to more or less unilaterally deprecate their work! John.
John Maddock wrote:
Darn, normally I'd say that the older version has priority over the name, however in this case since aligned_storage is part of the TR, I'm leaning toward agreeing that we should rename the old version.
My question may be naive, because I have no idea what the TR is, but what would be the problem with putting all of the TR code in a boost::tr namespace? Are there pieces of the tr already in use? -Jason
Jason Hise wrote:
My question may be naive, because I have no idea what the TR is, but what would be the problem with putting all of the TR code in a boost::tr namespace? Are there pieces of the tr already in use?
The latest(?) draft of the C++ Standard Library Technical Report is here: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1745.pdf See the discussion on TR1 => http://lists.boost.org/MailArchives/boost/msg74424.php Some of tr1:: already is in boost:: (and originated there) just with slightly differing details which is the point of the tr1:: versions being worked upon in the CVS. Kevin -- | Kevin Wheatley, Cinesite (Europe) Ltd | Nobody thinks this | | Senior Technology | My employer for certain | | And Network Systems Architect | Not even myself |
participants (10)
-
David Abrahams -
Jason Hise -
JOAQUIN LOPEZ MU?Z -
Joaquín Mª López Muñoz
-
John Maddock -
Jonathan Turkanis -
Kevin Wheatley -
Peter Dimov -
Robert Ramey -
Vyacheslav E. Andrejev