Hi Gustavo,
I understand the reasons for not using global as you describe, but it's
even a problem, I believe, when defining static const values inside a
class, as they are also initialised at Cinit time - sort of makes a
mockery of data encapsulation - we had to resort to using std:string in
the end (or defines - urgh).
In our particular circumstance, a global header file with constant paths
of all the different places we store stuff in the filesystem was the
reason. In this particular case, we ended up with defines.
James
________________________________
From: boost-users-bounces@lists.boost.org
[mailto:boost-users-bounces@lists.boost.org] On Behalf Of Gustavo Scotti
Sent: 28 January 2008 16:53
To: boost-users@lists.boost.org
Subject: Re: [Boost-users] [Filesystem] Crashes with global
const path
James,
I don't know if that would help, but experience told me not to
use global objects. The reason is quite simple: compiler decides
creation order, putting its destructor on atexit. This falls out to
unexpected behavior related to interdependency between globals. You may
try:
const boost::path& get_test() {
static boost::path g_test( "/usr/bin/whatever" );
return g_test;
}
you can even:
#define test g_test()
to make your switch more "friendly".
Anyway, there's nothing wrong with globals. All that matters is
its creation/destruction order when dependency exist. But that's the
main reason globals exists, right?
You may try to look for some singleton design pattern
implementation. It may help you either. I thought I've seen it on boost.
Regards,
GS
On Jan 28, 2008, at 2:06 PM, Hughes, James wrote:
Hello all,
We have had problems with boost::path when used as a
const global
variable, using gcc on ARM Linux. Example code (typed in
the the email
so probably missing code, but this is the basic premise)
#include