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@boostpro.com> 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