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

I'd like to again encourage proposed library authors to make their documentation browsable without decompressing an archive. It's just one more barrier to getting a review.

Easier said than done :-( Was easy when we had just one file. Now it's a directory tree, and when I upload it file after file, all the links get screwed up for some reason... Neither it can see images or the stylesheet. Also it doesn't allow to upload the file named "index.html". Regards, Arkadiy

Arkadiy Vertleyb <vertleyb <at> hotmail.com> writes:

Well, this is just:

typeof(expr) var = expr;

I am surprized that it compiles in the native mode. Can a variable have the type "void"?

Oops, I jumped into BOOST_TYPEOF section silently. It is BOOST_TYPEOF that works this way. Sorry for this.

Only type, integral, and template template parameters are currently

Any plans to support other non-type parameters in a future? -- Alexander Nasonov

On 5/30/05, Alexander Nasonov <alnsn-boost@yandex.ru> wrote:

Arkadiy Vertleyb <vertleyb <at> hotmail.com> writes:

...

The typeof documentation has been significantly changed.

I has change significantly, indeed. Now it looks much better!

A couple of notes (original text is "quoted").

1. BOOST_AUTO in reference section:

"var a free identifier"

- what is a free identifier? An identifier being defined?

Should be that var is the name of the variable to be assigned "expr" or something.

- Reference semantics explained in tutorial but it doesn't appear here. - Scope of var is not clear from the description.

"expr a valid c++ expression that has a type"

- Is there any valid C++ expression that has to type? I was thinking of something like: if(a==b) {something;} But that is a statement and not an expression. I'll rephrase.

- expression returning void compiles fine in native mode but fails in compliant mode.

2. INCREMENT_REGISTRATION_GROUP

Scope of #include BOOST_TYPEOF_INCREMENT_REGISTRATION_GROUP() should be clear. My sample compiles in compliant mode even though inclusion is at class scope. Is it legal?

3. REGISTER_TEMPLATE

- I don't see any information on other non-type template parameters such as a pointer to member and a pointer/reference to object or function (14.1/4). Are they supported?

Nope. Would require to register the actual functions you want to support, it is doable, but impractical to use. Is "integral template parameters" better? Regards, Peder

- "unsigned" implies int, 7.1/3

I'm still reading the docs. Be prepared for other notes :)

-- Alexander Nasonov

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

"Alexander Nasonov" <alnsn-boost@yandex.ru> wrote

...

BOOST_TYPEOF( Z() ), where Z is a class type, gives different results in native and compliant modes, at least on gcc 3.2.2.

#include <boost/typeof/typeof.hpp> #include <boost/mpl/assert.hpp> #include <boost/type_traits/is_same.hpp>

#include BOOST_TYPEOF_INCREMENT_REGISTRATION_GROUP()

struct Z {};

BOOST_TYPEOF_REGISTER_TYPE(Z)

int main() { typedef Z(F)(); // function in native mode typedef BOOST_TYPEOF( Z() ) fn_or_class;

// Which line should be commeneted? BOOST_MPL_ASSERT(( boost::is_same<fn_or_class,Z> )); BOOST_MPL_ASSERT(( boost::is_same<fn_or_class,F> )); }

Well, the meaning of Z() is ambiguous. It can be

1) a default-constructed temporary object of class Z; 2) a type, which is a function that accepts no parameters and returns Z.

A native gcc typeof can handle types, as well as objects: __typeof__(int) is valid in g++. So the compiler has a choice: either interpret Z() as a type or an object, and apparently chooses the easier one (I think the right

"Arkadiy Vertleyb" <vertleyb@hotmail.com> wrote thing

would be to complain about the ambiguity).

In case of emulation the argument of typeof is passed to a function, so it is unambiguously interpreted as an object.

I don't think we can do much about it except mention in the docs that we can't handle types in the emulation mode.

OTOH, passing the parameter through something like: template<class T> T make (const T&); seems to be able to convince GCC that this is indeed an expression. So, if we define the BOOST_TYPEOF (in native mode) something like this (mpl::identity insures consistency of typename usage): #define BOOST_TYPEOF(x) mpl::identity<__typeof__(make(x))>::type We should be able to achieve consistency between native and emulation modes. (It also looks very similar to what David suggested in order to workaround some ICEs in GCC, see http://lists.boost.org/boost/2005/05/26880.php) Regards, Arkadiy

"Alexander Nasonov" <alnsn-boost@yandex.ru> wrote

Arkadiy Vertleyb <vertleyb <at> hotmail.com> writes:

...

OTOH, passing the parameter through something like:

template<class T> T make (const T&);

seems to be able to convince GCC that this is indeed an expression. So, if we define the BOOST_TYPEOF (in native mode) something like this (mpl::identity insures consistency of typename usage):

#define BOOST_TYPEOF(x) mpl::identity<__typeof__(make(x))>::type

We should be able to achieve consistency between native and emulation modes.

Are you going to include it to the library?

I think so... What would be the benefit of allowing a type to be passed to typeof? I can only see confusion, as in case with GCC. Regards, Arkadiy