Static Analysis Tooling / Effective D

Marco Leise via Digitalmars-d digitalmars-d at puremagic.com
Thu Apr 24 12:40:23 PDT 2014


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

> On Wed, 23 Apr 2014 23:15:01 -0400, Marco Leise <Marco.Leise at gmx.de> wrote:
> 
> > Am Wed, 23 Apr 2014 22:56:27 -0400
> > schrieb "Steven Schveighoffer" <schveiguy at yahoo.com>:
> >
> >> On Wed, 23 Apr 2014 22:56:54 -0400, Marco Leise <Marco.Leise at gmx.de>  
> >> wrote:
> >>
> >> > Am Tue, 21 Jan 2014 04:34:56 +0000
> >> > schrieb "Brian Schott" <briancschott at 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



More information about the Digitalmars-d mailing list