April 24, 2014
On 04/24/14 14:49, Marco Leise via Digitalmars-d wrote:
> Am Thu, 24 Apr 2014 13:11:18 +0200
> schrieb Artur Skawina via Digitalmars-d
> <digitalmars-d@puremagic.com>:
> 
>> `size_t x = 1 << shiftAmount` is definitely not something that should be recommended, see above. Just use the correct type on the lhs of shift operators.
> 
> auto x = cast(size_t) 1 << shiftAmount;  // really ?! :(

Yes. D has not improved the situation in this area; it's no different from C.

A new enough compiler could make it look slightly better:

    auto x = size_t(1) << shiftAmount;


Of course the more fundamental problem is that 'size_t' is just an alias and not a distinct type in D.

artur
April 24, 2014
On Wed, 23 Apr 2014 23:15:01 -0400, Marco Leise <Marco.Leise@gmx.de> wrote:

> Am Wed, 23 Apr 2014 22:56:27 -0400
> schrieb "Steven Schveighoffer" <schveiguy@yahoo.com>:
>
>> On Wed, 23 Apr 2014 22:56:54 -0400, Marco Leise <Marco.Leise@gmx.de> wrote:
>>
>> > Am Tue, 21 Jan 2014 04:34:56 +0000
>> > schrieb "Brian Schott" <briancschott@gmail.com>:
>> >
>> >> There's a small feature wishlist in the project's README, but I'd
>> >> like to get some opinions from the newsgroup: What kinds of
>> >> errors have you seen in your code that you think a static
>> >> analysis tool could help with?
>> >
>> > Yes, this one:
>> >
>> > size_t shiftAmount = 63;
>> > […]
>> > auto x = 1 << shiftAmount;
>> >
>> > The trouble is that auto will now resolve to int instead of
>> > size_t as indicated by the type of shiftAmount. Sure, my fault
>> > was to use an innocent »1« instead of »cast(size_t) 1«.
>>
>> You could use 1UL instead.
>>
>> -Steve
>
> No, that would give you a ulong result.

Hm... I was thinking in terms of 1 << 63, that must be a ulong, no?

But I see your point that size_t may be 32 bits.

I also think this will work:

size_t(1);

-Steve
April 24, 2014
Am Thu, 24 Apr 2014 10:26:48 -0400
schrieb "Steven Schveighoffer" <schveiguy@yahoo.com>:

> On Wed, 23 Apr 2014 23:15:01 -0400, Marco Leise <Marco.Leise@gmx.de> wrote:
> 
> > Am Wed, 23 Apr 2014 22:56:27 -0400
> > schrieb "Steven Schveighoffer" <schveiguy@yahoo.com>:
> >
> >> On Wed, 23 Apr 2014 22:56:54 -0400, Marco Leise <Marco.Leise@gmx.de> wrote:
> >>
> >> > Am Tue, 21 Jan 2014 04:34:56 +0000
> >> > schrieb "Brian Schott" <briancschott@gmail.com>:
> >> >
> >> >> There's a small feature wishlist in the project's README, but I'd like to get some opinions from the newsgroup: What kinds of errors have you seen in your code that you think a static analysis tool could help with?
> >> >
> >> > Yes, this one:
> >> >
> >> > size_t shiftAmount = 63;
> >> > […]
> >> > auto x = 1 << shiftAmount;
> >> >
> >> > The trouble is that auto will now resolve to int instead of size_t as indicated by the type of shiftAmount. Sure, my fault was to use an innocent »1« instead of »cast(size_t) 1«.
> >>
> >> You could use 1UL instead.
> >>
> >> -Steve
> >
> > No, that would give you a ulong result.
> 
> Hm... I was thinking in terms of 1 << 63, that must be a ulong, no?

Actually in _that_ case the compiler will yell at you that the valid range to shift an »int« is [0..31].

> But I see your point that size_t may be 32 bits.
>
> I also think this will work:
> 
> size_t(1);
> 
> -Steve

Both you and Artur mentioned it. Will this generalized ctor syntax be in 2.066 ? It looks much less like "code smell" when you don't have to use a cast any more even if it is just a rewrite.

-- 
Marco

April 24, 2014
On Thu, 24 Apr 2014 15:40:23 -0400, Marco Leise <Marco.Leise@gmx.de> wrote:

> Am Thu, 24 Apr 2014 10:26:48 -0400
> schrieb "Steven Schveighoffer" <schveiguy@yahoo.com>:
>
>> On Wed, 23 Apr 2014 23:15:01 -0400, Marco Leise <Marco.Leise@gmx.de> wrote:
>>
>> > Am Wed, 23 Apr 2014 22:56:27 -0400
>> > schrieb "Steven Schveighoffer" <schveiguy@yahoo.com>:
>> >
>> >> On Wed, 23 Apr 2014 22:56:54 -0400, Marco Leise <Marco.Leise@gmx.de>
>> >> wrote:
>> >>
>> >> > Am Tue, 21 Jan 2014 04:34:56 +0000
>> >> > schrieb "Brian Schott" <briancschott@gmail.com>:
>> >> >
>> >> >> There's a small feature wishlist in the project's README, but I'd
>> >> >> like to get some opinions from the newsgroup: What kinds of
>> >> >> errors have you seen in your code that you think a static
>> >> >> analysis tool could help with?
>> >> >
>> >> > Yes, this one:
>> >> >
>> >> > size_t shiftAmount = 63;
>> >> > […]
>> >> > auto x = 1 << shiftAmount;
>> >> >
>> >> > The trouble is that auto will now resolve to int instead of
>> >> > size_t as indicated by the type of shiftAmount. Sure, my fault
>> >> > was to use an innocent »1« instead of »cast(size_t) 1«.
>> >>
>> >> You could use 1UL instead.
>> >>
>> >> -Steve
>> >
>> > No, that would give you a ulong result.
>>
>> Hm... I was thinking in terms of 1 << 63, that must be a ulong, no?
>
> Actually in _that_ case the compiler will yell at you that the
> valid range to shift an »int« is [0..31].

*sigh* The compiler is too smart for it's own good ;)

This SHOULD compile and result in a long. I can't see how you would have meant anything else, and range propagation should work for a literal.

>
>> But I see your point that size_t may be 32 bits.
>>
>> I also think this will work:
>>
>> size_t(1);
>>
>> -Steve
>
> Both you and Artur mentioned it. Will this generalized ctor
> syntax be in 2.066 ?

I don't know. I thought it was in 2.065, but see that it's not. I have read that it was introduced somewhere, so I assumed it was already in. Maybe only in git HEAD.

> It looks much less like "code smell" when
> you don't have to use a cast any more even if it is just a
> rewrite.
>

Yeah definitely. Cast should not be required for such mundane and obviously safe things.

-Steve
1 2 3 4
Next ›   Last »