Re: Should an 'extern(C++, "ns"):' override previous ones in the same scope?
On Sunday, September 8, 2019 12:12:53 PM MDT Exil via Digitalmars-d-learn wrote: > On Saturday, 7 September 2019 at 22:19:48 UTC, Jonathan M Davis > > wrote: > > On Saturday, September 7, 2019 3:40:58 PM MDT Exil via > > > > Digitalmars-d-learn wrote: > >> On Saturday, 7 September 2019 at 17:22:07 UTC, Jonathan M Davis > >> > >> wrote: > >> > @safe: > >> > @system: > >> > > >> > then @system overrides @safe. > >> > >> Just to add onto this, you can't do: > >> @safe @system void foo(); // error > >> > >> but you can do: > >> extern(C++, ns1) extern(C++, ns2) void foo(); // ok > > > > It makes no sense to apply multiple namespaces to the same > > symbol. I expect that this behavior is due to a lack of testing > > (the same with the out of order weirdness in the other post). > > It's the sort of thing that you test when you're trying to make > > sure that the feature does the right thing when people use it > > incorrectly, not the sort of thing when you're trying to make > > sure that the feature works as intended, so it's easy to forget. > > > > My guess is that this behavior leaked its way in due to the > > fact that you > > need to be able to put multiple extern(C++) declarations on a > > symbol when > > you use extern(C++, struct) or extern(C++, class) in addition > > to the > > extern(C++) for the namespace. > > > > - Jonathan M Davis > > You don't need to make guesses or assumptions. It most definitely > was intentional. > > https://github.com/dlang/dmd/commit/4b2578e208f2af9a02159fc2d8d87fb17b0900 > 5e#diff-62dcb5f0ffc3089b7565897d8beb3322R617 > > > By the looks of it, this feature was also implemented before > extern(C++, struct/class). Well, it's inconsistent with the rest of the language and bad design IMHO. And even if it were desirable behavior, it clearly becomes a mess with the ordering once the attributes are no longer directly on the symbol. Of course, ideally, the whole extern(C++) feature with identifiers instead of strings for the namespace would be deprecated anyway. - Jonathan M Davis
Re: Should an 'extern(C++, "ns"):' override previous ones in the same scope?
On Saturday, 7 September 2019 at 22:19:48 UTC, Jonathan M Davis wrote: On Saturday, September 7, 2019 3:40:58 PM MDT Exil via Digitalmars-d-learn wrote: On Saturday, 7 September 2019 at 17:22:07 UTC, Jonathan M Davis wrote: > @safe: > @system: > > then @system overrides @safe. Just to add onto this, you can't do: @safe @system void foo(); // error but you can do: extern(C++, ns1) extern(C++, ns2) void foo(); // ok It makes no sense to apply multiple namespaces to the same symbol. I expect that this behavior is due to a lack of testing (the same with the out of order weirdness in the other post). It's the sort of thing that you test when you're trying to make sure that the feature does the right thing when people use it incorrectly, not the sort of thing when you're trying to make sure that the feature works as intended, so it's easy to forget. My guess is that this behavior leaked its way in due to the fact that you need to be able to put multiple extern(C++) declarations on a symbol when you use extern(C++, struct) or extern(C++, class) in addition to the extern(C++) for the namespace. - Jonathan M Davis You don't need to make guesses or assumptions. It most definitely was intentional. https://github.com/dlang/dmd/commit/4b2578e208f2af9a02159fc2d8d87fb17b09005e#diff-62dcb5f0ffc3089b7565897d8beb3322R617 By the looks of it, this feature was also implemented before extern(C++, struct/class).
Re: Learning delegates
On Sunday, 8 September 2019 at 10:04:57 UTC, Joel wrote:
I'm trying to understand delegates. Is there any good ways I
can get a better understanding of them?
I am no compiler implementer, so what is below may contain a lot
of inaccuracies and conceptual shortcuts, but here is my view of
delegates in D. I hope this helps.
Delegates are fat function pointers.
D arrays are also fat function pointers: they can be implemented
as a struct with a size_t length and a pointer to the data:
sruct DArray(T) {
size_t length;
T * data;
}
D delegates can be implemented as a pointer to some context data
and a function pointer, something similar to D arrays:
struct DDelegate(Context, Return, Args) {
Context context;
Return function(Args) functionPointer;
}
The context can be:
- a struct value
- a class instance
- some data from a local function frame when the delegate is used
as a closure.
The compiler replaces a call to the delegate in the source code
by a call to the function pointer with the right data for runtime.
Something like:
dg.functionPointer(dg.context, "hello, world");
Sum of three cubes
import std.stdio, std.bigint;
//
// https://twitter.com/robinhouston/status/1169877007045296128
//
void main()
{
BigInt a = "80538738812075974";
BigInt b = "80435758145817515";
BigInt c = "12602123297335631";
writeln("42=", (-a)^^3 + b^^3 + c^^3);
}
Re: Learning delegates
On Sunday, 8 September 2019 at 10:04:57 UTC, Joel wrote: I'm trying to understand delegates. Is there any good ways I can get a better understanding of them? I wrote a foreach loop using opApply. A side effect of that was, that after I managed to do this I understood delegates. :-)
Re: Learning delegates
On Sunday, 8 September 2019 at 10:04:57 UTC, Joel wrote: I'm trying to understand delegates. Is there any good ways I can get a better understanding of them? You may want to read this: https://tour.dlang.org/tour/en/basics/delegates
Re: Should an 'extern(C++, "ns"):' override previous ones in the same scope?
On Sunday, 8 September 2019 at 09:35:03 UTC, Jonathan M Davis wrote: The C++ support has been improved kind of piecemeal over time, and initially, none of it was documented. So, it wasn't exactly fully planned out when it was added. IIRC, it was added originally so that the dmd frontend could be moved to D. The DIP process was very different at that point, and it was much more common then for Walter or one of the other core developers to just propose a feature in a PR and get it merged. I expect that the oddities in the implementation stem from stuff that whoever implemented it didn't think to try. The whole process is much more rigorous now than it used to be. - Jonathan M Davis Good to know, thank you.
Learning delegates
I'm trying to understand delegates. Is there any good ways I can get a better understanding of them?
Re: Should an 'extern(C++, "ns"):' override previous ones in the same scope?
On Sunday, September 8, 2019 3:03:31 AM MDT Max Samukha via Digitalmars-d- learn wrote: > On Saturday, 7 September 2019 at 22:19:48 UTC, Jonathan M Davis > > wrote: > > On Saturday, September 7, 2019 3:40:58 PM MDT Exil via > > > > Digitalmars-d-learn wrote: > >> On Saturday, 7 September 2019 at 17:22:07 UTC, Jonathan M Davis > >> > >> wrote: > >> > @safe: > >> > @system: > >> > > >> > then @system overrides @safe. > >> > >> Just to add onto this, you can't do: > >> @safe @system void foo(); // error > >> > >> but you can do: > >> extern(C++, ns1) extern(C++, ns2) void foo(); // ok > > > > It makes no sense to apply multiple namespaces to the same > > symbol. I expect that this behavior is due to a lack of testing > > (the same with the out of order weirdness in the other post). > > It's the sort of thing that you test when you're trying to make > > sure that the feature does the right thing when people use it > > incorrectly, not the sort of thing when you're trying to make > > sure that the feature works as intended, so it's easy to forget. > > > > My guess is that this behavior leaked its way in due to the > > fact that you > > need to be able to put multiple extern(C++) declarations on a > > symbol when > > you use extern(C++, struct) or extern(C++, class) in addition > > to the > > extern(C++) for the namespace. > > > > - Jonathan M Davis > > I wonder how that undocumented and not well thought-through (or > having some unobvious justifications) feature made it into a > stable release. > > Anyway, thank you for your help. I will probably file a bug > report when I have time. The C++ support has been improved kind of piecemeal over time, and initially, none of it was documented. So, it wasn't exactly fully planned out when it was added. IIRC, it was added originally so that the dmd frontend could be moved to D. The DIP process was very different at that point, and it was much more common then for Walter or one of the other core developers to just propose a feature in a PR and get it merged. I expect that the oddities in the implementation stem from stuff that whoever implemented it didn't think to try. The whole process is much more rigorous now than it used to be. - Jonathan M Davis
Re: Should an 'extern(C++, "ns"):' override previous ones in the same scope?
On Saturday, 7 September 2019 at 22:19:48 UTC, Jonathan M Davis wrote: On Saturday, September 7, 2019 3:40:58 PM MDT Exil via Digitalmars-d-learn wrote: On Saturday, 7 September 2019 at 17:22:07 UTC, Jonathan M Davis wrote: > @safe: > @system: > > then @system overrides @safe. Just to add onto this, you can't do: @safe @system void foo(); // error but you can do: extern(C++, ns1) extern(C++, ns2) void foo(); // ok It makes no sense to apply multiple namespaces to the same symbol. I expect that this behavior is due to a lack of testing (the same with the out of order weirdness in the other post). It's the sort of thing that you test when you're trying to make sure that the feature does the right thing when people use it incorrectly, not the sort of thing when you're trying to make sure that the feature works as intended, so it's easy to forget. My guess is that this behavior leaked its way in due to the fact that you need to be able to put multiple extern(C++) declarations on a symbol when you use extern(C++, struct) or extern(C++, class) in addition to the extern(C++) for the namespace. - Jonathan M Davis I wonder how that undocumented and not well thought-through (or having some unobvious justifications) feature made it into a stable release. Anyway, thank you for your help. I will probably file a bug report when I have time.
Re: Newbie linker errors - still missing _fltused _tls_index _tls_used localtime tzset mainCRTStartup
On 08/09/2019 00:30, malpropism wrote: > I just ported my Java application to D, got it to compile, but not to link. > > I'm using Windows 10 64 bit, DMD 2.088.0 , Visual D 0.50.1. This would > be a C/C++ project in Visual Studio with only D code. > > With my first attempt, I'm missing 65 externals, 328 errors. > > I added these two files > > ucrt.lib > vcruntime.lib > > to the Additional Dependencies in the linker property pages and have my > missing external count down to 6, 70 errors. > > I'm missing the following 6 symbols: > > _fltused _tls_index _tls_used localtime tzset mainCRTStartup > > What other libs would I need to add to the linker's additional > dependencies? I suspect you have disabled the C runtime library selection in the D compilation options to build against the shared C runtime DLLs (you can select that, too). Or your code might be missing a main function in which case the selection might not be embedded into any object file. In this case, you should add msvcrt.lib instead of vcruntime.lib. Depending on used functionality you will also need legacy_stdio_definitions.lib.
Newbie linker errors - still missing _fltused _tls_index _tls_used localtime tzset mainCRTStartup
PS: Here are the actual linker errors: 1>phobos64.lib(gc_23c0_122.obj) : error LNK2001: unresolved external symbol _fltused 1>phobos64.lib(ti_float_2680_3f3.obj) : error LNK2001: unresolved external symbol _fltused 1>phobos64.lib(hash_d99_76c.obj) : error LNK2001: unresolved external symbol _fltused 1>phobos64.lib(typeinfo_2629_49b.obj) : error LNK2001: unresolved external symbol _fltused 1>phobos64.lib(demangle_c1d_79b.obj) : error LNK2001: unresolved external symbol _fltused 1>phobos64.lib(parseoptions_dbf_7cf.obj) : error LNK2001: unresolved external symbol _fltused 1>phobos64.lib(gc_23bb_583.obj) : error LNK2001: unresolved external symbol _fltused 1>dcompile_ACME.obj : error LNK2001: unresolved external symbol _fltused 1>phobos64.lib(ti_double_267f_3f1.obj) : error LNK2001: unresolved external symbol _fltused 1>phobos64.lib(hash_d90_7d1.obj) : error LNK2001: unresolved external symbol _fltused 1>phobos64.lib(hash_da7_5fe.obj) : error LNK2001: unresolved external symbol _fltused 1>phobos64.lib(thread_cae_681.obj) : error LNK2001: unresolved external symbol _tls_index 1>phobos64.lib(thread_cb1_5f2.obj) : error LNK2001: unresolved external symbol _tls_index 1>phobos64.lib(gc_23e3_142b.obj) : error LNK2001: unresolved external symbol _tls_index 1>phobos64.lib(lifetime_2517_713.obj) : error LNK2001: unresolved external symbol _tls_index 1>phobos64.lib(exception_c7a_fff.obj) : error LNK2001: unresolved external symbol _tls_index 1>phobos64.lib(thread_cac_6f2.obj) : error LNK2001: unresolved external symbol _tls_index 1>phobos64.lib(gc_23df_13c3.obj) : error LNK2001: unresolved external symbol _tls_index 1>phobos64.lib(gc_23e0_687.obj) : error LNK2001: unresolved external symbol _tls_index 1>phobos64.lib(gc_23e1_687.obj) : error LNK2001: unresolved external symbol _tls_index 1>phobos64.lib(gc_23e2_e95.obj) : error LNK2001: unresolved external symbol _tls_index 1>phobos64.lib(gc_23db_12f9.obj) : error LNK2001: unresolved external symbol _tls_index 1>phobos64.lib(gc_23dc_1319.obj) : error LNK2001: unresolved external symbol _tls_index 1>phobos64.lib(gc_23dd_12df.obj) : error LNK2001: unresolved external symbol _tls_index 1>phobos64.lib(gc_23de_12a7.obj) : error LNK2001: unresolved external symbol _tls_index 1>phobos64.lib(gc_23d5_2117.obj) : error LNK2001: unresolved external symbol _tls_index 1>phobos64.lib(gc_23d7_1ed1.obj) : error LNK2001: unresolved external symbol _tls_index 1>phobos64.lib(gc_23d8_13ee.obj) : error LNK2001: unresolved external symbol _tls_index 1>phobos64.lib(gc_23d9_114b.obj) : error LNK2001: unresolved external symbol _tls_index 1>phobos64.lib(gc_23d1_10bd.obj) : error LNK2001: unresolved external symbol _tls_index 1>phobos64.lib(gc_23d2_12c9.obj) : error LNK2001: unresolved external symbol _tls_index 1>phobos64.lib(gc_23d3_12c9.obj) : error LNK2001: unresolved external symbol _tls_index 1>phobos64.lib(gc_23d4_1e85.obj) : error LNK2001: unresolved external symbol _tls_index 1>phobos64.lib(gc_23bb_583.obj) : error LNK2001: unresolved external symbol _tls_index 1>phobos64.lib(gc_23c0_122.obj) : error LNK2001: unresolved external symbol _tls_index 1>phobos64.lib(gc_23cf_e95.obj) : error LNK2001: unresolved external symbol _tls_index 1>phobos64.lib(gc_23d0_e95.obj) : error LNK2001: unresolved external symbol _tls_index 1>phobos64.lib(advapi32_3e23_45c.obj) : error LNK2001: unresolved external symbol _tls_index 1>phobos64.lib(tlsgc_25a3_1b4.obj) : error LNK2001: unresolved external symbol _tls_index 1>phobos64.lib(advapi32_3e22_45a.obj) : error LNK2001: unresolved external symbol _tls_index 1>phobos64.lib(sections_win64_2590_507.obj) : error LNK2001: unresolved external symbol _tls_index 1>phobos64.lib(deh_win64_posix_24d8_6ee.obj) : error LNK2001: unresolved external symbol _tls_index 1>phobos64.lib(thread_cd3_864.obj) : error LNK2001: unresolved external symbol _tls_index 1>phobos64.lib(thread_cbe_6a3.obj) : error LNK2001: unresolved external symbol _tls_index 1>phobos64.lib(registry_3d3f_4ba.obj) : error LNK2001: unresolved external symbol _tls_index 1>phobos64.lib(exception_c79_d6c.obj) : error LNK2001: unresolved external symbol _tls_index 1>phobos64.lib(exception_c77_1702.obj) : error LNK2001: unresolved external symbol _tls_index 1>phobos64.lib(thread_c9d_48b.obj) : error LNK2001: unresolved external symbol _tls_index 1>phobos64.lib(thread_c9a_713.obj) : error LNK2001: unresolved external symbol _tls_index 1>phobos64.lib(profilegc.obj) : error LNK2001: unresolved external symbol _tls_index 1>phobos64.lib(thread_c9c_258.obj) : error LNK2001: unresolved external symbol _tls_index 1>phobos64.lib(dll.obj) : error LNK2001: unresolved external symbol _tls_index 1>phobos64.lib(thread_cc0_1e8.obj) : error LNK2001: unresolved external symbol _tls_index 1>phobos64.lib(exception_c78_b74.obj) : error LNK2001: unresolved external symbol _tls_index 1>phobos64.lib(lifetime_2515_4a3.obj) : error LNK2001: unresolved external symbol _tls_index
