Re: Bitfields?
On Friday, 30 December 2016 at 13:45:23 UTC, Martin wrote: Are there any C-like bitfields in D? Yes - How can I use them? No - What could be used in their stead? If you're okay with dependencies and if you use DUB there's this very decent wrapper called EnumSet: - https://code.dlang.org/packages/iz - https://github.com/BBasile/iz/blob/master/import/iz/enumset.d#L226
Re: Bitfields?
On Friday, 30 December 2016 at 14:06:06 UTC, Marc Schütz wrote: On Friday, 30 December 2016 at 13:45:23 UTC, Martin wrote: Are there any C-like bitfields in D? Yes - How can I use them? No - What could be used in their stead? Not built-in, but in the standard library: https://dlang.org/phobos/std_bitmanip.html#.bitfields Thanks, will take a look now.
Re: Bitfields?
On Friday, 30 December 2016 at 13:45:23 UTC, Martin wrote: Are there any C-like bitfields in D? Yes - How can I use them? No - What could be used in their stead? Not built-in, but in the standard library: https://dlang.org/phobos/std_bitmanip.html#.bitfields
Bitfields?
Are there any C-like bitfields in D? Yes - How can I use them? No - What could be used in their stead?
Re: bitfields VS pure nothrow
On 05/13/12 23:01, David Nadlinger wrote: > Yes, the getters and setters should be both pure and nothrow. > > Your question about purity actually roots in a quite common > misunderstanding – I have a pretty comprehensive article on the > topic in the pipe, hope to be able to finish it later this week. > > David Looking forward to reading it. On 05/13/12 23:19, Alex Rønne Petersen wrote: > I've sent a pull request that fixes this: > https://github.com/D-Programming-Language/phobos/pull/583 Awesome. I was going to do so :)
Re: bitfields VS pure nothrow
On 13-05-2012 21:51, Guillaume Chatelet wrote:
Sure enough bitfields is a strange beast and I ran into some subtleties
with purity and nothrow.
Consider the following code :
--
struct POD {
int a;
}
int getA(POD o) pure nothrow {
return o.a;
}
POD setA(POD o, int value) pure nothrow {
o.a = value;
return o;
}
--
It compiles fine. But now with a bitfield :
struct POD {
mixin(std.bitmanip.bitfields!(
int, "a",10,
int, "", 22));
}
The compiler complains about missing pure and nothrow attributes
Error: pure function 'getA' cannot call impure function 'a'
Error: o.a is not nothrow
Error: function test.getA 'getA' is nothrow yet may throw
Error: pure function 'setA' cannot call impure function 'a'
Error: o.a is not nothrow
Error: function test.setA 'setA' is nothrow yet may throw
Which makes sense as the mixin outputs :
--
@property uint a() const {
auto result = (_a_& 1023U)>>0U;
return cast(uint) result;
}
@property void a(uint v){
assert(v>= a_min);
assert(v<= a_max);
_a_ = cast(typeof(_a_))
((_a_& ~1023U) | ((cast(typeof(_a_)) v<< 0U)& 1023U));
}
enum uint a_min = cast(uint)0U;
enum uint a_max = cast(uint)1023U;
private uint _a_;
--
IMHO getters and setters could be nothrow but what about purity ? Looks
like it's a bit far-fetched to qualify member methods as pure right ?
Yet it makes sense regarding the semantic. What's your take on that ?
I've sent a pull request that fixes this:
https://github.com/D-Programming-Language/phobos/pull/583
--
- Alex
Re: bitfields VS pure nothrow
On Sunday, 13 May 2012 at 20:49:13 UTC, Guillaume Chatelet wrote: IMHO getters and setters could be nothrow but what about purity? Looks like it's a bit far-fetched to qualify member methods as pure right? Yet it makes sense regarding the semantic. What's your take on that? Yes, the getters and setters should be both pure and nothrow. Your question about purity actually roots in a quite common misunderstanding – I have a pretty comprehensive article on the topic in the pipe, hope to be able to finish it later this week. David
bitfields VS pure nothrow
Sure enough bitfields is a strange beast and I ran into some subtleties
with purity and nothrow.
Consider the following code :
--
struct POD {
int a;
}
int getA(POD o) pure nothrow {
return o.a;
}
POD setA(POD o, int value) pure nothrow {
o.a = value;
return o;
}
--
It compiles fine. But now with a bitfield :
struct POD {
mixin(std.bitmanip.bitfields!(
int, "a",10,
int, "", 22));
}
The compiler complains about missing pure and nothrow attributes
Error: pure function 'getA' cannot call impure function 'a'
Error: o.a is not nothrow
Error: function test.getA 'getA' is nothrow yet may throw
Error: pure function 'setA' cannot call impure function 'a'
Error: o.a is not nothrow
Error: function test.setA 'setA' is nothrow yet may throw
Which makes sense as the mixin outputs :
--
@property uint a() const {
auto result = (_a_ & 1023U) >>0U;
return cast(uint) result;
}
@property void a(uint v){
assert(v >= a_min);
assert(v <= a_max);
_a_ = cast(typeof(_a_))
((_a_ & ~1023U) | ((cast(typeof(_a_)) v << 0U) & 1023U));
}
enum uint a_min = cast(uint)0U;
enum uint a_max = cast(uint)1023U;
private uint _a_;
--
IMHO getters and setters could be nothrow but what about purity ? Looks
like it's a bit far-fetched to qualify member methods as pure right ?
Yet it makes sense regarding the semantic. What's your take on that ?
Re: More for bitfields
Andrei Alexandrescu: > Sounds good. Did you have a chance to enter that into bugzilla? Done: http://d.puremagic.com/issues/show_bug.cgi?id=4425 Bye, bearophile
Re: More for bitfields
bearophile wrote:
This blog post shows possible ideas to make std.bitmanip.bitfields more
complete:
http://potential-lang.org/2010/07/02/quasi-quoting-ascii-art-to-define-data-structures/
An example of the ideas:
struct IntDesc_t {
...
immutable IST : 3 = 0;
immutable Unused0 : 5 = 0;
immutable type : 4 = 0b1110;
immutable Unused1 : 1 = 0b0;
dpl : 2;
p : 1;
That means allowing the fields to have an optional initialization value. And
they can be flagged to be immutable too :-) Bit fields that can't change are
common.
Bye,
bearophile
Sounds good. Did you have a chance to enter that into bugzilla?
Andrei
Re: More for bitfields
On 07/04/2010 07:20 AM, bearophile wrote:
This blog post shows possible ideas to make std.bitmanip.bitfields more
complete:
http://potential-lang.org/2010/07/02/quasi-quoting-ascii-art-to-define-data-structures/
An example of the ideas:
struct IntDesc_t {
...
immutable IST : 3 = 0;
immutable Unused0 : 5 = 0;
immutable type : 4 = 0b1110;
immutable Unused1 : 1 = 0b0;
dpl : 2;
p : 1;
...
That means allowing the fields to have an optional initialization value. And
they can be flagged to be immutable too :-) Bit fields that can't change are
common.
Bye,
bearophile
How is this different from erlang's bitfields, aside from the
mutable/immutable part?
More for bitfields
This blog post shows possible ideas to make std.bitmanip.bitfields more
complete:
http://potential-lang.org/2010/07/02/quasi-quoting-ascii-art-to-define-data-structures/
An example of the ideas:
struct IntDesc_t {
...
immutable IST : 3 = 0;
immutable Unused0 : 5 = 0;
immutable type : 4 = 0b1110;
immutable Unused1 : 1 = 0b0;
dpl : 2;
p : 1;
...
That means allowing the fields to have an optional initialization value. And
they can be flagged to be immutable too :-) Bit fields that can't change are
common.
Bye,
bearophile
