Re: Reset all Members of a Aggregate Instance
On 4/12/2015 8:38 AM, Chris Wright wrote: An object reference is just a pointer, but we can't directly cast it. So we make a pointer to it and cast that; the type system allows it. Now we can access the data that the object reference refers to directly. Casting is fine too: cast(void*)classRef
Re: Can someone check this on win32 ?
On 21/11/2015 10:46 PM, BBaz wrote:
Seems to be fixed:
__
import std.math;
void main() {real function(real) c = }
__
https://issues.dlang.org/show_bug.cgi?id=4541
At least it works on linux x86_64.
It works because of
https://github.com/D-Programming-Language/phobos/pull/3599
But it only works for the std.math intrinsics, there are plenty of
others without real bodies.
Re: Something about Chinese Disorder Code
On 25/11/2015 2:16 PM, Rikki Cattermole wrote: On 25/11/15 1:47 AM, Meta wrote: I'm pretty sure you can just do: wstring text = "my string"; Or auto text = "my string"w; The second one is correct yes. I'm just assuming that it isn't compiled into the executable. Either is fine. Non-suffixed string literals have a default type of string, but implicitly convert to wstring/dstring at compile time.
Re: Purity of std.conv.to!string
On 27/09/2015 3:14 AM, cym13 wrote: On Saturday, 26 September 2015 at 17:08:00 UTC, Nordlöw wrote: Why is the following code not pure: float x = 3.14; import std.conv : to; auto y = x.to!string; ??? Is there a reason for it not being pure? If not, this is a serious problem as this is such a fundamental function. Probably because it uses C's float formatting functions, and they probably set errno and therefore aren't pure. Maybe because of floating point numbers uncertainty that would cause the resulting string to be different for two equivalent inputs? I can't seem to put an example together though. No, it doesn't work like that.
Re: DIP64 - Regarding 'pure' and 'nothrow'
Brian Schott wrote in message news:pbfgiwaxsdxdxetpi...@forum.dlang.org... The delete keyword is deprecated[1] and making that decision never broke any code. [1] http://dlang.org/deprecate.html#delete If you look at the table up the top, delete hasn't actually been deprecated yet. If and when this will actually happen is uncertain.
Re: DIP64 - Regarding 'pure' and 'nothrow'
Jonathan M Davis wrote in message news:xjmfhegvanqdivhbt...@forum.dlang.org... AFAIK, the only reason that it's not deprecated is that no one has bothered to make the change (and you didn't want to deprecate it when you went through all of those and updated their status a while back). Andrei has stated on multiple occasions that it's going, and I think that Walter has said the same. Arguably, it should have been deprecated ages ago. The only good argument I see for keeping it around is that we don't have the custom allocators yet, so it's royal pain for anyone to construct classes on the malloc heap instead of on the GC heap (since using emplace to do it is non-trivial), and anyone who's using delete and really doesn't want to wait for the GC to collect the memory doesn't have an easy alternative at the moment. Until it actually gets merged in, nothing is certain. delete is not particularly dangerous now that we have @safe working, and it might be nice to have on non-GC platforms. Anyway, that's a discussion for when somebody actually tries to get rid of it.
Re: Building 32bit program with MSVC?
Jonathan M Davis via Digitalmars-d-learn wrote in message news:mailman.1421.1401576730.2907.digitalmars-d-le...@puremagic.com... By dynamic linking do you mean LoadLibrary or linking with import library? Both will work, otherwise we couldn't use Microsoft's libraries - e.g. std.windows.registry uses advapi32.dll to talk to the registry. But static linking requires that the library formats match. However, I'm afraid that I don't know enough about how linking works to know why that's a problem for static linking and not for dynamic linking. The big issue with static linking is sharing the c runtime, which you can avoid if you're using dlls. Import libs only contain a mapping from mangled name to exported name (or ordinal) and this can easily be converted from one library format to another. In some very simple cases it _is_ possible to convert COFF (msvc) to OMF (dmc) object files and static libraries, but as soon as msvc inserts anything msvc-runtime specific it will fail miserably. Some examples are stack-check functions, special sections, runtime built-ins (eg 64-bit divide on some platforms).
Re: Any chance to avoid monitor field in my class?
Yuriy wrote in message news:klosrzuxwmvilupzz...@forum.dlang.org...
Ok, i can understand that, but what about this one:
http://dpaste.dzfl.pl/6a9961e32e6d
It doesn't use d arrays in function interfaces. Should it work?
Similar problem, D arrays cannot be mangled correctly with C++ mangling.
This compiles:
extern(C++) interface I
{
extern(D):
int hi();
}
extern(C++) class A(T) : I
{
extern(D):
override int hi()
{
return 0;
}
}
void main()
{
A!string a;
}
Re: Any chance to avoid monitor field in my class?
Yuriy wrote in message news:rfirqtgbparjbqxwt...@forum.dlang.org...
On Wednesday, 14 May 2014 at 08:47:38 UTC, Daniel Murphy wrote:
I'm not getting any errors with the development head. What os/compiler
version?
Hm, now that's strange. Building with latest public version seems to work.
However, development head is doing the following:
Never mind I can reproduce the bug with master, I probably ran 'dmd test.d'
instead of './dmd test.d' after building dmd.
This version seems to compile - the new manger can't handle extern(C++)
functions with D arrays as arguments or return types.
extern(C++) class A(T)
{
extern(D):
string hi()
{
return asdf;
}
}
void main()
{
A!string a;
}
Only the subset of extern(C++) required to interface with actual C++ code
has been tested at all, so using it with D-only types is going to be fairly
unpleasant.
Re: Any chance to avoid monitor field in my class?
On Tuesday, 13 May 2014 at 17:41:42 UTC, Yuriy wrote:
On Tuesday, 13 May 2014 at 17:09:01 UTC, Daniel Murphy wrote:
What exactly is the mangling problem with extern(C++) classes?
Can't use D arrays (and strings) as function argument types.
Can't use D array types as template arguments.
extern (C++) MyClass(T)
{
}
MyClass!string a; // Mangling error
I'm not getting any errors with the development head. What
os/compiler version?
Re: Any chance to avoid monitor field in my class?
Yuriy wrote in message news:uflaemdlxvavfmvkb...@forum.dlang.org... Hello, is there a way of reducing size of an empty class to just vtbl? I tried to declare it as extern(C++) which works, but has a nasty side effect of limited mangling. What exactly is the mangling problem with extern(C++) classes?
