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 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 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
I want to call a method of the certain instance of "MyClass" from
certain widget.
Each widget should know its corresponding instance of "MyClass".
As far as I understood, delegates cannot do it.
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 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 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: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
Shouldn't the compiler be able to resolve foo!g(3) to the first
template foo?
import std.stdio;
import std.algorithm;
import std.range;
auto foo(F, T)(T x)
{
return x.foo(F);
}
auto foo(F, T)(T x, F f)
{
return f(x);
}
int g(int x) { return x; }
void main()
{
foo(3, &g); // 2nd f
On Wednesday, 28 June 2017 at 11:49:57 UTC, Balagopal Komarath
wrote:
Shouldn't the compiler be able to resolve foo!g(3) to the first
template foo?
import std.stdio;
import std.algorithm;
import std.range;
auto foo(F, T)(T x)
{
return x.foo(F);
}
auto foo(F, T)(T x, F f)
{
return f(x)
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 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.
I can't understand why follow code is crushing:
string error = "503 Server error!";
int error_code = 503;
res.render!("error.dt", error, error_code);
on res string (last in code above) I am getting error:
CoreTaskFiber was terminated unexpectedly: Access Violation
error.dt http://paste.code123.
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 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?
It's look like issue in another part of code...
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 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: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 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 00:22:56 UTC, Mike Parker wrote:
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
I am behind a corporate firewall at work so I have to manually
install dub packages. This requires setting the version manually,
otherwise master is inferred. This was working great until I had
ended a dub run command early. Now dub seems to have forgotten
that the versions are in there. It's w
On Wednesday, 28 June 2017 at 19:54:01 UTC, jmh530 wrote:
[snip]
Does not seem to be a problem for another project using dub with
dmd and similar dependencies...
On Wednesday, 28 June 2017 at 20:18:20 UTC, jmh530 wrote:
On Wednesday, 28 June 2017 at 19:54:01 UTC, jmh530 wrote:
[snip]
Does not seem to be a problem for another project using dub
with dmd and similar dependencies...
After spending some time looking through the dub issues, I found
that
According to the standard (http://dlang.org/spec/float.html), the
compiler is allowed to compute any floating-point statement in a
higher precision than specified. Is there a way to deactivate
this behaviour?
Context (reason why I need this): I am building a "double double"
type, which essent
On Wednesday, 28 June 2017 at 22:16:48 UTC, Simon Bürger wrote:
(If you are interested in the "double double" type, take a look
here:
https://github.com/BrianSwift/MetalQD
which includes a double-double and even quad-double
implementation in C/C++/Fortran)
Nice work can you re or dual licens
On Wednesday, 28 June 2017 at 23:56:42 UTC, Stefan Koch wrote:
As for your problems they can be worked around.
by assigning every temporary to a variable.
Which will enforce the discarding of precision.
Sorry for the misinformation!
I was using the newCTFE fork which fixes this.
Indeed you'll
On Wednesday, 28 June 2017 at 22:16:48 UTC, Simon Bürger wrote:
I am currently using LDC on 64-bit-Linux if that is relevant.
It is, as LDC on Windows/MSVC would use 64-bit compile-time
reals. ;)
Changing it to double on other platforms is trivial if you
compile LDC yourself. You'll want to
On Wednesday, 28 June 2017 at 12:19:31 UTC, vit wrote:
auto foo(alias F, T)(T x)
{
return x.foo(&F);
}
With this definition foo!((x) => x+1)(3); doesn't work. Is there
a way to solve this?
29 matches
Mail list logo
