"Andy Little" <andy@servocomm.freeserve.co.uk> wrote

Any chance to make it so it automagically registers types in its database as user uses the mechanism in code, rather than user having to do so manually. Other problem is that each "client" should really have a GUID. Any ideas on how that would work?

We have to tell the compiler about types/templates (whether it's done by the library itself or it's user -- is a different story). Therefore some kind of registration looks inavoidable. When I first posted this (a couple of months ago) I was trying to generate IDs automatically. Initially I used the MS-specific __COUNTER__ macro, then I switched to the method suggested by Paul Mensonides -- slightly less elegant, but much more portable. It turned out, however, that both these methods have the same problem -- they do not preserve IDs between compilation units, and therefore eventially leed to the ODR violation. I tried to work this around by using anonimous namespaces, but then David Abrahams proved that the ODR violation would still present in certain usage contexts. So I gave up, and started using manually-supplies IDs. I do realize that this is a significant inconvenience. Please note, however, that the IDs are specified on per-file rather than per-class basis (I use __LINE__ to distinguish inside one file). If we consider usage patterns of this facility, in many cases 3 parties are present: - the typeof library; - some other library (user library) that uses expression templates techniques (such as Spirit, Lambda, etc.); - the end user. In this case, the user library can register it's own classes. The end user than could just use the typeof for all the expressions geherated by this library, and would not have to worry about registration. In other words, the library authors could achieve the effect of typeof enabled for their library (I did this for Spirit -- can be found in the spirit repository in the TYPEOF_DEV branch). Of course, this assumes the best-case scenario, where no user-defined classes are used. When they are, they should still be registered by the end user. I am extremely interested in any strategies of generating IDs. GUID would be excelent, but, unfortunately, this is not an integer (can't be passed through sizeof). My current understanding -- the libraries should register their types against some undefined symbols which would be resolved by the end-user in the system-wide enum, so that different libraries can co-exist, something like this: enum { SPIRIT_REGISTRATION_GROUP = BOOST_TYPEOF_USER_GROUP, LAMBDA_REGISTRATION_GROUP, MY_GROUP1, MY_GROUP2, ... }; Regards, Arkadiy

On Jul 10, 2004, at 8:53 AM, David Abrahams wrote:

"Arkadiy Vertleyb" <vertleyb@hotmail.com> writes:

I'm not convinced that this particular ODR violation ends up being a problem in practice, though -- ultimately we end up getting the same type out of any typeof(...), and if we're never generating linker symbols within the computation performed by typeof, we're probably going to get away with it. I think it's worth trying an automatic scheme and stress-testing it to see if we can make it break. Better yet, explicitly construct a pared-down version _designed_ to break and see if we can cause a problem.

The only time I've ever seen a compiler/toolchain diagnose an ODR violation is when it results in two symbols with the same name and different sizes being linked together. As you said, we're not generating anything for the linker so this case won't crop up. Fear, Uncertainty, and Doubt make me wonder if trying to use Arkadiy's typeof in an exported template would trigger an ODR violation diagnostic in an EDG compiler, but I have neither proof nor the compiler around. I say we try to get away with the ODR violation. We know we're getting typeof/decltype eventually, so the ODR violation will eventually disappear anyway. Doug

"David Abrahams" <dave@boost-consulting.com> wrote

Well, it's the *un-* diagnosed ODR violations that are really dangerous...

When I was experimenting with this, as we discussed this topic during my initial submission, I was able to achieve the effect of calling different function by debug and release versions, probably because of inlining, by VC7.1 (although it was not related to the typeof). Scary... On the other hand, automatic registration can make it attractive to use the library in many cases where it is currently not. Do you think it's possible to create a test case that would test this more or less fully? Arkadiy

David Abrahams wrote:

I'm not convinced that this particular ODR violation ends up being a problem in practice, though -- ultimately we end up getting the same type out of any typeof(...), and if we're never generating linker symbols within the computation performed by typeof, we're probably going to get away with it. I think it's worth trying an automatic scheme and stress-testing it to see if we can make it break. Better yet, explicitly construct a pared-down version _designed_ to break and see if we can cause a problem.

