|
Boost : |
From: David Abrahams (dave_at_[hidden])
Date: 2005-05-21 18:35:23
"Arkadiy Vertleyb" <vertleyb_at_[hidden]> writes:
> "David Abrahams" <dave_at_[hidden]> wrote
>
>> I believe I have substantially simplified the implementation of typeof
>> and fixed the vc8 compatibility problems. See the enclosed
>> typeof_impl.hpp
>
> Right. That's exactly the simplification I meant in my previous post.
> Unfortunately it means at() is instantiated BOOST_TYPEOF_LIMIT_SIZE times,
> whereas with more complicated expression it is instantiated only n times,
> where n is the actual size of the encoded vector. I introduced this
> complexity about half a year ago, and it cut the time of my tests more than
> in half...
Okay, how about the one enclosed here, then?
>> I am a little concerned about the implementation. When I saw the
>> complexity of what the BOOST_TYPEOF macro expanded into, I was a bit
>> shocked. Aside from what I addressed, the fact that the expression
>> gets repeated 100 times was really surprising to me -- it seems to me
>> that asking the compiler to evaluate the type of the expression over
>> and over could get to be quite expensive.
>
> But this is on average seems to be compensated by less times the
> template is instantiated.
Okay.
>> The simplification I've
>> made results in the expression being repeated "only" 50 times. Is it
>> possible to do better?
>
> I don't believe it's possible with conventional metaprogramming. The
> problem is that, in order to calculate the size of the vector at compile
> time, we have to pass the expression inside a metafunction, which doesn't
> seem possible. Therefore we have to do it at preprocessing time, which
> means BOOST_TYPEOF_LIMIT_SIZE times. This is the price of crossing
> boundaries.
>
>> Also, on a stylistic note, the paucity of whitespace in
>>
>> namespace boost{namespace type_of{
>>
>> seems a bit draconian (yes, I'm exercising my vocabulary today ;->).
>
> Well, there are two whitespaces :-)
>
> Why? Does it make it unreadable?
Just less readable than it might be.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk