type_with_alignment.hpp / alignment_of.hpp too heavy
I need to allocate an object of type T, but I also need to bundle it in a single memory allocation with an object of class U. Something like "new std::pair<T,U>" would work, except that U is a rather heavy type and I want to pimpl it away into a cpp. This means that the cpp needs to deal with the alignment of T and U when allocating the memory. For that purpose, I could use type_traits/type_with_alignment.hpp in my header, but when I looked at it, I was blown away by how much crap it includes (remember, I want my header to be very very light.) Then I thought that I could probably build my system by just using type_traits/alignment_of.hpp. It sure would be very light, right? Wrong, it also includes mpl and whatnot. I hope someone shares my frustration. Shouldn't at least alignment_of.hpp be much, much lighter? I'd think that all it should contain is whatever compiler-specific hacks are needed and that's it. What is the justification for including stuff like <boost/mpl/aux_/lambda_support.hpp> in alignment_of.hpp? Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
on Tue Sep 30 2008, "Emil Dotchevski" <emil-AT-revergestudios.com> wrote:
I need to allocate an object of type T, but I also need to bundle it in a single memory allocation with an object of class U. Something like "new std::pair<T,U>" would work, except that U is a rather heavy type and I want to pimpl it away into a cpp.
This means that the cpp needs to deal with the alignment of T and U when allocating the memory. For that purpose, I could use type_traits/type_with_alignment.hpp in my header, but when I looked at it, I was blown away by how much crap it includes (remember, I want my header to be very very light.)
Then I thought that I could probably build my system by just using type_traits/alignment_of.hpp. It sure would be very light, right? Wrong, it also includes mpl and whatnot.
I hope someone shares my frustration. Shouldn't at least alignment_of.hpp be much, much lighter? I'd think that all it should contain is whatever compiler-specific hacks are needed and that's it. What is the justification for including stuff like <boost/mpl/aux_/lambda_support.hpp> in alignment_of.hpp?
None in particular if your compiler isn't broken. It can just be hard sometimes to limit the #includes that are brought in to support workarounds. I'm sure Aleksey would be glad to get a patch. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Emil Dotchevski wrote:
I need to allocate an object of type T, but I also need to bundle it in a single memory allocation with an object of class U. Something like "new std::pair<T,U>" would work, except that U is a rather heavy type and I want to pimpl it away into a cpp.
This means that the cpp needs to deal with the alignment of T and U when allocating the memory. For that purpose, I could use type_traits/type_with_alignment.hpp in my header, but when I looked at it, I was blown away by how much crap it includes (remember, I want my header to be very very light.)
Sorry if I'm missing something, but why would you need to include these headers in your header? Just forward-declare your internal pimpl class and define it in cpp. It is cpp where you would include type_with_alignment.hpp & co. and this is not that critical, is it?
On Wed, Oct 1, 2008 at 9:23 AM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
Emil Dotchevski wrote:
I need to allocate an object of type T, but I also need to bundle it in a single memory allocation with an object of class U. Something like "new std::pair<T,U>" would work, except that U is a rather heavy type and I want to pimpl it away into a cpp.
This means that the cpp needs to deal with the alignment of T and U when allocating the memory. For that purpose, I could use type_traits/type_with_alignment.hpp in my header, but when I looked at it, I was blown away by how much crap it includes (remember, I want my header to be very very light.)
Sorry if I'm missing something, but why would you need to include these headers in your header? Just forward-declare your internal pimpl class and define it in cpp. It is cpp where you would include type_with_alignment.hpp & co. and this is not that critical, is it?
The problem is that I still need the bootstrap code to be in the header, it's a function template with a single parameter T. The header needs to tell the cpp what's the size and alignment for T, and also pass pointers to a function that can copy a T and a function that destroys it. The cpp then can allocate the memory block, init the U object and copy the T. So, at least I need to include alignment_of.hpp which is so heavy it practically nullifies my efforts to pimpl the U type away in the cpp. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
2008/10/1 Emil Dotchevski <emil@revergestudios.com>
So, at least I need to include alignment_of.hpp which is so heavy it practically nullifies my efforts to pimpl the U type away in the cpp.
Have a look at boost/intrusive/detail/mpl.hpp, there's a alignment_of with the following comment //boost::alignment_of yields to 10K lines of preprocessed code, so we //need an alternative Since it's in detail, maybe it's safe to check with the author (Ion?) first.. / Christian
on Thu Oct 02 2008, "Christian Holmquist" <c.holmquist-AT-gmail.com> wrote:
2008/10/1 Emil Dotchevski <emil@revergestudios.com>
So, at least I need to include alignment_of.hpp which is so heavy it practically nullifies my efforts to pimpl the U type away in the cpp.
Have a look at boost/intrusive/detail/mpl.hpp, there's a alignment_of with the following comment
//boost::alignment_of yields to 10K lines of preprocessed code, so we //need an alternative
Since it's in detail, maybe it's safe to check with the author (Ion?) first..
I would prefer to fix this dependency problem. AFAICT it only exists for VC6/7 support of mpl lambda expressions with boost type traits. Is this the only trait that exhibits that level of dependency? -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Fri, Oct 3, 2008 at 9:05 AM, David Abrahams <dave@boostpro.com> wrote:
on Thu Oct 02 2008, "Christian Holmquist" <c.holmquist-AT-gmail.com> wrote:
2008/10/1 Emil Dotchevski <emil@revergestudios.com>
So, at least I need to include alignment_of.hpp which is so heavy it practically nullifies my efforts to pimpl the U type away in the cpp.
Have a look at boost/intrusive/detail/mpl.hpp, there's a alignment_of with the following comment
//boost::alignment_of yields to 10K lines of preprocessed code, so we //need an alternative
Since it's in detail, maybe it's safe to check with the author (Ion?) first..
I would prefer to fix this dependency problem. AFAICT it only exists for VC6/7 support of mpl lambda expressions with boost type traits. Is this the only trait that exhibits that level of dependency?
FWIW, I think we should be removing VC 6 and 7.0 workarounds, particularly in libraries where there is some real downside to continued support for these now long obsolete compilers. --Beman
Beman Dawes wrote:
FWIW, I think we should be removing VC 6 and 7.0 workarounds, particularly in libraries where there is some real downside to continued support for these now long obsolete compilers.
While those compilers still surely are in use, the people that use them care little about the non-mainstream parts of Boost. (if they did, they would surely upgrade) By non-mainstream, I mainly mean non-TR1 stuff.
David Abrahams wrote:
on Thu Oct 02 2008, "Christian Holmquist" <c.holmquist-AT-gmail.com> wrote:
2008/10/1 Emil Dotchevski <emil@revergestudios.com>
So, at least I need to include alignment_of.hpp which is so heavy it practically nullifies my efforts to pimpl the U type away in the cpp.
Have a look at boost/intrusive/detail/mpl.hpp, there's a alignment_of with the following comment
I would prefer to fix this dependency problem. AFAICT it only exists for VC6/7 support of mpl lambda expressions with boost type traits. Is this the only trait that exhibits that level of dependency?
I agree fixing alignment_of is the way to go and type_traits utilities need some work to simplify dependencies. For Intrusive I wanted to minimize nearly all external dependencies so I just took alignment_of code and simplified it. This simple code should work for most compilers: #include <cstddef> template <typename T> struct alignment_of; template <typename T> struct alignment_of_hack { char c; T t; alignment_of_hack(); }; template <unsigned A, unsigned S> struct alignment_logic { static const std::size_t value = A < S ? A : S; }; template< typename T > struct alignment_of { static const std::size_t value = alignment_logic < sizeof(alignment_of_hack<T>) - sizeof(T) , sizeof(T) >::value; }; I don't think we need to include <boost/config.hpp> (which includes some std header to detect std library configuration). Regards, Ion
participants (8)
-
Andrey Semashev -
Beman Dawes -
Christian Holmquist -
Daniel Walker -
David Abrahams -
Emil Dotchevski -
Ion Gaztañaga -
Mathias Gaunard