Re: [boost] [typeof] 2 questions

Subject: Re: [boost] [typeof] 2 questions
From: Eric Niebler (eric_at_[hidden])
Date: 2010-05-18 21:03:33

Rearranging because I top-posted. :-P

On 5/17/2010 6:12 PM, Daniel Walker wrote:
> On Sun, May 16, 2010 at 3:23 PM, Eric Niebler <eric_at_[hidden]> wrote:
>> On 5/11/2010 7:48 AM, Eric Niebler wrote:
>>> 1) Some compilers don't support typeof in any form, even emulated. From
>>> looking at typeof.hpp, it looks like just #include'ing typeof.hpp on
>>> those compilers results in a hard error. I'd like a way to test whether
>>> typeof is supported and use it if so, otherwise do something else. How
>>> can I do that?
>>>
>> Resending. Is Boost.Typeof actively maintained? I can submit a patch for
>> the first issue below, but decltype support should probably be added by
>> someone who knows the library better.
> 
> I'm not sure if Boost.Typeof is being actively maintained, but I agree
> that the first issue should be fixed. If you have a patch for it
> that's great. decltype support may introduce some minor backwards
> compatibility issues.

I take back what I said about the patch. It seems typeof.hpp is simply
assuming that emulation works, so we have no data about where it
doesn't, aside from the trunk tests which suggest emulation generally
works. I can't really fix this without more data.

>>> 2) I can't find "decltype" by grepping the typeof code. Why doesn't
>>> typeof use the decltype keyword on compilers that support it?
> 
> I think there are some differences. As I recall, typeof doesn't
> preserve references whereas decltype does, so existing code could be
> broken in some situations. But I second you're suggestion of migrating
> to decltype where available/possible.

I think it would be a simple matter to strip top-level references. Consider:

  template<typename T> T unref(T const &);
  #define BOOST_TYPEOF(x) decltype(unref(x))

That way the semantics of existing code remains unchanged.

>>> And I lied. I have another question. How expensive at compile-time is
>>> emulated typeof?
> 
> Not sure. I think it may vary depending on whether it's called with a
> user defined/registered class or a primitive type.

This was answered by Peder Holt in a private msg to me, which I
duplicate here:

Peder Holt wrote:
> Hi. I can try to look into using decltype on compilers that supports it.
> I'll try to squeeze in some time in the coming few weeks.
> 
> When it comes to compile time efficiency: For Visual Studio, it is
> negligible due to the bugfeatures. For true typeof emulation, I don't think
> we ever did a thorough test on many compilers.
> The number of templates that are instantiated will depends on the complexity
> of the template.
> std::set<int,std::less<int>,std::my_allocator<int> > has a comlexity of 6,
> (std::set, int, std::less, int, std::my_allocator, int)
> 
> And requires 6*3 templates to be instantiated during encoding: encode_type,
> encode_type_impl and push_back will be instantiated at each step.
> ~ 6*2 templates are instantiated during decoding: decode_type and
> decode_type_impl.
> 
> Only one template is instantiated to hold the encoded template as an array
> of compile time integers.
> 
> Depending on the maximum complexity you need, sizeof will be called
> BOOST_TYPEOF_LIMIT_SIZE  times, typically 50-200.
> 
> Hope this clarifies things a bit.
> Regards,
> Peder

I also got a private msg from Arkadiy which I hope he doesn't mind my
posting here:

> On the other note, I have to admit that I don't have plans to actively maintain the typeof library (I am speaking for myself -- don't know about Peder).  If someone wants to pick up, I would be happy to provide any necessary help.

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com