Re: [boost] Most needed/desired features in C++

From: Daniel Frey (daniel.frey_at_[hidden])
Date: 2002-02-19 06:39:25

Emily Winch wrote:
> 
> Daniel Frey said:
> 
> [ snipped my example of function declared using auto ]
> 
> > And how would you forward-declare this function? What is the compiler
> > expected to return without seeing the function's definition? I don't
> > think that it is a good idea to allow 'auto' for return types. (And yes,
> > typeof() doesn't work too, for the same reason). IMHO this leads to even
> > more forced 'inline'-functions like templates already gave us (as
> > compilers don't support 'export').
> 
> The compiler is expected to barf if it can't see the definition. People who
> need to export their template code will just have to Not Use Auto.
> 
> "auto" certainly won't give us _more_ "inline" functions than we already
> have
> at the moment. "auto" is useless with functions that aren't templates, and
> those functions are already "inline".

Is it really useless? It is convenient and the average programmer will
use it for almost everything. C++ already yields a great number of
weapons and the manual doesn't explain the little red button on the left
side :) 'auto' can easily be misused not just for template functions
where it could make sense. Or should the language limit 'auto' to
template functions? What about a function the should return the result
from boost::bind(...)?
I am probably biased as I have worked too much with Clipper in my former
job, but I hate it when the compiler (or the language) tries to be
over-clever, especially when it comes to types. I like to have as much
compile-time checks as possible and 'auto' will IMHO prevent this when
used too much. Another problem: The code is usually the best
documentation. Seeing a functions return types helps me a lot more than
reading the authors comment: "Return the Right Thing(tm)" (if there is a
documentation at all). As a user, I can only use 'auto' to save the
result of such a function and I still have no clue what I actually have
as once the information is hidden by the compiler, it is really hard to
find out what the type is. Imagine 'auto' being used by a chain of
nested functions. Can you tell what happens? I like to read and
understand my code as local as possible, without having to look at a
function definition to find out what it actually returns.

> IMO the advantages of using auto _for some functions_ by far outweigh the
> disadvantages of not being able to export the template. The workarounds for
> not having auto get stinky really quickly (for both the author and the user
> of
> the code) once you get into even slightly complicated metaprogramming. If I
> _need_ to export the template, nothing forces me to use auto: the stinky
> workarounds will still be there :)

My influence on the standard is roughly zero, I just would like to see
that people with a legitimate use for 'auto' don't throw all caution
over-board and focus on quick-and-easy solutions. If finally 'auto' as a
keyword is the only and best option to solve the problems, OK, but it
shouldn't be added just because it's easy.

Regards, Daniel

--
Daniel Frey
aixigo AG - financial training, research and technology
Schloß-Rahe-Straße 15, 52072 Aachen, Germany
fon: [phone], fax: [phone]
eMail: daniel.frey_at_[hidden], web: http://www.aixigo.de