On 10/08/2014 10:41 PM, Walter Bright wrote:
On 10/8/2014 6:25 PM, John wrote:
I wish you had some lighting on you. You are hardly visible!
It's to hide the scars where my head was sewed back on.
Getting the brain out was the easy part. The hard part was getting the
brain out! - Hubert
On 08/10/14 22:47, Rainer Schuetze wrote:
C main is no longer under user control, because it is auto-generated
with D main. I never liked that change, we've just discovered another
reason.
All platforms have API's to access the command line arguments passed to
main. On OS X that would be
On 09.10.2014 08:29, Jacob Carlborg wrote:
On 08/10/14 22:47, Rainer Schuetze wrote:
C main is no longer under user control, because it is auto-generated
with D main. I never liked that change, we've just discovered another
reason.
All platforms have API's to access the command line
On 10/8/2014 11:43 PM, Rainer Schuetze wrote:
Yes, but the problem is not to access command line arguments, but to run code
before the GC initialization i.e. before _d_run_main is executed.
If we can assume a C++ backend, using static initialization of a C++ global
could work:
static bool
On 09/10/14 08:43, Rainer Schuetze wrote:
Yes, but the problem is not to access command line arguments, but to run
code before the GC initialization i.e. before _d_run_main is executed.
If we can assume a C++ backend, using static initialization of a C++
global could work:
static bool
On Wednesday, 8 October 2014 at 17:39:46 UTC, Walter Bright wrote:
On 10/8/2014 12:43 AM, Leandro Lucarella wrote:
I think this is an unjustified fear, there are already many
environment
variables that can affect your program. That's why they are
called...
environment variables :)
Being on
On Thursday, 9 October 2014 at 14:20:07 UTC, Sean Kelly wrote:
Back when Druntime was called Ares, it was possible to choose
the GC at link time. Do we really need to defer the decision
to run time? If so, switching GCs after the app has started
should work in most cases, though I'm not sure
On 09.10.2014 10:18, Walter Bright wrote:
On 10/8/2014 11:43 PM, Rainer Schuetze wrote:
Yes, but the problem is not to access command line arguments, but to
run code
before the GC initialization i.e. before _d_run_main is executed.
If we can assume a C++ backend, using static initialization
On 09.10.2014 15:31, Jacob Carlborg wrote:
On 09/10/14 08:43, Rainer Schuetze wrote:
Yes, but the problem is not to access command line arguments, but to run
code before the GC initialization i.e. before _d_run_main is executed.
If we can assume a C++ backend, using static initialization of
On Thursday, 9 October 2014 at 18:33:25 UTC, Rainer Schuetze
wrote:
This is a gcc extension, which isn't supported under Windows by
dmd. Can you add this attribute in GDC/LDC as part of a D file
aswell?
On 2014-10-09 20:33, Rainer Schuetze wrote:
This is a gcc extension, which isn't supported under Windows by dmd.
It seems to be possible in Visual Studio [1], but that still leaves OMF.
[1]
http://stackoverflow.com/questions/1113409/attribute-constructor-equivalent-in-vc
--
/Jacob
On 10/9/2014 7:25 AM, Dicebot wrote:
At the same time I don't see what real benefit such runtime options brings to
the table. This is why in my PR garbage collector is currently chosen during
compilation time.
Choosing at compile time is probably best.
On 10/9/2014 11:25 AM, Rainer Schuetze wrote:
Martin is very much against this, one reason is that it does not work with
druntime in a shared library.
I can understand that, but I also don't know what a reasonable use case would be
for sharing a library yet using different GC's - it sounds
13 matches
Mail list logo