Instead of the .dup you can use the slice operator []. Although this
really should not cause a compiler crash if you forgett to do so.
int[3] staticArray;
int[] normalArray = staticArray[];
I'm not seeing something fundamentally wrong with your code right now. I
will most likely have some mor
On Sunday, May 12, 2013 14:00:49 evilrat wrote:
> why multiple alias this not supported? i know it was broken in
> 2.060 but with 2.061 it was fixed right?
Multiple alias this-es have never worked. They're described in TDPL, but
they've never been implemented. Hopefully, they'll get implemented a
On Monday, 13 May 2013 at 00:21:06 UTC, John Colvin wrote:
On Monday, 13 May 2013 at 00:18:34 UTC, D-Ratiseur wrote:
I went back from a trip...basically I spent 6 monthes in
Yukon...
Then, came back to my activities, I was a lot in the library of
the university linked to my geo. location...I've
On Monday, 13 May 2013 at 00:18:34 UTC, D-Ratiseur wrote:
I went back from a trip...basically I spent 6 monthes in
Yukon...
Then, came back to my activities, I was a lot in the library of
the university linked to my geo. location...I've noticed a
strange guy...He was always reading some books a
I went back from a trip...basically I spent 6 monthes in Yukon...
Then, came back to my activities, I was a lot in the library of
the university linked to my geo. location...I've noticed a
strange guy...He was always reading some books about computer
programming languages.
After a few monthes,
aren't you guys all getting tons of internal error's as soon as you combine
dynamic arrays with static arrays? It seems as if these things are
completely seperate things, but their syntax sugests a more closely related
connection. I really find it confusing...
So, after reducing, I am very certain
On 05/12/2013 02:09 PM, Paolo Bolzoni wrote:
> I need to user Red-Black trees with non-default sorting.
> Here is a minimal example
> >8
> import std.container;
> struct CC {
> int a;
> int b; }
>
> bool less(const ref CC lhs, const ref CC rhs) {
> if (lhs.a != rhs.a)
>
On Sunday, 12 May 2013 at 18:45:29 UTC, Maxim Fomin wrote:
On Sunday, 12 May 2013 at 18:21:14 UTC, SundayMorningRunner
wrote:
On Sunday, 12 May 2013 at 18:14:51 UTC, Maxim Fomin wrote:
On Sunday, 12 May 2013 at 17:31:22 UTC, SundayMorningRunner
wrote:
Hello, let's say I have the choice between
Do you have multiple threads in your application? If you do so
it is possible that you (or the derelict library) does a API
call in a different then the main thread which might lead to
the error you describe. As the GC runs the destructors in any
arbitrary thread you can not free any SDL resour
I need to user Red-Black trees with non-default sorting.
Here is a minimal example
>8
import std.container;
struct CC {
int a;
int b; }
bool less(const ref CC lhs, const ref CC rhs) {
if (lhs.a != rhs.a)
return lhs.a < rhs.a;
else
return lhs.b < rhs.b; }
void
Am 12.05.2013 12:11, schrieb Namespace:
I get the error, although I don't call any unload method (or quit any
SDL component) and although I recompiled derelict3, where I comment out
all static (shared) DTor's.
Maybe the only solution would be (as you said) to transfer all
deallocations into a ter
Am 12.05.2013 21:05, schrieb maarten van damme:
This is ridiculous. Your solution appears to keep the memory somewhat
constant around 20mb-28mb untill it suddenly runs out of memory.
Literally out of nowhere.
I have no idea what's causing everything, so I decided to get rid of the
window altoget
maarten van damme:
I have no idea what's causing everything, so I decided to get
rid of the
window altogether and to try saving the images instead of
displaying +
saving them. Now I run in "Internal error: ..\ztc\cgcs.c 343"...
Once minimized, this may be fit for D Bugzilla.
Bye,
bearophile
This is ridiculous. Your solution appears to keep the memory somewhat
constant around 20mb-28mb untill it suddenly runs out of memory. Literally
out of nowhere.
I have no idea what's causing everything, so I decided to get rid of the
window altogether and to try saving the images instead of displa
On Sunday, 12 May 2013 at 18:21:14 UTC, SundayMorningRunner wrote:
On Sunday, 12 May 2013 at 18:14:51 UTC, Maxim Fomin wrote:
On Sunday, 12 May 2013 at 17:31:22 UTC, SundayMorningRunner
wrote:
Hello, let's say I have the choice between using an abstract
class or an interface to declare a "plan"
On Sunday, 12 May 2013 at 18:14:51 UTC, Maxim Fomin wrote:
On Sunday, 12 May 2013 at 17:31:22 UTC, SundayMorningRunner
wrote:
Hello, let's say I have the choice between using an abstract
class or an interface to declare a "plan", a "template" for
the descendants.
From the dmd compiler point of
On Sunday, 12 May 2013 at 18:00:10 UTC, Diggory wrote:
On Sunday, 12 May 2013 at 17:31:22 UTC, SundayMorningRunner
wrote:
Hello, let's say I have the choice between using an abstract
class or an interface to declare a "plan", a "template" for
the descendants.
From the dmd compiler point of vi
On Sunday, 12 May 2013 at 17:31:22 UTC, SundayMorningRunner wrote:
Hello, let's say I have the choice between using an abstract
class or an interface to declare a "plan", a "template" for the
descendants.
From the dmd compiler point of view, should I use the abstract
class version (so I guess t
On Sunday, 12 May 2013 at 17:31:22 UTC, SundayMorningRunner wrote:
Hello, let's say I have the choice between using an abstract
class or an interface to declare a "plan", a "template" for the
descendants.
From the dmd compiler point of view, should I use the abstract
class version (so I guess
Hello, let's say I have the choice between using an abstract
class or an interface to declare a "plan", a "template" for the
descendants.
From the dmd compiler point of view, should I use the abstract
class version (so I guess that for each method call, there will
be a few MOV, in order to ex
On Sunday, 12 May 2013 at 16:18:00 UTC, Timon Gehr wrote:
On 05/11/2013 04:34 PM, TommiT wrote:
...
// CTFE internal error: unsupported assignment this =
Test(123)
...
An "internal error" is always a compiler bug.
Thanks. Bug report there:
http://d.puremagic.com/issues/show_bug.cgi?id
On 05/11/2013 04:34 PM, TommiT wrote:
...
// CTFE internal error: unsupported assignment this = Test(123)
...
An "internal error" is always a compiler bug.
I use RAII of course only with D structs, not with classes.
Tonight I will take a closer look what the source of evil is.
On Sunday, 12 May 2013 at 11:27:50 UTC, evilrat wrote:
oh right,
struct A {
this(this) { copy referenced mem here}
}
or
struct A {
ref A opAssign(ref const A other) { this = other; return this; }
}
so if you have fields that should be fully copied like array
this is the place to do it, otherwi
On Sunday, 12 May 2013 at 10:38:41 UTC, evilrat wrote:
the problem with structs in your case is that this a value
type, so may be you could use copy contructor?
struct Something {
// copy ctor
this(Something s) {}
}
D doesn't have copy constructors. What you have there is just a
regular cons
On Sunday, 12 May 2013 at 14:06:49 UTC, Mike Parker wrote:
What you are missing here is that there's no such thing as that
this "(and would cause a growing memory, if the game runs a
long time)" is an issue you are likely to run into by using D's
This was the result of a botched edit. You ca
On Sunday, 12 May 2013 at 14:06:49 UTC, Mike Parker wrote:
What you are missing here is that there's no such thing as that
this "(and would cause a growing memory, if the game runs a
long time)" is an issue you are likely to run into by using D's
This was the result of a botched edit. You ca
On Sunday, 12 May 2013 at 10:11:57 UTC, Namespace wrote:
I get the error, although I don't call any unload method (or
quit any SDL component) and although I recompiled derelict3,
where I comment out all static (shared) DTor's.
Maybe the only solution would be (as you said) to transfer all
deall
On Sunday, 12 May 2013 at 01:22:16 UTC, evilrat wrote:
On Saturday, 11 May 2013 at 22:01:33 UTC, Flamaros wrote:
Thanks a lot, I think using Variant[] is a better way. For the
moment (maybe for few minutes) it's necessary to always give
the Variant array to the getResource method, but it can be
On 2013-05-12, 14:00, evilrat wrote:
On Sunday, 12 May 2013 at 11:56:53 UTC, Maxim Fomin wrote:
You can place base struct instance inside nested and use alias
this. Note that currently multiple alias this are not supported.
Also note that you cannot override functions because there are no
virt
12-May-2013 16:00, evilrat пишет:
On Sunday, 12 May 2013 at 11:56:53 UTC, Maxim Fomin wrote:
You can place base struct instance inside nested and use alias
this. Note that currently multiple alias this are not supported.
Also note that you cannot override functions because there are no
virtual
On Sunday, 12 May 2013 at 11:56:53 UTC, Maxim Fomin wrote:
You can place base struct instance inside nested and use alias
this. Note that currently multiple alias this are not supported.
Also note that you cannot override functions because there are
no
virtual table for structs.
why multiple
On Sunday, 12 May 2013 at 11:21:16 UTC, Temtaime wrote:
Hello to all !
I'm surprised that there is no structure's inheritance.
This was done by Walter Bright deliberately because he believes
that polymorphism does not play well with automaic lifetime.
There is a problem:
I want to make Matrix
On Sunday, 12 May 2013 at 11:21:16 UTC, Temtaime wrote:
Hello to all !
I'm surprised that there is no structure's inheritance.
There is a problem:
I want to make Matrix MxN class. I also want to make child
classes Square Matrix and Vector from it with additional
functions.
I don't want use "cl
On Sunday, 12 May 2013 at 11:21:16 UTC, Temtaime wrote:
Hello to all !
I'm surprised that there is no structure's inheritance.
There is a problem:
I want to make Matrix MxN class. I also want to make child
classes Square Matrix and Vector from it with additional
functions.
I don't want use "cl
On Sunday, 12 May 2013 at 11:27:15 UTC, maarten van damme wrote:
I tried using gc.malloc and gc.free but got an
invalidmemoryoperation
exception when doing gc.free(data.ptr);
Simply using gc.malloc like you proposed, the memory keeps
growing. Is this
a bug in the d garbage collector?
What's r
oh right,
struct A {
this(this) { copy referenced mem here}
}
or
struct A {
ref A opAssign(ref const A other) { this = other; return this; }
}
so if you have fields that should be fully copied like array this
is the place to do it, otherwise there is a reference arguments,
if both is no go for
I tried using gc.malloc and gc.free but got an invalidmemoryoperation
exception when doing gc.free(data.ptr);
Simply using gc.malloc like you proposed, the memory keeps growing. Is this
a bug in the d garbage collector?
What's really strange though, is that the destructor of trueimagecolor (the
cl
Hello to all !
I'm surprised that there is no structure's inheritance.
There is a problem:
I want to make Matrix MxN class. I also want to make child
classes Square Matrix and Vector from it with additional
functions.
I don't want use "class" cause of "new" overhead. Std typecons's
Scoped - wo
oops. nevermind i've forgot about how it done in D :(
you'd better read about it in language reference.
On Sunday, 12 May 2013 at 07:51:39 UTC, TommiT wrote:
On Sunday, 12 May 2013 at 03:32:44 UTC, evilrat wrote:
what? structs has value semantics, every time you assign a
struct to variable it assign its copy.
you also don't have to have constructor for structs, it
initializes it fields in left-
I get the error, although I don't call any unload method (or quit
any SDL component) and although I recompiled derelict3, where I
comment out all static (shared) DTor's.
Maybe the only solution would be (as you said) to transfer all
deallocations into a terminate method, but that is no opinion f
1) You don't need to call unload on any Derelict loaders. That
is handled automatically by Derelict using static module
destructors just as you have here. And that leads to
That good to know.
2) Module destructors are run before the gc runs its final
collection at shutdown. So if in a destruct
I should expand a bit. The heart of the issue in this case is
that you need precise control over the order of deallocation:
resource allocated through the shared libraries need to be
deallocated before the libraries are unloaded. Even without the
static module destructors, you can't rely on nor
On Sunday, 5 May 2013 at 09:52:53 UTC, Namespace wrote:
Here a test example:
http://dpaste.1azy.net/2cfc8ead
The memory is allocated through the SDL as you can see.
1) You don't need to call unload on any Derelict loaders. That is
handled automatically by Derelict using static module destruct
Am 11.05.2013 01:18, schrieb maarten van damme:
I'm trying to generate images and after displaying them I want to save
them to a png file. I use parallelism to generate them asynchronously
with the gui-thread to avoid blocking (don't know if this is really
relevant).
If I add a single line in th
On Sunday, 12 May 2013 at 03:32:44 UTC, evilrat wrote:
what? structs has value semantics, every time you assign a
struct to variable it assign its copy.
you also don't have to have constructor for structs, it
initializes it fields in left-to-right order or so.
[..]
Yes, I know that. But I'
47 matches
Mail list logo
