Я думаю UB более вероятно :)
На моих clang 3.2-7 и gcc 4.8.1 я воспроизвести не могу. Но по вашей ссылке видно, что выход происходит в строке 72
assert ( deleter ); // TypeUnion::assign was not called
Т.е. каким то образом deleter == nullptr. Попробую найти GCC 4.9.0 и отдебажить.
Еще чуть выше мне подсказали о возможных проблемах с выравниванием. Может как то с этим связано. Короче, надо будет разобраться.
У меня тоже компилируется. Я использую clang 3.2-7 и gcc 4.8.1. Ваш пример с Variant я посмотрю. Пока просто не успел. Обязательно разберусь с этим подходом.
Потому что это не «фабрика», а «фабричный метод». Собственно переделать всю конструкцию в фабрику по общему принципу тоже можно. Просто на примере фабричного метода проще проиллюстрировать подход.
Деструктор явно вызывать не нужно, т.к.стековые объекты существуют лишь в границах содержащего их блока. Собственно с классическим фабричным методом тоже самое, если он возвращает не сырой указатель, а, как положено, unique_ptr.
Что касается применения, то оно ни чем не отличается от применения обычного фабричного метода с динамическим размещением. См. первый попавшийся пример из гугла
В этом случае как раз и получится то, что у меня представлено во втором варианте. Дело в том, что 1) доступ к членам union осуществляется по их именам, а не типам, и 2) мы не сможем создать объект такого объединения, если он будет содержать более одного не POD типа с нетривиальным конструктором. Попробуйте сами.
Спасибо за интересные ссылки.
По поводу выравнивания. Так ведь sizeof возвращает размер с учетом выравнивания. Так что не вижу с этим проблемы. Или какой то еще подвох здесь есть?
На счет std::aligned_union согласен, вместо unsigned char mem[usize] лучше использовать его.
Тоже присматриваюсь к этому фреймворку. Интересно было бы «пощупать» его в работе.
Автор, вы пробовали что-нибудь на нем делать? Поделитесь своими впечатлениями.
В чем подвох тогда? Функционал интересный. Можно подумать как это прикрутить к своему проекту. Но перед тем как использовать хотелось бы оценить стоимость.
Вам же как-то надо элементарно окупать нагрузку на сервер. Если бы это было open source решение, то понятно. А а так легко попасть на vendor lock.
А я благодарен ТМ за то что они позаботились о моем времени и перенесли все оффтопиковые хабы на отдельный ресурс.
Теперь Хабр почти как раньше. Т.е. про IT, а не про космос и гаджеты. Хабр не невеста, всем угодить невозможно, но лично мне это нововведение очень нравится.
На самом деле сильно просела экономика в 14-м году. Я на себе ощутил это очень прилично. Все мои знакомые, занимающиеся бизнесом, отмечают этот факт.
Яндекс и Mail.ru — компании зарабатывающие на продаже рекламы. А рекламный рынок всегда проседает в первую очередь при деградации экономики. В 2008-2009 этот эффект был не так заметен (наоборот был рост интернет рекламы) из-за перераспределения рекламных бюджетов и не насыщенности рынка интернет рекламы. Сейчас ситуация другая.
В вашем случае shared_ptr «не знает» размер массива, поэтому он никак не сможет вызвать деструкторы.
При создании shared_ptr можно указать свой deliter либо в C++11 есть контейнер std::array. Он здесь подошел бы идеально.
Не уверен, но, вроде бы, только unique_ptr умеет вызывать delete[] для массивов. shared_ptr тоже?
На первый взгляд выглядит весьма не плохо. Если развивать, мне кажется, может получиться очень даже круто. Со временем можно запилить приложение для планшетов/смартфонов сможете заработать.
Обязательно почитаю вашего Хоббита на досуге.
На моих clang 3.2-7 и gcc 4.8.1 я воспроизвести не могу. Но по вашей ссылке видно, что выход происходит в строке 72 Т.е. каким то образом
deleter == nullptr. Попробую найти GCC 4.9.0 и отдебажить.Еще чуть выше мне подсказали о возможных проблемах с выравниванием. Может как то с этим связано. Короче, надо будет разобраться.
TypeUnion(TypeUnion &&) = defaultя поторопился. Еще одни грабли.Потому что это не «фабрика», а «фабричный метод». Собственно переделать всю конструкцию в фабрику по общему принципу тоже можно. Просто на примере фабричного метода проще проиллюстрировать подход.
Деструктор явно вызывать не нужно, т.к.стековые объекты существуют лишь в границах содержащего их блока. Собственно с классическим фабричным методом тоже самое, если он возвращает не сырой указатель, а, как положено, unique_ptr.
Что касается применения, то оно ни чем не отличается от применения обычного фабричного метода с динамическим размещением. См. первый попавшийся пример из гугла
По поводу выравнивания. Так ведь
sizeofвозвращает размер с учетом выравнивания. Так что не вижу с этим проблемы. Или какой то еще подвох здесь есть?На счет std::aligned_union согласен, вместо
unsigned char mem[usize]лучше использовать его.А чем вас смущает, что фреймворк от «от фейсбука»?
Автор, вы пробовали что-нибудь на нем делать? Поделитесь своими впечатлениями.
Вам же как-то надо элементарно окупать нагрузку на сервер. Если бы это было open source решение, то понятно. А а так легко попасть на vendor lock.
Теперь Хабр почти как раньше. Т.е. про IT, а не про космос и гаджеты. Хабр не невеста, всем угодить невозможно, но лично мне это нововведение очень нравится.
Яндекс и Mail.ru — компании зарабатывающие на продаже рекламы. А рекламный рынок всегда проседает в первую очередь при деградации экономики. В 2008-2009 этот эффект был не так заметен (наоборот был рост интернет рекламы) из-за перераспределения рекламных бюджетов и не насыщенности рынка интернет рекламы. Сейчас ситуация другая.
При создании shared_ptr можно указать свой deliter либо в C++11 есть контейнер std::array. Он здесь подошел бы идеально.
Не уверен, но, вроде бы, только unique_ptr умеет вызывать delete[] для массивов. shared_ptr тоже?
Обязательно почитаю вашего Хоббита на досуге.