Здравствуйте, abrec, Вы писали:
A>Здравствуйте, AlexCrush, Вы писали:
AC>>С dynamic_cast-ом попутали? A>Да косячок
Не нужен там dynamic_cast. Иногда бывает полезным такой трюк:
template <typename derived>
class base
{
public:
// something...protected:
inline derived * self() { return static_cast<derived*>(this); }
};
Если параметром шаблона base всегда будет наследуемый от него класс ничего страшного не случится. главное функцией этой (self) в конструкторах и деструкторах не пользоваться
Здравствуйте, abrec, Вы писали:
A>Здравствуйте!
A>Может кто ткнет носом?
A> friend std::istream& operator >> (std::istream& s, CStreamNumberTypeImpl< TNumberHandler, T >& clLongTypeStream)
A>s >> CStreamSizeT( &size, true ); //-->тут дает ошибку при компиляции под gcc в msvc все ок
Здравствуйте, abrec, Вы писали:
A>Здравствуйте!
A>Может кто ткнет носом?
нельзя передавать временный объект (CStreamSizeT) по неконстантной ссылке (operator >> (std::istream& s, CStreamNumberTypeImpl< TNumberHandler, T >& clLongTypeStream) ).
В студии работает, т.к. у них это разрешено. Но это не по стандарту.
В вашем случае, по-моему, проще всего добавить const к вышеозначенному параметру, а так же к методу FromStream.
XuMuK:
XMK>временные объекты в гцц константны, поэтому operator >>, ожидающий неконстантную ссылку не может быть вызван.
Константность объекта и принадлежность выражения к rvalue — это две совершенно разные вещи. В данном случае объект неконстантный и на корректность инициализации ссылки влияет именно принадлежность инициализирующего выражения к rvalue. С lvalue-выражением такого же типа подобной проблемы бы не возникло — даже если бы оно обозначало временный объект.
Здравствуйте, abrec, Вы писали:
A>странность только в этом?
Еще, если T будет не простым целочисленным типом, то сохранение через reinterpret_cast<char*>, sizeof(T)- опасно. А вдруг, там, в классе T, были указатели? Или stl контейнеры?
Или же это невозможно, by-design? Тогда наверное можно сильно уменьшить количество кода.
Здравствуйте, AlexCrush, Вы писали:
AC>Еще, если T будет не простым целочисленным типом
простым AC>by-design? Тогда наверное можно сильно уменьшить количество кода. AC>Тогда наверное можно сильно уменьшить количество кода.
Буду признателен
На самом деле, почему бы temporary не-pod типов не быть lvalue — не очень понятно. Вероятно, авторы руководствовались той логикой, что какой смысл что-то изменять во временном объекте — он все равно сдохнет, но совершенно забыли о тоннах объектов с побочными эффектами. Простейший пример (хотя и не нужный в реальной жизни):
class AnyType {
...
AnyType (int i) {...}
AnyType operator++(int ) {...}
};
void dump_and_incr (AnyType& val) {
cout << val;
val++;
}
int i = 10;
dump_and_incr(i);