On 08/10/15 18:58, Marco Leise wrote:
Am Mon, 05 Oct 2015 13:42:50 +
schrieb Adam D. Ruppe :
On Monday, 5 October 2015 at 07:40:35 UTC, deadalnix wrote:
Not on the heap. There are many cases where the destructor
won't run and it is allowed by spec. We should do
On Friday, 9 October 2015 at 07:39:06 UTC, Shachar Shemesh wrote:
On 08/10/15 18:58, Marco Leise wrote:
Am Mon, 05 Oct 2015 13:42:50 +
schrieb Adam D. Ruppe :
On Monday, 5 October 2015 at 07:40:35 UTC, deadalnix wrote:
Not on the heap. There are many cases
On Friday, 9 October 2015 at 07:54:43 UTC, deadalnix wrote:
It is also very useful as a safety net. When the object is
released, if it still hold handle to scarce resource, it make
sense to log and release it, or something similar. That is
surely better than running out of the resource and
Am Mon, 05 Oct 2015 13:42:50 +
schrieb Adam D. Ruppe :
> On Monday, 5 October 2015 at 07:40:35 UTC, deadalnix wrote:
> > Not on the heap. There are many cases where the destructor
> > won't run and it is allowed by spec. We should do better.
>
> To be fair, if you
On Thursday, 8 October 2015 at 15:58:37 UTC, Marco Leise wrote:
Am Mon, 05 Oct 2015 13:42:50 +
schrieb Adam D. Ruppe :
On Monday, 5 October 2015 at 07:40:35 UTC, deadalnix wrote:
> Not on the heap. There are many cases where the destructor
> won't run and it is
Am Mon, 5 Oct 2015 12:22:59 +0300
schrieb Shachar Shemesh :
> On 05/10/15 10:01, Dmitry Olshansky wrote:
>
> >> When D structs has a destructor that is guaranteed to run for any
> >> instance that finished construction, no matter what is the use case,
> >> then we can have that
Am Sun, 04 Oct 2015 23:28:47 +
schrieb Jonathan M Davis :
> On Sunday, 4 October 2015 at 21:41:00 UTC, rsw0x wrote:
> > If D has no intentions of aiding the GC, then the GC should
> > just be dropped because it's basically just slapping Boehm on
> > C++ right now.
>
>
On Thursday, 8 October 2015 at 16:25:00 UTC, Marco Leise wrote:
Am Sun, 04 Oct 2015 23:28:47 +
schrieb Jonathan M Davis :
[...]
It was probably bad wording. I understood it as D's GC works on
a similar basis as Boehm now - conservative, stop the world
mark & sweep.
On 10/08/2015 05:20 AM, Shachar Shemesh wrote:
On 07/10/15 12:58, Timon Gehr wrote:
Shachar
struct S{
@disable this();
@disable enum init=0;
}
void main(){
S s; // error
auto d=S.init; // error
}
An honest question. Would that also cover all cases where init is being
On 10/08/2015 06:09 PM, Marco Leise wrote:
Am Mon, 5 Oct 2015 12:22:59 +0300
schrieb Shachar Shemesh :
On 05/10/15 10:01, Dmitry Olshansky wrote:
When D structs has a destructor that is guaranteed to run for any
instance that finished construction, no matter what is the use
On 07/10/15 12:58, Timon Gehr wrote:
Shachar
struct S{
@disable this();
@disable enum init=0;
}
void main(){
S s; // error
auto d=S.init; // error
}
An honest question. Would that also cover all cases where init is being
used implicitly by the compiler?
I will need
On Wednesday, 7 October 2015 at 14:50:52 UTC, Jonathan M Davis
wrote:
On Wednesday, 7 October 2015 at 14:13:38 UTC, Meta wrote:
On Wednesday, 7 October 2015 at 09:59:05 UTC, Timon Gehr wrote:
struct S{
@disable this();
@disable enum init=0;
}
void main(){
S s; // error
auto
On Wednesday, 7 October 2015 at 18:38:34 UTC, Timon Gehr wrote:
On 10/07/2015 04:13 PM, Meta wrote:
On Wednesday, 7 October 2015 at 09:59:05 UTC, Timon Gehr wrote:
struct S{
@disable this();
@disable enum init=0;
}
void main(){
S s; // error
auto d=S.init; // error
}
That's
On 10/05/2015 12:57 PM, Shachar Shemesh wrote:
On 05/10/15 13:39, Marc Schütz wrote:
On Monday, 5 October 2015 at 09:25:30 UTC, Shachar Shemesh wrote:
What's more, init is used even if you @disable this(). The following
compile and does what you'd expect (but not what you want):
struct S {
On Wednesday, 7 October 2015 at 14:13:38 UTC, Meta wrote:
On Wednesday, 7 October 2015 at 09:59:05 UTC, Timon Gehr wrote:
struct S{
@disable this();
@disable enum init=0;
}
void main(){
S s; // error
auto d=S.init; // error
}
That's just awful.
Being able to declare a
On Wednesday, 7 October 2015 at 09:59:05 UTC, Timon Gehr wrote:
struct S{
@disable this();
@disable enum init=0;
}
void main(){
S s; // error
auto d=S.init; // error
}
That's just awful.
On 10/07/2015 04:13 PM, Meta wrote:
On Wednesday, 7 October 2015 at 09:59:05 UTC, Timon Gehr wrote:
struct S{
@disable this();
@disable enum init=0;
}
void main(){
S s; // error
auto d=S.init; // error
}
That's just awful.
I was responding to:
The above shows that you
On 10/07/2015 06:52 PM, Meta wrote:
On Wednesday, 7 October 2015 at 14:50:52 UTC, Jonathan M Davis wrote:
Being able to declare a member named init is just asking for trouble...
https://issues.dlang.org/show_bug.cgi?id=14237
https://issues.dlang.org/show_bug.cgi?id=7066
- Jonathan M Davis
On Wednesday, 7 October 2015 at 14:50:52 UTC, Jonathan M Davis
wrote:
Being able to declare a member named init is just asking for
trouble...
https://issues.dlang.org/show_bug.cgi?id=14237
https://issues.dlang.org/show_bug.cgi?id=7066
- Jonathan M Davis
Yeah, no arguments there. This needs
On 04/10/15 19:14, welkam wrote:
On Sunday, 4 October 2015 at 12:40:00 UTC, rsw0x wrote:
these tools are not very good and they don't help when the standard
library(...or builtin language features...) use the GC and tie your hands
IMO tools for memory management in D are way better than that
On 05-Oct-2015 09:52, Shachar Shemesh wrote:
On 04/10/15 19:14, welkam wrote:
On Sunday, 4 October 2015 at 12:40:00 UTC, rsw0x wrote:
these tools are not very good and they don't help when the standard
library(...or builtin language features...) use the GC and tie your
hands
IMO tools for
On Monday, 5 October 2015 at 07:01:35 UTC, Dmitry Olshansky wrote:
Supposed to be the case for structs except for any bugs.
Not on the heap. There are many cases where the destructor won't
run and it is allowed by spec. We should do better.
Until then, no, D's mechanisms for non-heap
On 05-Oct-2015 10:40, deadalnix wrote:
In C++ you can't - not only self-references are permitted but also
there is no T.init so there is no bit-pattern that is guaranteed to
not explode in dtor.
Guaranteed construct/destruction is actually a desirable feature IMO.
You get all kind of extra
On 05/10/15 10:01, Dmitry Olshansky wrote:
When D structs has a destructor that is guaranteed to run for any
instance that finished construction, no matter what is the use case,
then we can have that discussion.
Supposed to be the case for structs except for any bugs.
Check this one out
On 05/10/15 10:40, deadalnix wrote:
Guaranteed construct/destruction is actually a desirable feature IMO.
You get all kind of extra case int he dtor to care for when you can't
ensure proper construction, and it is not always possible to have a
meaningful .init value, leading to many useless
On 05/10/15 10:49, Dmitry Olshansky wrote:
Yes and no, if your type is movable in C++ you have to have a T.init
equivalent to leave something behind after move (oops!).
No, under C++ you can choose whether it makes sense for your type to be
movable or not. No oops at all.
C++ does not make
On Sunday, 4 October 2015 at 21:01:45 UTC, Jonathan M Davis wrote:
That would be ideal but gets really nasty for a number of
reasons - primarily having to do with casting. It's perfectly
possible to cast to and from shared and much easier to create
something as thread-local and then cast it to
On 05/10/15 13:39, Marc Schütz wrote:
On Monday, 5 October 2015 at 09:25:30 UTC, Shachar Shemesh wrote:
What's more, init is used even if you @disable this(). The following
compile and does what you'd expect (but not what you want):
struct S {
int d;
@disable this();
this( int d ) {
On Monday, 5 October 2015 at 10:57:57 UTC, Shachar Shemesh wrote:
On 05/10/15 13:39, Marc Schütz wrote:
On Monday, 5 October 2015 at 09:25:30 UTC, Shachar Shemesh
wrote:
What's more, init is used even if you @disable this(). The
following
compile and does what you'd expect (but not what you
On Monday, 5 October 2015 at 09:25:30 UTC, Shachar Shemesh wrote:
What's more, init is used even if you @disable this(). The
following compile and does what you'd expect (but not what you
want):
struct S {
int d;
@disable this();
this( int d ) {
this.d = d;
}
}
...
S d
On 05-Oct-2015 12:33, Shachar Shemesh wrote:
On 05/10/15 10:49, Dmitry Olshansky wrote:
Yes and no, if your type is movable in C++ you have to have a T.init
equivalent to leave something behind after move (oops!).
No, under C++ you can choose whether it makes sense for your type to be
On Monday, 5 October 2015 at 07:40:35 UTC, deadalnix wrote:
Not on the heap. There are many cases where the destructor
won't run and it is allowed by spec. We should do better.
To be fair, if you new a struct in C++ and never delete it, the
destructor will never run there either. D's in the
On Monday, 5 October 2015 at 11:41:11 UTC, Marc Schütz wrote:
`@disable this();` works fine to prevent the user from doing
that accidentally. But in your example, this doesn't happen by
accident; you explicitly told the compiler to use the .init
value. That's not something you do just because
On Saturday, 3 October 2015 at 19:01:33 UTC, welkam wrote:
D gives users tools to avoid heap allocations and if it is
necessary to allocate heap memory you have scoped memory
management or ref counting so your GC heap is small or non
existent. People fear manual memory management because they
On Friday, 2 October 2015 at 11:27:12 UTC, Tourist wrote:
I know that it has the reputation of being of the simplest
kind. Haven't looked at the code actually (and I wouldn't
understand much even if I did).
Go has a very simple GC itself. It's concurrent, so it trades low
latency against
On Saturday, 3 October 2015 at 07:49:35 UTC, Iain Buclaw wrote:
On 2 Oct 2015 1:32 pm, "Tourist via Digitalmars-d" <
digitalmars-d@puremagic.com> wrote:
On Friday, 2 October 2015 at 06:53:56 UTC, Iain Buclaw wrote:
On 1 Oct 2015 11:35 am, "Tourist via Digitalmars-d" <
On Sunday, 4 October 2015 at 17:22:52 UTC, Martin Nowak wrote:
On Friday, 2 October 2015 at 11:27:12 UTC, Tourist wrote:
I know that it has the reputation of being of the simplest
kind. Haven't looked at the code actually (and I wouldn't
understand much even if I did).
Go has a very simple
On Sunday, 4 October 2015 at 12:40:00 UTC, rsw0x wrote:
these tools are not very good and they don't help when the
standard library(...or builtin language features...) use the GC
and tie your hands
IMO tools for memory management in D are way better than that of
other languages. Game
On Sunday, 4 October 2015 at 17:30:39 UTC, rsw0x wrote:
I still say it's worth investigating a thread-local GC by
taking advantage of the fact that shared has never really been
properly fleshed out. This would heavily play to D's TLS by
default, and preferring message passing over shared data.
On Sunday, 4 October 2015 at 21:01:45 UTC, Jonathan M Davis wrote:
On Sunday, 4 October 2015 at 17:30:39 UTC, rsw0x wrote:
I still say it's worth investigating a thread-local GC by
taking advantage of the fact that shared has never really been
properly fleshed out. This would heavily play to
On Sunday, 4 October 2015 at 21:41:00 UTC, rsw0x wrote:
If D has no intentions of aiding the GC, then the GC should
just be dropped because it's basically just slapping Boehm on
C++ right now.
I don't understand this attitude at all (and you're not the only
one to voice it lately). D has a
On Sunday, 4 October 2015 at 23:28:48 UTC, Jonathan M Davis wrote:
D's templates alone blow C++ totally out of the water. -
Jonathan M Davis
I have to agree here. This is one feature of D that I can't
complain about...at all. I honestly can't think of a single issue
I have had with D's
On Friday, 2 October 2015 at 07:32:02 UTC, Kagamin wrote:
Low latency (also a synonym for fast) is required by
interactive applications like client and server software
Isn't a typical collection cycle's duration negligible compared
to typical network latency?
On Saturday, 3 October 2015 at 13:35:19 UTC, Vladimir Panteleev
wrote:
On Friday, 2 October 2015 at 07:32:02 UTC, Kagamin wrote:
Low latency (also a synonym for fast) is required by
interactive applications like client and server software
Isn't a typical collection cycle's duration negligible
On Saturday, 3 October 2015 at 18:26:32 UTC, Vladimir Panteleev
wrote:
On Saturday, 3 October 2015 at 18:21:55 UTC, deadalnix wrote:
On Saturday, 3 October 2015 at 13:35:19 UTC, Vladimir
Panteleev wrote:
On Friday, 2 October 2015 at 07:32:02 UTC, Kagamin wrote:
Low latency (also a synonym for
D gives users tools to avoid heap allocations and if it is
necessary to allocate heap memory you have scoped memory
management or ref counting so your GC heap is small or non
existent. People fear manual memory management because they hear
stories about C but for most part it can be easy and
On Saturday, 3 October 2015 at 18:21:55 UTC, deadalnix wrote:
On Saturday, 3 October 2015 at 13:35:19 UTC, Vladimir Panteleev
wrote:
On Friday, 2 October 2015 at 07:32:02 UTC, Kagamin wrote:
Low latency (also a synonym for fast) is required by
interactive applications like client and server
On 2 Oct 2015 1:32 pm, "Tourist via Digitalmars-d" <
digitalmars-d@puremagic.com> wrote:
>
> On Friday, 2 October 2015 at 06:53:56 UTC, Iain Buclaw wrote:
>>
>> On 1 Oct 2015 11:35 am, "Tourist via Digitalmars-d" <
digitalmars-d@puremagic.com> wrote:
>>>
>>> [...]
>>
>> good GC. And they keep
On 1 Oct 2015 11:35 am, "Tourist via Digitalmars-d" <
digitalmars-d@puremagic.com> wrote:
>
> Hi Guys,
>
> I know that Go invested many time and resources in an implementation of a
good GC. And they keep working on it, e.g.
On Friday, 2 October 2015 at 06:53:56 UTC, Iain Buclaw wrote:
On 1 Oct 2015 11:35 am, "Tourist via Digitalmars-d" <
digitalmars-d@puremagic.com> wrote:
[...]
good GC. And they keep working on it, e.g.
https://github.com/golang/proposal/blob/master/design/12800-sweep-free-alloc.md
[...]
On Friday, 2 October 2015 at 01:21:15 UTC, rsw0x wrote:
No, no it's not. Go's GC has a massive overhead because it's
intended to have low latency because that's what Go programs
typically require.
Go's GC is actually pretty slow by design.
Low latency (also a synonym for fast) is required by
On Thursday, 1 October 2015 at 09:33:26 UTC, Tourist wrote:
Hi Guys,
I know that Go invested many time and resources in an
implementation of a good GC. And they keep working on it, e.g.
https://github.com/golang/proposal/blob/master/design/12800-sweep-free-alloc.md
I also see that the
On Thursday, 1 October 2015 at 09:48:57 UTC, Kagamin wrote:
On Thursday, 1 October 2015 at 09:40:09 UTC, Rikki Cattermole
wrote:
Go's GC would have been optimized for Go's patterns and usage
of it.
It's JIT,
no?
which usually gets optimized for patterns, the GC pattern is
generic: collect
On 01/10/15 10:33 PM, Tourist wrote:
Hi Guys,
I know that Go invested many time and resources in an implementation of
a good GC. And they keep working on it, e.g.
https://github.com/golang/proposal/blob/master/design/12800-sweep-free-alloc.md
I also see that the implementation is licensed as
On 01-Oct-2015 12:33, Tourist wrote:
Hi Guys,
I know that Go invested many time and resources in an implementation of
a good GC. And they keep working on it, e.g.
https://github.com/golang/proposal/blob/master/design/12800-sweep-free-alloc.md
I also see that the implementation is licensed as
On Thursday, 1 October 2015 at 09:40:09 UTC, Rikki Cattermole
wrote:
Go's GC would have been optimized for Go's patterns and usage
of it.
It's JIT, which usually gets optimized for patterns, the GC
pattern is generic: collect the garbage and do it fast.
Hi Guys,
I know that Go invested many time and resources in an
implementation of a good GC. And they keep working on it, e.g.
https://github.com/golang/proposal/blob/master/design/12800-sweep-free-alloc.md
I also see that the implementation is licensed as BSD, as far as
I see:
57 matches
Mail list logo