extragear/multimedia/amarok/src

[Jeff Mitchell]

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  :-)