Hello.
as there is no possibility to doing GC allocations in class
destructors, wouldn't it be nice to just force "@nogc" attribute on
such dtors?
i know, i know, "this will break alot of code". i'm pretty sure that
this will break alot of INVALID code, which better be broken at
compile-time anyw
On Tuesday, 20 January 2015 at 18:12:27 UTC, ketmar via
Digitalmars-d wrote:
Hello.
as there is no possibility to doing GC allocations in class
destructors, wouldn't it be nice to just force "@nogc"
attribute on
such dtors?
i know, i know, "this will break alot of code". i'm pretty sure
that
On Tue, 20 Jan 2015 18:17:56 +
Meta via Digitalmars-d wrote:
> On Tuesday, 20 January 2015 at 18:12:27 UTC, ketmar via
> Digitalmars-d wrote:
> > Hello.
> >
> > as there is no possibility to doing GC allocations in class
> > destructors, wouldn't it be nice to just force "@nogc"
> > attribu
On Tuesday, 20 January 2015 at 20:25:15 UTC, Meta wrote:
Is it that subtle of a bug? Your program crashes once, you go
on the forums and find the answer, and then you know never to
do it again.
Furthermore, this is something that seems like it'd be incredibly
simple to add to dscanner (of cou
On Tuesday, 20 January 2015 at 18:25:42 UTC, ketmar via
Digitalmars-d wrote:
how likely this to be changed? is there *any* chances of that
in 2015?
2016? and why we can't just remove that restriction when new GC
will be
implemented? removing the "@nogc" requirement on class dtors
will break
*no
On Tue, 20 Jan 2015 20:25:13 +
Meta via Digitalmars-d wrote:
> On Tuesday, 20 January 2015 at 18:25:42 UTC, ketmar via
> Digitalmars-d wrote:
> > how likely this to be changed? is there *any* chances of that
> > in 2015?
> > 2016? and why we can't just remove that restriction when new GC
>
On 1/20/15 3:39 PM, ketmar via Digitalmars-d wrote:
and all that mess can be avoided just by enforcing the one simple rule,
which compiler is perfectly able to check.
I think the current situation is fine.
1. There are functions that sometimes allocate. I don't want to forbid
those, or force
On Tue, 20 Jan 2015 15:51:17 -0500
Steven Schveighoffer via Digitalmars-d
wrote:
> On 1/20/15 3:39 PM, ketmar via Digitalmars-d wrote:
>
> > and all that mess can be avoided just by enforcing the one simple rule,
> > which compiler is perfectly able to check.
>
> I think the current situation i
On Tue, 20 Jan 2015 15:51:17 -0500
Steven Schveighoffer via Digitalmars-d
wrote:
p.s. another point is that all mechanics compiler needs for doing such
checks is already there, so it's not a huge change to compiler
codebase. it's not something that requires adding a whole new analysis
code.
sig
On Tuesday, 20 January 2015 at 20:51:18 UTC, Steven Schveighoffer
wrote:
On 1/20/15 3:39 PM, ketmar via Digitalmars-d wrote:
and all that mess can be avoided just by enforcing the one
simple rule,
which compiler is perfectly able to check.
I think the current situation is fine.
In other wo
On 1/20/15 4:10 PM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
" wrote:
On Tuesday, 20 January 2015 at 20:51:18 UTC, Steven Schveighoffer wrote:
On 1/20/15 3:39 PM, ketmar via Digitalmars-d wrote:
and all that mess can be avoided just by enforcing the one simple rule,
which compiler is perfectly ab
On 1/20/15 4:06 PM, ketmar via Digitalmars-d wrote:
On Tue, 20 Jan 2015 15:51:17 -0500
Steven Schveighoffer via Digitalmars-d
wrote:
p.s. another point is that all mechanics compiler needs for doing such
checks is already there, so it's not a huge change to compiler
codebase. it's not something
On Tuesday, 20 January 2015 at 18:12:27 UTC, ketmar via
Digitalmars-d wrote:
Hello.
as there is no possibility to doing GC allocations in class
destructors, wouldn't it be nice to just force "@nogc"
attribute on
such dtors?
i know, i know, "this will break alot of code". i'm pretty sure
that
On Tue, 20 Jan 2015 21:34:54 +
Freddy via Digitalmars-d wrote:
> On Tuesday, 20 January 2015 at 18:12:27 UTC, ketmar via
> Digitalmars-d wrote:
> > Hello.
> >
> > as there is no possibility to doing GC allocations in class
> > destructors, wouldn't it be nice to just force "@nogc"
> > attri
On Tuesday, 20 January 2015 at 21:29:40 UTC, Steven Schveighoffer
wrote:
How's that? The current runtime aborts on memory allocation
inside the GC collection routine, it's not a memory safety
issue.
Spurious race conditions in memory deallocation patterns that
remain undetected and cause rand
On Tue, 20 Jan 2015 16:30:14 -0500
Steven Schveighoffer via Digitalmars-d
wrote:
> On 1/20/15 4:06 PM, ketmar via Digitalmars-d wrote:
> > On Tue, 20 Jan 2015 15:51:17 -0500
> > Steven Schveighoffer via Digitalmars-d
> > wrote:
> >
> > p.s. another point is that all mechanics compiler needs for
On Tuesday, 20 January 2015 at 21:30:14 UTC, Steven Schveighoffer
wrote:
On 1/20/15 4:06 PM, ketmar via Digitalmars-d wrote:
On Tue, 20 Jan 2015 15:51:17 -0500
Steven Schveighoffer via Digitalmars-d
wrote:
p.s. another point is that all mechanics compiler needs for
doing such
checks is alr
On Tuesday, 20 January 2015 at 21:38:50 UTC, ketmar via
Digitalmars-d wrote:
On Tue, 20 Jan 2015 21:34:54 +
Freddy via Digitalmars-d wrote:
On Tuesday, 20 January 2015 at 18:12:27 UTC, ketmar via
Digitalmars-d wrote:
> Hello.
>
> as there is no possibility to doing GC allocations in class
On Tue, 20 Jan 2015 21:37:54 +
via Digitalmars-d wrote:
> On Tuesday, 20 January 2015 at 21:29:40 UTC, Steven Schveighoffer
> wrote:
> > How's that? The current runtime aborts on memory allocation
> > inside the GC collection routine, it's not a memory safety
> > issue.
>
> Spurious race
On Tue, 20 Jan 2015 21:41:15 +
Vladimir Panteleev via Digitalmars-d
wrote:
> >> Not an error, Make it a warning.
> > alas, attribute violations are errors. turning that into
> > warning means
> > that compiler needs new flags and new code to determine if that
> > is
> > "hard restriction" o
On Tuesday, 20 January 2015 at 21:47:34 UTC, ketmar via
Digitalmars-d wrote:
and the funniest thing that it is perfectly able to do that!
all the code is already there.
Yes. But, destructors should be removed for GC anyway... it is a
GC performance killer. So maybe it is better that they stay
On Tuesday, 20 January 2015 at 20:51:18 UTC, Steven Schveighoffer
wrote:
On 1/20/15 3:39 PM, ketmar via Digitalmars-d wrote:
and all that mess can be avoided just by enforcing the one
simple rule,
which compiler is perfectly able to check.
I think the current situation is fine.
1. There are
On Tuesday, 20 January 2015 at 21:37:56 UTC, Ola Fosheim Grøstad
wrote:
On Tuesday, 20 January 2015 at 21:29:40 UTC, Steven
Schveighoffer wrote:
How's that? The current runtime aborts on memory allocation
inside the GC collection routine, it's not a memory safety
issue.
Spurious race conditio
On Tuesday, 20 January 2015 at 22:10:36 UTC, deadalnix wrote:
That is GC implementation issue, not a language issue. If it
ain't broken, don't fix it.
Efficient GC with compile time safety is a language issue.
Current Class allocation and deallocation patterns are making
fast collection unlik
On Tuesday, 20 January 2015 at 22:16:31 UTC, Ola Fosheim Grøstad
wrote:
On Tuesday, 20 January 2015 at 22:10:36 UTC, deadalnix wrote:
That is GC implementation issue, not a language issue. If it
ain't broken, don't fix it.
Efficient GC with compile time safety is a language issue.
Current Cla
On Tuesday, 20 January 2015 at 22:25:05 UTC, deadalnix wrote:
Any serious GC can run concurrently (instead of stopping the
world). That mean any serious GC must be able to handle
allocations while collecting.
Concurrent GC is too expensive for a proper system level
language. Stopping the thre
On Tuesday, 20 January 2015 at 23:00:26 UTC, Ola Fosheim Grøstad
wrote:
On Tuesday, 20 January 2015 at 22:25:05 UTC, deadalnix wrote:
Any serious GC can run concurrently (instead of stopping the
world). That mean any serious GC must be able to handle
allocations while collecting.
Concurrent G
On Tuesday, 20 January 2015 at 23:17:28 UTC, deadalnix wrote:
Concurrent GC is too expensive for a proper system level
language.
That is an unsubstanciated claim.
And so is «pigs can't fly».
You want to run the collection when the GC-memory is hot in
caches. That basically means you want
On Tuesday, 20 January 2015 at 18:12:27 UTC, ketmar via
Digitalmars-d wrote:
let's see how this proposal will be rejected. will there be
some sane
reasons, or only the good old song about "broken code"? make
your bets!
Lots of functions can theoretically allocate, but don't in the
way you cal
On Wed, 21 Jan 2015 00:29:21 +
Kapps via Digitalmars-d wrote:
> On Tuesday, 20 January 2015 at 18:12:27 UTC, ketmar via
> Digitalmars-d wrote:
> > let's see how this proposal will be rejected. will there be
> > some sane
> > reasons, or only the good old song about "broken code"? make
> >
On Tuesday, 20 January 2015 at 23:47:44 UTC, Ola Fosheim Grøstad
wrote:
On Tuesday, 20 January 2015 at 23:17:28 UTC, deadalnix wrote:
Concurrent GC is too expensive for a proper system level
language.
That is an unsubstanciated claim.
And so is «pigs can't fly».
That is the old prove a
On Wednesday, 21 January 2015 at 01:05:28 UTC, weaselcat wrote:
there is no silver bllet for memory and
Sorry, meant "silver bullet for memory management", bit tired : )
On Tuesday, 20 January 2015 at 23:47:44 UTC, Ola Fosheim Grøstad
wrote:
On Tuesday, 20 January 2015 at 23:17:28 UTC, deadalnix wrote:
Concurrent GC is too expensive for a proper system level
language.
That is an unsubstanciated claim.
And so is «pigs can't fly».
You want to run the collec
On 1/20/15 4:39 PM, ketmar via Digitalmars-d wrote:
On Tue, 20 Jan 2015 16:30:14 -0500
Steven Schveighoffer via Digitalmars-d
wrote:
On 1/20/15 4:06 PM, ketmar via Digitalmars-d wrote:
On Tue, 20 Jan 2015 15:51:17 -0500
Steven Schveighoffer via Digitalmars-d
wrote:
p.s. another point is tha
On Tue, 20 Jan 2015 20:51:34 -0500
Steven Schveighoffer via Digitalmars-d
wrote:
> >> You can always put @nogc on the dtor if you want.
> > seems that you completely missing my point. (sigh)
>
> Nope, not missing it. The mechanics are there. You just have to annotate.
that is where you missing i
On 1/20/15 9:04 PM, ketmar via Digitalmars-d wrote:
On Tue, 20 Jan 2015 20:51:34 -0500
Steven Schveighoffer via Digitalmars-d
wrote:
You can always put @nogc on the dtor if you want.
seems that you completely missing my point. (sigh)
Nope, not missing it. The mechanics are there. You just h
On 1/20/15 4:37 PM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
" wrote:
On Tuesday, 20 January 2015 at 21:29:40 UTC, Steven Schveighoffer wrote:
How's that? The current runtime aborts on memory allocation inside the
GC collection routine, it's not a memory safety issue.
Spurious race conditions in
On Tue, 20 Jan 2015 22:02:53 -0500
Steven Schveighoffer via Digitalmars-d
wrote:
> You may be able to, but I don't see the point. writeln can work
> perfectly fine for the most part inside dtors. But it can't be marked nogc.
now, that's really nice. "it's wrong, it can fail, it even marked as
on
On Wednesday, 21 January 2015 at 03:02:53 UTC, Steven
Schveighoffer wrote:
On 1/20/15 9:04 PM, ketmar via Digitalmars-d wrote:
On Tue, 20 Jan 2015 20:51:34 -0500
Steven Schveighoffer via Digitalmars-d
wrote:
You can always put @nogc on the dtor if you want.
seems that you completely missin
On Wednesday, 21 January 2015 at 03:03:50 UTC, Steven
Schveighoffer wrote:
It's neither spurious, nor a race condition.
How can you say that a priori? If you are using a framework, then
subclass a node (which cannot be made @nogc), then do explicit
deallocation to speed it up, then do multi-t
On Wednesday, 21 January 2015 at 01:07:59 UTC, weaselcat wrote:
On Wednesday, 21 January 2015 at 01:05:28 UTC, weaselcat wrote:
there is no silver bllet for memory and
Sorry, meant "silver bullet for memory management", bit tired :
)
Yeah, but the silver bullet for memory management in real t
On Wednesday, 21 January 2015 at 00:47:43 UTC, deadalnix wrote:
On Tuesday, 20 January 2015 at 23:47:44 UTC, Ola Fosheim
Grøstad wrote:
On Tuesday, 20 January 2015 at 23:17:28 UTC, deadalnix wrote:
Concurrent GC is too expensive for a proper system level
language.
That is an unsubstanciated
On Wednesday, 21 January 2015 at 09:03:32 UTC, Ola Fosheim
Grøstad wrote:
You assert that something is too expensive for system
language, which is not a negative, so the burden of proof is
on you, substantiate your claim or you are just generating
noise.
Oh... But you are the one that is chal
On Wednesday, 21 January 2015 at 08:51:08 UTC, Ola Fosheim
Grøstad wrote:
Implicit concurrent GC collection leads to:
1. less efficient codegen + restrictions related to FFI
No.
2. higher memory usage with limited ability to put upper bounds
Yes, the memory allocated during the collection
On Wednesday, 21 January 2015 at 09:54:32 UTC, deadalnix wrote:
What is the status quo is irrelevant. You make a claim, you
substantiate.
You need to take a course called "the philosophy of science".
You've made a claim that concurrent GC is what is needed for
competitive system level program
On Wednesday, 21 January 2015 at 10:00:21 UTC, deadalnix wrote:
1. less efficient codegen + restrictions related to FFI
No.
How would that work? You cannot trace pointers that stay in
registers. You also cannot do precise unwinding of FFI stacks.
3. intermittent pauses
I think you don't
Ok listen, I'm gonna put a full stop to this conversation :
- You provide no evidence of your claims.
- You discard any evidence that contradict your claims without
solid argument.
- You are constantly shitfting the goalspot using more and more
ridiculous claims (like malloc should not be use
On 1/21/15 3:37 AM, Paolo Invernizzi wrote:
On Wednesday, 21 January 2015 at 03:02:53 UTC, Steven Schveighoffer wrote:
On 1/20/15 9:04 PM, ketmar via Digitalmars-d wrote:
On Tue, 20 Jan 2015 20:51:34 -0500
Steven Schveighoffer via Digitalmars-d
wrote:
You can always put @nogc on the dtor if
On Wednesday, 21 January 2015 at 20:15:53 UTC, deadalnix wrote:
Ok listen, I'm gonna put a full stop to this conversation :
- You provide no evidence of your claims.
HAHAHA…
- You discard any evidence that contradict your claims without
solid argument.
What evidence?
- You are constantl
On Wednesday, 21 January 2015 at 20:32:14 UTC, Steven
Schveighoffer wrote:
On 1/21/15 3:37 AM, Paolo Invernizzi wrote:
On Wednesday, 21 January 2015 at 03:02:53 UTC, Steven
Schveighoffer wrote:
On 1/20/15 9:04 PM, ketmar via Digitalmars-d wrote:
If he does it wrong, it gives him a stack trace o
On 1/21/15 6:03 PM, Paolo Invernizzi wrote:
On Wednesday, 21 January 2015 at 20:32:14 UTC, Steven Schveighoffer wrote:
On 1/21/15 3:37 AM, Paolo Invernizzi wrote:
On Wednesday, 21 January 2015 at 03:02:53 UTC, Steven Schveighoffer
wrote:
On 1/20/15 9:04 PM, ketmar via Digitalmars-d wrote:
If h
On 1/21/15 3:45 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
" wrote:
On Wednesday, 21 January 2015 at 03:03:50 UTC, Steven Schveighoffer wrote:
It's neither spurious, nor a race condition.
How can you say that a priori?
When the GC collects, it doesn't allow memory allocation. This is not a
r
On Thursday, 22 January 2015 at 11:50:55 UTC, Steven
Schveighoffer wrote:
On 1/21/15 6:03 PM, Paolo Invernizzi wrote:
On Wednesday, 21 January 2015 at 20:32:14 UTC, Steven
Schveighoffer wrote:
On 1/21/15 3:37 AM, Paolo Invernizzi wrote:
On Wednesday, 21 January 2015 at 03:02:53 UTC, Steven
Sch
On 1/22/15 8:42 AM, Paolo Invernizzi wrote:
You can't ban them, either now with an annotated @nogc destructor:
SetFunctionAttributes.
Right, but the runtime will still catch it if it allocates. I think
the correct place to check it is where it's checked now.
I have troubles following your re
On Thursday, 22 January 2015 at 11:58:13 UTC, Steven
Schveighoffer wrote:
A race condition can LEAD to this being triggered, but the
abort itself is not a race condition. And forcing a default of
@nogc will not fix this.
Why not? If you have a race condition that leads a memory leak
when usin
On Thursday, 22 January 2015 at 14:07:31 UTC, Steven
Schveighoffer wrote:
resources) and everything works fine. And the runtime catches
any slips with an appropriate handling (abort instead of
corrupt memory).
Runtime errors that could have been a compile time error should
always be caught at
On 1/22/15 10:59 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
" wrote:
On Thursday, 22 January 2015 at 11:58:13 UTC, Steven Schveighoffer wrote:
A race condition can LEAD to this being triggered, but the abort
itself is not a race condition. And forcing a default of @nogc will
not fix this.
Why n
On 1/22/15 11:10 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
" wrote:
On Thursday, 22 January 2015 at 14:07:31 UTC, Steven Schveighoffer wrote:
resources) and everything works fine. And the runtime catches any
slips with an appropriate handling (abort instead of corrupt memory).
Runtime errors t
On Thursday, 22 January 2015 at 16:53:10 UTC, Steven
Schveighoffer wrote:
Disallowing compilation of the dtor does not fix the race
condition. We are no closer to race-free code here.
What you are basically saying is, race conditions are OK, as
long as they don't allocate memory in dtors.
Mo
"Ola Fosheim Grøstad" " wrote in message
news:ncuttyurxztvrziuy...@forum.dlang.org...
Runtime errors that could have been a compile time error should always be
caught at compile time. Spurious runtime errors are just as bad as null
pointer accesses.
Allocating in a dtor shouldn't be a runtim
On Tuesday, 20 January 2015 at 18:12:27 UTC, ketmar via
Digitalmars-d wrote:
Hello.
as there is no possibility to doing GC allocations in class
destructors, wouldn't it be nice to just force "@nogc"
attribute on
such dtors?
Classes don't have to be designed to be allocated on the GC heap.
C
On Friday, 23 January 2015 at 06:16:21 UTC, Jakob Ovrum wrote:
Classes don't have to be designed to be allocated on the GC
heap. Class instances can be allocated on the stack, the C
heap, or anywhere else.
…and this is a badly typed design if you don't embed ownership in
reference types.
Bu
On Friday, 23 January 2015 at 08:58:11 UTC, Ola Fosheim Grøstad
wrote:
How about banning GC-allocation of classes with destructors?
Uh... what? ^__^
Maybe just ban classes altogether then?
On Friday, 23 January 2015 at 10:53:54 UTC, aldanor wrote:
On Friday, 23 January 2015 at 08:58:11 UTC, Ola Fosheim Grøstad
wrote:
How about banning GC-allocation of classes with destructors?
Uh... what? ^__^
Maybe just ban classes altogether then?
No, don't ban them, that will break to much
On 1/23/15 8:05 AM, Matthias Bentrup wrote:
On Friday, 23 January 2015 at 10:53:54 UTC, aldanor wrote:
On Friday, 23 January 2015 at 08:58:11 UTC, Ola Fosheim Grøstad wrote:
How about banning GC-allocation of classes with destructors?
Uh... what? ^__^
Maybe just ban classes altogether then?
On Friday, 23 January 2015 at 13:12:44 UTC, Steven Schveighoffer
wrote:
On 1/23/15 8:05 AM, Matthias Bentrup wrote:
On Friday, 23 January 2015 at 10:53:54 UTC, aldanor wrote:
On Friday, 23 January 2015 at 08:58:11 UTC, Ola Fosheim
Grøstad wrote:
How about banning GC-allocation of classes with
On Friday, 23 January 2015 at 13:12:44 UTC, Steven Schveighoffer
wrote:
On 1/23/15 8:05 AM, Matthias Bentrup wrote:
On Friday, 23 January 2015 at 10:53:54 UTC, aldanor wrote:
On Friday, 23 January 2015 at 08:58:11 UTC, Ola Fosheim
Grøstad wrote:
How about banning GC-allocation of classes with
On 1/23/15 3:40 PM, deadalnix wrote:
On Friday, 23 January 2015 at 13:12:44 UTC, Steven Schveighoffer wrote:
On 1/23/15 8:05 AM, Matthias Bentrup wrote:
On Friday, 23 January 2015 at 10:53:54 UTC, aldanor wrote:
On Friday, 23 January 2015 at 08:58:11 UTC, Ola Fosheim Grøstad wrote:
How about
On Friday, 23 January 2015 at 21:00:08 UTC, Steven Schveighoffer
wrote:
On 1/23/15 3:40 PM, deadalnix wrote:
On Friday, 23 January 2015 at 13:12:44 UTC, Steven
Schveighoffer wrote:
On 1/23/15 8:05 AM, Matthias Bentrup wrote:
On Friday, 23 January 2015 at 10:53:54 UTC, aldanor wrote:
On Friday,
On Fri, 23 Jan 2015 23:28:28 +, Matthias Bentrup wrote:
> If the program ends before the next GC the destructor is never called.
nope.
class A {
~this () { import iv.writer; writeln("dtor"); }
}
void main () {
auto n = new A;
assert(0);
}
this outputs "dtor".
signature.
On Friday, 23 January 2015 at 23:28:28 UTC, Matthias Bentrup
wrote:
On Friday, 23 January 2015 at 21:00:08 UTC, Steven Schveighoffer
wrote:
On 1/23/15 3:40 PM, deadalnix wrote:
On Friday, 23 January 2015 at 13:12:44 UTC, Steven
Schveighoffer wrote:
On 1/23/15 8:05 AM, Matthias Bentrup wrote:
On Friday, 23 January 2015 at 21:00:08 UTC, Steven Schveighoffer
wrote:
On 1/23/15 3:40 PM, deadalnix wrote:
On Friday, 23 January 2015 at 13:12:44 UTC, Steven
Schveighoffer wrote:
On 1/23/15 8:05 AM, Matthias Bentrup wrote:
On Friday, 23 January 2015 at 10:53:54 UTC, aldanor wrote:
On Friday,
On Saturday, 24 January 2015 at 00:31:48 UTC, Paolo Invernizzi
wrote:
But my real point is that depending on dtors being called by
the GC is not broken 90% of the time.
-Steve
You are right, on a literal point, but I think that what he was
If the classes are written for RAII then the destru
This is the first I've heard that allocating GC memory in a
destructor will crash. That's an unexpected gotcha. I'd expect to
be able to reliably do I/O or throw an exception.
Strategy 1. Fix the GC's limitation. (One fewer pitfall to
baby-sit.)
Strategy 2. Have the compiler inform the progr
On Wednesday, 21 January 2015 at 20:32:14 UTC, Steven
Schveighoffer wrote:
Actually there's nothing on the documentation about class
destructors
[1] that warns about that specific issue of the current (and
default) GC.
[1] http://dlang.org/class.html#destructors
I think the docs are in need
1. is the only viable plan.
On Sun, 25 Jan 2015 22:09:04 +, deadalnix wrote:
> 1. is the only viable plan.
...which, in turn, equals to "do nothing for another year or more".
instead of issuing warning to inform people that what they doing NOW is
bad. i'm pretty sure that people are very happy to know that their code
On Monday, 26 January 2015 at 00:39:18 UTC, ketmar wrote:
On Sun, 25 Jan 2015 22:09:04 +, deadalnix wrote:
1. is the only viable plan.
...which, in turn, equals to "do nothing for another year or
more".
We are waiting for your pull request.
On Mon, 26 Jan 2015 02:13:26 +, deadalnix wrote:
> On Monday, 26 January 2015 at 00:39:18 UTC, ketmar wrote:
>> On Sun, 25 Jan 2015 22:09:04 +, deadalnix wrote:
>>
>>> 1. is the only viable plan.
>>
>> ...which, in turn, equals to "do nothing for another year or more".
>
> We are waiting
On Saturday, 24 January 2015 at 23:28:35 UTC, Jerry Morrison
wrote:
This is the first I've heard that allocating GC memory in a
destructor will crash. That's an unexpected gotcha. I'd expect
to be able to reliably do I/O or throw an exception.
Strategy 1. Fix the GC's limitation. (One fewer pi
On Saturday, 24 January 2015 at 23:28:35 UTC, Jerry Morrison
wrote:
On Saturday, 24 January 2015 at 15:04:47 UTC, Ola Fosheim
Grøstad wrote:
If the classes are written for RAII then the destructors have
to be called in reverse order of the constructors. IIRC D does
not guarantee this when you u
On Tuesday, 27 January 2015 at 22:46:30 UTC, Ola Fosheim Grøstad
wrote:
On Saturday, 24 January 2015 at 23:28:35 UTC, Jerry Morrison
wrote:
On Saturday, 24 January 2015 at 15:04:47 UTC, Ola Fosheim
Grøstad wrote:
If the classes are written for RAII then the destructors have
to be called in reve
From the forum thread
http://forum.dlang.org/thread/ossuvfmqthllgdpgz...@forum.dlang.org?page=1
and the PR
https://github.com/D-Programming-Language/dlang.org/pull/851
I learned that allocation in a destructor isn't the only crash
case here.
The GC calls a class instance's invariant() meth
On 1/27/15 7:00 PM, Jerry Morrison wrote:
A solution to that would be to never call invariants during a collection
cycle, but what other gotcha's exist during collection? Would @nogc on
class destructors help them?
I, too, think no invariants should be called during GC-triggered
destruction.
On Wednesday, 28 January 2015 at 02:33:11 UTC, Jerry Morrison
wrote:
Sorry, I don't understand the question. I expect LIFO for
freeing structs on the stack.
Yes, but if the class is designed for unique_ptr style usage...
Anyway, a destructor is the "END" for the constructor "BEGIN".
Together
On Wednesday, 28 January 2015 at 09:51:09 UTC, Ola Fosheim
Grøstad wrote:
Some languages keep track of parent-child relationships, you
can do it in the typing even. Nevertheless, children ought to
be alive when the parent dies... If the language cannot provide
this, then provide another mechani
On Wednesday, 28 January 2015 at 10:36:11 UTC, Matthias Bentrup
wrote:
But wouldn't enforcing strict parent-child relationships make
cyclic references illegal ?
You would either need:
- serial number/timestamping (just a sort is required)
- dynamic information like a back pointer
- static ty
On Wednesday, 28 January 2015 at 11:32:26 UTC, Ola Fosheim
Grøstad wrote:
But I think GC and destructors are not a good match... so I
would personally go for performance and no destructors.
Yes. That is the bottom line.
A good match for GC is the phantom reference, which notifies you
when an
On Friday, 30 January 2015 at 00:28:18 UTC, Jerry Morrison wrote:
On Wednesday, 28 January 2015 at 11:32:26 UTC, Ola Fosheim
Grøstad wrote:
But I think GC and destructors are not a good match... so I
would personally go for performance and no destructors.
Yes. That is the bottom line.
A good
89 matches
Mail list logo
