Do we really need const?

Bruce Adams tortoise_74 at yeah.who.co.uk
Tue Sep 18 12:22:23 PDT 2007


Janice Caron Wrote:

> On 9/18/07, Bill Baxter <dnewsgroup at billbaxter.com> wrote:
> > Janice Caron wrote:
> > > About passing structs by reference: It's one of those things, like
> > > register or inline...
> > >
> > > Once upon a time, programmers used the keyword "register" because they
> > > thought they could do a better job than the compiler at figuring how
> > > to use its registers.
> > >
> > > Once upon a time, programmers used the keyword "inline" because they
> > > thought they could do a better job than the compiler at figuring out
> > > what to inline and what not.
> > >
> > > Now people explicitly choose between f(s) and f(ref s) (where s is a
> > > struct and the function does not modify it) because they think they
> > > can do a better job than the compiler at figuring out how to pass
> > > parameters to functions. I say give control back to the compiler. Lets
> > > let "ref" mean "the function may modify the parameter", and the
> > > absense of ref mean "the function may not modify the parameter", but
> > > leave it to the compiler to decide what is the most efficient way to
> > > pass the data to the function.
> >
> > This thought has occurred to me before to.  I think issue becomes that
> > the function signature may no longer enough for a compiler to tell what
> > kind of code it needs to generate to call the function.
> 
> Actually, I think it's possible my proposal may not have been
> understood. Under my suggestion, if the caller passes a struct...
> 
> f(s)
> 
> ...and the callee declares the function as...
> 
> void f(S s)
> 
> ...then all information is known. Both ends must surely know s.sizeof
> at compile time? And since that's the /only/ thing the compiler needs
> to know to make the decision.
> 
S could be an opaque type so s.sizeof may still be undefined.

Bruce.



More information about the Digitalmars-d mailing list