Oh, I see. How utterly annoying. That means there is no easy way to
eliminate the warning in this case. It's too much of a useful warning to
turn off altogether though, so what do you think of having some #pragmas
that only disable it for that specific portion of the code?
Regards,
Elias
On 10 April 2014 19:29, Juergen Sauermann <juergen.sauerm...@t-online.de>wrote:
> Hi,
>
> the reason is that gcc does not allow unions with members that have
> constructors.
> It used to be allowed earlier, but not anymore (and I miss it).
>
> /// Jürgen
>
>
>
> On 04/10/2014 05:15 AM, Elias Mårtenson wrote:
>
> I'm having some problems with warnings emitted when using
> -Wstrict-aliasing.
>
> One of the cases where this warning is emitted is when a pointer to some
> value is cast to another type of pointer and then dereferenced. This
> happens, for example, in the RANK_LXB structure, as well as the VALUE_Pmacro
> in
> SharedValuePointer.hh.
>
> Can you explain why the _sh_B_low is declared like this:
>
> char _sh_B_low [ sizeof(Shape) ]; ///< low dimensions of B
>
> instead of simply:
>
> Shape _sh_B_low;
>
> Regards,
> Elias
>
>
> On 10 April 2014 10:58, Elias Mårtenson <loke...@gmail.com> wrote:
>
>> I fully agree with you. I also feel that the designers of Java did the
>> right thing in eliminating unsigned int.
>>
>> The problem in this case is that size_t is declared as unsigned long,
>> so that's where the unsigned comes from.
>>
>>
>> On 10 April 2014 00:21, Juergen Sauermann
>> <juergen.sauerm...@t-online.de>wrote:
>>
>>> Hi Elias,
>>>
>>> yes, please. One word of warning, though:
>>>
>>> When I was young I tried to be precise in using unsigned for items that
>>> could not be negative,
>>> These days I would rather use signed even if I knew they can't be
>>> negative.
>>>
>>> The reason is that differences of unsigned are signed (or wrong if
>>> declared unsigned) and that
>>> can produce wrong results without a warning. In contrast signed
>>> arithmetic is always correct
>>> (unless you overflow which is almost never the case).
>>>
>>> The only case where unsigned is beneficial is things like ((unsigned)a <
>>> b) to have a single comparison instead of
>>> a >= 0 && a < b or so.
>>>
>>> /// Jürgen
>>>
>>>
>>>
>>> On 04/09/2014 03:56 PM, Elias Mårtenson wrote:
>>>
>>> There are plenty of warnings when compiling with the -Wall flag. One
>>> example is the following error (it's included from my code, but the error
>>> is in UCS_string.hh):
>>>
>>> c++ -Wall -fPIC -g -I/home/elias/src/apl/src -c -o ResultValue.o
>>> ResultValue.cc
>>> In file included from /home/elias/src/apl/src/Error.hh:27:0,
>>> from /home/elias/src/apl/src/Token.hh:29,
>>> from /home/elias/src/apl/src/Parser.hh:24,
>>> from /home/elias/src/apl/src/Cell.hh:26,
>>> from ResultValue.hh:24,
>>> from ResultValue.cc:21:
>>> /home/elias/src/apl/src/UCS_string.hh: In member function 'bool
>>> UCS_string::all_zeroes()':
>>> /home/elias/src/apl/src/UCS_string.hh:140:37: warning: comparison
>>> between signed and unsigned integer expressions [-Wsign-compare]
>>> { for (size_t s = 0; s < size(); ++s)
>>> ^
>>>
>>>
>>> I want to fix these, but in many cases the solution is not entirely
>>> clear. In the above case, for example, you could either do a
>>> static_cast<size_t>(size()), or one could change the return value of
>>> the size() function to size_t.
>>>
>>> There are plenty of others. Would you like me to send patches for the
>>> obvious ones?
>>>
>>> Regards,
>>> Elias
>>>
>>>
>>>
>>
>
>
