On Tuesday, 15 June 2021 at 12:39:40 UTC, Dennis wrote:
On Tuesday, 15 June 2021 at 12:18:26 UTC, VitaliiY wrote:
[...]
```D
enum string ADDBITS(string a, string b) = `
{
bitbuffer = (bitbuffer<<(`~a~`))|((`~b~`)&((1<<`~a~`)-1));
numbits += (`~a~`);
mixin(STOREBITS);
}`;
// on
On Tuesday, 15 June 2021 at 12:38:15 UTC, Ali Çehreli wrote:
On 6/15/21 5:18 AM, VitaliiY wrote:
> STOREBITS and ADDBITS use variables defined in STARTDATA
If possible in your use case, I would put those variables in a
struct type and make add() a member function. However, a
similar type
On Sunday, 13 June 2021 at 21:13:33 UTC, frame wrote:
On Sunday, 13 June 2021 at 10:02:45 UTC, cc wrote:
it seems to work as expected with the same C# code. Does D
explicitly disallow slices as an extern(C) export parameter
type?
The spec says that there is no equivalent to type[]. You get
On 6/15/21 12:24 AM, surlymoor wrote:
All my custom range types perform all their meaningful work in their
respective popFront methods, in addition to its expected source data
iteration duties. The reason I do this is because I swear I read in a
github discussion that front is expected to be
On Tuesday, 15 June 2021 at 09:09:29 UTC, Ali Çehreli wrote:
On 6/14/21 11:39 PM, seany wrote:
> [...]
I gave an example of it in my DConf Online 2020 presentation as
well:
https://www.youtube.com/watch?v=dRORNQIB2wA=1324s
> [...]
That is violating a
On Tue, Jun 15, 2021 at 02:20:11PM +, Paul Backus via Digitalmars-d-learn
wrote:
[...]
> It's a time-space tradeoff. As you say, caching requires additional
> space to store the cached element. On the other hand, *not* caching
> means that you spend unnecessary time computing the next element
On Tuesday, 15 June 2021 at 04:24:09 UTC, surlymoor wrote:
All my custom range types perform all their meaningful work in
their respective popFront methods, in addition to its expected
source data iteration duties. The reason I do this is because I
swear I read in a github discussion that
On 6/14/21 10:17 PM, mw wrote:
> I think there is another convention (although it's not formally
> enforced, but should be) is:
>
> -- `obj.front() [should be] const`, i.e. it shouldn't modify `obj`, so
> can be called multiple times at any given state, and produce the same
> result
In other
On Tuesday, 15 June 2021 at 12:18:26 UTC, VitaliiY wrote:
It's simple with STARTDATA as mixin, but STOREBITS and ADDBITS
use variables defined in STARTDATA scope, so I can't understand
how to do mixin template with it.
If the code duplication isn't too bad, consider just expanding
the C
On 6/15/21 5:18 AM, VitaliiY wrote:
> STOREBITS and ADDBITS use variables defined in STARTDATA
If possible in your use case, I would put those variables in a struct
type and make add() a member function. However, a similar type already
exists as std.bitmanip.BitArray.
Ali
Could anybody help with translation of this C macro to D
mixin/mixin template? Here a - unsigned char, b - int. It's
simple with STARTDATA as mixin, but STOREBITS and ADDBITS use
variables defined in STARTDATA scope, so I can't understand how
to do mixin template with it.
#define
On 6/14/21 11:39 PM, seany wrote:
> I know that D has parallel foreach [like
> this](http://ddili.org/ders/d.en/parallelism.html).
I gave an example of it in my DConf Online 2020 presentation as well:
https://www.youtube.com/watch?v=dRORNQIB2wA=1324s
> int[] c ;
>
On Monday, 14 June 2021 at 17:34:00 UTC, Steven Schveighoffer
wrote:
D doesn't have head-const. So you must hide the mutable
implementation to get this to work.
You'd want to do this anyway, since you don't want to directly
use the pointer for anything like indexing (it should first
validate
On Tuesday, 15 June 2021 at 07:41:06 UTC, jfondren wrote:
On Tuesday, 15 June 2021 at 06:39:24 UTC, seany wrote:
[...]
add a `writeln(c.length);` in your inner loop and consider
the output. If you were always pushing to the end of c, then
only unique numbers should be output. But I see e.g.
On Tuesday, 15 June 2021 at 06:39:24 UTC, seany wrote:
What am I doing wrong?
add a `writeln(c.length);` in your inner loop and consider
the output. If you were always pushing to the end of c, then
only unique numbers should be output. But I see e.g. six
occurrences of 0, four of 8 ...
Here's
On Tuesday, 15 June 2021 at 06:39:24 UTC, seany wrote:
I know that c# has parallel for [like
this](https://dotnettutorials.net/lesson/parallel-for-method-csharp/) .
[...]
PS :
I need the entire include list - while they are not necessary for
this minimal example - they are needed for the
I know that c# has parallel for [like
this](https://dotnettutorials.net/lesson/parallel-for-method-csharp/) .
I know that D has parallel foreach [like
this](http://ddili.org/ders/d.en/parallelism.html).
I want to do the following :
Given 4 sets , A = {a_1, a_2, ... }; B = {b_1, b_2, ... } ;
On Tuesday, 15 June 2021 at 04:24:09 UTC, surlymoor wrote:
At the moment, I feel that as long as the stashed front element
isn't too "big" (For some definition of big, I guess.), that
built-in caching should be fine. But is this acceptable? What's
the best practice for determining which
18 matches
Mail list logo
