недавно обнаружил проблему (debian sid) с гццпп - он мне так подвешивает систему, что быстрее просто отправить в перезагрузку. решил воспользоватсья возможностью и перейти на clang

я для прототипа использую python3 и boost::python. кода импортируешь туда класс ,буст может импортировать его как boost::shared_ptr и управлять соответственно. я использую std::shaerd_ptr и вот код (это переделанный код из вики питона)

#include <string>
#include <memory>
#include <boost/python.hpp>

struct A {
        static std::shared_ptr<A> create () { ptr=std::shared_ptr<A>(new A); return ptr;}
        std::string   hello  () { return "Just nod if you can hear me!"; }
        ~A(){std::cout<<"dest"<<std::endl;}
        static std::shared_ptr<A> ptr;
};
std::shared_ptr<A> A::ptr;

using namespace boost::python;
BOOST_PYTHON_MODULE(sptr)
{
        class_<A, std::shared_ptr<A>>("A")
            .def("create",&A::create )
            .staticmethod("create")
            .def("hello",&A::hello)
       ;
}

в гцц усе работает. когда говоришь питону del a, где а - это переменная созданная из этого кода, объект не удаляется, он удаляется только при закрытии программы. если закоментировать ptr то объект удаляется сразу - что и требовалось доказать. но! кланг не может это скомпилить
что можно сделать чтобы заставить работать именного clang?

g++ --version 4.9.2-10
clang++ --version 3.5.0-9

не совсем понятно, почему GCC "подвешивает систему", но скорее всего он выжирает память. это бывает по двум причинам: использование гигантских статических массивов начинающими программистами или очень большие проекты. в любом случае, вопрос решается использованием ограничений на память через ulimit и увеличением размера свопа.

у тебя в классе объявлен статический элемент типа shared_ptr. и он действительно создастся при старте и удалится только после завершения программы, когда последняя ссылка (статическое объявление) будет закрыто.

немного не понял. например gcc не осилил скомпилить приведеннй код с этим примером. не знаю от чего это зависит. свопа хватает но я пробовал его совсем отключить, так что расчитывал, что процесс компилятора просто изсчезнет. но все одинаково. виснет и c подкачкой и без
вот я как раз об этом. то есть есе работает как я хотел, если удается скомпилить c gcc. может там какие-то настройки не так стоят, что он думает, что компилится не на c++11 ? можно в бусте поставить какой-нибудь макрос руками, чтобы указать, что это именно c++11?

что-то у тебя неправильно установлено или проблемы с железом. компилятор может ругаться, но завешивать систему на таком примитиве он не может.

я не отслеживала самые последние изменения, но, по крайней мере, до версии 1.55.0 C++11 в бусте не использовался явно. главным образом потому, что буст сам по себе прототип стандартизации С++ и когда что-то становится стандартом, то буст пересматривается. а ещё потому, что С++11 с полным набором всех фич до сих пор не существует в некоторых компиляторах, которые буст поддерживает.

в последних версиях GCC (начиная с 4.7) для С++11 есть опция -std=c++11 (или -std=c++0x, начиная с GCC 4.3, но в старых версиях может быть далеко не полная поддержка фич C++11).