On 07/31/2012 06:57 PM, Era Scarecrow wrote:
On Tuesday, 31 July 2012 at 16:48:37 UTC, Andrej Mitrovic wrote:
On 7/31/12, Era Scarecrow <rtcv...@yahoo.com> wrote:
I wonder, is it really a bug? If you are going to have it fill a
whole size it would fit anyways, why even put it in as a bitfield?
You could just declare it separately.
I don't really know, I'm looking at this from a point of wrapping C++.
I haven't used bitfields myself in my own code.
I'd say it's not a bug since C/C++ is free to reorder the fields you'd
need to tinker with it anyways; HOWEVER if you still need to be able to
have it then who's to stop you from doing it?
I think more likely a flag/version or some indicator that you didn't
make a mistake, such as making them depreciated so it complains to you.
Kinda like how you can't make assignments in if statements or do useless
compares, it's an error and helps prevent issues that are quite
obviously mistakes.
This is obviously a mistake in the bitfield implementation. What else
could be concluded from the error message:
std\bitmanip.d(76): Error: shift by 32 is outside the range 0..31
Requesting a 32 bit or 64 bit member on the other hand is not a
mistake, and it is not useless, therefore the analogy breaks down.
(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?)
