I don't see the first message about the typeof operator.
Should it be something like:

class Base {/* ... */};
class Derived : public Base {/* ... */};

Base* p1 = new Derived;

now I need a copy of *p1;

Base* p2 = new typeof(*p1) (dynamic_cast<typeof(*p1)>(*p1));

instead of

Base* p2 = new Derived     (dynamic_cast<Derived&>(*p1));

?

--
Ryszard Kabatek
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

On 26 Oct 97 08:54:01 GMT, bparker@mailbox.uq.edu.au (Brian Parker)
wrote:

>typeof certainly appears to be a useful construct but I was wondering
>if anyone could post an example where it is *essential* for a generic
>function such that no work-around exists (excluding traits classes).

 Oh, sure! You cannot write an iterator class
that delegates to another iterator. There's no way to
find the value type, so you cannot, for example,
declare the return type of operator*.

 The workaround is to TELL the wrapper class
the return type .. manually.

[I do not consider "traits" a solution, they're a travesty.]

John Max Skaller                ph:61-2-96600850
mailto:skaller@zip.com.au       10/1 Toxteth Rd
http://www.zip.com.au/~skaller  Glebe 2037 NSW AUSTRALIA
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

On 07 Nov 97 01:45:14 GMT, skaller@zip.com.au (John (Max) Skaller)
wrote:
>...
> Oh, sure! You cannot write an iterator class
>that delegates to another iterator. There's no way to
>find the value type, so you cannot, for example,
>declare the return type of operator*.
>
> The workaround is to TELL the wrapper class
>the return type .. manually.
>
>[I do not consider "traits" a solution, they're a travesty.]

Yes, having thought about the issue more, I agree that typeof( ) is
pretty essential- particularly for function return types.

Also, on examining my own code I find that I have template code that
requires the user to "register" type promotions using a traits class
that would be unnecessary if typeof( ) were available (as well as
generally making template code much more concise).

,Brian Parker.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

typeof certainly appears to be a useful construct but I was wondering
if anyone could post an example where it is *essential* for a generic
function such that no work-around exists (excluding traits classes).

It seems to me that typeof would be useful in generic functions using
mixed-mode expressions of the template argument types in two places-
(1) within the function body primarily to declare local variables, and
(2) to declare the function return type.

Case (1) in most cases would have the work-around of declaring an
auxillary function to deduce the expression type. e.g.

Instead of -

template<class A, class B>
X func(A a, B b)
{
 // other context
 typeof(A * B) temp = a * b;
 // ... further computation using temp
}
(ignoring return type issues for now)

one could use-

template<class T>
X aux_func(T temp, //and pass in other context...)
{
 // the expression return type is now known to be T
 // ... further computation using temp
}

template<class A, class B>
X func(A a, B b)
{
 // other context
 aux_func(a * b, and pass in other context...);
 //...
}

(Of course, this is awful compared with the typeof solution, but I'm
just considering the logical necessity of it here. Note: the
expression passed to aux_func() may be a dummy expression used purely
to deduce the expression type for later code).

Case (2) would have two workarounds.
(i) the function could be rewritten to require an out argument instead
of returning a value.

(ii) the return type could be specified as an additional template
parameter, requiring the caller to explicity specify the return type.
i.e.

template<class R, class A>
R func(A a) { ....}

// calling function (non-generic- all types are known)
R r = func<R>(a);

This workaround is intrusive and not suitable for operators, however
if the language definition were changed such that otherwise undeduced
template function return types were deduced to be the type of the
return statement(s) in the function then the explicit template
argument specification would be unnecessary (if multiple return
statements differed in their types then the deduction would fail as
usual).
With that change, I believe that typeof would not be needed for case
(2) and would mainly be useful (though not essential) for case (1).

Even with the addition of typeof, I think that the change to the
return type deduction rules would be a useful addition for C++ 20xx.

To be honest, I haven't really thought this through completely, so I'd
be interested in any comments.

,Brian Parker.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

If typeof() were available, it may also be useful to standardise a
traits class to look up the result type, so that expressions that
return proxy classes could be given an opportunity to specialise the
default result type. e.g.

// standard traits class (either in a standard header or ?implicity
defined)
template<class T>
struct result_traits {
 typedef T result;  // by default, just return argument
}

// specialise for our Proxy class
template<>
struct result_traits<Proxy> {
 typedef double result; // assume Proxy returns a double
}

Knowing that this traits class was always available would allow one to
write functions that were accommodating to proxy-returning expressions
e.g. assuming A * B returns a proxy class.

template<class A, class B>
result_traits<typeof(A()*B())>::result f(A a, B b)
{
 result_traits<typeof(A()*B()>::result r = a * b;
 return r;
}

Or perhaps typeof() could be defined to implicity do this indirection
through the traits class, thus allowing the specialisation for proxy
classes with a simpler usage syntax.

The suggestion of using the syntax "expression::whatever" would also
cater for proxy classes provided they followed the convention of
having a typedef "result" defined, but this would not work for the
builtin types.

,Brian Parker.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Mark Russell writes:
> jbuck@synopsys.com (Joe Buck) writes:
> >For nested types, of course (STL).  So that you can write, say
> >
> >       typeof(a)::iterator a_iter = a.begin();
> >
> >instead of, say
> >
> >       map<some_big_type, some_other_type, complex_comparison>::iterator ...
>
> I'd like the syntax
>
>         x.::whatever
>
> to be equivalent to
>
>         {type of x}::whatever
>
> and similarly for x->::whatever.
>
> So you could write:
>
>         for (a.::iterator pos = a.begin(); pos != a.end(); ++pos) {
>                 // something
>         }
>
> I assume that .:: would not be hard for C++ parsers to cope with.  I think
> this gets most of the benefit of typeof, while avoiding some of the
> trickier issues.

The problem with this syntax is that it gets only the most superficial
benefits of typeof.  The true places were typeof would be useful are
places where .:: and ->:: wouldn't make sense.  For example, the
distance function in the standard looks like this:

template <class Iterator>
typename iterator_traits<Iterator>::difference_type
distance(Iterator first, Iterator last)

but if we had typeof, it could look like this:

template<class Iterator>
typeof(distance_type(Iterator)) distance(Iterator begin,Iterator end);

If typeof had been available, then the standards committee would not
have had to add the iterator_traits class to the standard.  Moreover, we
could be avoiding, for the most part, the proliferation of traits
classes that seem to be littered throughout the standard library.  Not
that I object to traits classes when they are truly necessary, but I
think that in many cases they could be eliminated if C++ had typeof.
--
Ian Haggard  ||  ian@shellus.com (work)  ||  IanHaggard@juno.com (home)
GNU/Linux -- "Oh, no, Mr Bill!" || #define employer_opinion !my_opinion
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]