Re: D for Game Development
On Wednesday, 5 August 2015 at 16:44:03 UTC, jmh530 wrote: On Wednesday, 5 August 2015 at 08:53:39 UTC, Benjamin Thaut wrote: Regarding D's GC and Games written in D you can also take a look at a old project of mine and the results that came out of it. http://3d.benjamin-thaut.de/?p=20 Towards the end you list some performance and memory leaking issues in D. Have you seen improvement in these areas? - Comparision of TypeInfo objects in druntime is done by building two strings and then comparing those two strings. This will always leak memory and do a lot of unneccesary allocations which are a performance bottleneck. I reworte the comparison so it does not allocate a single byte. I did a pull request to improve this once, but it was rejected. So this issue still remains. Comparing two type info objects still produces garbage. - Calls to the druntime invariant handler are emitted in release build also and there is no way to turn them off. Even if the class does not have any invariants the invariant handler will always be called, walk the class hirarchy and generate multiple cache misses without actually doing anything. Afaik this has been fixed. - The new statement will not free any memory if the constructor throws a exception. So you are forced to replace both the new and the delete statement. But you can not replace the new statement with similar nice syntax especially for inner classes and arrays. This issue still remains, although might improve soon with std.allocator. The language is not designed to make it possible for new/delete to be replaced in a nice way so most likely new int[3] will become allocator.makeArray!int(3) - Inlining of DMD. Inlining of DMD seems to be very minimal. Most of my overloaded operators are not inlined by dmd at all. This somewhat improved, especially with pragma(inline) but dmd is still really bad at inlining and I still can't compile all my projects with the -inline switch because dmd produces invalid function calls if I do so. And don't tell me to use a different compiler, on windows the only viable option still is dmd. Gdc for windows is no longer maintained and ldc is not there yet (but might be soon). - Array literals. They always allocate, even if they don’t have to. For example when asiging to a fixed size array, or when passing to a function with a scope parameter. This greatly improved. Thanks to Kenji you can now have non allocating array literals. - D-Style variadic functions. Same as array literals, because internaly they are rewrote to one. Especially for these kind of functions I don’t see any reason why they should allocate on the heap. I'm not sure about this one, I would have to investigate. Kind Regards Benjamin Thaut
Re: D for Game Development
On Thursday, 30 July 2015 at 13:44:41 UTC, deadalnix wrote: On Thursday, 30 July 2015 at 13:43:35 UTC, karabuta wrote: D is really cool and makes a good candidate for developing a game. Are there any guys out there using D for indie games? For some time I have been seeing some cool game engine being developed in the DUB repo. What more is happening? I don't see derelictSDl and derelictSFML activities much. Whatup? GC's up. Regarding D's GC and Games written in D you can also take a look at a old project of mine and the results that came out of it. http://3d.benjamin-thaut.de/?p=20 Kind Regards Benjamin Thaut
Re: rust
On Friday, 17 July 2015 at 17:18:16 UTC, roaming wrote: On Friday, 17 July 2015 at 13:48:25 UTC, anonymous wrote: On Friday, 17 July 2015 at 13:42:33 UTC, roaming wrote: On Thursday, 16 July 2015 at 12:06:46 UTC, Kagamin wrote: http://rainers.github.io/visuald/visuald/StartPage.html https://code.visualstudio.com/Updates/ can you do multiple dll on win yet? Do you ask this because of the runtime ? yes. i will have one D program calling several D made dll's. is that possible now No its not. I'm currently working on a patch for DMD, druntime phobos to make this possible but its still going to a few more months until I'm ready to submit a pull request.
Re: Destructors and static array assignment
On Monday, 20 July 2015 at 14:51:57 UTC, Jonathan M Davis wrote:
On Monday, 20 July 2015 at 14:18:33 UTC, David Nadlinger wrote:
Am I missing something here, or is this a major bug in struct
lifetime handling?
I understand why this happens from the DMD source, but it
almost seems like it was deliberately written this way; thus
the question.
Purposeful or not, I don't see how it could be anything other
than a bug. It fundamentally breaks your ability to control
what's going on with the construction or destruction of an
object. And a quick check seems to indicate that out parameters
have the same problem. If I add this function
void foo(out S s)
{
}
and then this to the end of main
{
S s;
foo(s);
}
it fails to hit the assertion. The dtorCount in 1, which I
think is correct, since the out param is a reference to s and
thus shouldn't destroy it, but it _should_ assign to it, and it
looks like it's just bitblitting S.init rather than assigning
it S.init.
- Jonathan M Davis
This bug with out and structs is very old:
https://issues.dlang.org/show_bug.cgi?id=6186
It even has 26 votes, but it doesn't seem to be important enough
to be fixed.
Kind Regards
Benjamin Thaut
really good talk about the Hotspot VM
This talk is really good and contains a lot of usefull information very densly packed: https://www.youtube.com/watch?v=vzzABBxo44g The speaker has 30 years of experience working on javas hotspot vm and shares his opinions on what you should do. My takeaways from this talk are: GC: -You want a fully percise GC (e.g. know _all_ pointers even the ones on the stack), the benenift outweights the cost for tracking pointers. -You do not want to pin allocations in the gc heap as it is to restrictive for your gc implementation. -GC safepoints worked out really well. TLS: To get fast thread local storage, align the start of the stack so you can chop of a few bits of the stack pointer to get to the TLS-section. We might be able to use this on platforms with slow TLS? Kind Regards Benjamin Thaut
Re: really good talk about the Hotspot VM
On Thursday, 16 July 2015 at 17:52:33 UTC, rsw0x wrote: On Thursday, 16 July 2015 at 17:30:06 UTC, Benjamin Thaut wrote: This talk is really good and contains a lot of usefull information very densly packed: https://www.youtube.com/watch?v=vzzABBxo44g [...] Treating D's GC the same as a managed language running in a VM's GC will only end in disappointment. Why? The only real difference is that a java vm generates the machine code during runtime while the D compiler generates the machine code ahead of time. The underlying implementation of the important GC parts (e.g. pointer discovery, safe points, etc) are still the same. And if you look for a state of the art GC, they only exist for VMs. I don't know any other compiled language with a GC you could compare against.
Re: really good talk about the Hotspot VM
On Thursday, 16 July 2015 at 17:37:44 UTC, Justin Whear wrote: On Thu, 16 Jul 2015 17:30:05 +, Benjamin Thaut wrote: The speaker has 30 years of experience working on javas hotspot vm How is this possible? Time travel? I confused that one. He actually states that he has 35 years of experience building compilers and 20 years on the Hotspot VM, which still is a huge amount of experience.
Re: AMD Windows 7
On Friday, 12 June 2015 at 14:39:55 UTC, Chris wrote: I wish it were an error in the Python code so I could fix it, but it works on all other machines (at least those with Intel). It's only on the HP625 with AMD that this error occurs. Another DLL (which isn't mine) also failed to load, although with a different error message. It might be just this particular model, or AMD, I dunno. I couldn't find anything about it on the internet. Atm I'm using dmd 2.067.1, maybe compiling with GDC or LDC will fix it. That sounds more like its the software installed on the machine and not the processor. Are you sure that all microsoft runtime libraries are installed? If you did use the vs 2012 linker to create the D-dll you need to install this redistributable package: http://www.microsoft.com/en-US/download/details.aspx?id=30679 Did you run Depends on the dll? Usually depends will tell you why the dll does not load: http://www.dependencywalker.com/ Kind Regards Benjamin Thaut
Re: Daily downloads in decline
On Monday, 1 June 2015 at 18:14:40 UTC, Andrei Alexandrescu wrote: On 6/1/15 11:11 AM, Andrei Alexandrescu wrote: What other large topics for 2.068? I'm still working on Windows DLL support whenever I find time, and I hope to get it done for 2.068 or 2.069 Kind Regards Benjamin Thaut
Re: DLL symbol identity
On Wednesday, 13 May 2015 at 11:27:18 UTC, Logan Capaldo wrote: Yes it won't happen for explicit LoadLibrary's and GetProcAddresses, but COM or other plugin systems is an example of a situation where many DLLs may expose the same named symbols with different definitions, and there may be situations where people link to those DLLs directly to get other things they provide. Once again, I'm going to patch the import table. The import table gets only generated for symbosl which are _imported_ by a import library. This only happens for things that get imported by D libraries / executables. Linking against multiple dlls via a import library which export the same symbol doesn't work no matter if I do the patching or not. So nothing changes in that regard. Your COM Dlls are not going to break even if each COM dll exports the same symbol. Because these COM specific symbols will not be imported by a D library via a import library, so nothing changes. The problems you think exist do not exist because I only patch the importing table and not the dlls that export the symbols. Even if you mix D with C++ you are not going to have that problem, because you can't link against multiple libraries with the same symbol with C++ either.
Re: Accessing x86 Performance Counters
On Wednesday, 13 May 2015 at 08:53:10 UTC, Kagamin wrote: There was no word about windows, but process explorer shows page faults and cycles per process from unprivileged account, so I guess, this information is available through some API. Not sure is such system-wide statistics is available too. He is talking about the performance counters build into intel x86 processors (at least thats what I understood) thats something completely different from page faults and cycles per process. And as it is processor specific there is _no_ general api for it.
Re: Broken contract programing
On Wednesday, 13 May 2015 at 12:05:48 UTC, Timon Gehr wrote:
On 05/13/2015 12:51 PM, iackhtak wrote:
There was discussion about broken contract programing. One
broken
thing was in contract within inheritance. If you add
different
in-contract in overridden parent and derived function only
one
will be checked.
No, this is incorrect. Only one needs to pass and if one does
not, the other is checked as well.
Wasn't the point that the set of values the derived contract
accepts must be a superset of the set of values the base
contract accepts? E.g.
class Base
{
int foo(int x)
in { assert( x = 0; );
body { ... }
}
This would be ok:
class DerivedOk : Base
{
override int foo(int x)
in { assert( x = 0 || x -5 ); }
body { ... }
}
This would be broken:
class DerivedBroken : Base
{
override int foo(int x)
in { assert( x = 0 x 5 ); }
body { ... }
}
Because if you have a pointer to the base type it must always
work with the contract specified in the definition of the base
type (because that is most likely the only thing the client
sees). So further restricting the possible range of values will
possibly break code when swapping out implementations. However
increasing the range of possible values will not break when
swapping implementations.
Re: DLL symbol identity
On Wednesday, 13 May 2015 at 12:57:35 UTC, Logan Capaldo wrote: a.dll provides symbol s1 b.dll provides symbol s1 c.dll imports symbol s1 from a.dll, provides symbol s2 d.dll imports symbol s1 from b.dll, provides symbol s3 e.exe imports symbol s2 from c.dll, imports symbol s3 from d.dll. e.exe only needs the import libs from c.dll and d.dll. You're patching the import tables at runtime correct?. If you patch c and d's import tables their s1 import is going to end up pointing at the same symbol. I can build a.dll and c.dll completely independently of d.dll and b.dll. There's no opportunity to prevent this at compile time. Likewise e.exe doesn't know or care s1 exists so it builds fine as well. You don't need a.lib or b.lib to build e.exe. Yes, but exactly the same behavior is currently in place on linux. Also your example is quite a corner case, the usual use case where you wan't symbols of multiple instances of the same template to be merged is more common. I don't see any real use case in D where it would be important that the duplicated s1 symbols are not merged. Non D dlls will not be touched and if you really need that behavior you can always put your non D code in a seperate Dll to avoid this behavior.
Re: DLL symbol identity
On Wednesday, 13 May 2015 at 13:50:52 UTC, Logan Capaldo wrote: I _think_ if you only do this for D-mangled symbols you'll get 99% of the benefits (doing the right things for templates etc.) without causing problems for the corner cases. Yes, that's the plan. I might even do it only for D data symbols, because you don't really care about the identity of functions.
Re: Broken contract programing
On Wednesday, 13 May 2015 at 12:54:52 UTC, Timon Gehr wrote: This will accept the same arguments as Base. Only one in-contract in the inheritance chain must pass in order for the call to go through. But wasn't exactly that the problem about the current implementation? Shouldn't all 'in' contracts in the chain be checked?
Re: DLL symbol identity
On Tuesday, 12 May 2015 at 17:48:50 UTC, Logan Capaldo wrote: q could be a completely different type in a.dll vs. c.dll. Please correct me if I am wrong, but my understanding of how import libs get used you can't detect this at build time and disallow it. Linking d.exe we have no reason to look at a.lib and notice the conflict, and even if we did there's no type information to go off of anyway and you could assume that they were the same. No q can not be a different type in a.dll vs c.dll Because of the mangling of the type it would be called a.q once and c.q so no conflict would arise. If you define the same type within the same module but it behaves differently depending on where it is used (e.g. depending on compiler flags -version -debug etc), this is already an issue and will also explode with static libraries. So nothing new here. The user of the language has to ensure that all uses of a type see the same declaration of the type. Is your intent to only apply this unification to extern (D) symbols? Why not? I can't think of anything special about extern (D) declarations. Just as a reminder, linux already does this for _all_ symbols. And it doesn't cause any issues there.
Re: Accessing x86 Performance Counters
On Wednesday, 13 May 2015 at 03:38:33 UTC, Maxime Chevalier-Boisvert wrote: I was wondering if anyone has written D code to access the x86 performance counters, to get information such as the number of cache misses and cycle count. I considered doing that at one point. So I looked for resources on the topic and it turns out that you need a kernel mode executable to be able to read the performance counters. Luckly there is a open source driver for windows which gives you some API to access the counters from user mode executables. Unfortunately you need to either switch your windows into a unsafe mode to allow for loading unsigned drivers or you need to somehow get a certificate to sign the driver (these are quite expensive). At that point I stopped looking into this, because both of these options weren't viable for my use case. Once I find some time I could dig up the resources I found if you are interested.
Re: DLL symbol identity
On Wednesday, 13 May 2015 at 07:41:27 UTC, Logan Capaldo wrote: If my program only links against DLLs written in D, sure this is no worse than the static library/version flag situation. But one of D's features is C and C++ interop. For instance if I link against a DLL that happens to provide COM objects am I going to start getting weird behaviors because all the DllGetClassObjects are 'unified' and we just pick one? Well this unification will only happen for D libraries. Its not going to do that for non D shared libraries (e.g. written in C or C++). The unification is also only going to happen for things that are linked in via a import library. So if you load the stuff manually with GetProcAddress you still get the real thing. All in all the summary is, if it breaks with static libraries it will break with shared libraries as well. If you have multiple static libraries that all define a symbol called DllGetClassObjects then it won't even link.
Re: DLL symbol identity
On Sunday, 10 May 2015 at 21:44:59 UTC, Dicebot wrote: Well choice between two presented options seems obvious so I suspect a catch :) Well, exactly like with the shared library visibility the only catch might be Walter's and Andrei's opinion.
Re: DLL symbol identity
Why did Microsoft go with that approach, Maybe they didn't know better back then. Historically DLLs initially didn't support data symbols at all, only functions where supported. For functions its not a problem if they are duplicated because usually you don't compare pointers to functions a lot. Later they added support for data symbols building on what they had. I assume the system that is in place now is a result of that. why did it work for them Because C/C++ are not as template heavy as D and you basically try to avoid cross dll templates in c++ at all cost when developing for windows. Because if you do use templates across dll boundaries and you are not super careful you get a lot of issues due to duplicate symbols (e.g. static variables existing twice etc). MSVC gets around the casting issue by essentially doing string comparisons for dynamic casts which comes with a significant performance impact. On the other hand you don't use dynamic casts in c++ a lot (if you care about performance). and why does it not map well to D ? D uses tons of templates everywhere. Even type information for non templated types is generated on demand and stored in comdats which can lead to duplicate symbols the same way it does for templates. In D the dynamic cast is basically the default and you have to force the compiler to not use a dynamic cast if you care for performance. Its not like the linux approach doesn't have issues as well. I heard of cases where people put large parts of boost into a shared library and the linux loader would take multiple minutes to load the shared library into the program. This however is mostly due to the fact that on linux all symbols are visible from a shared library by default. In later versions of gcc (4+) they added a option to make all symbols hidden by default (-fvisibility=hidden) and you can make only those visible that you need. This then significantly speeds up loading of shared libraries because the number of symbols that need to be resolved is greatly decreased. On the other hand the linux approach has a additional advantage I didn't mention yet. You can use the LD_PRELOAD feature to inject shared libraries into processes. E.g. for injecting a better malloc library to speed up your favorite program. This is not easily possible with the windows approach to shared libraries.
Re: DLL symbol identity
On Monday, 11 May 2015 at 14:57:46 UTC, Marco Leise wrote: Is that what would happen? Yes, that's exactly what would happen. You could go one step further and not do it for all symbols, instead you make the compiler emit a additional section with references to all relevant data symbols. Then you only do the patching operation on the data symbols and leave all other symbols as is. This would greatly reduce the number of symbols that require patching. The exepcted data set size should be significantly smaller then on linux. Because currently on linux D simply exports all symbols. Which means that the linux loader does this patching for all symbols. On windows only symbols with the export protection level get exported. That means the set of symbols this patching has to be done for is a lot smaller to begin with. The additional optimization would reduce the number of symbols to patch once again. So even if the custom implementation is vastly inferior to what the linux loader does (which I don't think it will be) it still should be fast enough to not influence program startup time a lot.
Re: DLL symbol identity
Am 11.05.2015 um 16:21 schrieb Martin Nowak: Can you elaborate a bit on that? How would you run into such an ODR violation, by linking against multiple import libraries that contain the same symbol? I will post some code examples later. Code usually shows the issue best. Last time we thought about this we came to the conclusion that global uniqueness for symbols isn't possible, even on Unix when you have 2 comdat/weak typeinfos for template classes in 2 different shared libraries but not in the executable. I suggested that we could wrap typeinfos for template types in something like TypeInfo_Comdat that would do a equality comparison based on name and type size. Do you have a code example for this issue? I wasn't able to produce a duplicate symbol with linux shared libraries yet.
Re: DLL symbol identity
Am 11.05.2015 um 21:39 schrieb Laeeth Isharc: On Monday, 11 May 2015 at 12:54:09 UTC, Benjamin Thaut wrote: and why does it not map well to D ? D uses tons of templates everywhere. Even type information for non templated types is generated on demand and stored in comdats which can lead to duplicate symbols the same way it does for templates. In D the dynamic cast is basically the default and you have to force the compiler to not use a dynamic cast if you care for performance. Sorry for the rookie question, but my background is C rather than C++. How do I force a static cast, and roughly order magnitude how big is the cost of a dynamic cast ? Would you mean for example rather than casting a char[] to a string taking the address and casting the pointer? Dynamic casts only apply to classes. They don't apply to basic types. Example object o = instance; SomeClass c = cast(SomeClass)instance; // dynamic cast, checks type info SomeClass c2 = cast(SomeClass)cast(void*)instance; // unsafe cast, simply assumes instance is SomeClass If you do the cast in a tight loop it can have quite some performance impact because it walks the type info chain. Walking the type info hirarchy may cause multiple cache misses and thus a significant performance impact. The unsafe cast literally does not anything besides copying the pointer.
Re: DLL symbol identity
Am 10.05.2015 um 21:51 schrieb Dicebot: On Friday, 8 May 2015 at 05:26:01 UTC, Benjamin Thaut wrote: Pro: - Its the plain windows shared library mechanism in all its uglyness. I wonder if anyone can provide more Pro input :) I described both implementations of shared libaries. From the description alone you should be able to find any other pro arguments for the windows approach. The only one I could find was, that its faster at program startup time, compared to the linux one, but is inferrior in all other points.
Re: DLL symbol identity
Does nobody have a opinion on this?
Re: DLL symbol identity
On Friday, 8 May 2015 at 08:04:20 UTC, Kagamin wrote: As I understand, if SomeClass is in some dll, it will be there and be unique. If typeid(SomeClass) loads the symbol address from IAT, it will be the same address as in dll. No, you don't understand. TypeInfos are stored in comdats. And they are only created if needed. So if you have SomeClass there is a typeinfo for SomeClass but not all possible typeinfos are created. Say you never use const(SomeClass) and then two other dlls use const(SomeClass) then each of those two dlls will contain a instance of the TypeInfo for const(SomeClass). This issue gets even worse with TypeInfos of templated types.
Re: DLL symbol identity
Am 08.05.2015 um 13:34 schrieb Kagamin:
bool checkIfSomeClass(Object o)
{
return typeid(o) is typeid(SomeClass);
}
Doesn't typeid(o) extract TypeInfo from the object? If it's stored as a
physical value in the object, how can it change transparently for const
class?
As I understand, C++ resorts to preinstantiation of needed templates
when compiling to dlls.
This is obviously a very simplified example. You either have to take my
word for it about the actualy issue and voice your opinion on the
decision to make or dig into dmds sources, understand how type infos
work and then question my issue description. But please don't question
my description of the issue without actually understanding what the
implementation looks like.
Let me put my question in a different way:
From the point of a D user, would you rather have 'is' expressions and
'static' / '__gshared' variables inside classes do strange things
sometimes when using dlls or would you wan't it to always work without
considering the underlying implementation. Please choose option 1 or
option 2.
DLL symbol identity
To implement shared libraries on a operating system level
generally two steps have to be taken
1) Locate which shared library provides a required symbol
2) Load that library and retrieve the final address of the symbol
Linux does both of those steps at program start up time. As a
result all symbols have identity. If a symbols appears in
multiple shared libraries only one will be used (first come first
serve) and the rest will remain unused.
Windows does step 1) at link time (through so called import
libraries). And Step 2) at program start up time. This means that
symbols don't have identity. If different shared libraries
provide the same symbol it may exist multiple times and multiple
instances might be in use.
Why is this important for D?
D uses symbol identity in a few places usually through the 'is'
operator. The most notable is type info objects.
bool checkIfSomeClass(Object o)
{
return typeid(o) is typeid(SomeClass);
}
The everyday D-user relies on this behavior usually when doing
dynamic casts.
Object o = ...;
SomeClass c = cast(SomeClass)o;
So if symbols don't have identity all places within druntime and
phobos which rely on symbol identity have to be identified and
changed to make it work with windows dlls. I'm currently at a
point in my Windows Dll implementation where I have to decide how
to solve this issue. There are two options now.
Option 1)
Leave as is, symbols won't have identity.
Con:
- It has a performance impact, because for making casts and other
features, which rely on type info objects, work we will have to
fallback to string comparisons on windows.
- All places within druntime and phobos which use symbol identity
have to be found and fixed. This is a lot of work and might
produce many bugs.
- Library writers have to consider this problem every time they
extend / modify druntime / phobos.
- There are going to be tons of threads on D.learn about Why
does this not work in a Dll
Pro:
- Its the plain windows shared library mechanism in all its
uglyness.
Option 2)
Windows already generates a indirection table we could patch.
Rebind the symbols at program start up time overwriting the
results of the windows program loader. Essentially reproducing
the behavior of linux with code in druntime.
Pro:
- Symbols would have identity.
- Everything would behave the same way as on Linux.
- No run time performance impact.
Con:
- Performance impact at program start up time.
- Might increase the binary size (I'm not entirely sure yet if I
can read all required information out of the binary itself or if
I have to add more myself)
I personally would prefer option 2 because it would be easier to
use and wouldn't cause lots of additional maintenance effort.
Any opinions on this? As both options would be quite some work I
don't wan't to start blindly with one and risking it being
rejected later in the PR.
Kind Regards
Benjamin Thaut
Re: C++ interface problem
On Wednesday, 29 April 2015 at 19:04:11 UTC, extrawurst wrote: On Wednesday, 29 April 2015 at 13:55:46 UTC, Benjamin Thaut wrote: On Monday, 27 April 2015 at 21:19:02 UTC, extrawurst wrote: here is the shortened version of the returned class CSteamID: https://gist.github.com/Extrawurst/936f56ceaa87cf287257 this is the shortened interface (no destructors in the rest of the code either): https://gist.github.com/Extrawurst/b20dc5ab84132ecab30d the method `GetFriendByIndex` is the one crashing on win32. I assume that's because CSteamID is returned by value. Are you defining CSteamID in D as a struct? If not you have to because only structs can be returned by value. The next problem is that CSteamID is 64bits wide, this might be a problem as it can not be returned in a single register. You could try changeing the definition of GetFriendByIndex on the D side to ulong GetFriendByIndex(...) and reinterpret the ulong on the D side. If that does not work however you are most likely out of luck because the way your c++ library returns a value type 32-bit is not compatible with what dmd expects. Do you have debug symbols for the third party c++ library? Can you step into the virtual function call to actually see if it ends up in the correct function on the c++ side? Kind Regards Benjamin Thaut Seems i am out of luck. I tried all that. The Steamworks SDK is closed source without debugging symbols. so it wont work.. too bad, this library would have been a good example case of seamless c++-interfacing from D... Did you try windows 64-bit? Calling conventions on 64-bit windows are better standardized.
Re: C++ interface problem
On Monday, 27 April 2015 at 21:19:02 UTC, extrawurst wrote: here is the shortened version of the returned class CSteamID: https://gist.github.com/Extrawurst/936f56ceaa87cf287257 this is the shortened interface (no destructors in the rest of the code either): https://gist.github.com/Extrawurst/b20dc5ab84132ecab30d the method `GetFriendByIndex` is the one crashing on win32. I assume that's because CSteamID is returned by value. Are you defining CSteamID in D as a struct? If not you have to because only structs can be returned by value. The next problem is that CSteamID is 64bits wide, this might be a problem as it can not be returned in a single register. You could try changeing the definition of GetFriendByIndex on the D side to ulong GetFriendByIndex(...) and reinterpret the ulong on the D side. If that does not work however you are most likely out of luck because the way your c++ library returns a value type 32-bit is not compatible with what dmd expects. Do you have debug symbols for the third party c++ library? Can you step into the virtual function call to actually see if it ends up in the correct function on the c++ side? Kind Regards Benjamin Thaut
Re: C++ interface problem
On Monday, 27 April 2015 at 13:08:33 UTC, extrawurst wrote:
Don't ask me about the compiler, like stated above I have no
control over the binaries, it is proprietary.
Thats bad to start with.
the C++ class basically is:
```
class S
{
union SteamID_t
{
struct SteamIDComponent_t
{
uint32 m_unAccountID : 32;
unsigned intm_unAccountInstance : 20;
unsigned intm_EAccountType : 4;
EUniverse m_EUniverse : 8;
} m_comp;
uint64 m_unAll64Bits;
} m_steamid;
}
```
Where is the fuction declaratiosn for bar? If bar is not virtual
you can not use a extern(C++) Interface. If bar is non-virtual
you have to use a extern(C++) class.
Re: C++ interface problem
On Monday, 27 April 2015 at 11:00:23 UTC, extrawurst wrote: Thought about that too and tried uint aswell. does not work either.. Please post the c++ declarations as well. Which c++ compiler do you use for win32? (dmc or msvc) Kind Regards Benjamin
Re: C++ interface problem
Am 27.04.2015 um 17:16 schrieb extrawurst:
On Monday, 27 April 2015 at 13:14:21 UTC, Benjamin Thaut wrote:
On Monday, 27 April 2015 at 13:08:33 UTC, extrawurst wrote:
Don't ask me about the compiler, like stated above I have no control
over the binaries, it is proprietary.
Thats bad to start with.
the C++ class basically is:
```
class S
{
union SteamID_t
{
struct SteamIDComponent_t
{
uint32m_unAccountID : 32;
unsigned intm_unAccountInstance : 20;
unsigned intm_EAccountType : 4;
EUniversem_EUniverse : 8;
} m_comp;
uint64 m_unAll64Bits;
} m_steamid;
}
```
Where is the fuction declaratiosn for bar? If bar is not virtual you
can not use a extern(C++) Interface. If bar is non-virtual you have to
use a extern(C++) class.
of course it is all virtual. it is a c++-interface. and everything works
fine under osx, that would not be the case otherwise, right ?
It depends on the compiler, I don't know the vtbl layout on OSX. Does
the class have a virtual destructor? If you would post a bit more of S
declaration I wouldn't have to guess into the blue. Not knowing the
compiler your third party library was compiled with doesn't really help
either.
Kind Regards
Benjamin
Re: Pitching an investment bank on using D for their bond analytics
- what are potential factors that might make D a bad choice in this scenario? I would like to use D certainly - but it is of course much more important that the client gets the best result, however it is done. You would have to asess if the analysis you should create is time critical. If it is, a possible pitfall is the GC, and you should try to avoid it from the start. Replacing the GC with custom memory management is a lot of work if you do it afterwards. If the analysis is not time critical, I don't see any problems with D. Kind Regards Benjamin Thaut
Re: Mid-term vision review
On Monday, 6 April 2015 at 02:11:08 UTC, Daniel Murphy wrote: Yes, exactly. If I get my way, the conversion tool will be put into the dmd repository for a while, and it should be possible to automatically upgrade a pull request with rebase+convert+rebase. This method will be properly documented and advertised before the switch is made. Conflicts will still need to be resolved manually, of course, and some converter config data may need to be updated manually. Thank you very much for the clarification. This is a nice migration path and should be more then sufficient. Kind Regards Benjamin Thaut
Re: Mid-term vision review
Am 03.04.2015 00:44, schrieb Andrei Alexandrescu: switching to ddmd, hopefully with 2.068. Andrei That sounds nice, I just hope that there is going to be some nice migration path for people currently working on Pull-Requests for the C++ Version of dmd. I would prefer to not redo all the changes in D code. -- Kind Regards Benjamin Thaut
Re: Mid-term vision review
On Sunday, 5 April 2015 at 18:30:16 UTC, Andrei Alexandrescu wrote: On 4/5/15 10:32 AM, Benjamin Thaut wrote: Am 03.04.2015 00:44, schrieb Andrei Alexandrescu: switching to ddmd, hopefully with 2.068. Andrei That sounds nice, I just hope that there is going to be some nice migration path for people currently working on Pull-Requests for the C++ Version of dmd. I would prefer to not redo all the changes in D code. Daniel, any thoughts? Can we help with tooling? -- Andrei Shouldn't it be possible to tag the last C++ version of dmd? Then rebase the pull-reuqest on top of that and run it through the C++ to D conversion tool. Afterwards the output of the tool could be used to do a diff against the first D version of dmd (tagged again). This diff could then be used as a starting point for a new pull request. This will obviously not be perfect and might require some additional manual merging but at least people with larger pull requests (like me) don't have to redo the entire thing. A page with instructions how to do this conversion should be enough. Main points in question beeing, where to get the conversion tool and how to use it. Kind Regards Benjamin Thaut
Re: Enhancement: issue error on all public functions that are missing ddoc sections
Am 22.03.2015 um 04:40 schrieb Martin Nowak:
Why would export make private functions public?
Following problem:
// public template
void foo(T)(T arg)
{
bar(T.sizeof);
}
// private implementation helper
private void bar(size_t size) { ... }
Because bar is used from foo, bar has to be exported, thus the
protection level has to be changed from private to export. But
export includes public so the function bar will now be public as well.
This problem was exessivly discussed here:
http://forum.dlang.org/thread/m9lhc3$1r1v$1...@digitalmars.com
The official response from Walter and Andrei was, that they don't want
any language change and symbols that need exporting should just become
public.
But this in turn will mean that tons of currently private helper
functions without documentation will become public and cause errors or
warnings in ddoc.
Kind Regards
Benjamin
Re: Enhancement: issue error on all public functions that are missing ddoc sections
On Wednesday, 18 March 2015 at 18:48:53 UTC, Walter Bright wrote: I'm fed up with this problem. It is actively hurting us every day. https://issues.dlang.org/show_bug.cgi?id=14307 Anyone want to take this on? Shouldn't be particularly difficult. This is going to be a lot of fun as soon as tons of currently private functions in phobos are public due to the usage of export.
Re: Should this work: export extern(C) auto ...
On Thursday, 19 March 2015 at 12:58:42 UTC, Robert M. Münch wrote: On 2015-03-18 21:50:39 +, Adam D. Ruppe said: It will not work because a function with an auto return value is actually a template, and unused templates won't be put into a dll. Ok, that makes it clear. Thanks. Generally don't expect to many things to work with DLLs at the moment. Generally speaking only exporting global functions works. Don't try to export classes / structs or anything fancy.
Re: Is it possible to call D functions from C++
On Thursday, 19 March 2015 at 11:47:37 UTC, Namal wrote: On Wednesday, 18 March 2015 at 15:52:33 UTC, Benjamin Thaut wrote: On Wednesday, 18 March 2015 at 14:50:21 UTC, Namal wrote: Can you help me show how to compile and link it together please, thank you. What platform are you on, windows, linux, osx? What c++ compiler do you use? msvc, clang, gcc? Linux, gcc and dmd. In my case c++ refuses to compile if main is void. well then change it to the full signature ;-)
Re: Is it possible to call D functions from C++
On Wednesday, 18 March 2015 at 14:17:13 UTC, Namal wrote:
Hello, as in the title. How can I call D functions from C++ (If
my main() is in a c++ file).
Thanks alot!
D:
extern(C++) void SomeDFunction()
{
doSomething();
}
C++:
void SomeDFunction();
void main()
{
SomeDFunction();
}
Please also see:
http://dlang.org/cpp_interface.html
Kind Regards
Benjamin
Re: Is it possible to call D functions from C++
On Wednesday, 18 March 2015 at 14:50:21 UTC, Namal wrote: Can you help me show how to compile and link it together please, thank you. What platform are you on, windows, linux, osx? What c++ compiler do you use? msvc, clang, gcc?
Re: Is it possible to call D functions from C++
On Wednesday, 18 March 2015 at 14:40:48 UTC, krzaq wrote: I'm pretty sure the OP wanted to call D functions from C++, not C++ functions from D. If you look very closely you will notice that my example does exactly what the OP wanted.
Re: Seems core.thread.Fiber is broken dmd windows 64-bit build
On Monday, 9 March 2015 at 14:39:34 UTC, Carl Sturtivant wrote: Please confirm or deny that this is a real bug, as its getting in the way of a genuine project. How should I proceed? I'm working on a 64-bit Windows port of the following. http://www.cs.arizona.edu/icon/ Here's the 32-bit Windows port. http://www.cs.arizona.edu/icon/v95w.htm Among other things I'm using D to implement Icon's coexpressions portably using core.thread.Fiber which works fine at 32 bits. They are implemented using pthreads on other platforms, though historically there used to be a platform dependent assembly code context switch, close to the way that core.thread.Fiber is implemented. The Fiber implementation is 20 times faster at 32 bits. I can reproduce this issue with dmd 2.066.1, please go forward and open a issue on https://issues.dlang.org/ Kind Regards Benjamin Thaut
Re: Initializing defaults based on type.
On Friday, 6 March 2015 at 15:36:47 UTC, anon wrote:
Hi,
I can't figure this out.
struct Pair(T)
{
T x;
T y;
alias x c;
alias y r;
}
What would like is that the x and y to be initialized to
different values depending on type eg:
struct Container
{
Pair!double sample1; // This will initialize sample1 with 0
for both x and y
Pair!intsample2; // This will initialize sample2 with 1
for both x and y
}
currently I'm using two different struct one with doubles and
the other with ints and initialized with default value but was
wondering if its possible to do the above.
anon
struct Pair(T)
{
static if(is(T == int))
enum int initValue = 1;
else
enum T initValue = 0;
T x = initValue;
T y = initValue;
alias x c;
alias y r;
}
Re: Int to float?
Am 05.03.2015 um 21:00 schrieb Taylor Hillegeist: How to I cast a Int to float without changing its binary representation? int someValue = 5; float sameBinary = *(cast(float*)cast(void*)someValue);
Re: D Unittest shortcomings with DLLs
On Thursday, 5 March 2015 at 07:28:12 UTC, Jacob Carlborg wrote: On 2015-03-03 18:49, Benjamin Thaut wrote: Sounds like you want to test an application that uses Phobos as a DLL. To me that sounds like a more higher level test than a unit test, i.e. integration tests. I would put those tests in completely separate files, in a separate testing directory. Then it should be no problem to compile the parts separately. As for private functions. That is more a question of if you really should write specific test for those or just test the public API. If you really want to, you can bypass the protection using pointers. BTW, I think we need to have integration tests in general. Testing how different parts/modules interact with each other. I don't want to write new tests. I want to use the tests for phobos which are already there. And I want to use them in a way, that if new tests are added to phobos they are also tested against the dll version of phobos. Yes integration tests would be nice, but the PR for Dll support is already going to be huge without me adding integration tests.
Re: D Unittest shortcomings with DLLs
On Thursday, 5 March 2015 at 03:24:05 UTC, TheFlyingFiddle wrote: Finding out if a unittest only accesses public symbols could be done by analyzing the ast of the method. Either inside the compiler of via one of the third party D parsers currently in use. I thought about writing a tool which extracts all unittest blocks and puts each one into a template. Then I could use __pragma(compiles, ) on the template to check if it uses any private symbol and if not instanciate that template. That way unittests that use private functions would automatically be filtered out. Kind Regards Benjamin Thaut
Re: D Unittest shortcomings with DLLs
On Thursday, 5 March 2015 at 07:42:10 UTC, Jacob Carlborg wrote: On 2015-03-05 08:38, Benjamin Thaut wrote: I don't want to write new tests. I want to use the tests for phobos which are already there. And I want to use them in a way, that if new tests are added to phobos they are also tested against the dll version of phobos. Yes integration tests would be nice, but the PR for Dll support is already going to be huge without me adding integration tests. Wouldn't it require more code to write a tool that extracts the unittest blocks? I've written a simple D Tokenizer in a few lines of D code already. Building on that it would be pretty easy to extract unittest blocks.
D Unittest shortcomings with DLLs
I'm currently in the process of annotating all of phobos with export
and its quite cumbersome. To verify that I annoted all relevant
functions and types with export I would like to run the unitests against
the shared version of phobos. There is a problem with this though. The
unittests are always compiled into the same binary the modules are in so
the unittests would end up in the phobos.dll and would not test phobos
across a shared library boundary. It would also be very usefull to have
this verifycation for the future when DLL support is officially in and
new features need to be tested if they are propperly annotated with
export. Once export is used for shared library symbol visibility on
non-windows as well this will be an issue on all pattforms.
The best solution would be if you could simply compile the unittests and
just the unittests into a executable. This would require some compiler
modifications, but even when done would cause some problems:
- Unittests may use private functions / types of a module. Private
functions and types are however not exported from an shared library so
this would require making a lot of private functions / types public just
to be able to run the unittests.
Instead of building this into the compiler you could use a tool which
extracts all unittest { } blocks out of all source files and puts them
into new .d files. Then compile these into an executable. Now the code
would not even compile because private symbols would not be accessible.
Any suggestions how to fix this issue? I'm also open for implementation
hints.
Kind Regards
Benjamin Thaut
Re: Mac Apps That Use Garbage Collection Must Move to ARC
Am 27.02.2015 um 00:05 schrieb deadalnix: Note that in D, you have union and all kind of crap like that, so what is writing a pointer is non obvious and so the tradeof is very different than it is in other languages. To have any chance of implementing a better GC in D I would simly start of with assuming all code is @safe. For code that is not @safe the user would have to make sure it plays nice with the GC. This would also apply to unions which contain pointer types. If you wan't to write a good GC that does support non @safe features without user input you don't even have to start in my opinion.
Re: Mac Apps That Use Garbage Collection Must Move to ARC
Am 26.02.2015 um 20:58 schrieb Walter Bright: It was a generational gc, I described earlier how it used page faults instead of write barriers. I eventually removed the page fault system because it was faster without it. Page faults are inferrior to compiler generated write barriers. Because with a page fault startegy you pay for every write. Even if the write does not write a pointer. Compiler generated write barriers only apply to pointers written through another pointer.
Re: Mac Apps That Use Garbage Collection Must Move to ARC
Am 26.02.2015 um 21:39 schrieb Walter Bright:
On 2/25/2015 1:27 PM, Benjamin Thaut wrote:
You seeing this completely one sided. Even if write barries make code
slower by
10% its a non issue if the GC collections get faster by 10% as well.
Then in
average the program will run at the same speed.
You'll be paying that 10% penalty for every write access, not just for
GC data. D is not Java in that D has a lot of objects that are not on
the GC heap. Tradeoffs appropriate for Java are not necessarily
appropriate for D.
Write barries only have to be generated for writes to pointers through
pointers. So you are not paying a penality for every write.
class Bar
{
int x;
Bar other;
void method()
{
x = 5; // no write barrier
other = this; // write barrier
}
}
Also the following code will not generate a single write barrier:
void someFunc(uint[] ar)
{
for(uint* it = someArray.ptr; it ar.ptr + ar.length; it++)
{
*it = 5;
}
}
Re: Mac Apps That Use Garbage Collection Must Move to ARC
Am 24.02.2015 um 10:53 schrieb Walter Bright: On 2/24/2015 1:30 AM, Tobias Pankrath wrote: Are the meaningful performance comparisons between the two pointer types that would enable us to estimate how costly emitting those barriers in D would be? Even 10% makes it a no-go. Even 1%. D has to be competitive in the most demanding environments. If you've got a server farm, 1% speedup means 1% fewer servers, and that can add up to millions of dollars. You seeing this completely one sided. Even if write barries make code slower by 10% its a non issue if the GC collections get faster by 10% as well. Then in average the program will run at the same speed.
Re: Mac Apps That Use Garbage Collection Must Move to ARC
Am 26.02.2015 um 05:08 schrieb Walter Bright: On 2/25/2015 7:27 PM, deadalnix wrote: On Thursday, 26 February 2015 at 02:48:15 UTC, Walter Bright wrote: Writing a generational collector for D is possible right now with no language changes, it's just that nobody has bothered to do it. Don't need write barriers for it, either. How are you planning to track assignment a pointer to the young generation in the old generation ? Because if you plan to rescan the whole old generation, this is not exactly a generational GC. A lot of benefit simply came from compacting all the remaining used allocations together, essentially defragging the memory. What you are describing is a compacting GC and not a generational GC. Please just describe in words how you would do a generational GC without write barriers. Because just as deadalnix wrote, the problem is tracking pointers within the old generation that point to the new generation.
Re: DDMD just went green on all platforms for the first time
Am 21.02.2015 um 15:02 schrieb Daniel Murphy: https://auto-tester.puremagic.com/?projectid=10 This is a pretty big milestone for the project. For the first time, an unpatched dmd can build ddmd, and that ddmd can build druntime and phobos and pass all the test suites. Hopefully in the next couple of weeks the remaining minor issues will be fixed (eg makefile changes, ddmd runs out of memory compiling std.algorithm unittests on win64) and we can start adding ddmd to master alongside the C++ compiler. A big thanks to Brad for upgrading the autotester, and to everyone who has helped fix bugs and get patches merged over the last couple of years. Github shows 376 closed DDMD pull requests, which is about 8% of all dmd pull requests ever. Congrats, nice work. Are there any performance comparisons? E.g. how long das DDMD take to compile phobos vs regular DMD? Kind Regards Benjamin Thaut
Re: Mac Apps That Use Garbage Collection Must Move to ARC
Am 22.02.2015 um 10:48 schrieb Russel Winder via Digitalmars-d: On Sun, 2015-02-22 at 10:21 +0100, Benjamin Thaut via Digitalmars-d wrote: Am 22.02.2015 um 03:13 schrieb Walter Bright: Nobody thinks GC is suitable for hard realtime. I think you should know manu good enough by now that you know he is not talking about hard realtime but soft realtime instead. (e.g. games) There are GCs which handle this situation pretty well but D's GC is not one of them. If the D GC really is quite so bad, why hasn't a cabal formed to create a new GC that is precise, fast and efficient? There have been countless dicussions about D's GC and how bad it is, and how to improve it. But it always turns out that it would be a ton of work or someone doesn't like the consequences. The key points always are: 1) We need full percise pointer discovery, even for pointers on the stack. 2) We need write barriers. 1) Is a really complex task for a language like D. There is a reason why java has so a small feature set. 2) For some reason nobody likes write barries because the general fear is, that they will cost performance, so it was decided to not implement them. (Without actually measuring performance impact vs GC improvement) The problem is that, to implement a non stop-the-world-GC you need 2) and to implement a GC which is on par with Java or C# you need 1). So until there is no implementation for any of the both mentioned points, there will be no better GC in D. You can fake 2) with fork on linux, thats what the CDGC did (see the DConf talk). This works because fork has copy on write semantics, but there is no equivalent on Windows. Experiments by Rainer Schuetze to implement similar copy on write semantics on Windows have shown to have major overhead which is most likely even worse then implementing write barries themselfs. Experiments implementing a Heap-percise GC, again by Rainer Schuetze, have schon that percicse heap scanning is slower compared to impercise scanning. In my opinion the key problem is, that D was designed in a way that requires a GC but D was not designed in a way to propperly support a GC. (shared, immutable and other things basically prevent thread local pools). Kind Regards Benjamin
Re: Mac Apps That Use Garbage Collection Must Move to ARC
Am 22.02.2015 um 03:13 schrieb Walter Bright: Nobody thinks GC is suitable for hard realtime. I think you should know manu good enough by now that you know he is not talking about hard realtime but soft realtime instead. (e.g. games) There are GCs which handle this situation pretty well but D's GC is not one of them.
Re: C++ calling convention only
Am 21.02.2015 um 11:30 schrieb Marc =?UTF-8?B?U2Now7x0eiI=?=
schue...@gmx.net:
For C++, you can just use the newly added namespace support:
extern(C++, nobody.uses.this.name) myFunc() {}
Thats actually a good idea. Thanks.
Re: C++ calling convention only
On Thursday, 19 February 2015 at 21:34:57 UTC, John Colvin wrote: I would duplicate the declaration, once without extern(C++), once with, the use the .mangleof from the 1st to set the mangle of the 2nd with pragma(mangle Yes that would work. But using pragma(mangle) feels so hacky...
Re: C++ calling convention only
On Friday, 20 February 2015 at 13:00:39 UTC, John Colvin wrote: I agree. Wrap it in a mixin / mixin template? Why do you need this? Presumably it'll be hidden in the depths of some library / bindings where beauty is somewhat optional? Using the .mangleof from an extern(D) function should mean it's robust. Well the use case is creating a function which sole purpose it is to create a function pointer from it and pass it to C++. If it recieves C++ mangling however I have to pay attention that it does not conflict with any other C++ symbols. The same goes for extern(C). Sometimes you want to create functions with a C calling convetion so you can create a function pointer from it. With extern(C) its even a bigger problem because the C mangling conflicts a lot easier.
C++ calling convention only
Is it possible to declare a function in D which gets the C++ calling convetion but not the C++ mangling? Kind Regards Benjamin Thaut
Re: C++ function signature template parameter mangling issue
Am 17.02.2015 um 09:13 schrieb Walter Bright:
On 2/16/2015 10:54 PM, Benjamin Thaut wrote:
Am 17.02.2015 um 02:21 schrieb Daniel Murphy:
struct X(T) { pragma(msg, X.stringof); }
void main()
{
X!(typeof(*(void function()).init)) x;
}
Error: ICE: Unsupported type void()
So close...
Please file bugzilla!
https://issues.dlang.org/show_bug.cgi?id=14195
https://github.com/D-Programming-Language/dmd/pull/4419
Re: Problem with coupling shared object symbol visibility with protection
So i looked at the Dll Test within the dmd test framework and when I make export an attribute, like I suggested, this perticular test will compile run without any code changes. This is another reason why I suspect that making export an attribute will only break very little if any code at all. Am 16.02.2015 um 09:08 schrieb Walter Bright: At this point I suggest simply making those private helper functions public and export them. It gets your project moving without waiting for language changes (and this is a breaking change). I have to big fears with doing this 1) I finish everything up any finally do the pull request. Then the reviewers will realize that using export in all required places will completely undermine D's module level protection system and reject the PR. Then all my work is in vain. 2) Even if 1 does not happen, that means from now on the broken export will be used in _actual_ code. Because it kind of works. Going forward this would mean that changing export into an attribute will break actual production code. So in my opinion we have to implement Dll Support on windows and fix export simulatiously, otherwise fixing export will lead to big breaking changes instead of a few small ones. Kind Regards Benjamin Thaut
Re: C++ function signature template parameter mangling issue
On Tuesday, 17 February 2015 at 08:16:37 UTC, Walter Bright wrote: True, it might be easier to adjust the C++ side so it takes a pointer to a function type. In this case it would be really ugly ezDelegatevoid() vs ezDelegatevoid(*)() I will do a pull request later today fixing this mangling issue.
Re: H1 2015 - C++ integration
On Tuesday, 17 February 2015 at 11:39:06 UTC, Guillaume Chatelet
wrote:
We'll also have to provide a new pragma to allow correct
mangling of types on Windows. Maybe something like :
extern(C++, std) {
pragma(mangleAs, class)
struct basic_string()
{
...
}
}
Yes please. I'm running into the same issue right now. Changing
everything to struct on the c++ side is not always possible.
Re: @nogc with assoc array
Am 16.02.2015 um 18:55 schrieb Jonathan Marler:
Why is the 'in' operator nogc but the index operator is not?
void main() @nogc
{
int[int] a;
auto v = 0 in a; // OK
auto w = a[0]; // Error: indexing an associative
// array in @nogc function main may
// cause GC allocation
}
Because the index operator throws a OutOfRange exception and throwing
exceptions allocates, maybe?
C++ function signature template parameter mangling issue
I have a c++ struct:
template typename retval
struct ezDelegateretval ()
{
}
void DelegateTest(ezDelegatevoid () func) { ... }
And I want to match that on the D side, unfortunately it does not work:
D:
struct ezDelegate(Signature) {}
alias delegate_t = ezDelegate!(void function());
extern(C++) void DelegateTest(delegate func);
D mangles
?DelegateTest@@YAXU?$ezDelegate@$$A6AXXZ@@@Z
void __cdecl DelegateTest(struct ezDelegatevoid (__cdecl*)(void))
What C++ does:
?DelegateTest@@YAXU?$ezDelegate@P6AXXZ@@@Z
void __cdecl DelegateTest(struct ezDelegatevoid __cdecl(void))
I understand that void function() is actually a function pointer and
thus the mangling is correct. But in what way would you actually able
to mirror the C++ declaration of ezDelegate? Does it even work? This
would be a central part of my interop with C++ so making it work would
be nice.
Kind Regards
Benjamin Thaut
Re: C++ function signature template parameter mangling issue
Am 17.02.2015 um 02:21 schrieb Daniel Murphy:
struct X(T) { pragma(msg, X.stringof); }
void main()
{
X!(typeof(*(void function()).init)) x;
}
Error: ICE: Unsupported type void()
So close...
Re: What is the Correct way to Malloc in @nogc section?
Hi, you can also take a look at my implementation: https://github.com/Ingrater/druntime/blob/master/src/core/allocator.d Look at AllocatorNew and AllocatorDelete Especially important is, that you correctly handle the constructor throwing an exception. You have to catch that exception in your new function, release the memory and rethrow. Kind Regards Benjamin Thaut
Re: Problem with coupling shared object symbol visibility with protection
On Monday, 16 February 2015 at 08:08:17 UTC, Walter Bright wrote: At this point I suggest simply making those private helper functions public and export them. It gets your project moving without waiting for language changes (and this is a breaking change). This is in fact not a breaking change because export is broken anyway. Due to bug 922 export can't be used in cross platform libraries. I haven't seen a single library on dub that uses export (most likely for exactly that reason). Also export on windows is broken as well, see Bug 9816. So making export an attribute would most likely not break anything because it already is broken and wouldn't work if you tried to use it.
Re: Problem with coupling shared object symbol visibility with protection
On Monday, 16 February 2015 at 09:59:07 UTC, Walter Bright wrote: -- Here is a list of all things wrong with export: 32 64 bit issues: 1) Exporting a global variable leads to a linker error 2) Exporting thread local variables should be an error (at least it is in c++) 3) The module info should be exported as soon the module has any exported symbols 4) __gshared members of a class are not exported 5) The TypeInfo Object of the TestClass is not exported 6) The TypeInfo Object of TestStruct is not exported - None of these are addressed by making export an attribute. I never said that. I said that making export an attribute is _not_ an breaking change because it is already broken up to a point where it currently can't be used anyway (especially because of 922). My current implementation fixes both 922 and 9816 but would greatly benefit from making export an attribute because otherwise D's entire protection system would be undermined like described multiple times throughout this thread.
Re: Binding C++ Value Type (Templates)
Am 13.02.2015 um 19:40 schrieb Daniel Murphy:
Benjamin Thaut wrote in message
news:mzgymsfzrxbvffgcf...@forum.dlang.org...
There are currently two problems with binding c++ value types and c++
value type templates.
1. Semantics are somewhat different. Copying / constructor /
destructing / operator overloading is a issue.
2. Only templates which are instantiated on the c++ side can be used.
Now it would be nice if I could tell a type, that it should be mangled
like a C++ type but only if it is used in a C++ function signature.
The entire type would still be implemented on the D side and the
implementor would have to garantuee that the binary layout is the same
as on the C++ side.
You don't need to tell the type anything, this is how all structs work
by default. One thing you need to be very careful about is making sure
that both languages see the struct as POD or non-POD, otherwise they may
disagree on how to pass it to/return it from functions.
What problems have you been having with this approach?
Well, it doesn't work for anything that is within an C++ namespace.
Example:
C++:
namespace Test
{
struct IntVector
{
private:
int* _data;
size_t _size;
public:
IntVector(size_t size)
{
_size = size;
_data = (int*)malloc(sizeof(int) * size);
}
IntVector(const IntVector other)
{
_size = other._size;
_data = (int*)malloc(sizeof(int) * _size);
memcpy(_data, other._data, sizeof(int) * _size);
}
int operator[](size_t index)
{
return _data[index];
}
int* begin()
{
return _data;
}
int* end()
{
return _data + _size;
}
};
void ProcessIntVector(IntVector v)
{
for (auto i : v)
{
i++;
}
}
}
D:
extern(C++, Test)
{
struct IntVector
{
private:
int[] _data;
public:
this(size_t size)
{
_data = (cast(int*)malloc(int.sizeof * size))[0..size];
}
this(this)
{
auto oldData = _data;
_data = (cast(int*)malloc(int.sizeof *
oldData.length))[0..oldData.length];
_data[] = oldData[];
}
int opIndex(size_t index)
{
return _data[index];
}
int[] data()
{
return _data;
}
alias data this;
}
void ProcessIntVector(ref IntVector v);
}
If I remove the Test namespace everything works as expected.
Kind Regards
Benjamin Thaut
Re: Binding C++ Value Type (Templates)
Am 15.02.2015 um 13:59 schrieb Daniel Murphy:
Benjamin Thaut wrote in message news:mbq03u$2h5v$1...@digitalmars.com...
Well, it doesn't work for anything that is within an C++ namespace.
If I remove the Test namespace everything works as expected.
I think what you want is something along these lines:
D:
extern(C++, Test)
{
extern(D)
struct IntVector
{
...
}
void ProcessIntVector(ref IntVector v);
}
I don't like the way namespaces are conflated with linkage changes but I
lost that argument. This is essentially saying I just want the
namespace part of the extern(C++).
Oh wow, that actually compiles. Thanks very much. Maybe this should be
documented on the Interfacing to C++ page.
Re: Binding C++ Value Type (Templates)
Am 15.02.2015 um 17:25 schrieb Andrei Alexandrescu: On 2/15/15 5:33 AM, Benjamin Thaut wrote: Maybe this should be documented on the Interfacing to C++ page. Pull request pliz pliz -- Andrei Honestly, I'm currentyl preparing a really huge pull request for D (Dll support for windows) and I'm kind of upset that blocking issues that have come up during that pull request don't seem to be important enough to actually decide on them. This leaves me with a working Dll implementation, which I put a ton of work into, which is now blocked. My current fear is, that I will end up invensting all this work in vain and until that is settled, you won't be seeing any further pull request from my side. Kind Regards Benjamin Thaut
Binding C++ Value Type (Templates)
There are currently two problems with binding c++ value types and
c++ value type templates.
1. Semantics are somewhat different. Copying / constructor /
destructing / operator overloading is a issue.
2. Only templates which are instantiated on the c++ side can be
used.
Now it would be nice if I could tell a type, that it should be
mangled like a C++ type but only if it is used in a C++ function
signature. The entire type would still be implemented on the D
side and the implementor would have to garantuee that the binary
layout is the same as on the C++ side.
e.g.
extern(C++, wrapper)
struct SomeVector //mangling exactly like any other D type
{
this(this)
{
D-Style copy code
}
void opBinary(string op)(ref SomeVector rh) if(op == +)
{
D-Style operator overloading
}
}
// In extern C++ decalrations SomeVector is mangled as C++ type.
extern(C++) SomeFunction(SomeVector vec);
That way you could mirror the implementation of Value Types on
the D side using all D features available. Only the binary layout
and size of the data members would have to be the same. But it
would allow to pass value types between D and C++ and use them on
both sides without the need to write wrapper functions which
convert from a C++ value type to a D value type.
What do you think?
Kind Regards
Benjamin Thaut
Re: Attributes lost in TypeInfo, please advise
On Thursday, 12 February 2015 at 12:59:39 UTC, Steven Schveighoffer wrote: I think given the necessity of the above (which was not discussed or noticed in that bug report), we should add a way to call the true destructor properly in the compiler. -Steve Yes please. Its also going to genereate more optimal code. Calling the destructor through the TypeInfo leads to two unnecessary indirections. Kind Regards Benjamin Thaut
Binding C++ value types
When binding C++ value types you might want to use them by placing them on the D-Stack. This however seems to be not supported as the mangling for the constructor is completely wrong. Is this supposed to work? Kind Regards Benjamin Thaut
Re: extern(Windows, user32.dll)
Am 01.02.2015 um 11:26 schrieb Vladimir Panteleev: The Delphi programming language allows specifying the DLL name right on the declaration of extern symbols: function GetVersion: DWORD; stdcall; external 'kernel32.dll'; I would like to suggest adding something similar to D: extern(Windows, kernel32.dll) DWORD GetVersion(); Rationale: This absolves the need for import libraries. * Import libraries are a major and unnecessary pain in the neck when using DLLs of any kind. * Import libraries may need conversion from COFF format to OMF format with a tool which is not included with D (coffimplib). * Import libraries can *sometimes* be created from the DLL using implib, but this does not always work, depending on the calling convention and its mangling. * Name mangling mismatches are difficult to diagnose. * Import libraries cannot be used with tools such as rdmd, except via pragma(lib). Any thoughts? DIP or not? Please no. Import libraries are the way it was designed and it should be used that way. I'm currently implementing D-Dll support for Windows with dmd and without import libraries it will never work. Also what you are proposing could easily be implemented by a library. E.g. @dllimport(kernel32.dll) extern(Windows) DWORD GetVersion(); mixin DllImportFunctions; Where DllImportFunctions would iterate over all symbols in the module, look for the UDA dllimport and then attemp to load the Dll and import the function. Kind Regards Benjamin Thaut
Re: Problem with coupling shared object symbol visibility with protection
Am 31.01.2015 um 23:42 schrieb deadalnix:
On Wednesday, 28 January 2015 at 13:48:45 UTC, Dicebot wrote:
Isn't that what your first proposed solution is about? That was my
understanding and I liked that understanding :) To be 100% clear :
export void foo(T : int)(T x)
{
bar(x);
}
private void bar(int x) { }
I'd expect `bar` to be exported into resulting binary so that it can
be linked against by any users of `foo` but for any attempt to call
`bar` directly from D code to fail because of protection violation. If
someone wants to circumvent protection by forging mangling - shooting
own feet is allowed.
So you'd want bar to be duplicated on both sides ? This is gonna cause
problems with di files.
No. He wants the compiler to automatically detect that the template foo
might call bar. As a result the compiler should export bar when
compiling the shared library so that any user of foo does not run into a
unresolved symbol reference linker error. Bar would still only exist
once: within the shared library.
Re: extern(Windows, user32.dll)
And lets just say it is required to link against druntime correctly. I don't want to give you a 4 page text explanation why. So you expect us to just trust you, then? No, you just need to wait like everyone else until I do the PR for dmd / druntime / phobos for a full explanation. If you don't want to wait until then just read the source code: https://github.com/Ingrater/dmd/tree/DllSupport I also did not say that we should replace all usage of import libraries in Druntime. Sorry, I did jump over the not in : Why? I'm not suggesting to remove import library support. It won't work in DLLs. You can't call LoadLibrary in DllMain. The runtime is initialized in DllMain, so static constructors run there too. Even if you defer the LoadLibrary call until the function is first called, that still leaves you the problem that the functions are unusable in static constructors. Thats why its called a proof of concept, it doesn't mean its perfect ;-) It also won't work with TLS (i.e. all D DLLs) except on recent Windows versions. But the TLS issues are going to remain no matter if the dll is loaded via LoadLibrary or not. Also there are TLS fixes in core.sys.windows.dll for Windows XP. And we officially don't support anything before XP. The real issue here is, that dmd simply does not come with all neccessary import libraries when using optlink. As soon as you switch to the microsoft linkers this becomes a non issue. It literally *can't* come with *all* necessary import libraries. But still, adding a feature for the sole purpose to link against Windows System Dlls is just overkill. But feel free to go ahead and try getting it past Andrei and Walter. Just don't expect my support. Recently even the int[$] = [1,2,3,4] feature was killed off because it could be implemneted in a library. So I highly doubt that they are OK with adding a feature for importing Windows System Dlls only.
Re: extern(Windows, user32.dll)
Am 01.02.2015 um 14:27 schrieb Vladimir Panteleev: On Sunday, 1 February 2015 at 12:09:56 UTC, Benjamin Thaut wrote: http://wiki.dlang.org/DIP45 OK, so I understand it's mostly about D DLLs. Yes of course. Because they are still not supported. This bit though: In an import library the original symbol is redifined as trampoline that simply dereferences the _imp_ pointer to the DLL function. Thus calling an exported function will be compatible with both import libraries and static libraries, in the later case without indirection. Is this different from how things are now? No its not. I'm sticking with the additional indirection. But linking against a Dll directly would still be possbile. The linker has to generate the additional indirection anyway, no matter if a import library was used or not. This must be done because otherwise the code generated by the compiler, which assumes a additional indirection, would no longer be working (in case of data symbols only, function symbols would work without the indirection). Also, how does this conflict with my proposal? It does not. The only conflict would be if we would ban import libraries completely, which I misunderstood. If the compiler knows the function to be in a DLL, it can elide generating a trampoline at all, and reference the __imp__ symbol directly. Yes it could. That's a good point. It would be possible to define my proposal so that it would be easy to switch between the two with a -version switch. On one hand, you trade one compiler switch (static.lib or import.lib) for another (-version=static). On the other hand, for the DLL case, you skip the headache of import libraries. Your proposal could also be translated to: pragma(lib, kernel32.dll); extern(dll) DWORD GetVersion(); You just want a way to tell the compiler that that function is definitly located in a dll. The additional benefit of the above example would be, that you don't have to repeat which library the symbol is in for each symbol. The problem I see here is that walter didn't want to have a seperation between export and import. So he designed export to mean both. So I don't know how happy he will be if you want to add in a dllimport equivalent keyword. You could do however: pragma(lib, wininet.dll); export extern(Windows) HINTERNET InternetOpen( LPCTSTR lpszAgent, DWORD dwAccessType, LPCTSTR lpszProxyName, LPCTSTR lpszProxyBypass, DWORD dwFlags ); The fun thing is, this would work with the current dmd. If export is applied to a function declaration, it means dllimport. That means during linktime it would look for the __imp_InternetOpen symbol. The only thing that doesn't work yet is pragma(lib, kernel32.dll); So what you should actually request is pragma(lib, kernel32.dll) to be implemented. Although the only way this could work is, that the compiler actually calls implib for you (or the msvc equivalent) and then actually links against that. The issue that ketmar originally had would remain though, this would only work with libraries that behave nicely and don't change function mangling in their import library. (like wininet does)
Re: extern(Windows, user32.dll)
Am 01.02.2015 um 11:45 schrieb Vladimir Panteleev: On Sunday, 1 February 2015 at 10:40:06 UTC, Benjamin Thaut wrote: Please no. Import libraries are the way it was designed Delphi does without them just fine. C++ does with them just fine. I'm currently implementing D-Dll support for Windows with dmd and without import libraries it will never work. Why? I'm not suggesting to remove import library support. I don't care what you are suggesting. If you want a implementation of Dll support without import libraries do it yourself. And lets just say it is required to link against druntime correctly. I don't want to give you a 4 page text explanation why. Dynamic loading delays the error until execution time, instead of link time, and is slower. I hardly doubt that. If you link against a dll the windows binary loader is just doing the work for you. But the symbols are looked up in the dll by string either way. Also, proof of concept: http://dpaste.dzfl.pl/efbd54314a69 The real issue here is, that dmd simply does not come with all neccessary import libraries when using optlink. As soon as you switch to the microsoft linkers this becomes a non issue. Kind Regards Benjamin Thaut
Re: extern(Windows, user32.dll)
Am 01.02.2015 um 13:02 schrieb Vladimir Panteleev: But I haven't heard of this project before. In a few words, what does this do? Or a link to a DIP or existing discussion? The last discussion is over a year old, the resulting DIP was DIP 45: http://wiki.dlang.org/DIP45 The currently blocking issue for this implementation is, that export both means public and dllexport which is discussed here: http://forum.dlang.org/thread/m9lhc3$1r1v$1...@digitalmars.com Thats why its called a proof of concept, it doesn't mean its perfect ;-) OK, but you can't solve these problems without using DLL imports, can you? most likely not. But it's not just system Windows libraries, but all DLLs with a C interface. You won't need to mess with import libraries to load curl, or OpenSSL, or SQLite... Yeah, but the problem is, that as soon as you do that you are limiting yourself to DLL versions of that library. If you for example want to link curl statically this will no longer work. And in my opinion its bad to hardcode in the sourcecode if your expecting a static or shared version of the library. Thats also the nice thing about import libraries in my opinion. If you ship a library you can simply create two folders .e.g. one called static and the other called shared. Both contain .lib files with the same name. So the only thing a user as to do when he wants to switch between statically and dynamically linking against your library is changing the search directory passed to the linker.
Re: windows wininet library
Am 01.02.2015 um 17:15 schrieb ketmar: On Sun, 01 Feb 2015 16:07:58 +, John Chapman wrote: On Sunday, 1 February 2015 at 08:37:23 UTC, ketmar wrote: seems that my idea of using D to write a simple windows utility was very wrong. ok, another attempt to use D for our windows developement has failed. i'm in no way can sell manual .def creation to our team -- they will make fun of me, showing how their Visual C can compile this code without any troubles and external utilities... It's easier to run coffimplib on the lib files from the Windows SDK. sorry if i'm rude, i really appreciate your advice. i messed myself thinking that this is another thread in general NG. The Windows SDK can be downloaded seperately from visual studio: https://msdn.microsoft.com/en-us/windows/desktop/ff851942.aspx They are also backwards compatible, so the latest one should work on XP. But you can also just use the oldest one available to make sure it still works on your machine.
Re: Problem with coupling shared object symbol visibility with protection
Am 31.01.2015 um 06:11 schrieb Dicebot:
On Friday, 30 January 2015 at 19:10:06 UTC, Martin Nowak wrote:
It has a serious drawback of increasing attribute noise even more
though. First approach allows for more automatic inference.
But with D restrictions it seems the least bad option.
Well, export is going to remain transitive. So the first approach is
still going to work. The only difference is going to be that you can
force export private declarations. So for most modules it is hopefully
going to be enough to put export { } around the public part of the
module and force export some of the needed private declarations. For a
module without templates a single export { } should be enough.
Re: Problem with coupling shared object symbol visibility with protection
Am 31.01.2015 um 13:07 schrieb Martin Nowak: That's probably how it should behave, though an attribute applying only to public members unless explicitly added is unprecedented. Still seems like the right choice here, but might require some additional compiler logic. Well you don't have to implement it that way with in the compiler. The only thing that matters is, that the users sees this transitive behavior of export. It is not neccessary that the attribute actually gets applied recursivly within the compiler implementation. Only the export behavior needs to be implemented recursivly and I already did a implementation for that. It currently works for the export protection level and would be trivial to adapt for a export attribute. It would also not require any additional logic for applying attributes recursivly under certain conditions. @Walter: Making export a attribute seems to be the preferred choice in this discussion. Additionaly this was the result of the last discussion around export, a year ago, although for different reasons. The last Discussion resulted in DIP 45 which also proposes making export an attribute. Before I start with the implementation, would you be ok with making export an attribute or would you veto it? Kind Regards Benjamin Thaut
Re: Problem with coupling shared object symbol visibility with protection
Am 30.01.2015 um 11:39 schrieb Martin Nowak:
If you mean float, then it
will instatiate the template when compiled individually and use b's
instantiation when b and c are compiled together.
If this is true, then please explain this behavior:
module a; // -- a.dll
struct Storage(T)
{
T var;
__gshared T s_var;
}
module b; // -- b.dll
import a;
export __gshared Storage!int g_var1;
module c; // -- c.exe
import a;
import b;
__gshared Storage!int g_var2;
void main(string[] args)
{
g_var1.var = 2;
g_var2.var = 3;
g_var1.s_var = 2;
g_var2.s_var = 3;
}
c.obj : error LNK2019: Verweis auf nicht aufgelöstes externes Symbol
_D1a14__T7StorageTiZ7Storage5s_vari in Funktion _Dmain.
If your statement would be true module c should not use the instance
from module b because they are not compiled together. But as you can
clearly see from the linker error message module c does not instanciate
the template, because if module c would instanciate the template there
would not be a unresolved symbol.
Compiling module c with -allinst solves the problem. Putting export
in front of struct Storage(T) also solves the problem. And thats exactly
the reason why it is neccessary to be able to export templates. (Where
export means, export all template instanciations)
Re: Problem with coupling shared object symbol visibility with protection
On Thursday, 29 January 2015 at 10:21:25 UTC, Walter Bright wrote:
On 1/28/2015 5:19 AM, Benjamin Thaut wrote:
On Wednesday, 28 January 2015 at 11:01:09 UTC, Walter Bright
wrote:
The example had marked the template itself as 'export'. This
raises the
specter of which binary the template instantiation exists in.
The export in this context actually means export all
instanciations of this
template. And this is needed to avoid using -allinst
everywhere.
The problem is what happens when the client side instantiates
the template, which it must in order to use it.
Well if there already is a statically known instanciation it will
not instanciate it. (I didn't change that behvaior). The question
is what happens when you have something like this:
module a:
struct SomeTemplate(T){}
alias knownInstance = SomeTemplate!int;
module b:
SomeTemplate!int var1; // will use instanciation from a (unless
-allinst)
SomeTemplate!float var2; // will instanciate
alias knownInstance2 = SomeTemplate!uint;
module c:
SomeTemplate!uint var3; // will this use instaction from b? Or
instanciate itself?
I don't know enough about D's template implementation to answer
the question regarding c.var3. Depending on the answer to this
question I can answer what should happen if a export marked
template is instanciated outside of its module. (e.g. by the user)
Please also correct me if any of the above assumptions are
incorrect.
Re: What is @return?
On Thursday, 29 January 2015 at 11:50:29 UTC, FG wrote:
@property auto info() @safe @nothrow @pure @return const {
return this; }
It is mesmerizing... (@ _ @)
And soon its gong to look like this:
export @property auto info() @safe @nothrow @pure @return const {
return this; }
Re: Throwable.TraceInfo
Why don't you simply store references to the TraceInfo objects until you want to print them?
Re: Problem with coupling shared object symbol visibility with protection
On Wednesday, 28 January 2015 at 11:01:09 UTC, Walter Bright wrote: The example had marked the template itself as 'export'. This raises the specter of which binary the template instantiation exists in. Also sorry for the harsh answer, this was a classical double misunderstanding.
Re: Problem with coupling shared object symbol visibility with protection
On Wednesday, 28 January 2015 at 11:01:09 UTC, Walter Bright wrote: The example had marked the template itself as 'export'. This raises the specter of which binary the template instantiation exists in. The export in this context actually means export all instanciations of this template. And this is needed to avoid using -allinst everywhere.
Re: Problem with coupling shared object symbol visibility with protection
On Wednesday, 28 January 2015 at 11:42:19 UTC, Dicebot wrote: 2) first proposed solution does not allow to mark private functions as export. It implicitly exports those if they are needed for actual public/export template function to work. This is not the same - those functions still can't be called via provide .di binding, it simply keeps them available for linking. So you would prefer to keep symbols private and just make them available for linking? Or what exactly is the message here? 3) there is a big maintenance benefit from encouraging people to explicitly mark their API, template or not. It is a clear sign this is a part of my libraries you are expected to use directly and that was what my idea for attribute inference abused. Agree here. Especially if you want to keep your shared library backwards compatible, so that people can simply drop in the new binary. To do that you need very fine control over what is exported and what is not.
Re: Problem with coupling shared object symbol visibility with protection
On Wednesday, 28 January 2015 at 13:48:45 UTC, Dicebot wrote:
Isn't that what your first proposed solution is about? That was
my understanding and I liked that understanding :) To be 100%
clear :
export void foo(T : int)(T x)
{
bar(x);
}
private void bar(int x) { }
I'd expect `bar` to be exported into resulting binary so that
it can be linked against by any users of `foo` but for any
attempt to call `bar` directly from D code to fail because of
protection violation. If someone wants to circumvent protection
by forging mangling - shooting own feet is allowed.
Well this would be ultimate goal. Although it is not possible to
automatically detect that bar needs to be exported because that
would mean you would have to analyze all possible instantiations
of the template foo. (static if...)
So Automatically detecting that bar needs to be exported is not
possible. We either have to make export into an attribute or use
the solution where bar is actually nested into a struct which is
exported instead. This is also described in my initial post with
examples.
Re: Problem with coupling shared object symbol visibility with protection
On Tuesday, 27 January 2015 at 22:29:41 UTC, Rainer Schuetze wrote: I would not mind if we export all symbols on Windows aswell. It doesn't seem to bother a lot of people for the linux version, even though it's unsafer and slower than on Windows (at least that was my experience more than 10 years ago). It might get us a first working version without adding export throughout the druntime/phobos source code. There are multiple reasons why I don't want to simply export every symbol: 1) Before I started this implementation I synchronized with Martin Nowak regrading hish plans for D shared libraries. It turns out that he wants to annotate all of druntime and phobos with export asap and use it to control symbol visibility on linux. He wants to get away from the export everything on linux because it hurts performance and prevents some optimizations. 2) Every data symbol that is considered for exporting adds a slight performance overhead through a additional indirection, even for static builds. That is because the compiler can't know if the symbol is imported or not, as export means both import and export at the same time. So if the compiler simply assumes that all symbols are exported this would add a lot of unnecessary overhead even in static builds. (but also in dynamic ones) 3) If we start with export everything on Windows now, it will be hared to go back to export only whats annotated. I don't have a clear favorite, but the second version makes it clearer that visibility and protection are separate issues. A note on: export public void templateFunc(T)() I don't think it is well defined what exporting a template is supposed to mean. My guess: whenever an instance of the template is created, its symbols are exported. This could make for a lot of duplicate symbols across multiple DLLs, though. Obviously its not yet well defined. But we can define it. And you are right, it means that all instances are exported. And we need that behavior because otherwise you have to spray in -allinst everywhere. Believe me I tried. Maybe there should be a method of explicitly exporting/importing a template instance from another DLL, e.g. export alias symbol = templateFunc!int; I would rather not do that. You don't have to explicitly import template instances from static libraries either. We should try to keep the behavior of static and dynamic libraries as similar as possible. The ideal situation would be that you can simply compile something that was a static library into a dynamic one without doing any code changes (other then writing export: at the beginning of every file)
Re: Who knows about https://github.com/D-Programming-Language/tools/blob/master/update.sh?
On Wednesday, 28 January 2015 at 16:18:18 UTC, Andrei Alexandrescu wrote: We have a really nice script: https://github.com/D-Programming-Language/tools/blob/master/update.sh And once again this only works for linux... DMDs test framework is also a hell to use on Windows. It takes 5 times as long to run on Windows compared to linux.
Re: Throwable.TraceInfo
On Wednesday, 28 January 2015 at 14:45:04 UTC, david wrote: BTW: The code of the 'ctor generates the calltrace - so it's not lazy! No, getting the pointers of the stack trace is not lazy. Translating them into a string via debug symbols is lazy. Btw what platform are you on?
Re: Problem with coupling shared object symbol visibility with protection
On Wednesday, 28 January 2015 at 14:31:54 UTC, Dicebot wrote: Yes, I see the problem now. static if isn't even the worst offender, any kind of string mixins that generate the call to `bar` are impossible to detect without having actual `foo` instance. Sorry for misinterpretation. With that in mind second option is starting to look more attractive despite the grammar change - forcing good chunk template API into structs does not sound very convenient :( Well and then there is the third option Walter proposed: - Make everything export even if it means that it gets callable by the user directly.
