Export was being implemented as an attribute last I saw of it, by
the guy that made that DIP. Looks like he last worked on it some
time in July.
https://github.com/Ingrater/dmd/commits/DllSupportD2
ne as soon as possible, so the D will be able to have a much better DLL support, which in turn will help both our development, both the adoption of the language.
Thanks. The interesting bit of that DIP w.r.t DIP1012 is
A single meaning of export
The classical solution to handle dllexport
`export` storage visibility, So that one can do
```
version(MyLib_Build)
enum MyLibExport = dynamicExport;
else
enum MyLibExport = dynamicImport;
// Exported when building the shared object,
//imported when linking against the shared object.
@MyLibExport void foo(int x
I have as part of DIP 1012
```
enum SymbolExport
{
neither,
dynamicImport,
dynamicExport
}
alias dynamicImport = SymbolExport .dynamicImport;
alias dynamicExport = SymbolExport .dynamicExport;
```
to replace the `export` storage visibility, So that one can do
```
version
On 2016-07-15 21:39, tcak wrote:
Never used D on Xcode, nor I knew it was possible.
Well, when it comes to using the debugger in Xcode or profiling using
Instruments both can load any application. Although you won't get any
demangling in the debugger but if you and the source files to an Xco
On 07/15/2016 03:42 PM, tcak wrote:
If it is about speed, we can still use a public shared memory for that
purpose. So, statistical messages can be written in shared memory, and
other program reads from that to get those messages. A suitable
communication protocol can be implemented in way. At th
On Friday, 15 July 2016 at 17:04:35 UTC, Andrei Alexandrescu
wrote:
On 07/15/2016 12:31 PM, tcak wrote:
Do you know about --profile=gc?
1. Never worked for me in a multithreaded program.
Could you please give it another look. Walter fixed it
relatively recently.
Hmm, I will check it out
On Friday, 15 July 2016 at 19:22:41 UTC, Jacob Carlborg wrote:
On 2016-07-15 18:14, tcak wrote:
It is great to see memory usage on Xcode while running an iOS
app.
Have you tried to run a D application inside Xcode to get the
same information? Or is it not available due to the GC?
Never used
On 2016-07-15 18:14, tcak wrote:
It is great to see memory usage on Xcode while running an iOS app.
Have you tried to run a D application inside Xcode to get the same
information? Or is it not available due to the GC?
--
/Jacob Carlborg
On 07/15/2016 12:31 PM, tcak wrote:
Do you know about --profile=gc?
1. Never worked for me in a multithreaded program.
Could you please give it another look. Walter fixed it relatively recently.
2. I am not able to retrieve that data on runtime by another application
to see close to real-ti
On Friday, 15 July 2016 at 16:21:15 UTC, Jack Stouffer wrote:
On Friday, 15 July 2016 at 16:14:39 UTC, tcak wrote:
It is great to see memory usage on Xcode while running an iOS
app.
What I thought is that:
1. GC knows available heap memory locations and their length.
2. GC can detect what par
On Friday, 15 July 2016 at 16:14:39 UTC, tcak wrote:
It is great to see memory usage on Xcode while running an iOS
app.
What I thought is that:
1. GC knows available heap memory locations and their length.
2. GC can detect what parts of heap is in use.
3. A program can create a file to write (
It is great to see memory usage on Xcode while running an iOS app.
What I thought is that:
1. GC knows available heap memory locations and their length.
2. GC can detect what parts of heap is in use.
3. A program can create a file to write (stdout, stderr, etc.)
So, when desired (e.g. use of a
On Thursday, 19 May 2016 at 15:08:32 UTC, Ali Çehreli wrote:
On 05/19/2016 07:15 AM, flamencofantasy wrote:
What's the URL to watch the videos? Thanks.
Until the HD versions appear later (presumably on YouTube), all
current videos are here:
https://www.sociomantic.com/blog/2016/05/follow-
On 05/19/2016 07:15 AM, flamencofantasy wrote:
What's the URL to watch the videos? Thanks.
Until the HD versions appear later (presumably on YouTube), all current
videos are here:
https://www.sociomantic.com/blog/2016/05/follow-dconf-2016-in-real-time/#.Vz3WR5R4foe
You can find a particul
On Thursday, 19 May 2016 at 14:00:54 UTC, Andre Pany wrote:
Hi,
after looking Benjamins talk I took some time to think about it.
Benjamin made some effort towards a sophisticated DLL suppport
for D.
What I understand: He won't push his changes until "export"
will become an
Hi,
after looking Benjamins talk I took some time to think about it.
Benjamin made some effort towards a sophisticated DLL suppport
for D.
What I understand: He won't push his changes until "export" will
become an attribute.
But without his changes there is no need to change t
On Wednesday, 25 November 2015 at 15:30:30 UTC, Daniel Murphy
wrote:
On 25/11/2015 11:53 AM, deadalnix wrote:
On Tuesday, 24 November 2015 at 23:14:28 UTC, deadalnix wrote:
According to this:
https://www.youtube.com/watch?v=RwdQA0pGWa4
There are plan to add these keyword in C++'s module system
On 25/11/2015 11:53 AM, deadalnix wrote:
On Tuesday, 24 November 2015 at 23:14:28 UTC, deadalnix wrote:
According to this:
https://www.youtube.com/watch?v=RwdQA0pGWa4
There are plan to add these keyword in C++'s module system.
Also, this module representation may be an opportunity for us to c
On Wednesday, 25 November 2015 at 08:27:22 UTC, Iain Buclaw wrote:
On 25 November 2015 at 01:53, deadalnix via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
On Tuesday, 24 November 2015 at 23:14:28 UTC, deadalnix wrote:
According to this: https://www.youtube.com/watch?v=RwdQA0pGWa4
Th
On Wednesday, 25 November 2015 at 08:27:22 UTC, Iain Buclaw wrote:
Not sure about Clang, but GCC already knows about modules from
Fortran.
It's been quite a while already:
http://clang.llvm.org/docs/Modules.html
On 25 November 2015 at 01:53, deadalnix via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> On Tuesday, 24 November 2015 at 23:14:28 UTC, deadalnix wrote:
>
>> According to this:
>> https://www.youtube.com/watch?v=RwdQA0pGWa4
>>
>> There are plan to add these keyword in C++'s module system.
On Tuesday, 24 November 2015 at 23:14:28 UTC, deadalnix wrote:
According to this:
https://www.youtube.com/watch?v=RwdQA0pGWa4
There are plan to add these keyword in C++'s module system.
I think I would prefer if C++ compilers started spitting out D
bindings instead ;)
Bit
On Tuesday, 24 November 2015 at 23:14:28 UTC, deadalnix wrote:
According to this:
https://www.youtube.com/watch?v=RwdQA0pGWa4
There are plan to add these keyword in C++'s module system.
Also, this module representation may be an opportunity for us to
compile D to something a C++ compiler can
According to this:
https://www.youtube.com/watch?v=RwdQA0pGWa4
There are plan to add these keyword in C++'s module system.
On Tuesday, 1 September 2015 at 18:25:06 UTC, H. S. Teoh wrote:
On Tue, Sep 01, 2015 at 06:14:05PM +, deadalnix via
Digitalmars-d wrote:
A ton of code is not unitestable. GUI as a starter. Random
number generator. Very rare events handling outside the
control of the program. Concurent code
On 09/04/2015 12:54 PM, deadalnix wrote:
On Friday, 4 September 2015 at 16:26:15 UTC, Andrei Alexandrescu wrote:
On 09/02/2015 05:07 PM, deadalnix wrote:
On Wednesday, 2 September 2015 at 09:28:49 UTC, Dominikus Dittes Scherkl
wrote:
It is not unitestable.
But we have concepts like "thread lo
On Friday, 4 September 2015 at 16:26:15 UTC, Andrei Alexandrescu
wrote:
On 09/02/2015 05:07 PM, deadalnix wrote:
On Wednesday, 2 September 2015 at 09:28:49 UTC, Dominikus
Dittes Scherkl
wrote:
It is not unitestable.
But we have concepts like "thread local per default" and
message
passing tha
On 09/02/2015 05:07 PM, deadalnix wrote:
On Wednesday, 2 September 2015 at 09:28:49 UTC, Dominikus Dittes Scherkl
wrote:
It is not unitestable.
But we have concepts like "thread local per default" and message
passing that should make avoiding race conditions easier. And
concurrent code doesn't
On Wednesday, 2 September 2015 at 09:28:49 UTC, Dominikus Dittes
Scherkl wrote:
It is not unitestable.
But we have concepts like "thread local per default" and
message passing that should make avoiding race conditions
easier. And concurrent code doesn't prevent us from testing all
paths of tem
e for devirtualization and the solution
does not cover it. That is a problem.
Can you expand on this problem a bit more please? I know about
issue of not knowing if some method is eventually overridden
but that seems to be fixed with export within single
compilation step (i.e. small static li
What I meant is, of course you cannot test everything with
unittest. It has a reason that there exist other types of test.
But that should not hold anybody back from unit-testing as much
as possible. If nothing else this is useful because unit-tests
are by far the cheapest tests. And within a l
least you can unittest all paths in a template so that
every called function occures in at least one test - this is all
what is needed for the proposed change of "export", or am I wrong
here?
Change the text on a button, the test is broken.
A test for some concrete button?
I wou
is a problem.
Can you expand on this problem a bit more please? I know about
issue of not knowing if some method is eventually overridden but
that seems to be fixed with export within single compilation step
(i.e. small static library). Do you mean something different?
First I'd like to
On Tuesday, 1 September 2015 at 18:25:06 UTC, H. S. Teoh wrote:
That would explain why GUI apps tend to be buggy and
unreliable, and RNGs tend to have unintended biases.
No, actually, GUIs should be written to be testable (e.g.,
input should be abstracted via dependency injection so that GUI
to release stuff that mostly works but falls apart in the
> >corner cases.
> >
> >So, if there's a feature that can be added which solves the export
> >problems that dicebot is talking about here, but it requires that you
> >unit test your code for it to catch everything
d of error
when export within template code calls non export code. That most
likely needs to be an error. The error would show up with descent
test coverage even without the special feature.
f the implications:
1) You force people to write unittest. If people don't write
a export unittest block their templates won't work across
shared library boundaries.
Not writing unittests is a bad idea anyway.
Much more so if you want to ship your code as library!
2) A template
don't write a
export unittest block their templates won't work across shared
library boundaries.
Not writing unittests is a bad idea anyway.
Much more so if you want to ship your code as library!
2) A template in D might get __very__ complex. To make sure
that each and every fun
On Tuesday, 1 September 2015 at 12:55:11 UTC, Benjamin Thaut
wrote:
While your proposal sounds interresting to start with I don't
like some of the implications:
1) You force people to write unittest. If people don't write a
export unittest block their templates won't wor
On Tuesday, 1 September 2015 at 12:55:11 UTC, Benjamin Thaut
wrote:
While your proposal sounds interresting to start with I don't
like some of the implications:
1) You force people to write unittest. If people don't write a
export unittest block their templates won't wor
On Sunday, 30 August 2015 at 14:08:15 UTC, Dicebot wrote:
Follow-up to old
http://forum.dlang.org/thread/m9lhc3$1r1v$1...@digitalmars.com
thread by Benjamin
Short reminder of the issue:
Currently unsolved issue with finishing `export` implementation
is lack of convenient semantics for its
the NG which is actually interested to solve the problems around
export, other people seam to simply ignore them or want to abuse
export for other language issues.
Keep up the good work ;-)
Kind Regards
Benjamin Thaut
On Tuesday, 1 September 2015 at 01:40:29 UTC, deadalnix wrote:
Problem arise with templates, for instance:
export void foo(T)(T t) { bar(); }
private void bar() { import std.stdio; writeln("bar was
called"); }
Here bar is called. Problem is, foo can be instantiated in a
differ
On Sunday, 30 August 2015 at 14:08:15 UTC, Dicebot wrote:
Follow-up to old
http://forum.dlang.org/thread/m9lhc3$1r1v$1...@digitalmars.com
thread by Benjamin
Short reminder of the issue:
Currently unsolved issue with finishing `export` implementation
is lack of convenient semantics for its
Follow-up to old
http://forum.dlang.org/thread/m9lhc3$1r1v$1...@digitalmars.com
thread by Benjamin
Short reminder of the issue:
Currently unsolved issue with finishing `export` implementation
is lack of convenient semantics for its interaction with
templates. If template function is marked
On Tuesday, 24 June 2014 at 09:34:44 UTC, seany wrote:
and could I as well write
class C2{
auto x
this(T)(T y)
{
this.x = y;
}
}
This would help me, for example, to use a single definition, to
cover, e.g. int and double, and not write them twice - as in
usual overload...
class C2(T)
On Tuesday, 24 June 2014 at 09:31:08 UTC, seany wrote:
I recon, that D has the keyword "export", with which symbols
can be accessed accross different applications.
It declares symbols from dynamic library.
Am 24.06.2014 11:34, schrieb seany:> Also, while we are at it,
>
> does d support declarations like:
>
> class C {
>
> public :
>
> int a;
> string b;
> double c;
>
> }
read the manual first http://dlang.org/class
> and could I as well write
>
> class C2{
>
> auto x
>
> this(T)(T y)
> {
> t
Thnak you, and what about the Export keywords?
seany:
does d support declarations like:
class C {
public :
int a;
string b;
double c;
}
Yes, that's possible.
and could I as well write
class C2{
auto x
this(T)(T y)
{
this.x = y;
}
}
This is not possible, and I see no plans in supporting that. You
have to use some workaround
to files, that I
access with openFoam.
I recon, that D has the keyword "export", with which symbols can
be accessed accross different applications. But, I dont get much
info on it.
I could, for example write a D gateway to openFoam - and channel
the output of the first D prog
Also, while we are at it,
does d support declarations like:
class C {
public :
int a;
string b;
double c;
}
etc? If not, could this be implemented in a future version? i.e.
are there ideas to do so? that would have been nice.
and could I as well write
class C2{
auto x
this(T)(T y)
{
On 12/19/13, Adam D. Ruppe wrote:
> Is there a way to skip writing the exports section and using a
> .def file when doing a DLL on Windows now?
>
> And if not, will/can DIP45 allow that?
Not sure if you mean avoiding using the EXPORTS section in a .def
file, or if you want to avoid
On 12/19/2013 09:55 PM, Adam D. Ruppe wrote:
Is there a way to skip writing the exports section and using a .def file
when doing a DLL on Windows now?
And if not, will/can DIP45 allow that?
I'm no Windows expert but I think you can always export symbols using a
.def file. It'
Is there a way to skip writing the exports section and using a
.def file when doing a DLL on Windows now?
And if not, will/can DIP45 allow that?
On 8/25/13, Jacob Carlborg wrote:
>> Also look at the confusing extern keyword semantics:
>> http://dlang.org/declaration.html#extern
>
> What's confusing about the extern keyword?
`extern` => storage class, `extern(NAME)` => linkage attribute. Using
the same keyword for two things is confusing.
Am 25.08.2013 15:51, schrieb Jacob Carlborg:
On 2013-08-25 14:17, Benjamin Thaut wrote:
export __gshared int bar; // this treated as import
I would have guessed that required extern as well to be import.
But as D does not have a Preprocessor and version statements can not be
used to
On 2013-08-25 15:18, Andrej Mitrovic wrote:
Also look at the confusing extern keyword semantics:
http://dlang.org/declaration.html#extern
What's confusing about the extern keyword?
--
/Jacob Carlborg
On 2013-08-25 14:17, Benjamin Thaut wrote:
export __gshared int bar; // this treated as import
I would have guessed that required extern as well to be import.
--
/Jacob Carlborg
On 8/25/13, Benjamin Thaut wrote:
> This makes using the export keyword very cumbersome as you always have
> to pay attention to initialize variables so they actually get treated as
> export.
Yeah I dislike this behavior as well, I think it might have been
carried over from C/C++ (?).
The logic behind the export keyword seems to be flawed. As explained in
this ticket:
http://d.puremagic.com/issues/show_bug.cgi?id=9816
For declarations export means __declspec(dllimport) and for definitions
__declspec(dllexport).
export void foo(); // this treated as import
export void
link.c, the function OPENSSL_Uplink
calls GetProcAddress on the application with the string
"OPENSSL_Applink".
So far I've tried
Writing a D version of applink.c: I can't get dmd to export my
OPENSSL_Applink without a leading underscore.
and
Recompiling OpenSSL without -DOPENSSL_ENAB
tion with the string "OPENSSL_Applink".
So far I've tried
Writing a D version of applink.c: I can't get dmd to export my
OPENSSL_Applink without a leading underscore.
and
Recompiling OpenSSL without -DOPENSSL_ENABLE_APPLINK: Converting
libraries to OMF gives me a series of
be builded successfully
void main()
{
foreach(cur; __traits(getOverloads, Foo, "bar"))
{
void* p = &cur;
writeln(cur); //prints a function pointer.
}
}
If I change protection of bar to export I've got a error:
struct Foo
{
export int bar() const {return
er.
}
}
If I change protection of bar to export I've got a error:
struct Foo
{
export int bar() const {return 0;}
export int bar() immutable {return 1;}
}
void main()
{
foreach(cur; __traits(getOverloads, Foo, "bar"))
{
void* p = &cur; //Er
On 2/15/13, Andrey wrote:
> // pascal model is the same that stdcall
> export extern(Pascal) // full analog of STDCALL
No it's not, pascal parameters are pushed left-to-right, stdcall does
it the other way around. Try using extern(Windows) here and see if
that works.
See http://en.wi
true );
break;
default:
break;
}
return true;
}
}
mydll.d code here:
module mydll;
import std.stdio;
import ;
// pascal model is the same that stdcall
export extern(Pascal) // full a
On Tue, 16 Oct 2012 23:43:52 +0200
Piotr Szturmaj wrote:
> We have:
>
> ImportExpression:
> import ( AssignExpression )
>
> Why not also add this:
>
> ExportStatement:
> export ( AssignExpression, AssignExpression )
>
> Both of the AssignExpressions
We have:
ImportExpression:
import ( AssignExpression )
Why not also add this:
ExportStatement:
export ( AssignExpression, AssignExpression )
Both of the AssignExpressions must evaluate at compile time to a
constant string. The text contents of the first string are interpreted
as a
On Friday, 27 April 2012 at 15:04:48 UTC, Matt Peterson wrote:
On Friday, 27 April 2012 at 13:02:56 UTC, 拖狗散步 wrote:
On Friday, 27 April 2012 at 01:21:56 UTC, Trass3r wrote:
export c callback fun:
alias void function(int id) ConnectedCallBack;
alias void function(int id, void* data, int len
On Friday, 27 April 2012 at 13:02:56 UTC, 拖狗散步 wrote:
On Friday, 27 April 2012 at 01:21:56 UTC, Trass3r wrote:
export c callback fun:
alias void function(int id) ConnectedCallBack;
alias void function(int id, void* data, int len) ReadCallBack;
add extern(C) to be safe
Thank, Trass3r
On Friday, 27 April 2012 at 01:21:56 UTC, Trass3r wrote:
export c callback fun:
alias void function(int id) ConnectedCallBack;
alias void function(int id, void* data, int len) ReadCallBack;
add extern(C) to be safe
Thank, Trass3r! Finally correct, why have to export these two?
export c callback fun:
alias void function(int id) ConnectedCallBack;
alias void function(int id, void* data, int len) ReadCallBack;
add extern(C) to be safe
On 4/26/12, "拖狗散步" wrote:
> export c callback fun:
>
> alias void function(int id) ConnectedCallBack;
> alias void function(int id, void* data, int len) ReadCallBack;
Those are D function pointers. Try this:
alias extern(C) void function(int id) ConnectedCallBack;
alias e
O God, no one answered...
export c callback fun:
alias void function(int id) ConnectedCallBack;
alias void function(int id, void* data, int len) ReadCallBack;
export extern (C) void AddListenersss( ConnectedCallBack
connectedCallBack=null, ReadCallBack readCallBack=null )
{
int id = 0;
int len = 0;
version
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 : « Export means that any code outside the
executable can access the member. Export is
analogous to exporting
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
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.
>> 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'?
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
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 Dav
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 t
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
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
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
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
wrote:
On Wednesday
On 11 April 2012 13:50, Jonathan M Davis 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
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
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
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 everythi
, 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
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
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
> win
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
On Tue, 31 Jan 2012 18:15:51 -0800, Martin Nowak wrote:
On Tue, 31 Jan 2012 20:49:33 +0100, Adam Wilson
wrote:
On Sun, 29 Jan 2012 04:43:58 -0800, Trass3r wrote:
export on a function declaration means dllimport for exactly that
purpose (.di files).
It's not mentioned at the attri
On 1/31/12 5:05 PM, Adam Wilson wrote:
On Tue, 31 Jan 2012 14:53:17 -0800, Andrei Alexandrescu
wrote:
On 1/31/12 11:49 AM, Adam Wilson wrote:
On Sun, 29 Jan 2012 04:43:58 -0800, Trass3r wrote:
export on a function declaration means dllimport for exactly that
purpose (.di files).
It'
On Tue, 31 Jan 2012 14:53:17 -0800, Andrei Alexandrescu
wrote:
On 1/31/12 11:49 AM, Adam Wilson wrote:
On Sun, 29 Jan 2012 04:43:58 -0800, Trass3r wrote:
export on a function declaration means dllimport for exactly that
purpose (.di files).
It's not mentioned at the attributes doc
On Tue, 31 Jan 2012 20:49:33 +0100, Adam Wilson wrote:
On Sun, 29 Jan 2012 04:43:58 -0800, Trass3r wrote:
export on a function declaration means dllimport for exactly that
purpose (.di files).
It's not mentioned at the attributes doc site but I'm sure I read it
somewhere else
1 - 100 of 143 matches
Mail list logo
