[Tim]
>> A non-broken compiler always allowd passing a
>>
>> T
>>
>> actual argument to a
>>
>> const T
>>
>> ...
[David Abrahams]
> I don't know if C differs from C++ in this respect, but in C++, const
> in a prototype argument list has no effect whatsoever (unless
> modifying the referent of a pointer or reference).
I meant T above to include cases like T = char*.
> So:
>
> void f(const int x);
>
> is identical to
>
> void f(int x);
Not in the presence of
#define int char*
it's not.
> In fact, a very useful idiom is:
>
> void f(int x); // prototype. No const; it communicates nothing
> // useful to the caller
>
> ...
>
> void f(const int x) // implementation. I know I can always use x
> { // and get the original argument value
> ...
> }
All seriousness aside, that's useful in C too, but rarely seen, since the
meaning of C code is always self-evident.
> ...
> There's a long discussion even now on comp.lang.c++.moderated about
> whether const-correctness is a dogma.
I prefer to think of it as a crock, except when I'm working on embedded C
applications that need to know which static data is ROMable. So far that
hasn't happened. We came close once at Dragon, until the vendor revealed
their compiler didn't support static data at all.
That said, I'm happy to add const decorations to Python's C API decls where
it helps C++ users, provided we get to stop about a thousand miles short of
making anyone truly happy.
compromise-is-the-art-of-spreading-misery-ly y'rs - tim
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4