extragear/multimedia/amarok/src

[Ian Monroe]

On Wed, Oct 22, 2008 at 9:34 PM, Jeff Mitchell
<kde-dev at emailgoeshere.com> wrote:
> Ian Monroe wrote:
>> On Wed, Oct 22, 2008 at 8:21 PM, Jeff Mitchell
>> <kde-dev at emailgoeshere.com> wrote:
>>> No, it's not ignored...trying to modify the object without const casting
>>> it will result in a compile error.
>>>
>>> For that reason, it's not misleading either.  The const is a warning to
>>> the caller that they should not be modifying that object, and since the
>>> compiler will force this upon them, it's far from misleading; it's very
>>> direct and specific.
>>
>> You can't modify an int or a long.
>>
>> You can modify a QString, though it's a copy so you wouldn't be
>> modifying the original. I suppose I could see it being good for
>> legibility assuming the compiler would actually error out with
>>
>>  QString hello = blah.world();
>>
>> Where world was defined as 'const QString world();'
>>
>> I've never seen such an error before.
>
> Ok, we're all kind of right.  Your example is right above; my example in
> my original email was also right; Soren's patch is also right.

Erik's it appears. :)

> My claims about compiler failure were based on my experiences with const
> return values; these experiences have always been with pointers,
> however.  The examples I put in my original email (which use pointers)
> are correct, and will cause compiler errors; what I didn't realize is
> that this behavior does not carry through to non-pointer types.

Yea const pointers are something different. I think its possible to
have a const *pause* const-pointer. Hooray for C++ reusing keywords
all over. :)

Ian