www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Export ?

reply deadalnix <deadalnix gmail.com> writes:
On this newsgroup with Jonathan M Davis, we started discussing export. 
As it was off topic, and as it was interesting, I wish to bring it here.

As most of you know, all symbol on posix systems are export, but not on 
windows. As D have an export keyword, the question is what to do with it.

The need for change in the UNIX world of this behavior exists, and some 
move has been made in direction of explicitly hiding symbols ( see 
http://gcc.gnu.org/wiki/Visibility ).

For consistency across systems, I suggest that, unless marked as 
exported, symbols are hidden by default. This have other advantages as 
shown in the linked page about gcc. For D, it also mean that the linker 
will have all information to finalize all methods that are not marked as 
export, and I think this is something we want to mitigate the cost of 
all methods virtual by default.

The site says : ę Ex≠port means that any code out≠side the ex≠e≠cutable 
can ac≠cess the mem≠ber. Ex≠port is anal≠o≠gous to ex≠port≠ing 
de≠f≠i≠n≠i≠tions from a DLL. Ľ so, clearly it is not saying anything 
about posix systems (you'll not find many DLL on those) and not what D 
compiler does.

It means that export comes as an extra qualifier, and not as an 
alternative to public/private/protected/package . You can be both export 
AND public/private/protected/package .

This already have been discussed here, but no conclusion has been made.
Apr 10 2012
next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, April 10, 2012 19:36:06 deadalnix wrote:
 On this newsgroup with Jonathan M Davis, we started discussing export.
 As it was off topic, and as it was interesting, I wish to bring it here.
 
 As most of you know, all symbol on posix systems are export, but not on
 windows. As D have an export keyword, the question is what to do with it.
 
 The need for change in the UNIX world of this behavior exists, and some
 move has been made in direction of explicitly hiding symbols ( see
 http://gcc.gnu.org/wiki/Visibility ).

As I said in the other thread, I _hate_ export. It's one of Windows largest misfeatures IMHO. It drives me nuts when I have to deal with it in C++. The fact that Linux exports everything is _fantastic_. It's so much easier to deal with. I'd _hate_ to see Linux or anything we do move in the direction of what Windows has done. - Jonathan M Davis
Apr 10 2012
next sibling parent deadalnix <deadalnix gmail.com> writes:
Le 10/04/2012 20:00, Kapps a écrit :
 On Tuesday, 10 April 2012 at 17:44:54 UTC, Jonathan M Davis wrote:
 As I said in the other thread, I _hate_ export. It's one of Windows
 largest
 misfeatures IMHO. It drives me nuts when I have to deal with it in
 C++. The
 fact that Linux exports everything is _fantastic_. It's so much easier
 to deal
 with. I'd _hate_ to see Linux or anything we do move in the direction
 of what
 Windows has done.

 - Jonathan M Davis

Agreed. Ideally, there would be a compiler flag to export all public symbols by default. Public is there for a reason, public is default for a reason. Now forcing a bunch of clutter just to add expor to everything, would defeat the purpose and is the single largest reason I don't use DLLs.

Note that this is easy to perform without compiler flag, with an ¬ę export: ¬Ľ
Apr 11 2012
prev sibling parent reply deadalnix <deadalnix gmail.com> writes:
Le 10/04/2012 19:44, Jonathan M Davis a écrit :
 On Tuesday, April 10, 2012 19:36:06 deadalnix wrote:
 On this newsgroup with Jonathan M Davis, we started discussing export.
 As it was off topic, and as it was interesting, I wish to bring it here.

 As most of you know, all symbol on posix systems are export, but not on
 windows. As D have an export keyword, the question is what to do with it.

 The need for change in the UNIX world of this behavior exists, and some
 move has been made in direction of explicitly hiding symbols ( see
 http://gcc.gnu.org/wiki/Visibility ).

As I said in the other thread, I _hate_ export. It's one of Windows largest misfeatures IMHO. It drives me nuts when I have to deal with it in C++. The fact that Linux exports everything is _fantastic_. It's so much easier to deal with. I'd _hate_ to see Linux or anything we do move in the direction of what Windows has done. - Jonathan M Davis

It isn't a misfeature. The link explain why it is interesting : - It improves load time of DSO. - Allow more optimizations. - Reduce DSO size by 5% to 20% for C++. Considering how long mangling are in D, probably more for us. - Reduce name collision (this one poorly apply to D, because the module system handle that quite nicely). Additionally, it allow automatic finalization for non exported methods in D. The drawback is having to explicitely export. I think it worth it, especially considering ¬ę export: ¬Ľ is an available solution. A compiler switch is also an option. BTW, Linux is moving in that direction, for the advantages given above. Some other posix systems also does that already.
Apr 11 2012
next sibling parent deadalnix <deadalnix gmail.com> writes:
Le 11/04/2012 19:03, Johannes Pfau a ťcrit :
 Am Wed, 11 Apr 2012 11:56:00 +0200
 schrieb deadalnix<deadalnix gmail.com>:
 It isn't a misfeature. The link explain why it is interesting :
    - It improves load time of DSO.
    - Allow more optimizations.
    - Reduce DSO size by 5% to 20% for C++. Considering how long
 mangling are in D, probably more for us.
    - Reduce name collision (this one poorly apply to D, because the
 module system handle that quite nicely).

 Additionally, it allow automatic finalization for non exported
 methods in D.

This explains why symbol visibility is useful. But do we really need 'export'? Are there cases where public = export, private/package = 'not exported' wouldn't work? When do you actually need 'not-exported' and public? And would export private/export package be valid?

public and export aren't the same thing. If public qualify how the symbol can be acessed by code, export qualify how the symbol can be linked. An exported symbol can be linked at runtime, but a non exported symbol cannot. If public = export, then drawback expressed above will occur. If protected = not exported, then you cannot extends a class from you main application in a DSO (or the other way around). You usually don't want that.
Apr 11 2012
prev sibling parent Paulo Pinto <pjmlp progtools.org> writes:
Am 11.04.2012 19:03, schrieb Johannes Pfau:
 Am Wed, 11 Apr 2012 11:56:00 +0200
 schrieb deadalnix<deadalnix gmail.com>:
 It isn't a misfeature. The link explain why it is interesting :
    - It improves load time of DSO.
    - Allow more optimizations.
    - Reduce DSO size by 5% to 20% for C++. Considering how long
 mangling are in D, probably more for us.
    - Reduce name collision (this one poorly apply to D, because the
 module system handle that quite nicely).

 Additionally, it allow automatic finalization for non exported
 methods in D.

This explains why symbol visibility is useful. But do we really need 'export'? Are there cases where public = export, private/package = 'not exported' wouldn't work? When do you actually need 'not-exported' and public? And would export private/export package be valid?

For example, a so/dll might be composed of several D packages. In those packages you want the public symbols to be visible between packages, but not visible to the applications that link to your so/dll library. This is why many languages make a distinction between modules and packages. Usually a module is composed of several packages. These type of modularity might seem complex, but actually is a good way to modularize applications.
Apr 11 2012
prev sibling next sibling parent "Kapps" <opantm2+spam gmail.com> writes:
On Tuesday, 10 April 2012 at 17:44:54 UTC, Jonathan M Davis wrote:
 As I said in the other thread, I _hate_ export. It's one of 
 Windows largest
 misfeatures IMHO. It drives me nuts when I have to deal with it 
 in C++. The
 fact that Linux exports everything is _fantastic_. It's so much 
 easier to deal
 with. I'd _hate_ to see Linux or anything we do move in the 
 direction of what
 Windows has done.

 - Jonathan M Davis

Agreed. Ideally, there would be a compiler flag to export all public symbols by default. Public is there for a reason, public is default for a reason. Now forcing a bunch of clutter just to add expor to everything, would defeat the purpose and is the single largest reason I don't use DLLs.
Apr 10 2012
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
Windows is not alone in this regard. AIX uses a similar behaviour

http://publib.boulder.ibm.com/infocenter/comphelp/v7v91/topic/com.ibm.vacpp7a.doc/proguide/ref/compile_library.htm#compile_library

Remember not all UNIXes are made alike. :)

--
Paulo



On Tuesday, 10 April 2012 at 17:44:54 UTC, Jonathan M Davis wrote:
 On Tuesday, April 10, 2012 19:36:06 deadalnix wrote:
 On this newsgroup with Jonathan M Davis, we started discussing 
 export.
 As it was off topic, and as it was interesting, I wish to 
 bring it here.
 
 As most of you know, all symbol on posix systems are export, 
 but not on
 windows. As D have an export keyword, the question is what to 
 do with it.
 
 The need for change in the UNIX world of this behavior exists, 
 and some
 move has been made in direction of explicitly hiding symbols ( 
 see
 http://gcc.gnu.org/wiki/Visibility ).

As I said in the other thread, I _hate_ export. It's one of Windows largest misfeatures IMHO. It drives me nuts when I have to deal with it in C++. The fact that Linux exports everything is _fantastic_. It's so much easier to deal with. I'd _hate_ to see Linux or anything we do move in the direction of what Windows has done. - Jonathan M Davis

Apr 10 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, April 11, 2012 11:56:00 deadalnix wrote:
 Le 10/04/2012 19:44, Jonathan M Davis a =C3=A9crit :
 On Tuesday, April 10, 2012 19:36:06 deadalnix wrote:
 On this newsgroup with Jonathan M Davis, we started discussing exp=



 As it was off topic, and as it was interesting, I wish to bring it=



=20
 As most of you know, all symbol on posix systems are export, but n=



 windows. As D have an export keyword, the question is what to do w=



=20
 The need for change in the UNIX world of this behavior exists, and=



 move has been made in direction of explicitly hiding symbols ( see=



 http://gcc.gnu.org/wiki/Visibility ).

As I said in the other thread, I _hate_ export. It's one of Windows=


 largest
 misfeatures IMHO. It drives me nuts when I have to deal with it in =


 The
 fact that Linux exports everything is _fantastic_. It's so much eas=


 deal with. I'd _hate_ to see Linux or anything we do move in the
 direction of what Windows has done.
=20
 - Jonathan M Davis

It isn't a misfeature. The link explain why it is interesting : - It improves load time of DSO. - Allow more optimizations. - Reduce DSO size by 5% to 20% for C++. Considering how long mangli=

 are in D, probably more for us.
   - Reduce name collision (this one poorly apply to D, because the
 module system handle that quite nicely).
=20
 Additionally, it allow automatic finalization for non exported method=

=20
 The drawback is having to explicitely export. I think it worth it,
 especially considering =C2=AB export: =C2=BB is an available solution=

 switch is also an option.
=20
 BTW, Linux is moving in that direction, for the advantages given abov=

 Some other posix systems also does that already.

Honestly, I don't care what list of benefits you can come up with for h= aving to=20 explicitly export symbols. I am sick and tired of having to deal with b= uild=20 breakages due to unexported symbols in C++ on Windows. It is really, re= allly,=20 really annoying. It's a usability nightmare as far as I'm concerned, an= d I=20 don't want to see it spread any more than I want to see cancer spread. As far as I'm concerned, Linux got this _right_ and Windows got it comp= letely=20 wrong, and I do _not_ want to see export being used in D any further th= an it=20 is. It's bad enough that the export keyword exists at all. - Jonathan M Davis
Apr 11 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--20cf3074da543a507504bd658e75
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 11 April 2012 13:50, Jonathan M Davis <jmdavisProg gmx.com> wrote:

 On Wednesday, April 11, 2012 11:56:00 deadalnix wrote:
 Le 10/04/2012 19:44, Jonathan M Davis a =C3=A9crit :
 On Tuesday, April 10, 2012 19:36:06 deadalnix wrote:
 On this newsgroup with Jonathan M Davis, we started discussing expor=




 As it was off topic, and as it was interesting, I wish to bring it



 As most of you know, all symbol on posix systems are export, but not



 windows. As D have an export keyword, the question is what to do wit=




 it.
 The need for change in the UNIX world of this behavior exists, and



 move has been made in direction of explicitly hiding symbols ( see
 http://gcc.gnu.org/wiki/Visibility ).

As I said in the other thread, I _hate_ export. It's one of Windows largest misfeatures IMHO. It drives me nuts when I have to deal with it in C+=



 The
 fact that Linux exports everything is _fantastic_. It's so much easie=



 to
 deal with. I'd _hate_ to see Linux or anything we do move in the
 direction of what Windows has done.

 - Jonathan M Davis

It isn't a misfeature. The link explain why it is interesting : - It improves load time of DSO. - Allow more optimizations. - Reduce DSO size by 5% to 20% for C++. Considering how long mangling are in D, probably more for us. - Reduce name collision (this one poorly apply to D, because the module system handle that quite nicely). Additionally, it allow automatic finalization for non exported methods

 The drawback is having to explicitely export. I think it worth it,
 especially considering =C2=AB export: =C2=BB is an available solution. =


 switch is also an option.

 BTW, Linux is moving in that direction, for the advantages given above.
 Some other posix systems also does that already.

Honestly, I don't care what list of benefits you can come up with for having to explicitly export symbols. I am sick and tired of having to deal with bui=

 breakages due to unexported symbols in C++ on Windows. It is really,
 reallly,
 really annoying. It's a usability nightmare as far as I'm concerned, and =

 don't want to see it spread any more than I want to see cancer spread.

 As far as I'm concerned, Linux got this _right_ and Windows got it
 completely
 wrong, and I do _not_ want to see export being used in D any further than
 it
 is. It's bad enough that the export keyword exists at all.

Apply the same rules to Linux, and it'll never bother you again. It's the only solution, you can't possibly influence Microsoft to apply the inverse. As far as I'm concerned windows got it _right_ and linux got it... 'linux'. I like DLL's being self contained modules with tightly controlled interfaces. And deadalnix lists important points. --20cf3074da543a507504bd658e75 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 11 April 2012 13:50, Jonathan M Davis <span d= ir=3D"ltr">&lt;<a href=3D"mailto:jmdavisProg gmx.com">jmdavisProg gmx.com</= a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0= 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"HOEnZb"><div class=3D"h5">On Wednesday, April 11, 2012 11:56:= 00 deadalnix wrote:<br> &gt; Le 10/04/2012 19:44, Jonathan M Davis a =C3=A9crit :<br> &gt; &gt; On Tuesday, April 10, 2012 19:36:06 deadalnix wrote:<br> &gt; &gt;&gt; On this newsgroup with Jonathan M Davis, we started discussin= g export.<br> &gt; &gt;&gt; As it was off topic, and as it was interesting, I wish to bri= ng it here.<br> &gt; &gt;&gt;<br> &gt; &gt;&gt; As most of you know, all symbol on posix systems are export, = but not on<br> &gt; &gt;&gt; windows. As D have an export keyword, the question is what to= do with it.<br> &gt; &gt;&gt;<br> &gt; &gt;&gt; The need for change in the UNIX world of this behavior exists= , and some<br> &gt; &gt;&gt; move has been made in direction of explicitly hiding symbols = ( see<br> &gt; &gt;&gt; <a href=3D"http://gcc.gnu.org/wiki/Visibility" target=3D"_bla= nk">http://gcc.gnu.org/wiki/Visibility</a> ).<br> &gt; &gt;<br> &gt; &gt; As I said in the other thread, I _hate_ export. It&#39;s one of W= indows<br> &gt; &gt; largest<br> &gt; &gt; misfeatures IMHO. It drives me nuts when I have to deal with it i= n C++.<br> &gt; &gt; The<br> &gt; &gt; fact that Linux exports everything is _fantastic_. It&#39;s so mu= ch easier to<br> &gt; &gt; deal with. I&#39;d _hate_ to see Linux or anything we do move in = the<br> &gt; &gt; direction of what Windows has done.<br> &gt; &gt;<br> &gt; &gt; - Jonathan M Davis<br> &gt;<br> &gt; It isn&#39;t a misfeature. The link explain why it is interesting :<br=

&gt; =C2=A0 - Allow more optimizations.<br> &gt; =C2=A0 - Reduce DSO size by 5% to 20% for C++. Considering how long ma= ngling<br> &gt; are in D, probably more for us.<br> &gt; =C2=A0 - Reduce name collision (this one poorly apply to D, because th= e<br> &gt; module system handle that quite nicely).<br> &gt;<br> &gt; Additionally, it allow automatic finalization for non exported methods= in D.<br> &gt;<br> &gt; The drawback is having to explicitely export. I think it worth it,<br> &gt; especially considering =C2=AB export: =C2=BB is an available solution.= A compiler<br> &gt; switch is also an option.<br> &gt;<br> &gt; BTW, Linux is moving in that direction, for the advantages given above= .<br> &gt; Some other posix systems also does that already.<br> <br> </div></div>Honestly, I don&#39;t care what list of benefits you can come u= p with for having to<br> explicitly export symbols. I am sick and tired of having to deal with build= <br> breakages due to unexported symbols in C++ on Windows. It is really, realll= y,<br> really annoying. It&#39;s a usability nightmare as far as I&#39;m concerned= , and I<br> don&#39;t want to see it spread any more than I want to see cancer spread.<= br> <br> As far as I&#39;m concerned, Linux got this _right_ and Windows got it comp= letely<br> wrong, and I do _not_ want to see export being used in D any further than i= t<br> is. It&#39;s bad enough that the export keyword exists at all.<br></blockqu= ote><div><br></div><div>Apply the same rules to Linux, and it&#39;ll never = bother you again. It&#39;s the only solution, you can&#39;t possibly influe= nce Microsoft to apply the inverse.</div> <div>As far as I&#39;m concerned windows got it _right_ and linux got it...= &#39;linux&#39;. I like DLL&#39;s being self contained modules with tightl= y controlled interfaces.=C2=A0And deadalnix lists important points.</div></= div> --20cf3074da543a507504bd658e75--
Apr 11 2012
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
And as I noted on my post, Windows is not alone in this regard.

Many other OS follow the same explicit export principle, AIX
being one of them.

Linux != UNIX

--
Paulo

On Wednesday, 11 April 2012 at 11:29:53 UTC, Manu wrote:
 On 11 April 2012 13:50, Jonathan M Davis <jmdavisProg gmx.com> 
 wrote:

 On Wednesday, April 11, 2012 11:56:00 deadalnix wrote:
 Le 10/04/2012 19:44, Jonathan M Davis a écrit :
 On Tuesday, April 10, 2012 19:36:06 deadalnix wrote:
 On this newsgroup with Jonathan M Davis, we started 
 discussing export.
 As it was off topic, and as it was interesting, I wish to 
 bring it



 As most of you know, all symbol on posix systems are 
 export, but not



 windows. As D have an export keyword, the question is 
 what to do with



 The need for change in the UNIX world of this behavior 
 exists, and



 move has been made in direction of explicitly hiding 
 symbols ( see
 http://gcc.gnu.org/wiki/Visibility ).

As I said in the other thread, I _hate_ export. It's one of Windows largest misfeatures IMHO. It drives me nuts when I have to deal with it in C++. The fact that Linux exports everything is _fantastic_. It's so much easier


 deal with. I'd _hate_ to see Linux or anything we do move 
 in the
 direction of what Windows has done.

 - Jonathan M Davis

It isn't a misfeature. The link explain why it is interesting : - It improves load time of DSO. - Allow more optimizations. - Reduce DSO size by 5% to 20% for C++. Considering how long mangling are in D, probably more for us. - Reduce name collision (this one poorly apply to D, because the module system handle that quite nicely). Additionally, it allow automatic finalization for non exported methods

 The drawback is having to explicitely export. I think it 
 worth it,
 especially considering ¬ę export: ¬Ľ is an available 
 solution. A compiler
 switch is also an option.

 BTW, Linux is moving in that direction, for the advantages 
 given above.
 Some other posix systems also does that already.

Honestly, I don't care what list of benefits you can come up with for having to explicitly export symbols. I am sick and tired of having to deal with build breakages due to unexported symbols in C++ on Windows. It is really, reallly, really annoying. It's a usability nightmare as far as I'm concerned, and I don't want to see it spread any more than I want to see cancer spread. As far as I'm concerned, Linux got this _right_ and Windows got it completely wrong, and I do _not_ want to see export being used in D any further than it is. It's bad enough that the export keyword exists at all.

Apply the same rules to Linux, and it'll never bother you again. It's the only solution, you can't possibly influence Microsoft to apply the inverse. As far as I'm concerned windows got it _right_ and linux got it... 'linux'. I like DLL's being self contained modules with tightly controlled interfaces. And deadalnix lists important points.

Apr 11 2012
prev sibling next sibling parent Johannes Pfau <nospam example.com> writes:
Am Wed, 11 Apr 2012 11:56:00 +0200
schrieb deadalnix <deadalnix gmail.com>:
 
 It isn't a misfeature. The link explain why it is interesting :
   - It improves load time of DSO.
   - Allow more optimizations.
   - Reduce DSO size by 5% to 20% for C++. Considering how long
 mangling are in D, probably more for us.
   - Reduce name collision (this one poorly apply to D, because the 
 module system handle that quite nicely).
 
 Additionally, it allow automatic finalization for non exported
 methods in D.
 

This explains why symbol visibility is useful. But do we really need 'export'? Are there cases where public = export, private/package = 'not exported' wouldn't work? When do you actually need 'not-exported' and public? And would export private/export package be valid?
Apr 11 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, April 11, 2012 14:11:49 Paulo Pinto wrote:
 And as I noted on my post, Windows is not alone in this regard.
 
 Many other OS follow the same explicit export principle, AIX
 being one of them.
 
 Linux != UNIX

I never said that it was. I'm just saying that I consider explicit exporting to be a usability nightmare and therefore an enormous mistake, and the fact that Windows does it is horrific. The fact that Linux doesn't is fantastic. Other *nixes may do it, but that doesn't make it any better of an idea IMHO. - Jonathan M Davis
Apr 11 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, April 11, 2012 14:29:42 Manu wrote:
 Apply the same rules to Linux, and it'll never bother you again. It's the
 only solution, you can't possibly influence Microsoft to apply the inverse.

That doesn't fix the problem. It just makes it so that Linux has it as well. - Jonathan M Davis
Apr 11 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 11 April 2012 at 17:03:48 UTC, Johannes Pfau wrote:
 This explains why symbol visibility is useful. But do we really 
 need 'export'? Are there cases where public = export, 
 private/package = 'not exported' wouldn't work?

I want to sort of hijack export for my web apps. Say you have public Data getUserData(string userId, string key) {} export Data getData(string key) {} so other modules, internal to the app, are allowed to replace the user id but still get the nice function, but external api consumers can only get data for the user they are logged in as.
Apr 11 2012
prev sibling next sibling parent Johannes Pfau <nospam example.com> writes:
Am Wed, 11 Apr 2012 20:27:31 +0200
schrieb Paulo Pinto <pjmlp progtools.org>:

 Am 11.04.2012 19:03, schrieb Johannes Pfau:
 Am Wed, 11 Apr 2012 11:56:00 +0200
 schrieb deadalnix<deadalnix gmail.com>:
 It isn't a misfeature. The link explain why it is interesting :
    - It improves load time of DSO.
    - Allow more optimizations.
    - Reduce DSO size by 5% to 20% for C++. Considering how long
 mangling are in D, probably more for us.
    - Reduce name collision (this one poorly apply to D, because the
 module system handle that quite nicely).

 Additionally, it allow automatic finalization for non exported
 methods in D.

This explains why symbol visibility is useful. But do we really need 'export'? Are there cases where public = export, private/package = 'not exported' wouldn't work? When do you actually need 'not-exported' and public? And would export private/export package be valid?

For example, a so/dll might be composed of several D packages. In those packages you want the public symbols to be visible between packages, but not visible to the applications that link to your so/dll library.

OK, I understand. I still can't think of a concrete example where I would want that behavior, but I'll just trust you all that it's useful.
 This is why many languages make a distinction between modules and 
 packages. Usually a module is composed of several packages.
 
 These type of modularity might seem complex, but actually is a good
 way to modularize applications.

Apr 12 2012
prev sibling next sibling parent "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Wednesday, 11 April 2012 at 10:50:21 UTC, Jonathan M Davis 
wrote:
 As far as I'm concerned, Linux got this _right_ and Windows got 
 it completely
 wrong, and I do _not_ want to see export being used in D any 
 further than it
 is. It's bad enough that the export keyword exists at all.

 - Jonathan M Davis

I think the problem is deeper: C++, which you have mentioned, doesn't tell anything about libraries leaving programmer alone with unportable issues. So, the problem is inconsistent behavior across different implementations. It is better to say not that Linux got it right, but you were luckier with Linux, because its export policy was beneficial for you. For example that bits Linux "everything is portable" policy, I had a cross platform project and thought that it would be safe to hide some internal functions but than i realized that it requires lots of unportable code. If D would offer portable solution to this problem, it would be its yet another big win.
Apr 19 2012
prev sibling next sibling parent "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Tuesday, 10 April 2012 at 17:34:25 UTC, deadalnix wrote:
 On this newsgroup with Jonathan M Davis, we started discussing 
 export. As it was off topic, and as it was interesting, I wish 
 to bring it here.

 As most of you know, all symbol on posix systems are export, 
 but not on windows. As D have an export keyword, the question 
 is what to do with it.

 The need for change in the UNIX world of this behavior exists, 
 and some move has been made in direction of explicitly hiding 
 symbols ( see http://gcc.gnu.org/wiki/Visibility ).

 For consistency across systems, I suggest that, unless marked 
 as exported, symbols are hidden by default. This have other 
 advantages as shown in the linked page about gcc. For D, it 
 also mean that the linker will have all information to finalize 
 all methods that are not marked as export, and I think this is 
 something we want to mitigate the cost of all methods virtual 
 by default.

 The site says : ¬ę Ex¬≠port means that any code out¬≠side the 
 ex­e­cutable can ac­cess the mem­ber. Ex­port is 
 anal­o­gous to ex­port­ing de­f­i­n­i­tions from a 
 DLL. ¬Ľ so, clearly it is not saying anything about posix 
 systems (you'll not find many DLL on those) and not what D 
 compiler does.

 It means that export comes as an extra qualifier, and not as an 
 alternative to public/private/protected/package . You can be 
 both export AND public/private/protected/package .

 This already have been discussed here, but no conclusion has 
 been made.

I found current export keyword "imaginary" because D treats each module as implementation and you have have no ability to divide declaration from implementation except pure C functions, which eliminates all D features. Each time when you import module it is pulled in a one executable. You can mark anything in a source code (which supposed to be part of the library) with export keyword but you either 1) pull it in the same executable with application and you don't care about whether it is exported or not or 2) compile "library" separately but you still have to import it (all source code, including implementation) when compiling "application" (you cannot import any declaration like in C/C++) and again you are indifferent about export keyword. So, I found export keyword as a pure comment and as much useful like "doesn't_launch_missiles" qualifier is. When I faced the problem in D that if I want to interface with shared library I only can do this through basic C-like functions (http://dlang.org/dll.html#Dcode), I feel like I am offered an attractive bag with broken handle.
Apr 19 2012
prev sibling parent "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Tuesday, 10 April 2012 at 17:34:25 UTC, deadalnix wrote:
 For consistency across systems, I suggest that, unless marked 
 as exported, symbols are hidden by default. This have other 
 advantages as shown in the linked page about gcc. For D, it 
 also mean that the linker will have all information to finalize 
 all methods that are not marked as export, and I think this is 
 something we want to mitigate the cost of all methods virtual 
 by default.

 The site says : ¬ę Ex¬≠port means that any code out¬≠side the 
 ex­e­cutable can ac­cess the mem­ber. Ex­port is 
 anal­o­gous to ex­port­ing de­f­i­n­i­tions from a 
 DLL. ¬Ľ so, clearly it is not saying anything about posix 
 systems (you'll not find many DLL on those) and not what D 
 compiler does.

 It means that export comes as an extra qualifier, and not as an 
 alternative to public/private/protected/package . You can be 
 both export AND public/private/protected/package .

 This already have been discussed here, but no conclusion has 
 been made.

TDPL is opposite about this issue. It clearly states that it is a top of permissive access. Currently dmd rejects both export and for example private, or public. Whether library files are compiled separately or not (because of the D module design) an importer always see an imported module as a source code and it doesn't care whether linker hides symbol or not. If you order compiler and linker to hide any symbol which is not exported (with export keyword) following problem occures: lib.d: export class Export {} public class Public {} ... main.d: import lib; void main() { auto e = new Export(); auto pub = new Public(); e.test(); pub.test(); // am i compiled as a library or part of executable? }
Apr 19 2012