On Tuesday, 31 July 2012 at 17:17:25 UTC, Era Scarecrow wrote:
On Tuesday, 31 July 2012 at 16:59:11 UTC, monarch_dodra wrote:
Maybe the user needs a 32 bit ulong? This way the ulong only
takes 32 bits, but can still be implicitly passed to functions
expecting ulongs.
I would think the bug only showed itself if you did int at
32bits and ulong at 64 bits, not ulong at 32bits.
No, the bug shows itself if the first field is 32 bits,
regardless of (ulong included).
I would add though that requesting a field in bits that is bigger
than the type of the field should not work (IMO). EG:
--------
struct A
{
mixin(bitfields!(
ushort, "a", 24,
uint, "", 8
)
);
}
--------
I don't see any way how that could make sense...
But it *is* legal in C and C++...
But it does generates warnings...
I think it should static assert in D.
On Tuesday, 31 July 2012 at 17:21:00 UTC, Era Scarecrow wrote:
On Tuesday, 31 July 2012 at 17:17:43 UTC, Timon Gehr wrote:
(Also IMO, the once-in-a-year wtf that is caused by
accidentally assigning in an if condition does not justify
special casing assignment expressions inside if conditions.
Also, what is an useless compare?)
I've noticed in my experience, DMD gives you an error if you
do a statement that has no effect; IE:
1 + 2; //statement has no effect
a == b;//ditto
That's part of the standard: Statements that have no effect are
illegal. This is a good think, IMO. I've seen MANY C++ bugs that
could have been saved by that.
Regarding the assignment in if. I think it is a good thing. D
sides with safety. If you *really* want to test assign, you can
always comma operator it.
--------
void main()
{
int a = 0, b = 5;
while(a = --b, a) //YES, I *DO* want to assign!
{
write(a);
}
};
--------I'm sure the compiler will optimize away what it needs.
