2011-09-02 62 views
1

我正在尝试const_string lib看起来不错,但它在运行时崩溃了访问冲突(atomic_count,operator ++())。测试代码:const_string lib问题

#include <boost/const_string/const_string.hpp> 
#include <boost/const_string/concatenation.hpp> 

typedef boost::const_string<wchar_t> wcstring; 

class Test 
{ 
private: 
    const wcstring &s1; 
    const wcstring &s2; 

public: 
    Test() 
     : s1(L"") 
     , s2(L"") 
    { 
    } 

    const wcstring &GetS1() 
    { 
     return s1; 
    } 

    const wcstring &GetS2() 
    { 
     return s2; 
    } 
}; 


Test t; 

int _tmain(int argc, _TCHAR* argv[]) 
{ 
    //Test t; 
    wcstring t1 = t.GetS1(); // crashes here 
    wcstring t2 = t.GetS2(); 

    return 0; 
} 

只有t是全局的,它才会崩溃。如果我将声明移到main()中,那没关系。 System:VS 2010,boost v。1.47.0

问题:我做错了什么,或者它是库/编译器的问题吗? 有人可以推荐一个更稳定的C++不可变字符串实现吗?

回答

6

你的Test实例已初始化其参考数据成员从文字L""创建的临时引用。

糟糕。在您尝试在崩溃的行的​​的复制构造函数中使用其中一个时,临时对象不再存在,因此您的引用不会引用任何内容。

我认为boost::const_string几乎总是被价值使用,这就是它的目的。

+0

我不得不承认在这一个无知 - const' ref *可以*绑定到一个临时的,从而延长其在当前范围内的生命周期。这里的范围是什么?构造函数?如果是这种情况,'const' ref将表现得像一个正常的参考。规则是什么? (这是否值得一个新的问题?) –

+0

@Konrad:是的,它是构造函数的主体。 12.2/5,“在构造函数的ctor-initializer(12.6.2)中临时绑定到引用成员,直到构造函数退出”。这确实会使const引用数据成员稍微有点危险,我不能直接想到在任何情况下你想要一个在构造函数中使用的数据成员,而在其他地方,所以不小心使用临时对它们进行初始化几乎可以保证某些不好的事情将在未定的晚些时候发生。 –

+0

谢谢史蒂夫,我现在看到了这个问题。 – G0r