Re: [Boost-users] [Filesystem] Crashes with global const path

From: Hughes, James (jhughes_at_[hidden])
Date: 2008-01-29 10:07:31

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_at_[hidden]
[mailto:boost-users-bounces_at_[hidden]] On Behalf Of Gustavo Scotti
        Sent: 28 January 2008 16:53
        To: boost-users_at_[hidden]
        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 <boost/filesystem/path.hhp>
                
                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_at_[hidden]
                http://lists.boost.org/mailman/listinfo.cgi/boost-users
                

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.