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 Wednesday, 28 June 2017 at 00:16:23 UTC, Mike Parker wrote:
On Tuesday, 27 June 2017 at 19:07:49 UTC,
You have to specify the appropriate linker option, e.g.
-L-option. For gcc, that happens to -L, so you get -L-L. For
optlink it's +something and for the MS linker it's /something.
I'm on m
On Tuesday, 27 June 2017 at 19:07:49 UTC, jmh530 wrote:
Is it possible to set relative -L paths on dub for Windows?
Absolute paths work fine, just can't get relative paths working.
I was looking at the thread here
https://forum.dlang.org/post/dkwqrwzwqbrnaamlv...@forum.dlang.org
and came up wit
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 Sunday, 25 June 2017 at 17:30:58 UTC, Petar Kirov [ZombineDev]
wrote:
On Sunday, 25 June 2017 at 13:32:57 UTC, Andrew Chapman wrote:
I think you've answered the question with "You cannot have
unimplemented templates in interfaces". Thanks for the answer.
I'll rethink the way I'm doing this
On Tuesday, 27 June 2017 at 19:22:02 UTC, Steven Schveighoffer
wrote:
Just delete the duplicate symbol, and add public imports of the
other module symbols.
e.g.:
public import core.sys.posix.netinet.in_: IP_ADD_MEMBERSHIP;
-Steve
Great. Will do.
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:12 PM, Sebastiaan Koppe wrote:
On Tuesday, 27 June 2017 at 17:58:29 UTC, Jonathan M Davis wrote:
Why would you need to remove anything from Phobos? The enum in
question is in a deprecated module. All that should need to happen is
that the enum be added to the appropriate module in
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
Is it possible to set relative -L paths on dub for Windows?
Absolute paths work fine, just can't get relative paths working.
I was looking at the thread here
https://forum.dlang.org/post/dkwqrwzwqbrnaamlv...@forum.dlang.org
and came up with something like
{
...
"lflags": ["-L-L..\\libs\\
On Tuesday, 27 June 2017 at 17:58:29 UTC, Jonathan M Davis wrote:
Why would you need to remove anything from Phobos? The enum in
question is in a deprecated module. All that should need to
happen is that the enum be added to the appropriate module in
druntime, and then any code that uses it can
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 Tuesday, June 27, 2017 3:46:39 PM MDT Sebastiaan Koppe via Digitalmars-d-
learn wrote:
> On Tuesday, 27 June 2017 at 11:16:17 UTC, Jonathan M Davis wrote:
> > Create a PR to add it to druntime and/or define it in your own
> > code.
> >
> > - Jonathan M Davis
>
> Creating a PR sounds reasonable.
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 Tuesday, 27 June 2017 at 11:16:17 UTC, Jonathan M Davis wrote:
Create a PR to add it to druntime and/or define it in your own
code.
- Jonathan M Davis
Creating a PR sounds reasonable. But I would have to create one
PR to remove them from phobos and one PR to add them to druntime,
right?
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 14:21:50 UTC, FoxyBrown wrote:
How can we clean an exe from the junk library functions that
are not actually used by an app. e.g., a hello world program
shouldn't be 500+kb. I release there are necessary extras like
the GC, but hell, in a hello world program is it ev
On Tuesday, 27 June 2017 at 14:21:50 UTC, FoxyBrown wrote:
Does Writeln even use the GC to display a single string?
Not if all goes well, but a good chunk of the library is loaded
to handle various situations. It might call a GC function if
there's no stdout.
Take a look at this:
http://th
How can we clean an exe from the junk library functions that are
not actually used by an app. e.g., a hello world program
shouldn't be 500+kb. I release there are necessary extras like
the GC, but hell, in a hello world program is it even necessary?
Does Writeln even use the GC to display a sin
On Tuesday, 27 June 2017 at 01:20:01 UTC, ag0aep6g wrote:
import std.meta: allSatisfy, ApplyRight;
import std.traits: isImplicitlyConvertible;
this(Vs...)(Vs values)
if (allSatisfy!(ApplyRight!(isImplicitlyConvertible,
T), Vs))
{
// do stuff
}
Th
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 10:48:12 Sebastiaan Koppe via Digitalmars-d-learn
wrote:
> I am building a multicast application, and I am using the
> std.c.*.socket modules to provide the definition of the
> IP_ADD_MEMBERSHIP constant.
>
> These modules are marked as deprecated telling me to look in
>
I am building a multicast application, and I am using the
std.c.*.socket modules to provide the definition of the
IP_ADD_MEMBERSHIP constant.
These modules are marked as deprecated telling me to look in
core.sys.posix.* instead.
I grepped the complete sourcetree, but nowhere is the
IP_ADD_M
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.
38 matches
Mail list logo
