"Alexander Nasonov" <alnsn@yandex.ru> wrote
Peder Holt wrote:
On 1/3/06, Alexander Nasonov <alnsn@yandex.ru> wrote:
The patch below fixes this problem. It's built around comma operator:
struct void_ {}; template<class T> T& operator,(T const&, void_);
How will this work if someone implements their own operator,? template<class T> T& operator,(const my_type&,const T&);
if expr equals my_type, wouldn't this break typeof for my_type?
You're right. I should have added a special object to the left of expr:
( wrap_nonvoid_expr(), (expr), resolve_void() ).get()
template<class T> struct wrapped_obj { T& get(); };
struct wrap_nonvoid_expr { template<class T> wrapped_obj<T> operator,(T const&); };
struct resolve_void { void get(); };
template<class T> wrapped_obj<T> operator,(wrapped_obj<T>, resolve_void);
AFAIU, you are trying to fix ensure_obj, but this is only one context in which typeof would fail with void expression. The other contexts include: 1) typeof emulation; 2) MSVC trick; 3) LVALUE_TYPEOF All of the above try to pass the expression into a function, and will fail if type of the expression is void. Whichever solution we'll find, I think we should wrap it into a macro, and consistently apply everywhere. As far as what you suggesting, it looks promising, but we need to evaluate consiquenses... Such as one Peder found. Also there is at least one more case when something can't be bound to const T&, and this is MSVC-specific problem found on RSDN (see a couple of tests failing for vc-7_1). We'll have to see that the solution to the "void" problem works together with whichever MSVC workaround we apply... Regards, Arkadiy