Re: Acceptable to "const" a parameter in the definition but not in
the declaration?
* Paavo Helde, on 09.06.2010 00:33:
"Alf P. Steinbach"<alfps@start.no> wrote in
news:humcfr$7l7$1@news.eternal-september.org:
[...]
Placing the copying at the call site, on the other hand, allows that
copying to be elided when the compiler can prove that there's no
aliasing and can assume that foo does not change the actual argument
via the passed pointer. So this could be an optimization. But if the
source code implementation of foo is e.g.
void foo( T v ) { v = bar(); blahblah(); use( v ); }
then, at least for local code generation, the code generated for foo
would also have to copy v, resulting in potentially two copy
operations per call (one at each call site and one inside foo) instead
of just one: hardly an optimization!
However, if a 'T const' in the declaration guaranteed a 'T const' in
the definition, then the compiler could do this optimization, perhaps
with some wording in the standard that you're in UB-land if you cast
away the const. Because then the compiler could assume that foo would
not modify the actual argument via the pointer. All it'd have to do
would be to prove no aliasing for any particular call site, and then
it could just pass a pointer with no copying.
If the compiler can prove the function does not modify the argument, it
can apply this optimization anyway, regardless of whether there is
'const' present or not.
That "if" is pretty big: with the rules that we have it would require whole
program optimization and is not possible with dynamic libraries without
introducing overhead (the opposite of optimization).
Since the context has been lost, and you're arguing below is if the context was
very different than what it actually was:
The context for the above quote was whether a possible rationale for the current
rules held water or not, and it did not hold water.
And about adding new UB in the language - I would have thought there is
already too much of that. Besides, such a change could break existing
code in very annoying ways.
I discussed the rationale for the existing rules. I did not discuss changing the
rules. In particular, I did not advocate introducing new UB.
Essentially, any restriction enforced by the type system increases
what is known and so may facilitate some optimization, not just
correctness. ;-)
Except the 'const' keyword in interfaces, which can be cast away legally
in most cases.
It's unclear what you're referring to.
Banning const_cast would indeed resolve this problem,
It's unclear what you're referring to.
but
would create many more instead.
I did not propose or discuss "banning const_cast". With C++98 rules const_cast
for an original const object is UB if you modify the result. The alternative
rules I discussed would presumably have extended that to formal arguments.
I think I will stick to passing const references, it's just one more
character to type after all.
That statement does not make sense to me, I'm sorry.
Cheers,
- Alf
--
blog at <url: http://alfps.wordpress.com>