Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
+14
template<typename U>
shared_ptr(const shared_ptr<U> & ptr) throw()
: m_value(0)
, m_ref_count(0)
{
m_value = static_cast<T *>(ptr.get());
if(m_value)
{
m_ref_count = reinterpret_cast<const shared_ptr &>(ptr).m_ref_count;
++*m_ref_count;
}
}Выражаясь метафорично, я работаю на велосипедном заводе.
Запостил: 
Xom94ok,
09 Июня 2013
Follow us!
в бусте/стд этот самый ref count потокобезопасный
надеюсь, ++*m_ref_count об этом курсе
чем вызвано такое старообрядчество? работает на 2003 - отойди и не трожь?
Вроде того. Коллеги пишут на подмножестве плюсов "си с классами", вылавливая по полдня причины Access Violation и утечек памяти. Да чего уж там, даже попытка внедрить использование vector вместо массивов на malloc/realloc провалилась :)
Однопоточный атомик без поддержки многопоточности.
std::tr1::shared_ptr в такой древней студии ещё нет...
Тарас, ты не одинок.
Разве что полное мудачество с моей стороны - это смириться с отсутствием встроенного в 2003 <array>, не написать свой и использовать сырые массивы. Несколько раз наступал на грабли.
Meanwhile in 2011:
Ещё, кстати, Safe STL есть.
Я могу понять, зачем может понадобитсья оператор, делающий проверки в релизе, ну мало ли там парноидальный случай, но ёпт, нахуя вообще нужен оператор, не проверяющий в дебаге? Мне эти крестоблядские тонкости не понять, наверное.
да и в релизе всякая хуита от микрософта _SCL_SECURE_* тоже может присутствовать
просто может конкретно в 2003 этого нет
Только после моих правок в исходниках СТЛ
Чтобы я что-то специально выключал, не помню, что изначально было, то и поставил, только исключения отрубил, кстати тоже ради их отсутствия пришлось дохрена в исходниках СТЛ править, и всё равно одно предупреждение вылазит, которое лечится только директивой "не выдавать предупреждение номер не помню".
а про сишку до сих пор актуально