Anybody have any preferences as to declaring primitive type parameter as
const, if the function body doesn't change it?
e.g.:
int f(int x)
{
return x+2;
}
versus
int f(const int x)
{
return x + 2;
}
I'm trying to update a project-wide style guide, and there are
developers who are insistent about the second style. 9 3995
red floyd wrote: Anybody have any preferences as to declaring primitive type parameter as const, if the function body doesn't change it?
e.g.:
int f(int x) { return x+2; }
versus
int f(const int x) { return x + 2; }
I'm trying to update a project-wide style guide, and there are developers who are insistent about the second style.
Have you tried asking them?
To asnwer your question, I prefer the latter. Adding a 'const' there
changes nothing for a function like that, except requires 6 characters
to be typed.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
red floyd wrote: Anybody have any preferences as to declaring primitive type parameter as const, if the function body doesn't change it?
e.g.:
int f(int x) { return x+2; }
versus
int f(const int x) { return x + 2; }
I'm trying to update a project-wide style guide, and there are developers who are insistent about the second style.
I'd say that it would make more sense if the logic was "reversed". I
have seen some style guides that suggested that function parameter
values should never be changed inside the function. Whenever it is
necessary to "play" with the value, it should be copied to a local
variable first. I don't follow this rule myself, but I'd agree that it
makes certain sense. For a programmer who follows such style guide, it
would be perfectly logical to _always_ declare all function parameters
as 'const' (apart from situations when it is impossible or makes no
sense, like references and arrays).
The logic that you propose ("declare it as const iff it is not changed")
doesn't appear to be very useful to me. Maybe it is just me, though...
--
Best regards,
Andrey Tarasevich
red floyd posted: Anybody have any preferences as to declaring primitive type parameter
as const, if the function body doesn't change it?
e.g.:
int f(int x) { return x+2; }
versus
int f(const int x) { return x + 2; }
I'm trying to update a project-wide style guide, and there are developers who are insistent about the second style.
I use the second whenever I won't be altering the object. However,
there's times when I do the likes of the following:
void Func( char *p )
{
for( ; *p; ++p ) *p = 'a';
}
On Thu, 22 Jun 2006 17:11:06 GMT, red floyd <no*****@here.dude> wrote: Anybody have any preferences as to declaring primitive type parameter as const, if the function body doesn't change it?
e.g.:
int f(int x) { return x+2; }
versus
int f(const int x) { return x + 2; }
Changes to the copy of a value in the 'function body' are an
implementation detail that should not affect the interface. I see no
advantage for version 2.
I'm trying to update a project-wide style guide, and there are developers who are insistent about the second style.
At least, the first version is written in the usual style.
Best wishes,
Roland Pibinger
Roland Pibinger wrote: On Thu, 22 Jun 2006 17:11:06 GMT, red floyd <no*****@here.dude> wrote: Anybody have any preferences as to declaring primitive type parameter as const, if the function body doesn't change it?
e.g.:
int f(int x) { return x+2; }
versus
int f(const int x) { return x + 2; }
Changes to the copy of a value in the 'function body' are an implementation detail that should not affect the interface. I see no advantage for version 2.
I'm trying to update a project-wide style guide, and there are developers who are insistent about the second style.
At least, the first version is written in the usual style.
For once, Roland, I agree with you. I was overruled by TPTB on my
project however. If a function doesn't tweak a parameter, then it's
const. If it changes (as the loop example someone else posted does),
then it's non-const.
Ugh.
On Thu, 22 Jun 2006 21:48:48 +0000, Roland Pibinger wrote: Changes to the copy of a value in the 'function body' are an implementation detail that should not affect the interface. I see no advantage for version 2.
Does declaring a by-value argument const affect the interface, though?
Consider:
void f(int i)
{
return;
}
void f(const int i)
{
return;
}
G++ and Comeau, at least, complain that the second is a redefinition of
the function, which makes sense to me. If that's the correct behavior, it
then presumably the const-ness of the arguments is not part of the
function signature. Thus, when you're declaring the interface, you can
omit the const, but in the function definition, you add the const, if it's
appropriate, for the same reason you would declare a local variable const.
On Thu, 22 Jun 2006 22:18:34 -0700, I V <wr******@gmail.com> wrote: On Thu, 22 Jun 2006 21:48:48 +0000, Roland Pibinger wrote: Changes to the copy of a value in the 'function body' are an implementation detail that should not affect the interface. I see no advantage for version 2.
Does declaring a by-value argument const affect the interface, though? Consider:
void f(int i) { return; }
void f(const int i) { return; }
G++ and Comeau, at least, complain that the second is a redefinition of the function, which makes sense to me. If that's the correct behavior, it then presumably the const-ness of the arguments is not part of the function signature. Thus, when you're declaring the interface, you can omit the const, but in the function definition, you add the const, if it's appropriate, for the same reason you would declare a local variable const.
You are right from the syntactical point of view. But shall the
following functions really be different WRT the constness of the
parameter?
int f1 (const int i) {
return i+2;
}
int f2 (int i) {
return i+=2;
}
red floyd wrote: Roland Pibinger wrote: On Thu, 22 Jun 2006 17:11:06 GMT, red floyd <no*****@here.dude> wrote: Anybody have any preferences as to declaring primitive type parameter as const, if the function body doesn't change it?
e.g.:
int f(int x) { return x+2; }
versus
int f(const int x) { return x + 2; }
Changes to the copy of a value in the 'function body' are an implementation detail that should not affect the interface. I see no advantage for version 2.
I'm trying to update a project-wide style guide, and there are developers who are insistent about the second style.
At least, the first version is written in the usual style.
For once, Roland, I agree with you. I was overruled by TPTB on my project however. If a function doesn't tweak a parameter, then it's const. If it changes (as the loop example someone else posted does), then it's non-const.
I clearly prefer version 2. What can be const should be const. For trivial
examples like the one above it may not make a difference but for more
complex functions it improves code readability because you can rely on the
value of the variable not changing throughout the function. I actually try
to avoid updating variables to preserve their constness e.g. instead of
int f(int x)
{
// use x
++x;
// use x
}
I write
int f(const int x)
{
// use x
const int x1 = x + 1;
// use x1
}
also helpful is the ?: operator to initialize const variables.
I think this style of programming captures some of the advantages of (pure)
functional languages.
On Fri, 23 Jun 2006 19:58:46 +0000, Roland Pibinger wrote: You are right from the syntactical point of view. But shall the following functions really be different WRT the constness of the parameter?
int f1 (const int i) { return i+2; }
int f2 (int i) { return i+=2; }
Why not? Should these two function differ as to the constness of the local
variable?
int f1()
{
const int i = get_value();
return i+2;
}
int f2()
{
int i = get_value();
return i+=2;
}
Obviously, for small, pointless example functions it doesn't really
matter. But, if there are advantages to making local variables const,
surely the same advantages apply to making parameters const. After all a
parameter _is_ a local variable; some features of it are also part of the
interface, but constness isn't one of these, so wrt const, the same rules
should apply to parameters as to any other local variable, I would think. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Marcin Vorbrodt |
last post by:
I understand that compiler may optimize better, if as parameters to my
functions i pass:
const Object &o
instead of
Object &o
All the implicit type conversion and all sounds good...
|
by: christopher diggins |
last post by:
I have heard it is considered good practice to pass function parameters as
const& as often as possible, is this true? Is it possible to go overboard?
And if so why? Thanks a lot in advance...
|
by: case2005 |
last post by:
Can anyone help with the following, I don't know if it's possible, but I'm
certain there must be a standard way of dealing with this.
I have the following:
template<typename FooBar, typename...
|
by: BigMan |
last post by:
Why does an emtpy class require an explicit default ctor in order to
initialize const objects of that type:
class EmptyClass
{
};
class EmptyClass2
{
EmtpyClass2( ) { }
|
by: Spoon |
last post by:
Hello,
I don't understand why gcc barks at me in this situation:
$ cat foo.c
extern void func(const int * const list, int nent);
int main(void)
{
int *p;
|
by: d3x0xr |
last post by:
---- Section 1 ----
------
x.c
int main( void )
{
char **a;
char const *const *b;
b = a; // line(9)
|
by: minseokoh |
last post by:
Hi,
Could someone explain why "const" is located after the function name
and what it means?
inline unsigned char *access(int off) const {
if (off < 0)
abort();
return (&bits_);
}
|
by: Darin Johnson |
last post by:
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...
|
by: lovecreatesbeauty |
last post by:
Is the keyword const necessary in the comparison function in qsort and
bsearch?
int (*compar)(const void *, const void *)
If the pointer cannot be dereferenced why worry if the pointed object...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
| |