On Friday, 16 August 2019 at 12:23:01 UTC, Newbie2019 wrote:
I has this simple function has some memory bugs:
---
struct TreeRange {
@disable this() ;
@disable this(this) ;
}
struct Tree {
ref auto getRange() return scope {
return TreeRange!T(_root);
On Friday, 16 August 2019 at 13:51:49 UTC, Jonathan M Davis wrote:
It is not possible to prevent moving in D as things currently
stand. DIP 1014 will need to be implemented to either hook into
moves or to prevent them. However, once DIP 1014 has been
implemented, I would expect the result to
On Friday, 16 August 2019 at 11:42:01 UTC, Ron Tarrant wrote:
Continuing on with Cairo, this post covers loading and
displaying three types of image (including a structured
drawing) using two different load-n-display methods.
As an extra bonus, you'll see a photo of my cat, Bob, and three
of
On Friday, August 16, 2019 6:29:19 AM MDT Newbie2019 via Digitalmars-d-learn
wrote:
> On Friday, 16 August 2019 at 12:23:01 UTC, Newbie2019 wrote:
> > I has this simple function has some memory bugs:
> >
> > ---
> > struct TreeRange {
> >
> > @disable this() ;
> > @disable this(this)
On Friday, 16 August 2019 at 08:07:28 UTC, aliak wrote:
Hi, I'm trying to fix a use-case where you have a wrapper
template type (it's an optional) and the wrapping type has
@disable this(this). And having this scenario work:
[...]
2) use isRef inside opAssign like this:
void opAssign(auto
I has this simple function has some memory bugs:
---
struct TreeRange {
@disable this() ;
@disable this(this) ;
}
struct Tree {
ref auto getRange() return scope {
return TreeRange!T(_root);
}
}
Tree tree;
auto range = tree.getRange();
--
Continuing on with Cairo, this post covers loading and displaying
three types of image (including a structured drawing) using two
different load-n-display methods.
As an extra bonus, you'll see a photo of my cat, Bob, and three
of the seven guitars I've found in my building's recycle room
On Friday, 16 August 2019 at 11:42:01 UTC, Ron Tarrant wrote:
Continuing on with Cairo, this post covers loading and
displaying three types of image (including a structured
drawing) using two different load-n-display methods.
As an extra bonus, you'll see a photo of my cat, Bob, and three
of
On Friday, August 16, 2019 8:14:52 AM MDT Newbie2019 via Digitalmars-d-learn
wrote:
> On Friday, 16 August 2019 at 13:51:49 UTC, Jonathan M Davis wrote:
> > It is not possible to prevent moving in D as things currently
> > stand. DIP 1014 will need to be implemented to either hook into
> > moves
On Friday, 16 August 2019 at 07:27:36 UTC, zabruk wrote:
may be std.mmfile can be usefull
https://dlang.org/phobos/std_mmfile.html
Thank you Zabruk.
I will study it.
Giovanni
On Friday, 16 August 2019 at 16:22:27 UTC, Jonathan M Davis wrote:
[...]
Thanks very much again, very helpful explain.
I use pass by ref scope instead "return TreeRange.__ctor();" to
workround this issue.
Hi
Do they exist arrays in the disk?
I must manage very very large data.
Thank you very much.
Giovanni
may be std.mmfile can be usefull
https://dlang.org/phobos/std_mmfile.html
Here is the code I have which doesn't work:
```
string[] foo;
string[] bar;
auto args = ["app", "--bar", "bar", "--foo", "foo"]; // (1)
import std.getopt;
getopt(args,
std.getopt.config.stopOnFirstNonOption, // (2)
"foo", ,
"bar", );
```
The error I see:
On Thursday, 15 August 2019 at 02:23:06 UTC, Adam D. Ruppe wrote:
On Thursday, 15 August 2019 at 01:55:17 UTC, Bert wrote:
void main()
{
class X { ... }
I would just make it `static class X` and then it should work
fine.
Won't be able to access main's local variables then though, but
On 08/16/2019 02:07 PM, Andrey Zherikov wrote:
But:
- if I change line (1) to `auto args = ["app", "--foo", "foo", "--bar",
"bar"];` then this code works.
- if I remove line (2) then this code works.
Yes, it's a bug.
Another workaround--which I haven't tested to see whether produces the
On Friday, August 16, 2019 2:16:31 AM MDT Piotr Mitana via Digitalmars-d-
learn wrote:
> On Thursday, 15 August 2019 at 19:51:30 UTC, Jonathan M Davis
>
> wrote:
> > Not being able to implicitly convert to const is a bit odd, but
> > arguably, nothing should ever be called on a shared AA anyway.
>
Hi, I'm trying to fix a use-case where you have a wrapper
template type (it's an optional) and the wrapping type has
@disable this(this). And having this scenario work:
struct S {
@disable this(this);
}
Optional!S fun() {...}
Optional!S a;
a = fun.move;
Now that won't work because of the
On Thursday, 15 August 2019 at 19:51:30 UTC, Jonathan M Davis
wrote:
Not being able to implicitly convert to const is a bit odd, but
arguably, nothing should ever be called on a shared AA anyway.
If an operation isn't thread-safe, then it shouldn't work with
shared. To use a shared object
19 matches
Mail list logo
