[bt-devel] Problems with GCC 4.3.2 on Kubuntu 8.10

[Greg Hellings]

Eeli,

On Wed, Nov 5, 2008 at 4:23 PM, Eeli Kaikkonen
<eekaikko at mail.student.oulu.fi> wrote:
> Eeli Kaikkonen wrote:
>> Martin Gruner wrote:
>>
>>> Hi all,
>>>
>>> I'm getting tons of compiler warnings on BT and Sword.
>>>
>>> "warning: type qualifiers ignored on function return type"
>>>
>>> In all kinds of places. I haven't yet found out what exactly causes these
>>> warnings. I seem to be unable to turn them off with "-Wno-return-type". It
>>> seems that in C, functions cannot return const values, I am not sure about
>>> C++. Is this behaviour correct? Do we need to change our codebase and remove
>>> all const qualifiers on function return types?
>>>
>>> Can somebody please enlight me? ;)
>>>
>>>
>>
>> Isn't this the same problem somebody found before and I fixed in some
>> places? There are quite many "const QString get()" style functions but
>> they don't make any sense because the returned QString is a copy, not
>> original, and calling it const is meaningless. "QString get() const" is
>> very meaningful, it tells that the method doesn't change member data.
>> So, all "const xxx xxx();" functions should probably be changed to "xxx
>> xxx() const;". It may trigger some other compilation problems if the
>> function changes some member data. If it happens it's easier to remove
>> the const but then we loose compile time safety checks and possibly
>> there is some logic but in the code because getter method shouldn't
>> usually change anything. If necessary a const data may be cast to
>> non-const with const_cast<>() or something like that (IIRC).
>>
>>
> I hope this was correct. There's more to const than this. For example
> "x* const y", "x const* y" and "const x* y" are different things, or the
> last two are the same. "const QString x();" is wrong (or meaningless)
> but "const QString& x()" is correct, I guess. However, I don't know why
> we have so many "const x& y();"s. Returning for example a reference to
> an int is at least as expensive as returning the copy of that int, and
> the copy may be changed safely.

Most of the errors that I see are not for "const vartype function()"
but rather for "vartype const function()."  It tooke me some time of
looking through the errors very carefully to note that all the errors
I could see were of that type.  Also, there were a few "static vartype
function() const" which also threw all sorts of problems.  I found
that adding -Werror to the compile flags is the easiest way to sort
out the mess, one compiled file at a time.

--Greg

>
> Using const may be wise but it's difficult to do wisely.
>
> I'm working on this, removing the unnecessary consts. There are huge
> amounts of them so it takes some time.
>
> --Eeli Kaikkonen
>
> _______________________________________________
> bt-devel mailing list
> bt-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/bt-devel
>