Ничто не мешает variant<enum1, enum2, ...> где enum имеет underlying type int32_t быть структурой с одним int64_t

Ничто не мешает написать enum_variant

Ничто не мешает variant<enum1, enum2, ...> где enum имеет underlying type int32_t быть структурой с одним int64_t

Базовая реализация не знает ничего о расширениях.

Тем более, что частный случай variant под названием optional есть в стандарте

Базовая реализация не знает ничего о расширениях.

Это вопрос реализации, полагаю, там ничего не ограничивает её, кроме как мордой

Я вот не знаю, почему optional<T&> не определен как T*, а optional<std::vector> не хранится во внутреннем состоянии vector

Но это к комитету

Я вот не знаю, почему optional<T&> не определен как T*, а optional<std::vector> не хранится во внутреннем состоянии vector

Первое вполне реализуемо, просто наверное никто не использует optional<T&> как замену T*. А второе уже не так просто, инстанциирование аллокатора может иметь side effects например.

Это вопрос реализации, полагаю, там ничего не ограничивает её, кроме как мордой

Какая то базовая реализация http со стандартным набором статусов и пользовательское расширение. Естественно базовая реализация о расширении не знает, это её и ограничивает.

Первое вполне реализуемо, просто наверное никто не использует optional<T&> как замену T*. А второе уже не так просто, инстанциирование аллокатора может иметь side effects например.

Не знаю, что там инстанцируется, но у вектора три указателя, которые либо одновременно nullptr, либо нет

Т.е. его внутреннее состояние не полное

Не знаю, что там инстанцируется, но у вектора три указателя, которые либо одновременно nullptr, либо нет

Не только. Ещё где то зарыт аллокатор.

Не только. Ещё где то зарыт аллокатор.

- У машины четыре колеса - Не только, еще крыша!

Который кстати может не иметь default конструктора.

Это никак не связано с обсуждением

Вектор хранит три указателя

И эта тройка имеет не полное множество значений

Это значит, что его пополнение возможно через некорректное состояние

Мне не нужно для этого нарушать требование optional не вызывать конструктор

Я знаю, что если объект сконструирован, то вот тут лежит либо три нуля, либо три не нуля

Так что мне не нужно хранить дополнительный параметр для проверки, что объект сконструирован

Так. Чего то не понимаю. Предполагается в специализации для вектора в optional хранить сам вектор потому что у него есть "пустое" состояние?

Предлагается делать sizeof(optional<vector>) == sizeof(vector)

Это не одно и то же. Немножко json: "arr":null vs "arr":[]

Вы же понимаете, что я не собираюсь нарушать логику работы optional?

Я знаю, что если объект сконструирован, то вот тут лежит либо три нуля, либо три не нуля

^

Так что мне не нужно хранить дополнительный параметр для проверки, что объект сконструирован

^

А, использовать знание потрохов вектора чтобы хранить состояние невозможной комбинацией?

Именно

Через traits запилить impossible_instance? :)

optional_traits<T>::constuct_null(void*)

Ещё кстати на уровне библиотеки может неплохо бы приделать какие то enum_traits с sorted массивом пар <Enum, string_view>. Тогда можно было бы в runtime enum валидировать, to/from string всякие задешево.

Вектор хранит три указателя

Просвети, пожалуйста, что это за три указателя?

Просвети, пожалуйста, что это за три указателя?

begin, end, begin + capacity

begin, end, begin + capacity

А, ну да, логично) Ток я так понимаю это какая то конкретная реализация?

А, ну да, логично) Ток я так понимаю это какая то конкретная реализация?

Так и optional конкретная реализация, а через traits подобное поведение можно приделать кому угодно.

А, ну да, логично) Ток я так понимаю это какая то конкретная реализация?

Я так понимаю, это любая реализация

Например записать единичку в то место где должен быть указатель любой.

Там нет ни малейшего смысла делать не так

Только это уже будет не constexpr наверное.

Хотя bit_cast же :)

Я так понимаю, это любая реализация

Как насчёт https://github.com/lnishan/vector ?

Как насчёт https://github.com/lnishan/vector ?

new в default конструкторе? Ффууу. Ещё и для получения end что то складывать?

Как насчёт https://github.com/lnishan/vector ?

Учитывая, что sizeof(size_t) ну наверняка равен sizeof(ptrdiff_t), который ну наверняка равен sizeof(T*) автор упоролся

Какое это имеет отношение к утвержденимю "любая реализация хранит три указателя"?

Какое это имеет отношение к утвержденимю "любая реализация хранит три указателя"?

Ну я могу написать реализацию, храня четыре инта, я почти уверен, что любая реализация уровня std будет так делать

Как насчёт https://github.com/lnishan/vector ?

https://github.com/lnishan/vector/blob/master/vector.hpp#L451

дальше не читал

Для получения невалидного состояния достаточно одного указателя с ненулевым младшим битом например.

Ну я могу написать реализацию, храня четыре инта, я почти уверен, что любая реализация уровня std будет так делать

Я сейчас смотрю у себя на машине "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.14.26428\include\cliext\vector". Там тоже не указатели. Это недостаточно std-уровня реализация?

Я сейчас смотрю у себя на машине "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.14.26428\include\cliext\vector". Там тоже не указатели. Это недостаточно std-уровня реализация?

