Boost logo

Boost :

From: Arkadiy Vertleyb (vertleyb_at_[hidden])
Date: 2006-01-04 13:28:17

"Alexander Nasonov" <alnsn_at_[hidden]> wrote

> Peder Holt wrote:
> > On 1/3/06, Alexander Nasonov <alnsn_at_[hidden]> 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;

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...


Boost list run by bdawes at, gregod at, cpdaniel at, john at