Hi,
I also want to say a big thank you to all of you involved
in this topic and especially to Benjamin.
Proper DLL handling in D I would really appreciate.
I think this topic is the break through.
Kind regards
André
On Tuesday, 17 February 2015 at 18:03:06 UTC, Benjamin Thaut
wrote:
So i
On Monday, 16 February 2015 at 20:19:27 UTC, Jacob Carlborg wrote:
On 2015-02-16 10:40, Benjamin Thaut wrote:
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
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.
On 2015-02-16 10:40, Benjamin Thaut wrote:
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).
Most likely due to
On 2/16/2015 12:19 PM, Jacob Carlborg wrote:
Most likely due to that the support for dynamic libraries is fairly new only
works on Linux (?).
Part of the test suite creates a DLL using D for Windows.
On Monday, 16 February 2015 at 21:41:00 UTC, Walter Bright wrote:
On 2/16/2015 12:19 PM, Jacob Carlborg wrote:
Most likely due to that the support for dynamic libraries is
fairly new only
works on Linux (?).
Part of the test suite creates a DLL using D for Windows.
Martin recently added
On 1/31/2015 11:52 AM, Benjamin Thaut wrote:
@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
On Monday, 16 February 2015 at 08:08:17 UTC, Walter Bright wrote:
On 1/31/2015 11:52 AM, Benjamin Thaut wrote:
@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
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
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
On 2/16/2015 1:40 AM, Benjamin Thaut wrote:
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
On Sunday, 1 February 2015 at 09:24:46 UTC, Benjamin Thaut wrote:
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
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
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,
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
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
On Saturday, 31 January 2015 at 09:25:10 UTC, Benjamin Thaut
wrote:
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
On Tuesday, 20 January 2015 at 12:23:32 UTC, Benjamin Thaut wrote:
2) Make export an attribute. If export is no longer an
protection level but instead an attribute this issue can easily
be solved by doing.
export public void templateFunc(T)()
{
someHelperFunc();
}
export private void
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
On Friday, 30 January 2015 at 19:10:06 UTC, Martin Nowak wrote:
On Tuesday, 20 January 2015 at 12:23:32 UTC, Benjamin Thaut
wrote:
2) Make export an attribute. If export is no longer an
protection level but instead an attribute this issue can
easily be solved by doing.
export public void
On Thursday, 29 January 2015 at 13:24:36 UTC, Benjamin Thaut
wrote:
module c:
SomeTemplate!uint var3; // will this use instaction from b? Or
instanciate itself?
That's the first instantiation with uint. If you mean float, then
it will instatiate the template when compiled individually and
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
On 1/28/2015 5:27 AM, Benjamin Thaut wrote:
Also sorry for the harsh answer, this was a classical double misunderstanding.
No problemo.
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
On Wednesday, 28 January 2015 at 14:16:03 UTC, Benjamin Thaut
wrote:
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
On Wednesday, 28 January 2015 at 13:30:17 UTC, Benjamin Thaut
wrote:
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
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.
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.
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
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
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
My 5 cents:
1) export all approach is extremely limiting and I'd like to
see it go on Linux too. One of major problems with it is that
many forms of link-time optimizations (such as --gc-sections)
become simply impossible when compiler can't know what symbols
are actually supposed to be
On 1/27/2015 2:05 PM, Rainer Schuetze wrote:
On 26.01.2015 23:24, Walter Bright wrote:
The problem here is that you don't want to make someHelperFunc()
export because that would mean users could call it directly, but
you want it to be available for cross shared library calls. The
cross shared
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
On Wednesday, 28 January 2015 at 15:01:30 UTC, Benjamin Thaut
wrote:
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
On 26.01.2015 23:24, Walter Bright wrote:
The problem here is that you don't want to make someHelperFunc()
export because that would mean users could call it directly, but
you want it to be available for cross shared library calls. The
cross shared library call happens if a template is
On 20.01.2015 13:23, Benjamin Thaut wrote:
I'm currently working on Windows DLL support which has stronger rules
than linux shared objects for which symbols actually get exported from a
shared library. But as we want to replicate the same behaviour on linux
using symbol visibility (e.g. gcc 4
Am 26.01.2015 um 23:24 schrieb Walter Bright:
exporting a template and then having the user instantiate outside of the
library doesn't make a whole lot of sense, because the instantiation
won't be there in the library. The library will have to instantiate
every use case. If the compiler knows
On 1/20/2015 4:23 AM, Benjamin Thaut wrote:
I'm currently working on Windows DLL support which has stronger rules than linux
shared objects for which symbols actually get exported from a shared library.
But as we want to replicate the same behaviour on linux using symbol visibility
(e.g. gcc 4
There are uses in Phobos where workaround 1) would require some code
changes:
private @property File trustedStdout() @trusted { return stdout; }
void write(T...)(T args) if (!is(T[0] : File))
{
trustedStdout.write(args);
}
My workaround so far:
export struct _impl1
{
package @property
I like the first version more as it fits better the natural way
people design their interfaces and reduces attributed noise.
Can't say if it will trigger some hidden issues.
First version also fits better some of ideas I had about
automated API generation/verification
On Tuesday, 20 January 2015 at 12:23:32 UTC, Benjamin Thaut wrote:
I'm currently working on Windows DLL support which has stronger
rules than linux shared objects for which symbols actually get
exported from a shared library. But as we want to replicate the
same behaviour on linux using symbol
Thanks for keeping to poke this issue - symbol visibility is
currently a big undefined minefield in D ABI.
Your welcome. At this point I'm so desperate for D Dll support
that I stopped poking and started implementing it myself. I'm 3
unresolved symbol references away from actually building
I'm currently working on Windows DLL support which has stronger rules
than linux shared objects for which symbols actually get exported from a
shared library. But as we want to replicate the same behaviour on linux
using symbol visibility (e.g. gcc 4 -fVisibility=hidden) this issue also
44 matches
Mail list logo
