Board index » delphi » Declaring method signatures - constant or non constant

Declaring method signatures - constant or non constant

Hello,

I understand the difference in the following declarations:

1) function GetVendorID(Vendor : ShortString) : Integer;
2) function GetVendorID(const Vendor : ShortString) : Integer;
3) function GetVendorID(var Vendor : ShortString) : Integer;

What I am not sure of, is that if you know the variable being passed into a
method is not going to change should you *always* declare that method's
variable using the "const" keyword?

If so what are you gaining other than clarity?

Thanks

--
Reid Roman
Future Generation Software
http://www.fgsoft.com
re...@fgsoft.com

 

Re:Declaring method signatures - constant or non constant


Quote
"Reid Roman" <re...@fgsoft.com> wrote:
>I understand the difference in the following declarations:

>1) function GetVendorID(Vendor : ShortString) : Integer;
>2) function GetVendorID(const Vendor : ShortString) : Integer;
>3) function GetVendorID(var Vendor : ShortString) : Integer;

>What I am not sure of, is that if you know the variable being passed into a
>method is not going to change should you *always* declare that method's
>variable using the "const" keyword?

>If so what are you gaining other than clarity?

There's more to it than clarity. If a parameter is declared "const",
the compiler may generate different code to pass it more efficiently.
For example, a large record structure could be passed just as a
pointer and no copying of the data is needed. But there are syntactic
and symantic effects as well. Your code can not even appear to modify
that parameter, or pass it to another routine that might modify it.

In general, you may (not always) gain some performance advantage by
passing a parameter as const.

Good luck.

Kurt

Re:Declaring method signatures - constant or non constant


I have also heard that if it is declared using the const keyword than the
variable is placed on the stack.  Is that true?  And if so, will get "stack
overflow" errors if I go through this project and add "const" to the method
declarations of all the methods  that will not change the variable but
rather just refer to it internally in it's processing?

Quote
> >If so what are you gaining other than clarity?

> There's more to it than clarity. If a parameter is declared "const",
> the compiler may generate different code to pass it more efficiently.
> For example, a large record structure could be passed just as a
> pointer and no copying of the data is needed. But there are syntactic
> and symantic effects as well. Your code can not even appear to modify
> that parameter, or pass it to another routine that might modify it.

> In general, you may (not always) gain some performance advantage by
> passing a parameter as const.

So with that said, since I am not technically savvy enough to know what the
compiler is going to do with each method call, if you know that the method
that receives the variable is not going to change it or pass it on to
another method that is, should you as a rule add the "const" keyword?

For instance just quickly browsing the StdCtrls unit in the VCL, their is a
method used in the following way:

procedure TCustomMemo.SetAlignment(Value: TAlignment);
begin
  if FAlignment <> Value then
  begin
    FAlignment := Value;
    RecreateWnd;
  end;
end;

The "Value" parameter is not changed, only referred to at runtime to set a
private variable, yet the "const" keyword is not used.

So I am still a bit unclear as to what rules other than what has been
discussed will give me a better sense of when it should be used.

Thanks,

--
Reid Roman
Future Generation Software
http://www.fgsoft.com
re...@fgsoft.com

Re:Declaring method signatures - constant or non constant


Quote
"Reid Roman" <re...@fgsoft.com> wrote:
>I have also heard that if it is declared using the const keyword than the
>variable is placed on the stack.  Is that true?

Depends on the type of the variable. It is certainly not true in
general.

Quote
>And if so, will get "stack
>overflow" errors if I go through this project and add "const" to the method
>declarations of all the methods  that will not change the variable but
>rather just refer to it internally in it's processing?

Unlikely. Your allowed stack under Win32 is so huge that it is
extremely unlikely you will ever get a stack overflow (absent a bug in
your app, of course<g>.) And if anything, using const will reduce the
amount of stack space required, since a const record structure does
not have to be duplicated.

Quote
>So with that said, since I am not technically savvy enough to know what the
>compiler is going to do with each method call, if you know that the method
>that receives the variable is not going to change it or pass it on to
>another method that is, should you as a rule add the "const" keyword?

I would unless the type of the variable is trivial, e.g., an Integer,
or something similar. There's another advantage in that if you think
you aren't modifying it and you declare it as const, you get nailed
immediately<g>.

Quote
>procedure TCustomMemo.SetAlignment(Value: TAlignment);
>begin
>  if FAlignment <> Value then
>  begin
>    FAlignment := Value;
>    RecreateWnd;
>  end;
>end;

>The "Value" parameter is not changed, only referred to at runtime to set a
>private variable, yet the "const" keyword is not used.

In  this case a TAlignment is passed as a simple Integer type.
Changing it to const wouldn't gain you anything except to catch you if
you tried to modify it as I mentioned above.

Quote
>So I am still a bit unclear as to what rules other than what has been
>discussed will give me a better sense of when it should be used.

I'm not sure there is a generic rule that can be relied upon. You can
review the parameter passing conventions on pg 12-1 of the OP manual.
That's part of it. But then you need to consider that if the parameter
is not declared const, a copy of the data has to be made by the
callee. So if you passed a 128 byte record, for example, the callee
has to allocate a new record, copy the original data into it, and
then, on exit, deallocate it.

Good luck.

Kurt

Other Threads