Namespace policy: putting names in boost::detail
A GSoC student and I are currently converting a library to use the namespace boost::simd. Some of the implementation details of the library are not simd-specific, and we would like to use them in some other libraries that extend boost::simd. Would it be ok to put them in the boost::detail namespace, or is that considered as bad as putting stuff in the boost namespace? We need to inject overloads and specializations into a unique namespace for boost.simd and NT2, so we could need two names, like boost::detail::dispatch and boost::detail::specialize.
Mathias Gaunard-2 wrote:
A GSoC student and I are currently converting a library to use the namespace boost::simd.
Some of the implementation details of the library are not simd-specific, and we would like to use them in some other libraries that extend boost::simd.
Would it be ok to put them in the boost::detail namespace, or is that considered as bad as putting stuff in the boost namespace?
We need to inject overloads and specializations into a unique namespace for boost.simd and NT2, so we could need two names, like boost::detail::dispatch and boost::detail::specialize.
What kind of dispatch and specializations do you need to share that they can not be on simd? Maybe some more context will help. Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/Namespace-policy-putting-names-in-boost-d... Sent from the Boost - Dev mailing list archive at Nabble.com.
On 04/07/2011 18:53, Vicente Botet wrote:
Mathias Gaunard-2 wrote:
A GSoC student and I are currently converting a library to use the namespace boost::simd.
Some of the implementation details of the library are not simd-specific, and we would like to use them in some other libraries that extend boost::simd.
Would it be ok to put them in the boost::detail namespace, or is that considered as bad as putting stuff in the boost namespace?
We need to inject overloads and specializations into a unique namespace for boost.simd and NT2, so we could need two names, like boost::detail::dispatch and boost::detail::specialize.
What kind of dispatch and specializations do you need to share that they can not be on simd? Maybe some more context will help.
NT2 and Boost.SIMD use a fully externalizable function dispatching and specialization mechanism. In NT2, we have some functions, like plus, multiplies, etc. that work on a variety of types: scalars, simd packs, expression trees, tables, matrices, polynoms, etc. Each function can thus be specialized many times, some times just for particular scalars or simd pack types for example. All specializations of all functions are provided as specializations of the same class. The dispatching uses overloading to select the best specialization available using partial ordering. It already relies on ADL tricks so I don't think we can be very flexible with regards to namespaces. Boost.SIMD will only contain the scalar and simd packs specializations, and we would need to add the other versions of NT2. Actually, I think it might be better to put all that in the namespace boost::detail::dispatch (or even boost::dispatch), as some kind of "pending" library
Mathias Gaunard-2 wrote:
On 04/07/2011 18:53, Vicente Botet wrote:
Mathias Gaunard-2 wrote:
A GSoC student and I are currently converting a library to use the namespace boost::simd.
Some of the implementation details of the library are not simd-specific, and we would like to use them in some other libraries that extend boost::simd.
Would it be ok to put them in the boost::detail namespace, or is that considered as bad as putting stuff in the boost namespace?
We need to inject overloads and specializations into a unique namespace for boost.simd and NT2, so we could need two names, like boost::detail::dispatch and boost::detail::specialize.
What kind of dispatch and specializations do you need to share that they can not be on simd? Maybe some more context will help.
NT2 and Boost.SIMD use a fully externalizable function dispatching and specialization mechanism.
In NT2, we have some functions, like plus, multiplies, etc. that work on a variety of types: scalars, simd packs, expression trees, tables, matrices, polynoms, etc. Each function can thus be specialized many times, some times just for particular scalars or simd pack types for example. All specializations of all functions are provided as specializations of the same class.
The dispatching uses overloading to select the best specialization available using partial ordering. It already relies on ADL tricks so I don't think we can be very flexible with regards to namespaces.
Boost.SIMD will only contain the scalar and simd packs specializations, and we would need to add the other versions of NT2.
Actually, I think it might be better to put all that in the namespace boost::detail::dispatch (or even boost::dispatch), as some kind of "pending" library
I don't know if this can be used by the user as an extension mechanism in your case, but if it is the case, the namespace should be public. Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/Namespace-policy-putting-names-in-boost-d... Sent from the Boost - Dev mailing list archive at Nabble.com.
On Tue, Jul 5, 2011 at 7:40 AM, Vicente Botet <vicente.botet@wanadoo.fr> wrote:
Mathias Gaunard-2 wrote:
On 04/07/2011 18:53, Vicente Botet wrote:
Mathias Gaunard-2 wrote:
A GSoC student and I are currently converting a library to use the namespace boost::simd.
Some of the implementation details of the library are not simd-specific, and we would like to use them in some other libraries that extend boost::simd.
Would it be ok to put them in the boost::detail namespace, or is that considered as bad as putting stuff in the boost namespace?
We need to inject overloads and specializations into a unique namespace for boost.simd and NT2, so we could need two names, like boost::detail::dispatch and boost::detail::specialize.
What kind of dispatch and specializations do you need to share that they can not be on simd? Maybe some more context will help.
NT2 and Boost.SIMD use a fully externalizable function dispatching and specialization mechanism.
In NT2, we have some functions, like plus, multiplies, etc. that work on a variety of types: scalars, simd packs, expression trees, tables, matrices, polynoms, etc. Each function can thus be specialized many times, some times just for particular scalars or simd pack types for example. All specializations of all functions are provided as specializations of the same class.
The dispatching uses overloading to select the best specialization available using partial ordering. It already relies on ADL tricks so I don't think we can be very flexible with regards to namespaces.
Boost.SIMD will only contain the scalar and simd packs specializations, and we would need to add the other versions of NT2.
Actually, I think it might be better to put all that in the namespace boost::detail::dispatch (or even boost::dispatch), as some kind of "pending" library
I don't know if this can be used by the user as an extension mechanism in your case, but if it is the case, the namespace should be public.
I agree, when its supposed to be something a user is supposed to customize, it, imho, doesn't make a lot of sense to put into a detail namespace. Besides my understanding of "implementation detail" is that its supposed to be able to be changed without further notification and without disrupting already existing user code depending on that. It would have to be documented at least, and putting it along with other implementation details, that are never documented and subject to change, doesn't make a lot of sense to me. Just my 0.02€ Regards, Thomas
Mathias Gaunard wrote:
A GSoC student and I are currently converting a library to use the namespace boost::simd.
Some of the implementation details of the library are not simd-specific, and we would like to use them in some other libraries that extend boost::simd.
Would it be ok to put them in the boost::detail namespace, or is that considered as bad as putting stuff in the boost namespace?
We need to inject overloads and specializations into a unique namespace for boost.simd and NT2, so we could need two names, like boost::detail::dispatch and boost::detail::specialize.
I think we want to move away from including anything in boost::detail. Consider making you're "sublibrary" as boost::smid::sublibrary. Should the sublibrary attract wider interest so it might be considered promotion, all you'll have to do is do a global replace boost::smid::sublibrary <- boost::sublibrary. In fact, if you've used "using" judiciously in your code even that would be trivial. Robert Ramey
On 7/4/2011 1:54 PM, Robert Ramey wrote:
Mathias Gaunard wrote:
A GSoC student and I are currently converting a library to use the namespace boost::simd.
Some of the implementation details of the library are not simd-specific, and we would like to use them in some other libraries that extend boost::simd.
[...]
Would it be ok to put them in the boost::detail namespace, or is that considered as bad as putting stuff in the boost namespace?
I think we want to move away from including anything in boost::detail. Consider making you're "sublibrary" as
boost::smid::sublibrary.
Should the sublibrary attract wider interest so it might be considered promotion, all you'll have to do is do a global replace boost::smid::sublibrary<- boost::sublibrary. In fact, if you've used "using" judiciously in your code even that would be trivial.
+1 -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
On 07/04/2011 08:54 PM, Robert Ramey wrote:
In fact, if you've used "using" judiciously in your code even that would be trivial.
That doesn't work to inject overloads and specializations. namespace A { template<class T> struct foo; } namespace B { using A::foo; template<> struct foo<int> {}; } does not work. The implementation detail in question is a generalized concept-based overloading system, and it requires all overloads and specializations to be in the same namespace. I guess I'll just put it in boost::simd::detail and hide its uage behind a macro.
participants (5)
-
Mathias Gaunard -
Rene Rivera -
Robert Ramey -
Thomas Heller -
Vicente Botet