Just to understand you correctly: When I used typeof() in my constant library, I was told that it is not acceptable because it's not yet standard. Although both the EDG-based compiler I used (Intel) and the GCC offered __typeof__. Now people are trying to emulate the functionality of typeof. They want users to register their types and the library is still not as capable as a native typeof. Try the examples I provided for unit-library-compatible constants. And now you even say that it's OK to violate existing language rules on purpose just because you think it will likely work in practice? Sorry I don't get this. If violating the existing standard is an option, than __typeof__ should be an option as well. My 2¢. Regards, Daniel -- Daniel Frey aixigo AG - financial solutions & technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: daniel.frey@aixigo.de, web: http://www.aixigo.de

David Abrahams wrote:

Daniel Frey <daniel.frey@aixigo.de> writes:

...

David Abrahams wrote:

...

I'm not convinced that this particular ODR violation ends up being a problem in practice, though -- ultimately we end up getting the same type out of any typeof(...), and if we're never generating linker symbols within the computation performed by typeof, we're probably going to get away with it. I think it's worth trying an automatic scheme and stress-testing it to see if we can make it break. Better yet, explicitly construct a pared-down version _designed_ to break and see if we can cause a problem.

Just to understand you correctly: When I used typeof() in my constant library, I was told that it is not acceptable because it's not yet standard. Although both the EDG-based compiler I used (Intel) and the GCC offered __typeof__.

Perhaps you could post links to specific messages so we can see exactly what was said?

If you're talking about http://lists.boost.org/MailArchives/boost/msg59186.php, "it's not acceptable because it's not standard" is not an accurate paraphrase of the message there.

This is the message I was talking about. And to me it means, that __typeof__ is not acceptable because it's not standard. Maybe I don't understand the message? The library needs some way to find out the type of an expression, __typeof__ works today for some compilers, in the future, we might have something like decltype and we can switch to it once it becomes available. Even if it's not compatible with __typeof__ directly, I'm sure it will provide the functionality needed. The details might differ, but I would be more than surprised to find out that decltype would not provide what is needed. So doesn't this mean that I can't use __typeof__? Maybe you refer to the fact that the message suggests that all I need is an appropriate fallback, but this depends on whether or not such a fallback is available. AFAICT, no proposed typeof-emulation was able to work for the unit-library examples I've shown, but maybe I haven't tried hard enough. But given that nothing worked for me, the conclusion for me is, that I can't use typeof because it (or decltype) is not (yet) standard.

...

Now people are trying to emulate the functionality of typeof. They want users to register their types and the library is still not as capable as a native typeof. Try the examples I provided for unit-library-compatible constants.

Perhaps you could post links to specific messages?

Hm, sorry, this is my fault. I think I haven't posted an analysis *why* all approaches of typeof-emulation won't do for the constant library. I just thought about these things, taking into account the examples for unit-libraries, and decided it won't work. The reason is, that the author of the constant library (or the constants) cannot know which unit-libraries are to be supported, and the author of the unit-library doesn't want to register stuff for a specific constant library. Dependencies. The problem is, that you have to register operators for pairs of arguments, one from the unit library, the other from the constant-library. Who is supposed to do that? But I also remember that this was a problem anyway, as -depending on the design of the unit-library- it sometimes worked out-of-the-box, sometimes it didn't. I guess I will have to work this out more detailed, but currently, I don't have time for it...

...

And now you even say that it's OK to violate existing language rules on purpose just because you think it will likely work in practice?

As an experiment, to see how portable it actually is... and only because we expect to see full language support soon.

Oh, I missed the "full language support soon"-part. Again, sorry.

IMO __typeof__ is an option as long as there's a fallback for compilers that don't support it.

As an alternative: Would a limited functionality be OK, too? In my case, meaning you can use the constant library with all types that have the same result type for operators as their arguments, e.g. T+T gives you a T, etc. This doesn't hold for unit-types, where we need typeof instead of the simple assumption above, but it still provides lots of useful functionality for "normal" types. Regards, Daniel -- Daniel Frey aixigo AG - financial solutions & technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: daniel.frey@aixigo.de, web: http://www.aixigo.de

Daniel Frey <daniel.frey@aixigo.de> writes:

Hm, sorry, this is my fault. I think I haven't posted an analysis *why* all approaches of typeof-emulation won't do for the constant library. I just thought about these things, taking into account the examples for unit-libraries, and decided it won't work. The reason is, that the author of the constant library (or the constants) cannot know which unit-libraries are to be supported, and the author of the unit-library doesn't want to register stuff for a specific constant library. Dependencies. The problem is, that you have to register operators for pairs of arguments, one from the unit library, the other from the constant-library.