В реализации MSC ТОЧНО три указателя

Если вы пользовались MSC 7.1, то знали бы их имена

Например есть базовый ResultCode в какой то библиотеке и его расширение на application level.

std::errc

В реализации MSC ТОЧНО три указателя

Прошу проследовать по указанному пути, если установлена студия 2017.

Оно конечно cliext/vector, но речь изначально шла про то, что таких реализаций нет вообще.

Я сейчас смотрю у себя на машине "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.14.26428\include\cliext\vector". Там тоже не указатели. Это недостаточно std-уровня реализация?

тебя не напрягло что это C++/CLI ?

тебя не напрягло что это C++/CLI ?

Если бы исходное утверждение звучало как "любая реализация, кроме расширений CLI" - напрягло бы =)

CLI это вообще про другой язык программирования

и да, просьба в качестве примера реализации гениев, у которых крашится v.push_back(std::move(v[0])); не приводить)

и да, просьба в качестве примера реализации гениев, у которых крашится v.push_back(std::move(v[0])); не приводить)

ой, нахер так делать

ой, нахер так делать

нахрена делать это UB - спроси у автора https://github.com/lnishan/vector/blob/master/vector.hpp#L451

ой, сложна, ну нахер, пойду лучше спать

и да, просьба в качестве примера реализации гениев, у которых крашится v.push_back(std::move(v[0])); не приводить)

Не запускал. Кинул первую попавшуюся ссылку, соответствующую утверждению. Триггеред на излишне безапелляционное утверждение, короче.

ой, сложна, ну нахер, пойду лучше спать

ниче сложного, push_back(T&& val) должен в случае реаллокейта проверять std::addressof(val) на диапазон

Не запускал. Кинул первую попавшуюся ссылку, соответствующую утверждению. Триггеред на излишне безапелляционное утверждение, короче.

Ну вы приводите в качестве примера непрофессионала, а, как известно, сложно понять логику непрофессионала

Ну вы приводите в качестве примера непрофессионала, а, как известно, сложно понять логику непрофессионала

Не, ну если уж экономить, можно пару uint32 воткнуть, минус восемь байт.

Не, ну если уж экономить, можно пару uint32 воткнуть, минус восемь байт.

Это куда?

Собираетесь написать vector, который 2^32 на x64 не умеет?

Ради 8 байт?

ниче сложного, push_back(T&& val) должен в случае реаллокейта проверять std::addressof(val) на диапазон

И чем это поможет?

А почему бы и нет

Стандарт разрешает :)

И чем это поможет?

Там если ссылка в диапазоне, через индекс элемента идет. Т.е. реалокация и перемещение элемента по индексу

Стандарт разрешает :)

Да потому что экономить 8 байт структуры не имеет смысла почти никогда

Да потому что экономить 8 байт структуры не имеет смысла почти никогда

Но изначально речь как раз об экономии флага в optional :)

Там если ссылка в диапазоне, через индекс элемента идет. Т.е. реалокация и перемещение элемента по индексу

Эм, вносить оверхед всем дабы обезопасить не умеющих в ub?

Давай уж тогда обязательный gc сразу

Эм, вносить оверхед всем дабы обезопасить не умеющих в ub?

Там нет оверхеда, и, вроде, это требование стандарта

Оверхед в случае реаллокации в виде двух вычислений, серьезно? Там операция в два порядка дольше

Там нет оверхеда, и, вроде, это требование стандарта

Проверку бесплатно делать? Хотя относительно реаллокейта не так дорого, да

Проверку бесплатно делать? Хотя относительно реаллокейта не так дорого, да

Угу. Плюс реаллокейт это максимум логарифм раз

Т.е. оверхед + log N

Вообще смешной товарищ, делает реаллок х4 и рассказывает, что у него в два раза быстрее стандартной реализации при запихивании 10^7 элементов без резерва

а я могу сделать вектор, в котором бесплатная реаллокация для такого случая! vector<T> { T inner_array[10'000'000]; .... };

Что реаллок x4 приводит к оверхеду в 4 раза (а не в 3, еще 1 за фрагментацию при >= x2) он, видимо, даже догадывается :)

а я могу сделать вектор, в котором бесплатная реаллокация для такого случая! vector<T> { T inner_array[10'000'000]; .... };

а потом еще memset и еще в два раза! :)

а я могу сделать вектор, в котором бесплатная реаллокация для такого случая! vector<T> { T inner_array[10'000'000]; .... };

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

пес знает, я уже не соображаю

А что за гарантии?

А, там все наоборот, все поломали

А что за гарантии?

http://eel.is/c++draft/container.requirements.general#9

Не хватает явного запрета swap через allocator traits. Тогда бы и без UB обошлось. Просто не компилировалось бы например.

А, ну хотя если его сделать noncopyable, это же оно и будет.

то ли томск, то ли солвинг жаловался, что от такого кульбита сборки встанут, место кончится а матрица станет неподдерживаемо громоздкой, неужели таки решили превозмогать ?

Пока решилось, выделили терабайт места (было 200 гигов), плюс запилили скрипт для очистки outdated пакетов

http://www.opennet.ru/opennews/art.shtml?num=48990