On Wednesday, 28 June 2017 at 15:55:41 UTC, John Burton wrote:
On Tuesday, 27 June 2017 at 09:54:19 UTC, John Burton wrote:
I'm coming from a C++ background so I'm not too used to
garbage collection and it's implications. I have a function
that creates a std.socket.Socket using new and connects
On Tuesday, 27 June 2017 at 09:54:19 UTC, John Burton wrote:
I'm coming from a C++ background so I'm not too used to garbage
collection and it's implications. I have a function that
creates a std.socket.Socket using new and connects to a tcp
server, and writes some stuff to it. I then explicitl
On Wednesday, 28 June 2017 at 13:19:37 UTC, Guillaume Piolat
wrote:
https://forum.dlang.org/post/pmulowxpikjjffkrs...@forum.dlang.org
Not an issue with DerelictUtil, an issue with the strategy of
closing resources in GC with this case.
Derelict loaders work-around this by not unloading shar
On Wednesday, 28 June 2017 at 12:33:24 UTC, Guillaume Piolat
wrote:
On Wednesday, 28 June 2017 at 11:34:17 UTC, Moritz Maxeiner
wrote:
Requirement: Do not allocate using the GC
Option 1) Use structs with `@disable this`, `@disable
this(this)`, and a destructor that checks whether the resource
On Wednesday, 28 June 2017 at 13:02:04 UTC, Mike Parker wrote:
On Wednesday, 28 June 2017 at 09:16:22 UTC, Guillaume Piolat
wrote:
So far everyone is ignoring my example when A needs B to be
destroyed. This happens as soon as you use DerelictUtil for
example.
What's the issue with Derelic
On Wednesday, 28 June 2017 at 09:16:22 UTC, Guillaume Piolat
wrote:
So far everyone is ignoring my example when A needs B to be
destroyed. This happens as soon as you use DerelictUtil for
example.
What's the issue with DerelictUtil?
On Wednesday, 28 June 2017 at 12:28:28 UTC, Guillaume Piolat
wrote:
On Wednesday, 28 June 2017 at 11:21:07 UTC, Moritz Maxeiner
wrote:
On Wednesday, 28 June 2017 at 09:16:22 UTC, Guillaume Piolat
wrote:
So far everyone is ignoring my example when A needs B to be
destroyed. This happens as soon
On Wednesday, 28 June 2017 at 11:34:17 UTC, Moritz Maxeiner wrote:
Requirement: Do not allocate using the GC
Option 1) Use structs with `@disable this`, `@disable
this(this)`, and a destructor that checks whether the resource
reference is != invalid resource reference before trying to
release.
On Wednesday, 28 June 2017 at 11:21:07 UTC, Moritz Maxeiner wrote:
On Wednesday, 28 June 2017 at 09:16:22 UTC, Guillaume Piolat
wrote:
So far everyone is ignoring my example when A needs B to be
destroyed. This happens as soon as you use DerelictUtil for
example.
I thought I had (implicitly):
On Wednesday, 28 June 2017 at 09:22:07 UTC, Guillaume Piolat
wrote:
Deterministic destruction is a _solved_ problem in C++, and a
number of users to convert are now coming from C++.
It is also in D, as long as you don't use the GC (which is
inherently non-deterministic).
3. Suggest a syste
On Wednesday, 28 June 2017 at 09:16:22 UTC, Guillaume Piolat
wrote:
So far everyone is ignoring my example when A needs B to be
destroyed. This happens as soon as you use DerelictUtil for
example.
I thought I had (implicitly): B needs to be `@disable finalize`.
On Wednesday, 28 June 2017 at 09:16:22 UTC, Guillaume Piolat
wrote:
On Wednesday, 28 June 2017 at 02:13:10 UTC, Jonathan M Davis
wrote:
There are definitely cases where finalizers make sense. Case
in point: if you have a socket class, it makes perfect sense
for it to have a finalizer. Yes, it's
On Wednesday, 28 June 2017 at 02:13:10 UTC, Jonathan M Davis
wrote:
There are definitely cases where finalizers make sense. Case in
point: if you have a socket class, it makes perfect sense for
it to have a finalizer. Yes, it's better to close it manually,
but it will work just fine for the GC
On 2017-06-27 11:54, John Burton wrote:
I'm coming from a C++ background so I'm not too used to garbage
collection and it's implications. I have a function that creates a
std.socket.Socket using new and connects to a tcp server, and writes
some stuff to it. I then explicitly close the socket, and
On 2017-06-27 17:24, Steven Schveighoffer wrote:
Yes, Tango solved this by having a separate "finalize()" method. I wish
we had something like this.
Not sure if this is the same, but I remember that Tango had a separate
method called "dispose" that was called if a class was allocated on the
On Tuesday, 27 June 2017 at 09:54:19 UTC, John Burton wrote:
I'm coming from a C++ background so I'm not too used to garbage
collection and it's implications. I have a function that
creates a std.socket.Socket using new and connects to a tcp
server, and writes some stuff to it. I then explicitl
On Wednesday, 28 June 2017 at 02:13:10 UTC, Jonathan M Davis
wrote:
On Wednesday, June 28, 2017 01:11:35 Moritz Maxeiner via
Digitalmars-d-learn wrote:
Not every class can't be finalized, so it might make sense for
finalization to remain an available option.
There are definitely cases where fi
On Wednesday, June 28, 2017 01:11:35 Moritz Maxeiner via Digitalmars-d-learn
wrote:
> On Wednesday, 28 June 2017 at 00:05:20 UTC, Guillaume Piolat
>
> wrote:
> > On Tuesday, 27 June 2017 at 23:54:50 UTC, Moritz Maxeiner wrote:
> >> - Replace calls by the GC to `~this` with calls to `finalize`
> >>
On Wednesday, 28 June 2017 at 00:05:20 UTC, Guillaume Piolat
wrote:
On Tuesday, 27 June 2017 at 23:54:50 UTC, Moritz Maxeiner wrote:
- Replace calls by the GC to `~this` with calls to `finalize`
(or invent some cool other shortened name for the latter)
My point is that in such a "finalize()" f
On Tuesday, 27 June 2017 at 23:54:50 UTC, Moritz Maxeiner wrote:
Do you mean destructors?
Yes.
- Replace calls by the GC to `~this` with calls to `finalize`
(or invent some cool other shortened name for the latter)
My point is that in such a "finalize()" function the only sane
things to
On Tuesday, 27 June 2017 at 23:42:38 UTC, Guillaume Piolat wrote:
On Tuesday, 27 June 2017 at 18:04:36 UTC, Moritz Maxeiner wrote:
Well, technically speaking the `~this` for D classes *is* a
finalizer that you may optionally manually call (e.g. via
destroy).
It would be nice, though, to chang
On Tuesday, 27 June 2017 at 18:04:36 UTC, Moritz Maxeiner wrote:
Well, technically speaking the `~this` for D classes *is* a
finalizer that you may optionally manually call (e.g. via
destroy).
It would be nice, though, to change class `~this` into a
destructor and move the finalization into a
On Tuesday, 27 June 2017 at 15:24:00 UTC, Steven Schveighoffer
wrote:
The GC still needs to call something to clean up non-memory
resources,
Well, I'd much prefer if the GC would simply not call
destructors. Yes, destructor can work for _some_ resources, but
because of ordering it also create
On Tuesday, 27 June 2017 at 10:14:16 UTC, Jonathan M Davis wrote:
On Tuesday, June 27, 2017 09:54:19 John Burton via
Digitalmars-d-learn wrote:
[...]
Arguably, std.socket should have used structs instead of
classes for sockets for precisely this reason (though there are
some advantages in us
On 6/27/17 2:04 PM, Moritz Maxeiner wrote:
On Tuesday, 27 June 2017 at 15:24:00 UTC, Steven Schveighoffer wrote:
On 6/27/17 9:25 AM, Guillaume Piolat wrote:
On Tuesday, 27 June 2017 at 13:11:10 UTC, Steven Schveighoffer wrote:
But I would use a close method, and not destroy(obj). The reason is
On Tuesday, 27 June 2017 at 15:24:00 UTC, Steven Schveighoffer
wrote:
On 6/27/17 9:25 AM, Guillaume Piolat wrote:
On Tuesday, 27 June 2017 at 13:11:10 UTC, Steven Schveighoffer
wrote:
But I would use a close method, and not destroy(obj). The
reason is because often times, you have wrapper types
On 6/27/17 12:16 PM, Steven Schveighoffer wrote:
On 6/27/17 11:24 AM, Steven Schveighoffer wrote:
On 6/27/17 9:25 AM, Guillaume Piolat wrote:
That's how the GC-proof resource class came to existence, after many
destruction bugs, and it let's you use the GC as a detector for
non-deterministic
On 6/27/17 11:24 AM, Steven Schveighoffer wrote:
On 6/27/17 9:25 AM, Guillaume Piolat wrote:
That's how the GC-proof resource class came to existence, after many
destruction bugs, and it let's you use the GC as a detector for
non-deterministic destruction. I miss it in @nogc :)
https://p0nc
On 6/27/17 9:25 AM, Guillaume Piolat wrote:
On Tuesday, 27 June 2017 at 13:11:10 UTC, Steven Schveighoffer wrote:
But I would use a close method, and not destroy(obj). The reason is
because often times, you have wrapper types around your socket type,
and just one extra level of indirection mean
On Tuesday, 27 June 2017 at 13:11:10 UTC, Steven Schveighoffer
wrote:
But I would use a close method, and not destroy(obj). The
reason is because often times, you have wrapper types around
your socket type, and just one extra level of indirection means
the destructor cannot be used to clean up
On 6/27/17 8:29 AM, Guillaume Piolat wrote:
On Tuesday, 27 June 2017 at 09:54:19 UTC, John Burton wrote:
Am I doing this right with GC? In C++ I'd ensure that the Socket class
had a destructor that closed the socket and I'd also assume that once
it went out of scope there was no memory left all
On Tuesday, 27 June 2017 at 12:29:03 UTC, Guillaume Piolat wrote:
[...]
Hmm... Isn't it possible to just allocate the object/a pool of
objects outside the loop and reuse it? Everybody's proposing
other means of allocations which is nice, but I wonder why there
is such a need for reallocation
On Tuesday, 27 June 2017 at 09:54:19 UTC, John Burton wrote:
I assume that I do need to explicitly call close on the socket
as there is no deterministic destructor for class objects.
Yes.
I further assume that the runtime will garbage collect any
memory allocated to the socket object at a la
On Tuesday, 27 June 2017 at 09:54:19 UTC, John Burton wrote:
Now the issue is that I now need to call this function more
than once every second. I worry that it will create large
amounts of uncollected "garbage" which will eventually lead to
problems.
Since nobody has mentioned Allocator, yet
On Tuesday, 27 June 2017 at 11:43:27 UTC, John Burton wrote:
On Tuesday, 27 June 2017 at 10:14:16 UTC, Jonathan M Davis
wrote:
On Tuesday, June 27, 2017 09:54:19 John Burton via
Digitalmars-d-learn wrote:
I'm coming from a C++ background so I'm not too used to
garbage collection and it's implic
On Tuesday, 27 June 2017 at 10:14:16 UTC, Jonathan M Davis wrote:
On Tuesday, June 27, 2017 09:54:19 John Burton via
Digitalmars-d-learn wrote:
I'm coming from a C++ background so I'm not too used to
garbage collection and it's implications. I have a function
that creates a std.socket.Socket us
On Tuesday, June 27, 2017 09:54:19 John Burton via Digitalmars-d-learn
wrote:
> I'm coming from a C++ background so I'm not too used to garbage
> collection and it's implications. I have a function that creates
> a std.socket.Socket using new and connects to a tcp server, and
> writes some stuff t
On Tuesday, 27 June 2017 at 09:54:19 UTC, John Burton wrote:
I'm coming from a C++ background so I'm not too used to garbage
collection and it's implications. I have a function that
creates a std.socket.Socket using new and connects to a tcp
server, and writes some stuff to it. I then explicitl
I'm coming from a C++ background so I'm not too used to garbage
collection and it's implications. I have a function that creates
a std.socket.Socket using new and connects to a tcp server, and
writes some stuff to it. I then explicitly close the socket, and
the socket object goes out of scope.
39 matches
Mail list logo