I'm don't see why you'd need to register operators. If I'm not mistaken, with Arkadiy's solution you only need to register user-defined types and templates (and maybe functions if they are used as template arguments).

Who is supposed to do that? But I also remember that this was a problem anyway, as -depending on the design of the unit-library- it sometimes worked out-of-the-box, sometimes it didn't. I guess I will have to work this out more detailed, but currently, I don't have time for it...

...

...

And now you even say that it's OK to violate existing language rules on purpose just because you think it will likely work in practice? As an experiment, to see how portable it actually is... and only because we expect to see full language support soon.

Oh, I missed the "full language support soon"-part. Again, sorry.

...

IMO __typeof__ is an option as long as there's a fallback for compilers that don't support it.

As an alternative: Would a limited functionality be OK, too? In my case, meaning you can use the constant library with all types that have the same result type for operators as their arguments, e.g. T+T gives you a T, etc.

It seems reasonable that a library acquires added features on compilers where language extensions are available.

This doesn't hold for unit-types, where we need typeof instead of the simple assumption above, but it still provides lots of useful functionality for "normal" types.

Seems OK to me, in principle. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

"Arkadiy Vertleyb" <vertleyb@hotmail.com> writes:

"David Abrahams" <dave@boost-consulting.com> wrote

...

I'm don't see why you'd need to register operators. If I'm not mistaken, with Arkadiy's solution you only need to register user-defined types and templates (and maybe functions if they are used as template arguments).

Functions (as well as member functions and data members) are supported by the typeof library -- you don't need to register them. This comes from the fact that, for example, R(*)(T0, T1) can be applied to any function that matches this signature, and only depends on R, T0, and T1.

So, as long as you register MyType, the following, for example, will be handled:

int (MyType::*)(short&, const MyType&) const //FWIW

It's clearly not a complete solution, then: template <int (*)()> struct f {}; int g(); int h(); BOOST_STATIC_ASSERT((!boost::is_same<typeof(f<&g>()),typeof(f<&h>()))); That's all I meant about registering functions. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

"Daniel Frey" <daniel.frey@aixigo.de> wrote

Now people are trying to emulate the functionality of typeof. They want users to register their types and the library is still not as capable as a native typeof.

I totally agree with this, except native typeof is not available on most compilers. Considering the fact that companies tend to stick with compilers (like many still use VC6 -- believe it or not), the native typeof is not going to be available to most people for a few more years after the typeof is in the Standard. Are we willing to wait 3 - 5 years? Regards, Arkadiy

Alexander Nasonov <alnsn@yandex.ru> wrote

My attempt to compile ./libs/typeof/test/main.cpp failed...

Could you tell me what exactly the Intel compiler complained about?

so I quickly typed my small test (attached). Intel compiler compiled it.

I am curious how it knew about std::string and vector. They are not supposed to be registered by the basic typeof facility. Are you sure you didn't #include anything else? Arkadiy

Alexander Nasonov <alnsn@yandex.ru> wrote

Can you switch to boost scheme of detecting the compiler?

Done. http://groups.yahoo.com/group/boost/files/typeof.zip The best I could do non-intruisively to Boost was to repeat the switch defined in "select_compiler_config.hpp"... Or can I do any better? Arkadiy

Alexander Nasonov <alnsn@yandex.ru> wrote

...

My attempt to compile ./libs/typeof/test/main.cpp failed...

Could you tell me what exactly the Intel compiler complained about? If you surround typename by comments at line 115 in register_functions.hpp

Arkadiy Vertleyb wrote: the compilation will stop only after #pragma message("compiling Modifiers example..."). -- Alexander Nasonov

... and only in there saying: ../../../boost/typeof/typeof.hpp(37): error: more than one partial specialization matches the template argument list of class "boost::type_of::encode_type_impl<boost::type_of::encode_type_impl<boost::ty

Alexander Nasonov wrote: pe_of::detail::push_back<boost::type_of::detail::push_back<boost::mpl::vecto r0<boost::mpl::void_>, boost::mpl::int_<131093>>::type, boost::mpl::int_<458770>>::type, const int *const>::type, const int [20]>"

"boost::type_of::encode_type_impl<V, const T>" "boost::type_of::encode_type_impl<V, T [N]>"

Hmmm, do you think this is a compiler bug or a standard behavior? const int[20] looks to me like an array of const integers, so I would definitely expect the second specialization envoked, but maybe it's also legal to view it something like a const integer that happens to be here 20 times? Do you think similar problems are possible in other contexts?

