Re: [boost] Environment Variables Library?

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

On Tue, May 19, 2015 at 11:51 AM, Michael Ainsworth <
michael_at_[hidden]> wrote:

> > 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, I agree.

> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>