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
On Wednesday, 13 May 2015 at 07:49:26 UTC, Benjamin Thaut wrote:
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++
On Wednesday, 13 May 2015 at 11:41:27 UTC, Benjamin Thaut wrote:
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
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.
On Wednesday, 13 May 2015 at 13:31:15 UTC, Benjamin Thaut wrote:
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
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
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
On Wednesday, 13 May 2015 at 06:17:36 UTC, Benjamin Thaut wrote:
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
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
On Friday, 8 May 2015 at 05:26:01 UTC, Benjamin Thaut wrote:
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
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.
Am Sun, 10 May 2015 19:51:26 +
schrieb Dicebot pub...@dicebot.lv:
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 :)
Yep, this is an area where I
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
Thanks for the insight into how this affects MSVC++, too.
How much work do you think would have to be done at startup of
an application like Firefox or QtCreator if they were not in
C++, but D?
Most of us have no idea what the algorithm would look like and
what data sets to expect.
I guess
On Friday, 8 May 2015 at 05:26:01 UTC, Benjamin Thaut wrote:
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.
Can you elaborate a bit on
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.
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
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
On Monday, 11 May 2015 at 15:32:47 UTC, Benjamin Thaut wrote:
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
On Sunday, 10 May 2015 at 19:27:03 UTC, Benjamin Thaut wrote:
Does nobody have a opinion on this?
Sorry for being an extreme noob in the matter.
Probably, only Manu fought with Windows dlls for real.
As a user I would say I want short startup times as I
change/execute the active application
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
On Monday, 11 May 2015 at 20:53:40 UTC, Benjamin Thaut wrote:
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
Well choice between two presented options seems obvious so I
suspect a catch :)
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
Does nobody have a opinion on this?
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 :)
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.
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
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++
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
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
31 matches
Mail list logo