I'd suggest to use is_array in combination with mpl::if_:

template<class V, class T> struct encode_type_impl; template<class V, class T> struct encode_type_impl_array; // HERE! template<class T, class Iter> struct decode_type_impl;

template<class V, class T> struct encode_type : boost::mpl::if_< ::boost::is_array<T>, encode_type_impl_array<V, T>, // AND HERE! encode_type_impl<V, T> >::type {};

Of course, you have to append _array to appropriate specialization of encode_type_impl.

#ifdeffed, as a workaround for Intel? Otherwise it may significantly affect the compile time... Arkadiy

"David Abrahams" <dave@boost-consulting.com> wrote

In the first specialization, T is int[20]. This is due to the strange way in which cv-qualification "commutes" with array bounds:

typedef int a20[20]; typedef a20 const ca20i; // an const array of 20 ints

typedef int const a20ci[20]; // an array of 20 const ints. template <class T> struct X; template <class T> struct X<T const> {}; // template <class T, int N> struct X<T[N]> {}; -- uncomment for ambiguity X<ca20i> a; // the same type X<a20ci> b;

Or, in other words, by definition, "array of const/volatile T" is the same as "const/volatile array of T" (which basically causes the ambiguity)? This looks like unique quality of arrays and we should not run into it in any other contexts, should we?

Here's how you check whether they're equally specialized:

synthesize unique types and values for T and N in each specialization:

template <class T> struct X<T const> {}; // T = struct Foo {}; template <class T, int N> struct X<T[N]> {}; // T = struct Bar {};, N = Q

can "Foo const" match "T[N]"? No. can "Bar[Q]" match "T const"? No.

Therefore: they're equally specialized.

And the easiest way to resolve this particular case would be to provide the third specialization: template <class T, int N> struct X<const T[N]> {}; // T = struct Foo{};, N = Q To handle volatiles (I am not doing this right now), I would just have to add another two: template <class T, int N> struct X<volatile T[N]> {}; template <class T, int N> struct X<const volatile T[N]> {}; Am I getting this correctly? Arkadiy

Arkadiy Vertleyb wrote:

This would definitely solve the problem but, as I said, I have concernes about the need to instantiate mpl::if_<> and is_array<> for every node in the expression. I think we can get away by just providing a more specialized case:

boost::type_of::encode_type_impl<V, const T [N]>.

http://groups.yahoo.com/group/boost/files/typeof.zip

On VC7.1 it seems to work fine (as it was before, actually), but unfortunately I can't test this on Intel...

If you change modifiers.hpp:110 from typedef typename const d::type type[n]; to typedef typename d::type const type[n]; and add using namespace std; to main.cpp (cout and endl are not always prefixed with std:: in your test) everything will compile on Intel C++. I also tried not to use native typeof under g++. Both 3.2.2 and 3.4.0 compile the test. BTW, I think it's good idea to add BOOST_NO_NATIVE_TYPEOF definition. BTW2, Intel 8.0 has also native typeof. -- Alexander Nasonov

Doug Gregor wrote:

On Jul 11, 2004, at 1:16 AM, <alnsn@yandex.ru> wrote:

...

Arkadiy Vertleyb wrote: compile the test. BTW, I think it's good idea to add BOOST_NO_NATIVE_TYPEOF definition.

We tend to use BOOST_NO_XXX to describe language/library features that should be there but aren't (or work improperly) [skiped]

Then I suspect we may need BOOST_NO_TYPEOF in a future. Let's reserve it now ;-) -- Alexander Nasonov

Arkadiy Vertleyb wrote:

Or do you mean forcing compilers to use encoding/decoding even if they do support typeof natively? In this case it is library-specific, and I would call it something like BOOST_TYPEOF_DISABLE_NATIVE_SUPPORT. or BOOST_FORCE_TYPEOF_EMULATION. -- Alexander Nasonov

Arkadiy, I put a reference to your library to Russian site www.rsdn.ru. Shortly after that Andrey Beliakov commented out sizer class. He writes that sizeof(sizer<N>) is not necessarily equal to N::value. Andrey suggests rewriting the sizer: template<class N> struct sizer { typedef char(&type)[N::value]; }; and use sizer<N>::type in place of sizer<N>. Here is a reference to his message (in Russian): http://www.rsdn.ru/Forum/Message.aspx?mid=717690&only=1 -- Alexander Nasonov