www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Enhancement on `export` symbol

reply Hipreme <msnmancini hotmail.com> writes:
Currently, my engine is using `export` for debug builds, while I 
wanted to not `export` things for release build.

That happens because I structured the engine to load a game as a 
DLL when in development. But for releases, it gets all built 
together. The problem is that the symbols are still `export`ed. 
And exporting a symbol increases binary size needlessly and also 
(possibly) losing some optimization opportunities since that 
symbol is exposed.

```d

version(Standalone)
{
     extern(System):
}
else version(dll): export extern(System):


int[2] getWindowSize(){return [HipRenderer.width, 
HipRenderer.height];}

void setWindowSize(uint width, uint height)
{
     HipRenderer.setWindowSize(width, height);
     HipRenderer.setViewport(viewport);
     
camera.setSize(cast(int)viewport.worldWidth,cast(int)viewport.worldHeight);
}

```

This is basically what I'm needing. I know that asking for that 
may be a chaos. But it would be good to at least have something 
like `export(dll)` or something like that, so, at least I would 
be able to use `version` for identifying if I need that exported 
or not.

That would basically mean, if I'm specifying `-version=dll`, 
`export` would work, else, it won't matter.
Mar 13
next sibling parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
https://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1045.md#export-annotation
Mar 13
parent reply Johan <j j.nl> writes:
On Friday, 14 March 2025 at 02:46:08 UTC, Richard (Rikki) Andrew 
Cattermole wrote:

 https://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1045.md#export-annotation


My intuition says that it'll be more broadly useful if attributes 
can be combined and aliased.
Something like this:

```
version(X) {
   // some arbitrary list of attributes
   alias attribs = AliasSeq!(export, extern(C), 
ldc.attributes.weak);
} else {
   // some arbitrary list of attributes
   alias attribs = AliasSeq!(extern(D), ldc.attributes.hidden);
}

 attribs
void foo() {}
```

You can already do this for the LDC attributes (because they are 
implemented as magic types), but not for D core language 
attributes.

-Johan
Mar 14
parent Hipreme <msnmancini hotmail.com> writes:
On Friday, 14 March 2025 at 12:07:00 UTC, Johan wrote:

 On Friday, 14 March 2025 at 02:46:08 UTC, Richard (Rikki) 
 Andrew Cattermole wrote:

 https://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1045.md#export-annotation


 My intuition says that it'll be more broadly useful if 
 attributes can be combined and aliased.
 Something like this:

 ```
 version(X) {
   // some arbitrary list of attributes
   alias attribs = AliasSeq!(export, extern(C), 
 ldc.attributes.weak);
 } else {
   // some arbitrary list of attributes
   alias attribs = AliasSeq!(extern(D), ldc.attributes.hidden);
 }

  attribs
 void foo() {}
 ```

 You can already do this for the LDC attributes (because they 
 are implemented as magic types), but not for D core language 
 attributes.

 -Johan


Seconded. I believe having those core language attributes 
transformed into magic types would definitely solve a long 
standing issue on the language and would make more C/C++ 
behaviors (such as `#define dllimport`) available in the language.
Mar 14
prev sibling parent reply kinke <noone nowhere.com> writes:
With LDC, you can use `-fvisibility={public,hidden}` to control 
the default visibility (for symbols without explicit `export` 
visibility / ` hidden` UDA). It defaults to `public` when 
compiling & linking a DLL in a single step via `-shared`; when 
compiling the DLL separately without linking, you need to specify 
it yourself.

Recent DMD has that CLI option too, `-visibility` (no leading 
`f`).

For (a lot of) context, see 
https://forum.dlang.org/post/dobouzmhwabquswguunk forum.dlang.org.
Mar 14
parent reply Hipreme <msnmancini hotmail.com> writes:
On Friday, 14 March 2025 at 16:32:55 UTC, kinke wrote:

 With LDC, you can use `-fvisibility={public,hidden}` to control 
 the default visibility (for symbols without explicit `export` 
 visibility / ` hidden` UDA). It defaults to `public` when 
 compiling & linking a DLL in a single step via `-shared`; when 
 compiling the DLL separately without linking, you need to 
 specify it yourself.

 Recent DMD has that CLI option too, `-visibility` (no leading 
 `f`).

 For (a lot of) context, see 
 https://forum.dlang.org/post/dobouzmhwabquswguunk forum.dlang.org.


I'm already using that since it reduces a lot the binary size. I 
would say that it is almost difficult to not use it, but still 
doesn't solve that issue I'm having unfortunately
Mar 14
parent kinke <noone nowhere.com> writes:
On Friday, 14 March 2025 at 16:41:05 UTC, Hipreme wrote:

 I'm already using that since it reduces a lot the binary size. 
 I would say that it is almost difficult to not use it, but 
 still doesn't solve that issue I'm having unfortunately


Have you tried compiling your DLL with `-fvisibility=public 
-d-version=Standalone`? That shouldn't reduce the binary size at 
all, but avoid having to uglify the code with `export` everywhere.
Mar 14