Re: [boost] Re: New utility at boost/detail/allocator.hpp
----- Mensaje original ----- De: David Abrahams <dave@boost-consulting.com>
Joaquín Mª López Muñoz <joaquin@tid.es> writes: [...]
is in boost::detail::allocator), I don't have any problem with renaming to allocator_helper (it's a better name, actually.) If no one else objects (which I doubt) I'll apply the name change tomorrow.
I think allocator_rebind would be a much better name than allocator_helper.
Ummm, the problem with allocator_rebind is that the header contains some other stuff not strictly related to rebinding: * partial_std_allocator_wrapper * construct (allocator-independent construction function) * destroy (allocator-independent destruction function) ?? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
JOAQUIN LOPEZ MU?Z <joaquin@tid.es> writes:
----- Mensaje original ----- De: David Abrahams <dave@boost-consulting.com>
Joaquín Mª López Muñoz <joaquin@tid.es> writes: [...]
is in boost::detail::allocator), I don't have any problem with renaming to allocator_helper (it's a better name, actually.) If no one else objects (which I doubt) I'll apply the name change tomorrow.
I think allocator_rebind would be a much better name than allocator_helper.
Ummm, the problem with allocator_rebind is that the header contains some other stuff not strictly related to rebinding:
* partial_std_allocator_wrapper * construct (allocator-independent construction function) * destroy (allocator-independent destruction function)
Those latter two aren't really allocator helpers, are they? ;-) I don't know what the first one is, but maybe this should be 3 separate headers. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams <dave <at> boost-consulting.com> writes: [...]
I think allocator_rebind would be a much better name than allocator_helper.
Ummm, the problem with allocator_rebind is that the header contains some other stuff not strictly related to rebinding:
* partial_std_allocator_wrapper * construct (allocator-independent construction function) * destroy (allocator-independent destruction function)
Those latter two aren't really allocator helpers, are they? I don't know what the first one is, but maybe this should be 3 separate headers.
Thre three together form some kind of nanolibrary to ease allocator handling. construct and destroy are convenient substitutes for the corresponding allocator memfuns, as they can help eliminate unnecessary dependencies from the allocator type. I could detach construct() and destruct() from the header, but partial_std_allocator_wrapper is used in the rebinding utility. For these reasons, I think allocator_rebind is not an appropriate name. Anyone suggesting a better name than allocator_helper? (Andreas? you wanted to use this stuff) Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
From: Joaquin M Lopez Munoz <joaquin@tid.es>
For these reasons, I think allocator_rebind is not an appropriate name. Anyone suggesting a better name than allocator_helper? (Andreas? you wanted to use this stuff)
Why not simply allocator_utilities.hpp? -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Rob Stewart <stewart <at> sig.com> writes:
From: Joaquin M Lopez Munoz <joaquin <at> tid.es>
For these reasons, I think allocator_rebind is not an appropriate name. Anyone suggesting a better name than allocator_helper? (Andreas? you wanted to use this stuff)
Why not simply allocator_utilities.hpp?
Yes, sounds good. Same name for the namespace (boost::detail::allocator_utilities)? Isn't it a little long? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
From: Joaquin M Lopez Munoz <joaquin@tid.es>
Rob Stewart <stewart <at> sig.com> writes:
From: Joaquin M Lopez Munoz <joaquin <at> tid.es>
For these reasons, I think allocator_rebind is not an appropriate name. Anyone suggesting a better name than allocator_helper? (Andreas? you wanted to use this stuff)
Why not simply allocator_utilities.hpp?
Yes, sounds good. Same name for the namespace (boost::detail::allocator_utilities)? Isn't it a little long?
Any reason why the ns can't be "allocator?" This code will coexist with any allocator library that may appear, I should think, and these should interoperate with such a library; it might even become part of such a library. I can't see a problem with them sharing a ns. (That also suggests that the directory for the header is boost/allocator/detail.) -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
participants (4)
-
David Abrahams -
JOAQUIN LOPEZ MU?Z -
Joaquin M Lopez Munoz
-
Rob Stewart