April 24, 2014 Re: Static Analysis Tooling / Effective D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Marco Leise | 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 Re: Static Analysis Tooling / Effective D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Marco Leise | 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 Re: Static Analysis Tooling / Effective D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | 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 Re: Static Analysis Tooling / Effective D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Marco Leise | 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 |
Copyright © 1999-2021 by the D Language Foundation