Re: [boost] Environment Variables Library?

Subject: Re: [boost] Environment Variables Library?
From: Klaim - Joël Lamotte (mjklaim_at_[hidden])
Date: 2015-05-19 07:42:01

On Tue, May 19, 2015 at 12:54 PM, Paul A. Bristow <pbristow_at_[hidden]>
wrote:

>
>
> > -----Original Message-----
> > From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Michael
> Ainsworth
> > Sent: 19 May 2015 10:51
> > To: boost_at_[hidden]
> > Subject: Re: [boost] Environment Variables Library?
> >
> > > On 19 May 2015, at 7:18 pm, Klaim - Joël Lamotte <mjklaim_at_[hidden]>
> wrote:
> >
> > >
> > > I'm not sure for other devs but my personal guideline so far is:
> > >
> > > 1. Don't use the register except if you must (mostly because of
> > > requirements from the kind of application you are making).
> > > 2. Don't use environment variables except if you must (mostly for dev
> > > tools helping locating each other).
> > > 3. Prefer user-specific or shared directories to put config data in
> > > (config files or databases).
> > >
> > > The reasons for the first two are mainly to avoid issues like
> "pollution"
> > > of the system with montains of unuseful data (in particular with
> > > computers used by non-developers).
> > > Part of the source of the issue is the lack of common good
> > > uninstallation system, part of it is just historical scars itching
> > > (from windows98/me era).
> > >
> > > There is also the cross-platform code issue: if you want to provide
> > > data to the whole system in a cross-platform way, the environment
> > > variables is the only way to do so, because there is no register on
> > > non-windows platforms (that I know of).
> > >
> > > The environment variables in windows have a limited size which is
> > > small enough to be hit very quickly if you abuse it.
> > > For example the famous PATH can be filled with paths to tools like
> > > git,hg,svn, python, ruby, your favorite C++ compilers and hit the
> > > point where you can't add anything anymore. Of course, this can be
> > > worked aroudn but it's still an annoying limitation.
> > >
> > > Finally there is the "it's a public global state" issue, which I kind
> > > of like public global non-const variables in a program.
> > > It's just problematic.
> > >
> > > I'm not a specialist of the windows specifics so any of my assumptions
> > > might be wrong.
> >
> > Your comparison of environment variables in an operating system to
> global non-const variables in a
> > software library is a good one - it's usage appears contrary to
> encapsulation principles. I can think of two
> > generalised uses of environment variables:
> >
> > 1. It provides users with the ability to pass configuration information
> to a process, such the $CXX variable
> > used in Makefiles, or $GIT_DIR for Git.
> > 2. It provides processes with the ability to communicate with other
> processes (a rudimentary form of inter
> > process communication), such as an HTTP server implementing the CGI
> specification, or SVN executing
> > $EDITOR for commit messages.
> >
> > It'd be nice for an alternative that provides a cleaner implementation
> with less "global namespace
> > pollution", but regardless, it appears that in the current situation:
> >
> > 1. Windows does not use environmental variables as much as POSIX, but
> still does use them.
> > 2. There is not great support for environmental variables in the curren
> C++ standard.
> > 3. Therefore, there is a need for such a library.
> >
> > Would you agree with the above from your background and experience?
>
> Yes.
>
> Bad in theory, useful in practice.
>
>
Exactly.

> Paul
>
> ---
> Paul A. Bristow
> Prizet Farmhouse
> Kendal UK LA8 8AB
> [phone]
>
>
>
>
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>