Boost logo

Boost :

From: brianjparker (brianjparker_at_[hidden])
Date: 2002-02-21 16:48:25


--- In boost_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
> From: "Fernando Cacciola" <fcacciola_at_g...>
> > I don't think that the very small increased complexity of
requiring auto
> > declarations to have a type name are not worth the increased
safety.
> > Don't you think it does improves safety a lot?
>
> No, actually, I don't. Partly because the right time to use auto
> declarations is exactly when the actual type doesn't matter, and
partly
> because I don't see how requiring a dummy identifier would improve
safety
> somehow.

Having the deduced type available is essential for functionality
reasons as well as type safety improvements.

e.g.
template<typename T1, typename T2>
void func(T1 t1, T2 t2)
{
     auto L temp = t1 + t2;
     // ...
 
     vector<L> v;
     // creating this vector cannot be done by typeless auto
}

(in my preferred syntax, this would be-
template<typename T1, typename T2, typename L>
void func(T1 t1, T2 t2)
{
     L temp = t1 + t2;
     // ...
 
     vector<L> v;
}
)

A real-world example that I have posted earlier (using the template
syntax above) is-

template<typename R, typename T1, typename T2, typename L>
complex<R> operator*(const complex<T1>& lhs, imaginary<T2> rhs)
{
L l1 = -(lhs.im * rhs); // L is deduced here
L l2 = lhs.re * rhs;

complex<L> ret;

ret.re = l1;
ret.im = l2;
return ret;
}

How would this be implemented using typeless auto alone (without
using a full typeof)?

As far as improved type safety is concerned, a (contrived) example
would be-

template<typename T1, typename T2, typename L>
void func2(T1 t1, T2 t2)
{
    complex<L> z = func3(t1, t2);
    // compile-time type check that func3 indeed returns a complex
    // ...
}

Actually, this example shows the limitation of even the type-
annotated "auto" proposal, and is a manifestation of the fact that
the various "auto" proposals are attempting to duplicate the type
deduction mechanisms already existing for template function arguments.

,Brian Parker


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk