Board index » cppbuilder » Re: const

Re: const


2006-02-22 07:13:56 PM
cppbuilder65
"Andrue Cope [TeamB]" < XXXX@XXXXX.COM >wrote:
Quote
Funnily enough anyone who introduces const to an existing project tends
to mutter the same thing under their breath :)
I find the best way is to declare absolutely everything const, and then
to let the compiler tell me what absolutely cannot be const. But it's a
long and tedious process as the changes ripple outwards.
For new code, it's always const unless it can't be.
Alan Bellingham
--
ACCU Conference 2006 - 19-22 April, Randolph Hotel, Oxford, UK
 
 

Re:Re: const

Alan Bellingham wrote:
Quote
But it's a long and tedious process as the changes ripple outwards.
Oh yes. I spent an amusing six months retrofitting 'const' to our
runtime library. It's still not complete but it's pretty close. The
ugly bit is the API. I really couldn't expose clients to 'const'
because that would have rippled through 95% of our source code
(probably over 30MB and eight developers including all our offices) so
I had to use const_cast :(
That's on the list of things I'd like to fix..along with (as of this
morning) rewriting one of our core I/O classes. Sigh. It's amazing how
much ugliness you can find when digging around in the darker depths of
a 12 year old project. 'char *' parsing. Not even 'char const *'. Yuk.
Quote
For new code, it's always const unless it can't be.
Oh yes although I sometimes still forget on 'methods' :)
--
Andrue Cope [TeamB]
[Bicester, Uk]
info.borland.com/newsgroups/guide.html
 

Re:Re: const

Quote
Oh yes. I spent an amusing six months retrofitting 'const' to our
runtime library
and how much advantage have you reaped from the exercise. In other words,
how much could the compiler exploit the new freedoms for optimization ?
 

{smallsort}

Re:Re: const

John Blackburn wrote:
Quote
and how much advantage have you reaped from the exercise. In other
words, how much could the compiler exploit the new freedoms for
optimization ?
Not very much for the compiler as it was mainly upgrading or replacing
'char *'. The real gain was in protecting me from careless and foolish
mistakes.
--
Andrue Cope [TeamB]
[Bicester, Uk]
info.borland.com/newsgroups/guide.html
 

Re:Re: const

"John Blackburn" < XXXX@XXXXX.COM >writes:
Quote
>Oh yes. I spent an amusing six months retrofitting 'const' to our
>runtime library

and how much advantage have you reaped from the exercise. In other words,
how much could the compiler exploit the new freedoms for optimization ?
The only optimization I know of is the compiler's ability to inline
const local variables, like here, x could be inlined into the
expression using it:
int f(int n)
{
const int x = 23;
return x * x / n;
}
The compiler could inline it anyway, but when it's const there is no
storage requirement for x.
Adding const to a function interface is more for correct usage rather
than for performance.
--
Chris (TeamB);
 

Re:Re: const

It can reduce bugs in an application if used properly.
Rgds Pete
Quote
"John Blackburn" < XXXX@XXXXX.COM >writes:
>and how much advantage have you reaped from the exercise. In other
>words,
>how much could the compiler exploit the new freedoms for optimization ?
 

Re:Re: const

Andrue Cope [TeamB] wrote:
Quote
Funnily enough I was wondering on my lunchtime work if there would be
any milleage in allowing 'const' to be used with a non-member function
to indicate that it doesn't change any static data or to prevent
someone changing static data. I suppose that would depend how much
static data you had :)
Something like:
www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1703.pdf
the 'static pure' qualifier.
Pure functions are very useful qualifiers when trying to schedule work
across multiple CPUs, as each invocation is guaranteed independent of
any other. Thus, you could safely unroll a loop across multiple CPUs
at once, as a compiler optimization invisible to code author.
So there is potentially a very real benefit to be gained from this,
especially when you think about hardware that will be commonplace in
the next decade.
That said, you also need compiler vendors buy-in to make it work, and
so far they don't look convinced it would be worth the effort.
--
AlisdairM(TeamB)
 

Re:Re: const

"Andrue Cope [TeamB]" < XXXX@XXXXX.COM >wrote in message
Quote
John Blackburn wrote:

>and how much advantage have you reaped from the exercise. In other
>words, how much could the compiler exploit the new freedoms for
>optimization ?

Not very much for the compiler as it was mainly upgrading or replacing
'char *'. The real gain was in protecting me from careless and foolish
mistakes.

Good point.
 

Re:Re: const

Chris Uzdavinis (TeamB) < XXXX@XXXXX.COM >wrote:
Quote
"John Blackburn" < XXXX@XXXXX.COM >writes:

>>Oh yes. I spent an amusing six months retrofitting 'const' to our
>>runtime library
>
>and how much advantage have you reaped from the exercise. In other words,
>how much could the compiler exploit the new freedoms for optimization ?

The only optimization I know of is the compiler's ability to inline
const local variables, like here, x could be inlined into the
expression using it:

int f(int n)
{
const int x = 23;
return x * x / n;
}

The compiler could inline it anyway, but when it's const there is no
storage requirement for x.
I wonder whether compilers wouldn't be able to
further optimize. Consider this:
struct X {
X() : i(0) {}
void f() const;
int i;
};
// ...
while( blah() ) {
X x;
x.f();
};
// ...
The compiler might be able to see 'x' as a loop
invariant and move it out of the loop. However,
since 'this' could be 'const_cast<>()'ed within
'X::f()', this might be just a theoretical idea...
Quote
Adding const to a function interface is more for correct usage rather
than for performance.
That's certainly true.
Schobi
--
XXXX@XXXXX.COM is never read
I'm Schobi at suespammers dot org
"If you put a large switch in some cave somewhere, with a sign
on it saying 'End-of-the-World Switch. PLEASE DO NOT TOUCH',
the paint wouldn't even have time to dry."
Terry Pratchett
 

Re:Re: const

"Hendrik Schober" < XXXX@XXXXX.COM >writes:
Quote
>Adding const to a function interface is more for correct usage rather
>than for performance.

That's certainly true.
But as Alistair pointed out, if one could indicate that a function is
completely without side effect, then it could be optimized in
additional ways. With today's C++ that's not possible, due to
const_cast, mutable, and other operations that enable an end-run
around constness.
--
Chris (TeamB);