469,593 Members | 2,057 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,593 developers. It's quick & easy.

why "const char &" as a parameter?

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
Feb 23 '08 #1
6 4944
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?
Feb 23 '08 #2
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.

Feb 23 '08 #3
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
Feb 23 '08 #4
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
Feb 23 '08 #5
Gerhard Fiedler <ge*****@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' );
}
Feb 24 '08 #6
On Feb 23, 4:06 am, Jeff Schwab <j...@schwabcenter.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
Feb 25 '08 #7

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

4 posts views Thread by barney | last post: by
2 posts views Thread by s88 | last post: by
5 posts views Thread by martin | last post: by
4 posts views Thread by C. J. Clegg | last post: by
20 posts views Thread by liujiaping | last post: by
4 posts views Thread by Virtual_X | last post: by
reply views Thread by suresh191 | last post: by
4 posts views Thread by guiromero | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.