D2 port of Sociomantic CDGC available for early experiments

[Regan Heath via Digitalmars-d-announce]

On Mon, 20 Oct 2014 18:19:33 +0100, Sean Kelly <sean at invisibleduck.org>  
wrote:

> On Monday, 20 October 2014 at 10:39:28 UTC, Regan Heath wrote:
>>
>> Sure, but past/current env vars being used are used *privately* to a  
>> single program.  What you're suggesting here are env vars which will  
>> affect *all* D programs that see them.  If D takes over the world as we  
>> all hope it will then this will be a significantly different situation  
>> to what you are used to.
>
> I'm not advocating the approach, but you could create a "run_d"
> app that simply set the relevant environment args and then
> executed the specified app as a child process.  The args would be
> picked up by the app without touching the system environment.
> This would work on Windows as well as on *nix.

Sure, but in this case passing an argument is both simpler and clearer  
(intent).

This is basically trying to shoehorn something in where it was never  
intended to be used, envvars by design are supposed to affect everything  
running in the environment and they're the wrong tool for the job if you  
want to target specific processes, which IMO is a requirement we have.

A specific example.  Imagine we have the equivalent of the windows CRT  
debug malloc feature bits, i.e. never free or track all allocations etc.   
These features are very useful, but they are costly.  Turning them on for  
an entire process tree may be unworkable - it may be too slow or consume  
too much memory.  A more targeted approach is required.

There are plenty of options, but a global envvar is not one of them.

R

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