By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
454,479 Members | 1,749 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 454,479 IT Pros & Developers. It's quick & easy.

HOWTO: const and pointer variants in C and C++

P: n/a
HOWTO: const and pointer variants in C and C++ :

void test()
{
int n = 1; // n is non-const data of type int
++n; // ok

const int c = 2; // c is const data of type int
// ++c; // err

// Case1:
int* p1 = &n; // p1 is a non-const ptr to non-const data
++p1; // ok
*p1 += 3; // ok

// int* px = &c; // err

// Case2:
int* const p2 = &n; // p2 is a const ptr to non-const data
// ++p2; // err
*p2 += 3; // ok

// Case3:
const int* p3 = &c; // p3 is a non-const ptr to const data
++p3; // ok
// *p3 += 3; // err

// Case4:
const int* const p4 = &c; // p4 is a const ptr to const data
// ++p4; // err
// *p4 += 3; // err

// Case5:
const int* const p5 = &n; // Similar to Case4 but here non-const n is treated as const data when accessed via p5
// ++p5; // err
// *p5 += 3; // err

// Case6:
const int *const p6 = &c; // same as Case4
// ++p6; // err
// *p6 += 3; // err

// Case7:
const int *const p7 = &n; // Same as Case5
// ++p7; // err
// *p7 += 3; // err

// const* int p8 = &n; // err
// const* int p9 = &c; // err

// const int const* pa = &n; // err: duplicate 'const'
// const int const* pb = &c; // err: duplicate 'const'
}

For safety and speed you should use const whenever possible.

Nov 11 '08 #1
Share this Question
Share on Google+
13 Replies


P: n/a
Adem wrote:
HOWTO: const and pointer variants in C and C++ :

void test()
{
int n = 1; // n is non-const data of type int
++n; // ok

const int c = 2; // c is const data of type int
// ++c; // err
I hate to be pedantic, but this line isn't an error since it's commented out.
// Case1:
int* p1 = &n; // p1 is a non-const ptr to non-const data
++p1; // ok
*p1 += 3; // ok
No, that's undefined behavior because you're dereferencing a past-the-end
pointer. This isn't, though:

int* p1 = &n;
++p1;
--p1;
*p1 += 3;

[...]
For safety and speed you should use const whenever possible.
Care to show any examples of where const helps speed-wise? That is, a
program where removing const wouldn't change the semantics of the program,
but would reduce its speed. I'm not arguing against using const, just
questioning this often-made claim.
Nov 11 '08 #2

P: n/a
blargg wrote:
Care to show any examples of where const helps speed-wise? That is, a
program where removing const wouldn't change the semantics of the program,
but would reduce its speed. I'm not arguing against using const, just
questioning this often-made claim.
const could help a compiler determine if a variable
could be replaced with a constant in machine code.
Opcodes with operands, usually have smaller faster
versions which operate on constants.

On general principle,
I prefer to give the compiler whatever information I can.

I don't think that removing const
ever changes the semantics of a program.
Assuming that by that, you mean to start with a correct program
which happens to use the const keyword, and then remove the keyword.

--
pete
Nov 11 '08 #3

P: n/a
pf*****@mindspring.com wrote:
blargg wrote:
Care to show any examples of where const helps speed-wise? That is, a
program where removing const wouldn't change the semantics of the program,
but would reduce its speed. I'm not arguing against using const, just
questioning this often-made claim.

const could help a compiler determine if a variable
could be replaced with a constant in machine code.
Opcodes with operands, usually have smaller faster
versions which operate on constants.
[...]

Yes, but can you provide EXAMPLES of where const actually helps the
compiler determine this, where it couldn't determine it without const?
About the only one is a non-static variable at file scope, where the
compiler can't in general assume its value after code in other translation
units has executed, unless it's declared const. A variantis a local const
object whose address is passed to a function; removing const would prevent
the compiler from assuming its value doesn't change during the function
call. I contend that these are rare cases.
Nov 11 '08 #4

P: n/a
pete wrote:
[...]
I don't think that removing const
ever changes the semantics of a program.
struct test {
int f() {return 1;}
int f() const {return 0;}
};

int main()
{
/*const*/ test x;
return x.f();
}
[...]
Schobi
Nov 11 '08 #5

P: n/a
blargg wrote:
pf*****@mindspring.com wrote:
>blargg wrote:
>>Care to show any examples of where const helps speed-wise? That is, a
program where removing const wouldn't change the semantics of the program,
but would reduce its speed. I'm not arguing against using const, just
questioning this often-made claim.
const could help a compiler determine if a variable
could be replaced with a constant in machine code.
Opcodes with operands, usually have smaller faster
versions which operate on constants.
[...]

Yes, but can you provide EXAMPLES of where const actually helps the
compiler determine this, where it couldn't determine it without const?
'const' in C++ has serves multiple purposes. It can 1) declare constness
of an object itself, and 2) declare constness of an access path to an
object, 3) serve as a distinguishing trait in overload resolution.

How the third role can be used in "optimization" is rather obvious. But
these are basically user optimizations, as opposed to complier
optimizations. I assume that you are talking about compiler
optimizations, to which the third role is not immediately relevant.

I don't think I need to provide examples of how the first role of
'const' can speed up the code. They are immediately obvious as well.
Constant values can be calculated at compile time. Code that depends on
constant values can be reduced at compile time. Etc.

