extragear/multimedia/amarok/src

[Dan Meltzer]

On Wed, Oct 22, 2008 at 11:17 PM, Jeff Mitchell
<kde-dev at emailgoeshere.com> wrote:
> Ian Monroe wrote:
>> 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. :)
>>
>
> Yes, sorry  :-)
>
>>> 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. :)
>
> Yeah, you can have things like this, which is perfectly valid:
>
> const QObject * const * const myObject
>
> which would be an unchangeable pointer to an unchangeable pointer to an
> unchangeable object  :-)

And that, my friends, is change you *can't* count on!
> _______________________________________________
> Amarok-devel mailing list
> Amarok-devel at kde.org
> https://mail.kde.org/mailman/listinfo/amarok-devel
>