Greetings
This small code snippet works:
//
import std.conv;
import std.stdio;
void main() {
writeln(toChars!10(45));
}
But if I change toChars!10 with toChars!2, I get:
/tmp/test.d(6): Error: template std.conv.toChars cannot deduce
function from argument types !(2)(int), candidates are:
The fix turned out to be much simpler than what I had thought.
https://github.com/D-Programming-Language/druntime/pull/1506
Greetings
I am using my D code as a dynamically loadable library that gets
loaded at run time into C/C++ world. As discussed earlier on this
thread, the GC does not mark TLS objects in this scenario and as
a result the GC ends up collecting TLS objects even though these
objects are still in
On Thursday, 18 February 2016 at 13:00:12 UTC, Witek wrote:
Anyhow, everything was good on 1 or 2 threads, or maybe few
more, on my laptop with old Dual Core CPU. I was able to speed
it up exactly by a factor of 2x.
I wanted to try it out on bigger machine, so used Amazone AWS
EC2
Too illustrate how headconst can help with multithreading (shared
memory) code, I have created this small snippet. In my
experience, there are lots of *effectively immutable* objects
(like Foo.bar in the code snippet). If these variables can be
declared headconst, a lot of hierarchical
Greetings
Having coded a multithreaded library in D, I sorely miss headcost
like specifier.
The library code dealt with lots of composite class object
hierarchy where many element objects of a parent are *effectively
immutable*. You build an effectively immutable object in the
constructor
Thanks Daniel
I have added the testcase to a more obscure testcase that I had
raised on Bugzilla earlier.
https://issues.dlang.org/show_bug.cgi?id=15513
I want to request developers to show some love.
Regards
- Puneet
Greetings
I am struggling with strange memory corruption issues with
dmd-2.069.2 release.
The issue shows up only when I load a shared library created from
D code from C and call some D functions from the C side. But
since the program control is completely with the D code, and data
Another workaround is to use GC.addRoot for dynamic allocated
data in Dynamic.proc
void proc () {
import core.memory: GC;
dash.length = 32;
GC.addRoot(cast(void*)dash.ptr);
dash[] = '-';
}
And another one is hold pointer to data:
class Dynamic {
static char[] space;
Thanks Basile/Adam. The templates that you provided work for me.
It seems like saying that a constructor with all default
arguments is not a default constructor is a distinction without
meaning. What are you doing that you would care?
The Object.factory does not seem to consider a constructor with
default arguments as a defaultConstructor. Consider the
I think this is related to the bug 3438 that got fixed recently.
https://issues.dlang.org/show_bug.cgi?id=3438
Regards
- Puneet
Hello Folks
When I try using TypeInfo_Class.defaultConstructor during compile
time, I get:
typeid(Foo).defaultConstructor is not yet implemented at
compile time
Is there any other way to find out at compile time if a default
constructor exists for a given class?
Regards
- Puneet
You might be able to just do `static if(__traits(compiles, new
YourClass()))` and if it returns true then figure it does.
That gives me a false positive if a defined constructor has
default value for all its arguments.
Greetings
I am calling a D function from an opensource application coded in
C/C++. My code crashes, though there is no reason for it to
crash. Also when I call my D function from inside D, it does not
crash. The D function does not take any arguments, nor does it
try to access any variable
15 matches
Mail list logo
