;
uint ackNo;
mixin(bitfields!(
bool, "flagFin", 1,
bool, "flagSyn", 1,
bool, "flagRst", 1,
bool, "flagPsh", 1,
bool, "flagAck", 1,
bool, "flagUrg", 1,
bool, "fl
I am using libpcap to read from stored pcap files, and want to
use std.bitmanip.bitfields to read TCP flags from the file, using
a struct like:
struct TcpHeader {
align(1):
ushort srcPort;
ushort dstPort;
uint seqNo;
uint ackNo;
mixin(bitfields!(
bool, "fl
On Wednesday, 22 May 2019 at 08:54:45 UTC, Russel Winder wrote:
On Tue, 2019-05-21 at 19:14 +, Era Scarecrow via
Digitalmars-d-learn wrote:
[…]
I worked on/with bitfields in the past, the limit sizes is
more
or less for natural int types that D supports.
Rust bitfield crate and it's
On Tue, 2019-05-21 at 19:14 +, Era Scarecrow via Digitalmars-d-learn
wrote:
>
[…]
> I worked on/with bitfields in the past, the limit sizes is more
> or less for natural int types that D supports.
Rust bitfield crate and it's macros are the same, the underlying type for a
bitf
/std_bitmanip.html#.peek
I'll have to mull that one over. The incoming data is a sequence of bytes that
is treated as a bitfield. Although the standard says "big-endian" it is isn't
entirely clear how this relates to the bitfields, I guess I need to read the
standard more. :-(
I guess the
On Tuesday, 21 May 2019 at 17:16:05 UTC, Russel Winder wrote:
As far as I can see std.bitmanip only caters for 8, 16, 32, and
64 bit long bitfields.
I worked on/with bitfields in the past, the limit sizes is more
or less for natural int types that D supports.
However this limitation
On Tuesday, 21 May 2019 at 17:16:05 UTC, Russel Winder wrote:
Hi,
Has anyone used D to work with arbitrary length bitfields with
multiple occurences of a sub-bitfield. I am working with DVB
Sections and EIT packets are defined as bitfields with loops in
them and the header is 112 bits
Hi,
Has anyone used D to work with arbitrary length bitfields with multiple
occurences of a sub-bitfield. I am working with DVB Sections and EIT packets
are defined as bitfields with loops in them and the header is 112 bits. The
loops are handleable with subfields obviously, assuming you can work
On Wednesday, 7 November 2018 at 14:22:43 UTC, lithium iodate
wrote:
On Wednesday, 7 November 2018 at 13:05:49 UTC, test wrote:
I am confused about the bitfields order.
The bitfields start with the least significant bits:
fin -> 1
rsv1 -> 0
rsv2 -> 0
rsv3 -> 0
opcode -> 1000
On Wednesday, 7 November 2018 at 13:05:49 UTC, test wrote:
I am confused about the bitfields order.
mixin(bitfields!(
bool, "fin",1,
bool, "rsv1", 1,
bool, "rsv2", 1,
bool, "rsv3",
I am confused about the bitfields order.
mixin(bitfields!(
bool, "fin",1,
bool, "rsv1", 1,
bool, "rsv2", 1,
bool, "rsv3", 1,
Opcode, "opcode", 4,
I have a struct with a mixin(bitfields) containing many small
bitfields. I also have a class member in the struct.
And because I want the class member to compare by using `is` I
need to define
bool opEquals(const scope typeof(this) that) const @safe pure
nothrow @nogc
On Thursday, 22 March 2018 at 09:55:44 UTC, Russel Winder wrote:
I am guessing you mean against DStep rather than D :-)
Yes :)
Though clearly T and I would prefer version not to be a D
keyword.
I suspect I have seen one place where DStep has turned version
into version_ where version was
On Wednesday, 21 March 2018 at 19:41:39 UTC, H. S. Teoh wrote:
version(all) { ... }
version(none) { ... }
version(Posix) { ... }
version(Windows) { ... }
But yeah, using "version" for this purpose makes the very
common identifier "version" unavailable for use.
On Wed, 2018-03-21 at 22:18 +0100, Jacob Carlborg via Digitalmars-d-learn
wrote:
> On 2018-03-21 20:30, Russel Winder wrote:
>
> > Thanks to Adam and Ali, it was clear and obvious.
>
> Please report and issue so it's not forgotten.
I am guessing you mean against DStep rather than D :-)
Though
On 2018-03-21 20:30, Russel Winder wrote:
Thanks to Adam and Ali, it was clear and obvious.
Please report and issue so it's not forgotten.
--
/Jacob Carlborg
On Wed, Mar 21, 2018 at 07:30:28PM +, Russel Winder via Digitalmars-d-learn
wrote:
[...]
> But :-(
>
> Why does version have to be a keyword?
[...]
version(all) { ... }
version(none) { ... }
version(Posix) { ... }
version(Windows) { ... }
But yeah, using
On Wed, 2018-03-21 at 18:11 +, Adam D. Ruppe via Digitalmars-d-
learn wrote:
> On Wednesday, 21 March 2018 at 18:00:38 UTC, Russel Winder wrote:
> > ubyte, "version", 5,
>
>
> version is a D keyword, so I would suggest trying "version_"
> there instead and see if it works. (I'm
On 03/21/2018 11:00 AM, Russel Winder wrote:
> The code I am playing with generated by DStep involves lots of lots of
> structs with mixin bitfields. All of them seem to compile file, except
> one. How is it that:
>
> mixin(bitfields!(
> ubyte, "current_nex
On Wednesday, 21 March 2018 at 18:00:38 UTC, Russel Winder wrote:
ubyte, "version", 5,
version is a D keyword, so I would suggest trying "version_"
there instead and see if it works. (I'm guessing btw, the error
message was way to long and illegible, but this is an easy first
guess
The code I am playing with generated by DStep involves lots of lots of
structs with mixin bitfields. All of them seem to compile file, except
one. How is it that:
mixin(bitfields!(
ubyte, "current_next", 1,
ubyte, "version", 5,
ubyte, "one
Thank you both!
On 01/19/2017 05:21 PM, Nestor wrote:
On Wednesday, 18 January 2017 at 12:52:56 UTC, drug wrote:
I've "solved" the same problem by using AliasSeq to generate bitfields
so that for iterating over bitfields I can iterate over alias sequence
and mixin code. Not very good bu
20.01.2017 15:04, Nestor пишет:
Where does one define the size for a field using AliasSeq, and in this
example, why does it take 1 bit if the size is not declared anywhere?
Something like that https://goo.gl/zV8T23
(Fields...)
{
import std.bitmanip : bitfields;
mixin(makeBitfields!Fields); // <-- Fields instead of UAP
}
```
Where does one define the size for a field using AliasSeq, and in this
example, why does it take 1 bit if the size is not declared anywhere?
I have fie
On Friday, 20 January 2017 at 08:13:08 UTC, drug wrote:
Something like that https://goo.gl/C4nOqw
Because you generate code iterating over AliasSeq you can do
almost everything you need - for example generate
setters/getters.
Interesting site, I wouldn't implemente something like this in a
20.01.2017 04:21, Nestor пишет:
On Wednesday, 18 January 2017 at 12:52:56 UTC, drug wrote:
I've "solved" the same problem by using AliasSeq to generate bitfields
so that for iterating over bitfields I can iterate over alias sequence
and mixin code. Not very good but it works.
I
On Wednesday, 18 January 2017 at 12:52:56 UTC, drug wrote:
I've "solved" the same problem by using AliasSeq to generate
bitfields so that for iterating over bitfields I can iterate
over alias sequence and mixin code. Not very good but it works.
Interesting, could you provide a working example?
I've "solved" the same problem by using AliasSeq to generate bitfields
so that for iterating over bitfields I can iterate over alias sequence
and mixin code. Not very good but it works.
;
writeln("Please improve this function by parsing
fieldImpl. :)");
}
};
}
struct S {
enum myFields = bitfields!(int, "a", 24,
byte, "b", 8);
pragma(msg, "This is the mixed-in bit field
code\n
;
if (max < temp) max = temp;
}
max += 1;
foreach (index, value; values) {
writefln("%-" ~ to!string(max) ~ "s %s", T.tupleof[index].stringof,
value);
}
}
Can something similar be done for bitfields? I tried running this and I
only get something like this:
emp;
}
max += 1;
foreach (index, value; values) {
writefln("%-" ~ to!string(max) ~ "s %s",
T.tupleof[index].stringof, value);
}
}
Can something similar be done for bitfields? I tried running this
and I only get something like this:
_f01_f02_f03 25312
_f04_f05_f06_
(Moved from: What have I missed?)
If this is the wrong place to ask these questions I apologize,
getting back into this takes some work.
So I guess I need to ask: Should I try to resume work on the
BitManip library? (So far it seems none of my code has been
integrated to phobos)
On Thu, Aug 07, 2014 at 01:10:06AM +, Era Scarecrow via Digitalmars-d-learn
wrote:
(Moved from: What have I missed?)
If this is the wrong place to ask these questions I apologize,
getting back into this takes some work.
Since this is about contributing to Phobos, probably a better
On Thursday, 7 August 2014 at 01:51:46 UTC, H. S. Teoh via
Digitalmars-d-learn wrote:
Since this is about contributing to Phobos, probably a better
place to ask is on the main D forum.
Yeah posted in my 'what have i missed?' as well...
Do you have a pull request? Which one is it?
into a
single request i think...
Looks like that pull is just the bitfields... but the actual
bitmanip one i listed has the whole source.
On Thu, Aug 07, 2014 at 02:04:12AM +, Era Scarecrow via Digitalmars-d-learn
wrote:
On Thursday, 7 August 2014 at 01:51:46 UTC, H. S. Teoh via
Digitalmars-d-learn wrote:
Since this is about contributing to Phobos, probably a better place to ask
is on the main D forum.
Yeah posted in my
On Thursday, 7 August 2014 at 02:12:20 UTC, H. S. Teoh via
Digitalmars-d-learn wrote:
Hold on a sec... that's a pull for your own fork of Phobos. You
need to submit a pull to the main Phobos repo in order to get
it reviewed and merged. :-)
Well, no wonder, your pull was submitted against
On Thursday, 3 January 2013 at 21:45:24 UTC, Era Scarecrow wrote:
K, I'll likely re-work my multi-level huffman algorithmn and a
LZW compression, although the LZW wouldn't make use of the more
exotic features. Got half the LZW written, but I likely won't
get this done for a few days.
Nearly
07-Jan-2013 00:51, Era Scarecrow пишет:
On Thursday, 3 January 2013 at 21:45:24 UTC, Era Scarecrow wrote:
K, I'll likely re-work my multi-level huffman algorithmn and a LZW
compression, although the LZW wouldn't make use of the more exotic
features. Got half the LZW written, but I likely won't
On Thursday, 3 January 2013 at 07:57:46 UTC, Dmitry Olshansky
wrote:
1/3/2013 6:05 AM, Era Scarecrow wrote:
Hm, I'd think that having Slice type be:
BitArraySlice{
BitArray* bp;
size_t start, end;
// all else forwards to the pointed array
}
should work avoiding the most of code duplication.
1/3/2013 2:20 PM, Era Scarecrow пишет:
On Thursday, 3 January 2013 at 07:57:46 UTC, Dmitry Olshansky wrote:
1/3/2013 6:05 AM, Era Scarecrow wrote:
Hm, I'd think that having Slice type be:
BitArraySlice{
BitArray* bp;
size_t start, end;
// all else forwards to the pointed array
}
should work
On Thursday, 3 January 2013 at 15:48:50 UTC, Dmitry Olshansky
wrote:
1/3/2013 2:20 PM, Era Scarecrow wrote:
Suddenly it won't work and slicing is only a range and can
only be used in foreach.
No surprise here. Basically container != range over it. It all
flows from there. Range doesn't have
04-Jan-2013 00:11, Era Scarecrow пишет:
On Thursday, 3 January 2013 at 15:48:50 UTC, Dmitry Olshansky wrote:
1/3/2013 2:20 PM, Era Scarecrow wrote:
Suddenly it won't work and slicing is only a range and can only be
used in foreach.
No surprise here. Basically container != range over it. It
On Thursday, 3 January 2013 at 21:15:19 UTC, Dmitry Olshansky
wrote:
04-Jan-2013 00:11, Era Scarecrow wrote:
Appending a slice *to* BitArray is perfectly fine as in fact
any range of bool (or bit if you like). Any array-like or
string-like container has to support appending a range of
12/31/2012 9:35 PM, Era Scarecrow пишет:
As BitArray is coming back up and my resumed work I'll comment a few
questions and suggestions and go from there. I'll polish up the code and
try to resubmit it.
Yay!
On Saturday, 28 July 2012 at 21:07:31 UTC, Jonathan M Davis wrote:
I would point
be cool ;)
https://github.com/rtcvb32/phobos/blob/BitArray-Updates/std/bitmanip.d
There's a merge issue due to having tried to keep the bitfields
and bitarray separated; That seems to have made more problems
than solutions. Working on it but may have to wait until I've
read my Git book when
As BitArray is coming back up and my resumed work I'll comment a
few questions and suggestions and go from there. I'll polish up
the code and try to resubmit it.
On Saturday, 28 July 2012 at 21:07:31 UTC, Jonathan M Davis wrote:
I would point out that while hasSlicing doesn't currently check
On Wednesday, 1 August 2012 at 07:24:09 UTC, Era Scarecrow wrote:
On Tuesday, 31 July 2012 at 20:41:55 UTC, Dmitry Olshansky
wrote:
Great to see things moving. Could you please do a separate
pull for bitfields it should get merged easier and it seems
like a small but important bugfix
On Thursday, 2 August 2012 at 09:03:54 UTC, monarch_dodra wrote:
I had an (implementation) question for you: Does the
implementation actually require knowing what the size of the
padding is?
eg:
struct A
{
int a;
mixin(bitfields!(
uint, x,2,
int, y,3
(bitfields!(
uint, x,2,
int, y,3,
ulong, ,3 // - This line right there
));
}
It that highlighted line really mandatory?
I'm fine with having it optional, in case I'd want to have,
say, a 59 bit padding, but can't the implementation figure it
out on it's own
)
If your using bitfields, then you are going for space, and to be
as small as reasonably possible. Especially important for packets
of information like headers for compression, and making it
compatible with C/C++'s bitpacking.
That said, something that could fix the above problem could
be:
*Bitfields
On 8/2/12 5:14 AM, Era Scarecrow wrote:
On Thursday, 2 August 2012 at 09:03:54 UTC, monarch_dodra wrote:
I had an (implementation) question for you: Does the implementation
actually require knowing what the size of the padding is?
eg:
struct A
{
int a;
mixin(bitfields!(
uint, x, 2,
int, y, 3
On 8/2/12 5:26 AM, monarch_dodra wrote:
One of the *big* reasons I'm against having a hand chosen padding, is
that the implementation *should* be able to find out what the most
efficient padding is on the current machine (could be 32 on some, could
be 64 on some)
In my neck of the woods they
On Thursday, 2 August 2012 at 12:35:20 UTC, Andrei Alexandrescu
wrote:
Please don't. The effort on the programmer side is virtually
nil, and keeps things in check. In no case would the use of
bitfields() be so intensive that the bloat of one line gets any
significance.
If you're using
Following from issue list:
bearophile_hugs 2010-10-04 18:16:44 PDT
Another possible feature is to make std.bitmanip.bitfields
generate two
versions of the code, that get compiled conditionally according
to the CPU
endianess:
static if (std.system.endian == std.system.Endian.BigEndian) {
On Thursday, 2 August 2012 at 12:38:10 UTC, Andrei Alexandrescu
wrote:
On 8/2/12 5:26 AM, monarch_dodra wrote:
One of the *big* reasons I'm against having a hand chosen
padding, is
that the implementation *should* be able to find out what the
most
efficient padding is on the current machine
On 8/2/12 9:48 AM, monarch_dodra wrote:
On Thursday, 2 August 2012 at 12:38:10 UTC, Andrei Alexandrescu wrote:
On 8/2/12 5:26 AM, monarch_dodra wrote:
One of the *big* reasons I'm against having a hand chosen padding, is
that the implementation *should* be able to find out what the most
On Tuesday, 31 July 2012 at 20:41:55 UTC, Dmitry Olshansky wrote:
Great to see things moving. Could you please do a separate pull
for bitfields it should get merged easier and it seems like a
small but important bugfix.
https://github.com/rtcvb32/phobos/commit
On Tuesday, 31 July 2012 at 05:27:58 UTC, Philippe Sigaud wrote:
No. Use a 3-params template or a tuple:
void func(A,B,C)(X!(A,B,C) x) {}
or
void func(Ts...)(X!(Ts) x) {}
I don't know how many arguments it will have (depends on how
many options I give it), and I honestly don't; It should be
On 29/07/12 23:36, bearophile wrote:
Era Scarecrow:
Another commonly needed operation is a very fast bit count. There
are very refined algorithms to do this.
Likely similar to the hamming weight table mentioned in TDPL.
Combined with the canUseBulk I think I could make it fairly fast.
/issues/show_bug.cgi?id=8474
The bug is only when the field is EXACTLY 32 bits BTW. bitfields
works quite nice with 33 or whatever. More details in the report.
On 7/31/12, monarch_dodra monarchdo...@gmail.com wrote:
The bug is only when the field is EXACTLY 32 bits BTW. bitfields
works quite nice with 33 or whatever. More details in the report.
Yeah 32 or 64 bits, thanks for changing the title.
On Tuesday, 31 July 2012 at 15:25:55 UTC, Andrej Mitrovic wrote:
On 7/31/12, monarch_dodra monarchdo...@gmail.com wrote:
The bug is only when the field is EXACTLY 32 bits BTW.
bitfields works quite nice with 33 or whatever. More details
in the report.
Yeah 32 or 64 bits, thanks for changing
++.
I haven't used bitfields myself in my own code.
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
On Tuesday, 31 July 2012 at 16:16:00 UTC, Era Scarecrow wrote:
On Tuesday, 31 July 2012 at 15:25:55 UTC, Andrej Mitrovic wrote:
On 7/31/12, monarch_dodra monarchdo...@gmail.com wrote:
The bug is only when the field is EXACTLY 32 bits BTW.
bitfields works quite nice with 33 or whatever. More
On Tuesday, 31 July 2012 at 16:59:11 UTC, monarch_dodra wrote:
No, it's a bug. There is no reason for it to fail (and it
certainly isn't a feature).
If I made two fields in a 64bit bitfield, each 32bits int's I'd
like it to complain; If it's calculated from something else then
finding the
?
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
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
:
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
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...
Maybe so ushort has extra padding for expansion at some later
date when
On Tuesday, 31 July 2012 at 17:17:43 UTC, Timon Gehr wrote:
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
On Tuesday, 31 July 2012 at 17:17:43 UTC, Timon Gehr wrote:
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
On 07/31/2012 09:15 AM, Era Scarecrow wrote:
On Tuesday, 31 July 2012 at 15:25:55 UTC, Andrej Mitrovic wrote:
On 7/31/12, monarch_dodra monarchdo...@gmail.com wrote:
The bug is only when the field is EXACTLY 32 bits BTW. bitfields
works quite nice with 33 or whatever. More details
of consequence?
Great to see things moving. Could you please do a separate pull for
bitfields it should get merged easier and it seems like a small but
important bugfix.
--
Dmitry Olshansky
?
Great to see things moving. Could you please do a separate pull
for bitfields it should get merged easier and it seems like a
small but important bugfix.
Guess this means I'll be working on BitArrays a bit later and
work instead on the bitfields code. What fun... :) I thought I
had bitfields
On Sunday, 29 July 2012 at 12:39:13 UTC, Era Scarecrow wrote:
But having them statically separated by name/type seems much
more likely to be safer in the long run with reliable results.
A question regarding templates. A template with different
parameters is completely incompatible correct?
On 30-Jul-12 23:50, Era Scarecrow wrote:
On Sunday, 29 July 2012 at 12:39:13 UTC, Era Scarecrow wrote:
But having them statically separated by name/type seems much more
likely to be safer in the long run with reliable results.
A question regarding templates. A template with different
On Mon, Jul 30, 2012 at 9:50 PM, Era Scarecrow rtcv...@yahoo.com wrote:
A question regarding templates. A template with different parameters is
completely incompatible correct?
Correct. They have no reason, in general, too even generate the same code:
template Chameleon(T)
{
static if
On Monday, 30 July 2012 at 21:03:39 UTC, Era Scarecrow wrote:
Alright... Considered a major (Maybe even blocking).
http://d.puremagic.com/issues/show_bug.cgi?id=8475
On Monday, 30 July 2012 at 20:48:26 UTC, Philippe Sigaud wrote:
Now if all that is correct, say I want to make two functions
that both use X, but are not compatible, but template
functions will allow it. So...
I'm not sure I understand what you're trying to do. Do you mean
you want a
On 31-Jul-12 01:03, Era Scarecrow wrote:
On Monday, 30 July 2012 at 20:19:51 UTC, Dmitry Olshansky wrote:
Not sure what you would like to accomplish here.
Than an example...
You can go for simpler separation:
struct BitArray{
//() - is an empty template spec
ref
On Monday, 30 July 2012 at 21:56:20 UTC, Dmitry Olshansky wrote:
You can go for simpler separation:
struct BitArray{
//() - is an empty template spec
ref BitArrayopSliceAssign()(const BitArray ba, int start, int
end)
{
//two bit array can try balk mode etc.
I'll give it a try, it may very
On Monday, 30 July 2012 at 22:23:46 UTC, Era Scarecrow wrote:
On Monday, 30 July 2012 at 21:56:20 UTC, Dmitry Olshansky wrote:
in == scope const not sure what scope buys here but couldn't
hurt.
If it can avoid making a new copy, then it likely would help.
I'll need to test it. I actually am
On 31-Jul-12 02:40, Era Scarecrow wrote:
On Monday, 30 July 2012 at 22:23:46 UTC, Era Scarecrow wrote:
On Monday, 30 July 2012 at 21:56:20 UTC, Dmitry Olshansky wrote:
in == scope const not sure what scope buys here but couldn't hurt.
If it can avoid making a new copy, then it likely would
On Monday, 30 July 2012 at 22:44:21 UTC, Dmitry Olshansky wrote:
Fixed :
void func(bool smth)(X!(smth).XT x){
By default XT is deduced as X!(current value of smth).XT
Doesn't really fix it...
a.func(b); //65 - doesn't match declaration.
a.func(ba); //66
//other template
On Monday, 30 July 2012 at 17:43:28 UTC, Ali Çehreli wrote:
On 07/30/2012 10:15 AM, Andrej Mitrovic wrote:
import std.bitmanip;
struct Foo
{
mixin(bitfields!(
uint, bits1, 32,
));
}
D:\DMD\dmd2\windows\bin\..\..\src\phobos\std\bitmanip.d(76):
Error:
shift by 32
On 7/31/12, Era Scarecrow rtcv...@yahoo.com wrote:
And likely one I'll be working on fairly soon. I've been
concentrating on the BitArray, but I'll get more of the bitfields
very very soon.
Cool. What about the max limit of 64bits per bitfield instantiation? I
don't suppose this is common
On Monday, 30 July 2012 at 23:41:39 UTC, Andrej Mitrovic wrote:
On 7/31/12, Era Scarecrow rtcv...@yahoo.com wrote:
And likely one I'll be working on fairly soon. I've been
concentrating on the BitArray, but I'll get more of the
bitfields very very soon.
Cool. What about the Max limit
On Tuesday, 31 July 2012 at 00:00:24 UTC, Era Scarecrow wrote:
Corrections:
So, 2 variables using 4 bit ints would be
void a(int v) @property {
value = ~(0x7 4);
value |= (v 0x7) 4;
}
the second setter should be
void b(int v) @property {
On 7/31/12, Era Scarecrow rtcv...@yahoo.com wrote:
It assumes the largest type we can currently use which is ulong
Ah yes, it makes sense now. Thanks for the brain cereal. :p
On Mon, Jul 30, 2012 at 11:19 PM, Era Scarecrow rtcv...@yahoo.com wrote:
void func(T)(X!T x)
{}
void main()
{
X!bool b;
X!int i;
func(b);
func(i);
}
Hmmm i do think that seems right... but if it contains multiple parameters,
then...?
template X(x1, x2, x3) {
in the container
itself.
No it doesn't. bitfields are used to handle the beginning/ending
offsets, equaling a total of 14 bits. It's the most confusing part
(aside from [offset + sliceoffset + i[ formulas). canExpand and
isCompact fill the other two bits.
OK, finally I think I understand how your
only propagate to a new true copy, otherwise it's
read-only as a slice.
Because of d, I proposed that slices be separate type that is
always a reference to original. Then only coping arrays
themselves involves dup.
Mmmm... i think you're right...
No it doesn't. bitfields are used to handle
On Sunday, 29 July 2012 at 06:27:32 UTC, Dmitry Olshansky wrote:
Thus BitArray either becomes value type (that may come as
unexpected, see your option c/d). Or it becomes full reference
type as in option a (though it sucks). Sorry but b is no go, as
it makes code unpredictable I'd rather take
On 29-Jul-12 12:55, Era Scarecrow wrote:
On Sunday, 29 July 2012 at 06:27:32 UTC, Dmitry Olshansky wrote:
Thus BitArray either becomes value type (that may come as unexpected,
see your option c/d). Or it becomes full reference type as in option a
(though it sucks). Sorry but b is no go, as it
On Sunday, 29 July 2012 at 09:03:08 UTC, Dmitry Olshansky wrote:
On 29-Jul-12 12:55, Era Scarecrow wrote:
Doing it this way the arguments being passed as reference
slices would ensure unneeded copies wouldn't be made. On the
other hand a smaller portion of the code would need to be
updated.
On 29-Jul-12 13:18, Era Scarecrow wrote:
On Sunday, 29 July 2012 at 09:03:08 UTC, Dmitry Olshansky wrote:
On 29-Jul-12 12:55, Era Scarecrow wrote:
Doing it this way the arguments being passed as reference slices
would ensure unneeded copies wouldn't be made. On the other hand a
smaller portion
On 29-Jul-12 14:28, Era Scarecrow wrote:
On Sunday, 29 July 2012 at 09:30:06 UTC, Dmitry Olshansky wrote:
I have simpler suggestion. Maybe doing it as 2 containers:
BitSet is a plain value type with small array optimization (what you
called BitArray in last 2 posts) and no slicing (only as
1 - 100 of 148 matches
Mail list logo
