why "const char &" as a parameter?

[Darin Johnson]

I keep running across that I'm maintaining that likes to define
function parameters as "const char &" or "const int &", etc.
Ie, constant reference parameters to a primitive type. This is
for normal functions, not operators.

I keep changing these to just have the plain old type, which
is more efficient (I'm using embedded systems) and less
obtuse. I'm puzzled why this one programmer insisted on
odd style everywhere. Maybe he's just applying a template
without thinking, as if it were like "const BigStruct &".
But I'm wondering if there's some school of thought out
there that encourages this and I'm missing something subtle.

--
Darin Johnson

[Juha Nieminen]

Re: why "const char &" as a parameter?

Darin Johnson wrote:

I keep changing these to just have the plain old type, which
is more efficient (I'm using embedded systems)

Did you check that your compiler is not already doing that
automatically for you?

[Rolf Magnus]

Re: why "const char &" as a parameter?

Juha Nieminen wrote:

Darin Johnson wrote:

>I keep changing these to just have the plain old type, which
>is more efficient (I'm using embedded systems)

>
Did you check that your compiler is not already doing that
automatically for you?

If the function is expanded inline, this is highly likely, but for other
functions OTOH, it's rather not likely.

[Pavel]

Re: why "const char &" as a parameter?

Darin Johnson wrote:

I keep running across that I'm maintaining that likes to define
function parameters as "const char &" or "const int &", etc.
Ie, constant reference parameters to a primitive type. This is
for normal functions, not operators.
>
I keep changing these to just have the plain old type, which
is more efficient (I'm using embedded systems) and less
obtuse. I'm puzzled why this one programmer insisted on
odd style everywhere. Maybe he's just applying a template
without thinking, as if it were like "const BigStruct &".
But I'm wondering if there's some school of thought out
there that encourages this and I'm missing something subtle.
>
--
Darin Johnson

It was already implicitly mentioned but before changing make sure the
functions do not use the address of the parameter; otherwise, the
behavior may change. Barring that, I am not aware of any drawbacks of
what you are doing -- as long as you know it gives your code an
advantage on your particular platform.

With the performance equal, I personally would still use by-value
convention because, for a prospective code reader, it results in less
tokens to scan and comprehend and less side effects to watch for.

If a parameter type is a template parameter, however, the whole
different can of worms should be considered. Unsure if it is relevant to
your question.

Hope this will help
-Pavel

[Gerhard Fiedler]

Re: why "const char &" as a parameter?

On 2008-02-23 13:49:33, Pavel wrote:

Darin Johnson wrote:

>I keep running across that I'm maintaining that likes to define function
>parameters as "const char &" or "const int &", etc. Ie, constant
>reference parameters to a primitive type. This is for normal
>functions, not operators.
>>
>I keep changing these to just have the plain old type, which is more
>efficient (I'm using embedded systems) and less obtuse. I'm puzzled
>why this one programmer insisted on odd style everywhere. Maybe he's
>just applying a template without thinking, as if it were like "const
>BigStruct &". But I'm wondering if there's some school of thought out
>there that encourages this and I'm missing something subtle.

>
It was already implicitly mentioned but before changing make sure the
functions do not use the address of the parameter; otherwise, the
behavior may change. Barring that, I am not aware of any drawbacks of
what you are doing -- as long as you know it gives your code an
advantage on your particular platform.

Besides taking the address, there's always also the possibility to cast the
const away, isn't there? This then may also change the behavior.

Gerhard

[Daniel T.]

Re: why "const char &" as a parameter?

Gerhard Fiedler <gelists@gmail. comwrote:

On 2008-02-23 13:49:33, Pavel wrote:

Darin Johnson wrote:

I keep running across that I'm maintaining that likes to define function
parameters as "const char &" or "const int &", etc. Ie, constant
reference parameters to a primitive type. This is for normal
functions, not operators.
>
I keep changing these to just have the plain old type, which is more
efficient (I'm using embedded systems) and less obtuse. I'm puzzled
why this one programmer insisted on odd style everywhere. Maybe he's
just applying a template without thinking, as if it were like "const
BigStruct &". But I'm wondering if there's some school of thought out
there that encourages this and I'm missing something subtle.

It was already implicitly mentioned but before changing make sure the
functions do not use the address of the parameter; otherwise, the
behavior may change. Barring that, I am not aware of any drawbacks of
what you are doing -- as long as you know it gives your code an
advantage on your particular platform.

>
Besides taking the address, there's always also the possibility to cast the
const away, isn't there? This then may also change the behavior.

Taking an address of the parameter or casting away constness would both
be dangerous...

void foo( const char& c ) {
// casting away constness would be undefined behavior and
// taking (and presumably saving) the address would be pointless.
}

int main() {
foo( '5' );
}

[Darin Johnson]

Re: why &quot;const char &amp;&quot; as a parameter?

On Feb 23, 4:06 am, Jeff Schwab <j...@schwabcen ter.comwrote:

Yes, there is. I have yet to see a compelling argument either for or
against.

Ok, thanks for replies everyone. I had checked the
compiler for PowerPC and it does use extra indirections
when used this way instead of optimizing it away.
(2 indirections, since the caller also has to put stuff
that would normally be in registers on the PowerPC
onto the stack first)

None of the code takes the address of the paramters,
and the functions aren't templated. I normally just
leave it alone, unless I've got the files checked out
and am modifying them anyway.

I had seen other styles that seemed "odd" until
others explained the reasoning behind them, and
wondered if this might be one of them.

--
Darin Johnson