Re: Can opApply be made @nogc?
On Friday, 19 October 2018 at 23:32:44 UTC, solidstate1991 wrote: Since it's a bit difficult to make tree traversal through range (especially if someone wants to make it @nogc), I thought I'll make it through opApply override, however the delegate passed by it doesn't have the @nogc attribute, which would automatically make it incapable to be used in a @nogc context. I also don't know if it would work with structs instead of classes, since they're easier to handle in a @nogc situation. https://forum.dlang.org/thread/erznqknpyxzxqivaw...@forum.dlang.org
Re: Can opApply be made @nogc?
On 20/10/2018 12:32 PM, solidstate1991 wrote:
Since it's a bit difficult to make tree traversal through range
(especially if someone wants to make it @nogc), I thought I'll make it
through opApply override, however the delegate passed by it doesn't have
the @nogc attribute, which would automatically make it incapable to be
used in a @nogc context.
I also don't know if it would work with structs instead of classes,
since they're easier to handle in a @nogc situation.
class Foo
{
uint[2] array;
int opApply(scope int delegate(ref uint) @nogc dg) @nogc
{
int result = 0;
for (int i = 0; i < array.length; i++)
{
result = dg(array[i]);
if (result)
break;
}
return result;
}
}
void test()
{
Foo a = new Foo();
a.array[0] = 73;
a.array[1] = 82;
foreach (uint u; a)
{
printf("%d\n", u);
}
}
Can opApply be made @nogc?
Since it's a bit difficult to make tree traversal through range (especially if someone wants to make it @nogc), I thought I'll make it through opApply override, however the delegate passed by it doesn't have the @nogc attribute, which would automatically make it incapable to be used in a @nogc context. I also don't know if it would work with structs instead of classes, since they're easier to handle in a @nogc situation.
Re: Which Docker to use?
On Wednesday, 17 October 2018 at 23:15:53 UTC, Jon Degenhardt wrote: I need to use docker to build static linked Linux executables. My reason is specific, may be different than the OP's. I'm using Travis-CI to build executables. Travis-CI uses Ubuntu 14.04, but static linking fails on 14.04. The standard C library from Ubuntu 16.04 or later is needed. There may be other/better ways to do this, I don't know. Yes I'm also using Travis-CI and that's why I need some Docker support.
Re: custom sorting of lists ?
On Friday, 19 October 2018 at 17:53:58 UTC, Stanislav Blinov wrote: On Friday, 19 October 2018 at 17:40:59 UTC, Carl Sturtivant wrote: If we imagine an Ordered Range being a finite Range of some kind with the additional property that its values are ordered (--- exact definition needed ---)... There's already a SortedRange: https://dlang.org/phobos/std_range.html#.SortedRange That's nice. So perhaps all this can be done in using the existing machinery in Phobos.
Re: custom sorting of lists ?
On Friday, 19 October 2018 at 17:40:59 UTC, Carl Sturtivant wrote: If we imagine an Ordered Range being a finite Range of some kind with the additional property that its values are ordered (--- exact definition needed ---)... There's already a SortedRange: https://dlang.org/phobos/std_range.html#.SortedRange
Re: custom sorting of lists ?
On Wednesday, 17 October 2018 at 19:02:00 UTC, Steven Schveighoffer wrote: On 10/17/18 2:03 PM, Carl Sturtivant wrote: On Monday, 15 October 2018 at 13:39:59 UTC, Steven Schveighoffer wrote: But that's just the thing -- merge sort *does* depend on the container type. It requires the ability to rearrange the elements structurally, since you merge the sets of items together. This requires making another list from the original list, and ranges don't lend themselves to that. One thing you *can* do is allocate an array beside the original container, and move things back and forth. But this is not required if you have a linked-list type which can simply be restructured without moving. Doesn't this just mean a new special kind of range is needed to be defined? I don't think it fits into range primitives. Basically, I need to rearrange one element from one place to another in O(1) time (and without actually moving/copying the data). This really just is a linked-list special feature. One thing to note is that in a range of T, this move has nothing to do with the T. -Steve If we imagine an Ordered Range being a finite Range of some kind with the additional property that its values are ordered (--- exact definition needed ---). And work with Ranges of Ordered Ranges, can't we then sort by starting with a Range of single element Ranges (which are automatically ordered), and then pairwise merge repeatedly, i.e. get the next two elements (which are ordered ranges) and merge them & repeat, producing a Range of Ordered Ranges with half as many elements --- this is what I meant by pairwise merging --- and apply that pairwise merge repeatedly to the original range. I'm speculating intuitively, but it does look like there exists a possible extension of the notion of Range that would do the job.
Re: assigment to null class object member compiled? is this a bug?
On Friday, 19 October 2018 at 06:53:32 UTC, dangbinghoo wrote:
hi,
why the code bellow compiles?
---
import std.stdio;
class A {
int m;
}
void main() {
A a;
a.m = 1;
}
---
and running this code get:
`segmentation fault (core dumped) ./test`
I consider this couldn't be compiled according to book Programming Language>.
The latest dmd (2.082) and LDC2 behaves the same.
Technically the code you have is syntactically correct. You are
permitted to create a class variable without assigning it to a
class object. (Assigning it to a class object would look like "A
a = new A();")
Which section of The D Programming Language book makes you think
this would not compile? I have the book as well, but I'm not
quite sure what part of the book you're referring to.
assigment to null class object member compiled? is this a bug?
hi,
why the code bellow compiles?
---
import std.stdio;
class A {
int m;
}
void main() {
A a;
a.m = 1;
}
---
and running this code get:
`segmentation fault (core dumped) ./test`
I consider this couldn't be compiled according to book Programming Language>.
The latest dmd (2.082) and LDC2 behaves the same.