The second role of 'const' is more about discipline, than about
optimization. In general case, the constness of access path does not
imply the constness of the object this access path leads to. Which means
that in general case without preforming a thorough aliasing analysis,
the compiler can't do much based on the constness of access path itself.
And if the compiler is smart enough to perform a sufficiently thorough
aliasing analysis, it should be smart enough to optimize it regardless
of whether the explicit 'const' is supplied by the user or not. So, I'd
agree that the second role of 'const' by itself is not immediately
useful for compiler optimizations. However, it is worth noting that it
might become quite useful if the user explicitly gives the compiler the
permission to perform "overly agressive" optimizations (meaning, that
they might be formally invalid in general case) by assuming some
aliasing properties of the code, instead of trying to derive them from
the code itself. (I'm not sure, but it is quite possible that the
combination of 'const' with C99's 'restrict' allows for more valid
straightforward optimizations that just a mere 'restrict'.)

--
Best regards,
Andrey Tarasevich
Nov 11 '08 #6

P: n/a
blargg wrote:
pf*****@mindspring.com wrote:
>blargg wrote:
>>Care to show any examples of where const helps speed-wise? That is, a
program where removing const wouldn't change the semantics of the program,
but would reduce its speed. I'm not arguing against using const, just
questioning this often-made claim.
const could help a compiler determine if a variable
could be replaced with a constant in machine code.
Opcodes with operands, usually have smaller faster
versions which operate on constants.
[...]

Yes, but can you provide EXAMPLES of where const actually helps the
compiler determine this, where it couldn't determine it without const?
No, I can't really.

--
pete
Nov 11 '08 #7

P: n/a
Hendrik Schober wrote, On 11/11/08 15:41:
pete wrote:
>[...]
I don't think that removing const
ever changes the semantics of a program.

struct test {
int f() {return 1;}
int f() const {return 0;}
};
This is not valid C and is an example of why cross-posting between C and
C++ groups is generally a bad idea. Please keep answers which are
specifically C++ in groups where C++ is topical.
--
Flash Gordon
If spamming me sent it to sm**@spam.causeway.com
If emailing me use my reply-to address
See the comp.lang.c Wiki hosted by me at http://clc-wiki.net/
Nov 11 '08 #8

P: n/a
Flash Gordon wrote:
>
Is it really too difficult for people with C++ specific answers to drop
the cross-post to comp.lang.c?
Dropping is not difficult. _Noticing_ might be. I, for one, use
Thunderbird and most of the time don't notice that I post to multiple
newsgroups at once.

--
Best regards,
Andrey Tarasevich
Nov 11 '08 #9

P: n/a
On 11 Nov 2008 at 21:20, Flash Gordon wrote:
People in all three of these groups (including comp.lang.c) need to
watch out for cross-posts and drop comp.ang.c++ where it is a C
specific answer, and comp.lang.c where it is a C++ answer,
You might /like/ people to do this for your own political reasons. But
they don't /need/ to. They can do whatever they think is appropriate,
whether it suits your prejudices or not.
and tell the OP what a bad idea the cross-post is because of the
problems it causes.
There is no problem - you just choose to believe there is for your own
political reasons.

Nov 11 '08 #10

P: n/a
On Nov 11, 4:34 pm, blargg....@gishpuppy.com (blargg) wrote:
pfil...@mindspring.com wrote:
blargg wrote:
Care to show any examples of where const helps speed-wise?
That is, a program where removing const wouldn't change
the semantics of the program, but would reduce its speed.
I'm not arguing against using const, just questioning this
often-made claim.
const could help a compiler determine if a variable could be
replaced with a constant in machine code. Opcodes with
operands, usually have smaller faster versions which operate
on constants.
[...]
Yes, but can you provide EXAMPLES of where const actually
helps the compiler determine this, where it couldn't determine
it without const?
It's generally true of top-level const. Something like:

int const i = 42 ;

, for example. The compiler knows that regardless of what
happens elsewhere in a legal program, i will always be equal to
42.
About the only one is a non-static variable at file scope,
where the compiler can't in general assume its value after
code in other translation units has executed, unless it's
declared const. A variantis a local const object whose address
is passed to a function; removing const would prevent the
compiler from assuming its value doesn't change during the
function call. I contend that these are rare cases.
In C, probably, since such variables can't be used in constant
expressions. In C++, it's actually quite common.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Nov 12 '08 #11

P: n/a
Flash Gordon wrote:
Hendrik Schober wrote, On 11/11/08 15:41:
[...]
This is not valid C and is an example of why cross-posting between C and
C++ groups is generally a bad idea. Please keep answers which are
specifically C++ in groups where C++ is topical.
I'm sorry. I, too, hadn't noticed this was cross-posted.

Schobi
Nov 12 '08 #12

P: n/a
On Nov 11, 11:19*pm, "Adem" <for-usenet...@alicewho.comwrote:
* * const *int* * * * p3 = &c; *// p3 is a non-const ptr to const data
Not exactly, e.g. :
const int *p3 = &n; // not error
Also, you omitted:
int const *p
int const *const p
Nov 12 '08 #13

P: n/a
pete wrote:
blargg wrote:
>Care to show any examples of where const helps speed-wise? That is, a
program where removing const wouldn't change the semantics of the
program,
but would reduce its speed. I'm not arguing against using const, just
questioning this often-made claim.

const could help a compiler determine if a variable
could be replaced with a constant in machine code.
Opcodes with operands, usually have smaller faster
versions which operate on constants.

On general principle,
I prefer to give the compiler whatever information I can.

I don't think that removing const
ever changes the semantics of a program.
Assuming that by that, you mean to start with a correct program
which happens to use the const keyword, and then remove the keyword.
Well removing const can have serious effects in a C++ program where
overload resolution might be changed.
Nov 13 '08 #14

This discussion thread is closed

Replies have been disabled for this discussion.