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

From: Emily Winch (emily_at_[hidden])
Date: 2002-02-19 07:10:33

Daniel Frey said:

> > 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(...)?

Yep, OK, auto is useful for more than I thought. For things like returning
the result of boost::bind(...), I think it really would be useful and not,
um, 
misuseful :)

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

mmm. This is the one drawback. If we could just have "auto" with a
convenient
place where the function author should put their concept checking on the
return type, 
this would serve as documentation for the user, who can look and say "aha!
this 
function returns a thing that I can do X and Y with".

But, if you think about it, this problem is quite similar to the problems 
posed by return _values_. If I write

int foo(int x, int y);

and omit to document precisely what the function does, and what range of
values
can be expected from it, then you are stuck reading the source to find
out... and if 
there's a chain of nested functions, this gets complex. Our only fix is
proper 
documentation, or preconditions and postconditions, and the language doesn't

provide a framework for that.

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

don't worry, so's mine :)

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

Agreed. At the moment, I'm convinced that it is the best (not the only)
option, and that the need for it overrides the concern over providing bad or
inexperienced programmers more things to make a mess with. I can argue the
first of those things, but the second is only an opinion with nothing to
back it up. (Other than a gut 
feeling that if people are going to write code and not explain what it does,
they'll 
do it anyway, auto or not).

Emily.