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? 2) I can't find "decltype" by grepping the typeof code. Why doesn't typeof use the decltype keyword on compilers that support it? And I lied. I have another question. How expensive at compile-time is emulated typeof? TIA, -- Eric Niebler BoostPro Computing http://www.boostpro.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/11/2010 10: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?
I can't answer your other two questions, but I'll take a shot at this one: I've seen scripts that try to compile trivial code that uses something questionable, and reads the response from the compiler to see if it worked. Then it configures the real project to use it or not. (I saw this used by VMware Tools, when compiled under Linux. I'm sure other Linux-based projects use it too.) I doubt that's what you were asking for, but if the library isn't designed to give you that information, it's the only way I know of to determine it. - -- Chad Nelson Oak Circle Software, Inc. * * * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvqq2EACgkQp9x9jeZ9/wTCkQCcDmxhbN7BcC86vUyAvIhrZ+ig /noAn2Y3cYPu4gXVanjL3YWqvqm3+Zln =jJm3 -----END PGP SIGNATURE-----
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. 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?
2) I can't find "decltype" by grepping the typeof code. Why doesn't typeof use the decltype keyword on compilers that support it?
And I lied. I have another question. How expensive at compile-time is emulated typeof?
TIA,
-- Eric Niebler BoostPro Computing http://www.boostpro.com
On Sun, May 16, 2010 at 3:23 PM, Eric Niebler <eric@boostpro.com> wrote:
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.
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?
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.
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. Daniel Walker
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
On Tue, May 18, 2010 at 9:03 PM, Eric Niebler <eric@boostpro.com> wrote:
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:
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.
Yeah, that could do the trick. The regression tests may turn up other differences, which could be addressed as they're discovered, but this looks doable. It would be a boon to users, since they'd no longer have to register their types. And it would reduce compile time overhead. Daniel Walker
2010/5/11 Eric Niebler <eric@boostpro.com>
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?
Sorry for the long delay. I have checked in a fix for this. If you include the typeof header on a compiler not supporting typeof emulation (read: Borland compilers), BOOST_TYPEOF_EMULATION_UNSUPPORTED will be defined. BOOST_TYPEOF(Expr) will expand to boost::type_of::typeof_emulation_is_unsupported_on_this_compiler Regards Peder
2) I can't find "decltype" by grepping the typeof code. Why doesn't typeof use the decltype keyword on compilers that support it?
And I lied. I have another question. How expensive at compile-time is emulated typeof?
TIA,
-- Eric Niebler BoostPro Computing http://www.boostpro.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 6/27/2010 2:16 PM, Peder Holt wrote:
2010/5/11 Eric Niebler <eric@boostpro.com>
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?
Sorry for the long delay. I have checked in a fix for this. If you include the typeof header on a compiler not supporting typeof emulation (read: Borland compilers), BOOST_TYPEOF_EMULATION_UNSUPPORTED will be defined. BOOST_TYPEOF(Expr) will expand to boost::type_of::typeof_emulation_is_unsupported_on_this_compiler
Great! Thanks Peter. -- Eric Niebler BoostPro Computing http://www.boostpro.com
participants (4)
-
Chad Nelson -
Daniel Walker -
Eric Niebler -
Peder Holt