D2 port of Sociomantic CDGC available for early experiments
Regan Heath via Digitalmars-d-announce
digitalmars-d-announce at puremagic.com
Fri Oct 17 02:55:01 PDT 2014
On Fri, 17 Oct 2014 00:01:39 +0100, Leandro Lucarella <luca at 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/
More information about the Digitalmars-d-announce
mailing list