[Filesystem] Crashes with global const path

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

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
const boost::path test = "/usr/bin/whatever";
main() { //something }
This crashes prior to getting to main, obviously whilst the path is being set up during initialisation.
Is this a known problem? Is there a way round it? Have we misunderstood something important?
Path works fine elsewhere, its only when some sort of initialisation code is called that it goes pear shaped.
James
This message (including any attachments) contains confidential and/or proprietary information intended only for the addressee. Any unauthorized disclosure, copying, distribution or reliance on the contents of this information is strictly prohibited and may constitute a violation of law. If you are not the intended recipient, please notify the sender immediately by responding to this e-mail, and delete the message from your system. If you have any questions about this e-mail please notify the sender immediately. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

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
participants (2)
-
Gustavo Scotti
-
Hughes, James