On Fri, 17 Oct 2014 00:01:39 +0100, Leandro Lucarella <l...@llucax.com.ar> wrote:

Regan Heath, el 14 de October a las 11:11 me escribiste:
>I still don't understand why wouldn't we use environment variables for
>what they've been created for, it's foolish :-)

As mentioned this is not a very windows friendly/like solution.

As mentioned you don't have to use a unique cross-platform solution, you
can have different solutions for different OSs. No need to lower down to
the worse solution.

You've got it backwards. I'm looking for a *better* solution than environment variables, which are a truly horrid way to control runtime behaviour IMHO. Something built into the language or runtime itself. And, better yet would be something that is more generally useful - not limited to GC init etc.

Wouldn't it be more generally useful to have another function like
main() called init() which if present (optional) is called
before/during initialisation.  It would be passed the command line
arguments.  Then a program can chose to implement it, and can use it
to configure the GC in any manner it likes.

Seems like this could be generally useful in addition to solving
this issue.

It is nice, but a) a different issue, this doesn't provide
"initialization time" configuration.

I don't follow. You want to execute some code A before other code B occurs. This meets that requirement - assuming init() is called at the point you need it to be called.

Think of development vs. devops. If
devops needs to debug a problem they could potentially re-run the
application activating GC logging, or GC stomping. No need to recompile,
no need to even have access to the source code.

./application -gclog
./application -gcstomp

..code..

init(string[] args)
{
 if ..
}

Not need to recompile.

Some GC options might make sense for all D applications, in that case the compiler default init() could handle those and custom init() functions would simply call it, and handle any extra custom options.

Other GC/allocation options might be very application specific i.e. perhaps the application code cannot support RC for some reason, etc.

And b) where would this init() function live? You'll have to define it
always

Surely not.

, even if you don't want to customize anything, otherwise the
compiler will have to somehow figure out if one is provided or not and
if is not provided, generate a default one. Not a simple solution to
implement.

Sounds pretty trivial to me.

R

--
Using Opera's revolutionary email client: http://www.opera.com/mail/

Reply via email to