Prev: Last Call for Papers Reminder (extended): International Conference on Soft Computing and Applications ICSCA 2010
Next: Mutable Objects and Thread Boundaries
From: Lew on 21 Jul 2010 00:51
On 07/21/2010 12:06 AM, Peter Duniho wrote:
> Java's "final" _could_ have applied to the type, as it does in C++. But
> it doesn't. This is what everyone is trying to point out to you. The
> fact that Java doesn't have pass-by-reference in no way makes "const"
> and "final" equivalent. Even ignoring pass-by-reference in C++, "const"
> still is a stronger guarantee than "final" in Java.

I am not saying that they're equivalent. I've pointed out before that I'm not
saying that they're equivalent. Straw man.

Lew wrote:
>> As for changing the values in structures to which the argument points,
>> that isn't prevented in C++ by making a pointer 'const', only by
>> making the thing to which it points 'const', something that Java does
>> and for which it uses - guess what? - 'final'. It does a similar
>> thing, just in a different way.

Peter wrote:
> No, it doesn't. Java doesn't have any way to prevent values in
> structures to which the argument points from being modified. Not in the
> parameter declaration, that is.

That's the point of saying that Java does it "in a different way".

> You can, of course, make the fields in a class "final", preventing them
> from being modified. But that would prevent them from being modified
> _ever_. Applying "const" to a type in a parameter list in C++ only
> prevents modification _in that method_. The object can still be modified
> later elsewhere.

Thank you for elucidating some of the differences.

I've said that 'final' is "sort of similar" to 'const'. I've never said that
they're the same. I've disavowed saying that they're the same. Of course
they're different!

Lew wrote and Peter cited:
>> No one is saying that 'final' and 'const' are the same. If you think
>> that's my point, you haven't been reading my posts. The languages

See?

>> themselves differ, so there's no way they can be the same, like in the
>> case of method arguments. But they are similar, insofar as both
>> prevent change to the variable to which they're attached.

> Many of your posts have seemed to be claiming that "const" in C++ is
> similar enough to "final" so as there to not be any point in discussing

Seeming is in the eye of the beholder. I've pointed out many times that they
are only "sort of similar". I've explicitly disavowed saying that they're
equivalent. I don't know how the hell you read into that that I said they're
is no point in discussing what's different. I don't disagree with the points
you make, only with you claiming that I said something different from what I
actually said, then trying to pin that on me.

> what's different. C++'s "const" is actually quite a bit different from
> "final" in Java, sharing only one small aspect of its behavior with
> Java's "final".

OK.

--
Lew
From: Peter Duniho on 21 Jul 2010 01:10
Lew wrote:
> [...]
>>> themselves differ, so there's no way they can be the same, like in the
>>> case of method arguments. But they are similar, insofar as both
>>> prevent change to the variable to which they're attached.
>
>> Many of your posts have seemed to be claiming that "const" in C++ is
>> similar enough to "final" so as there to not be any point in discussing
>
> Seeming is in the eye of the beholder. I've pointed out many times that
> they are only "sort of similar". I've explicitly disavowed saying that
> they're equivalent. I don't know how the hell you read into that that I
> said they're is no point in discussing what's different.

Perhaps it was statements like "Or perhaps Java's 'final' doesn't need
those 'perks' because of the other differences between the languages",
or "Since Java supports only pointers and primitives and not
value-object variables, the semantics of its 'final' are bound to differ
from those of C++'s 'const'".

Whatever. It's just how I read the statements. You may not understand
how I got the conclusion I did, but the fact remains that I did, and
it's possible others did as well.

In any case, your comments seem (to me) to be saying that "final" and
"const" are differently only to the extent that C++ and Java are
different. But that's simply not true. The semantics "const" offers in
C++ could just as well be applied to Java, in the same way.

But, they aren't.

> I don't
> disagree with the points you make, only with you claiming that I said
> something different from what I actually said, then trying to pin that
> on me. [...]

I have not claimed you said anything that you didn't. I have simply
made observations about the apparent meaning of things you've said. You
didn't mean what it appeared you meant? Fine with me. Thanks for the
clarification. But there's no reason to get all huffy about it.

Pete
From: Stuart Redmann on 21 Jul 2010 03:02
On 20 Jul., Christian Hackl wrote:
> Maybe I'm just lucky, but I cannot even remember the last time I
> actually had to use const_cast because of some broken (or legacy) C++ or
> C API. How often do you really encounter this problem?

Quite seldom. Most often these are in-house projects where the co-
workers offers a header for some wrapper Dll that has been written in
MatLab or IDL, and the generated headers file are not const-correct.
Since they don't know C++ I most often correct those headers by hand.

The Win32 API is not always const-correct (see VerQueryValue,
CreatePenIndirect, or TOOLTIPTEXT).

MS MFC uses some macros like RUNTIME_CLASS which contain const_casts.
If I cannot use such macros because my classes are inside a namespace
or are generated from a template, I have to replace the macro by hand,
which introduces const-casts in my code.

I generate some wrapper classes for COM components from the raw .idl
file, and import the type library that is generated from the .idl
file. Since type libraries "eat away" all const-modifiers, I'll have
to const-cast a lot in my wrapper classes (so that at least C++ users
have a const-correct API).

In some measurement and automation APIs you'll find non-const correct
functions (for example Roper Scientific's PVCAM API).

Those are only the examples that I found when I searched for
const_cast through all my projects. There may be a lot more cases
where I just used a plain C-cast.

Regards,
Stuart
First  |  Prev  | 
Pages: 1 2 3
Prev: Last Call for Papers Reminder (extended): International Conference on Soft Computing and Applications ICSCA 2010
Next: Mutable Objects and Thread Boundaries