+1, го го го го го

Вычищено во имя Омниссии.

Есть какие-то требования к типу value_type для initializer_list?

Есть какие-то требования к типу value_type для initializer_list?

а ты можешь предоставить доказательства того, что ты был на cppreference и там ничего об этом нет?

а ты можешь предоставить доказательства того, что ты был на cppreference и там ничего об этом нет?

Ну я видел each element is copy-initialized, тем не менее мой clang дает создать пустой список для элементов с удаленными конструкторами копирования, например

Ну я видел each element is copy-initialized, тем не менее мой clang дает создать пустой список для элементов с удаленными конструкторами копирования, например

Просто я как-то использовал std::array<T, 0>, потом оказалось, что на каких-то компиляторах оно не работает

Просто я как-то использовал std::array<T, 0>, потом оказалось, что на каких-то компиляторах оно не работает

https://reviews.llvm.org/D41223 вот, например

Просто я как-то использовал std::array<T, 0>, потом оказалось, что на каких-то компиляторах оно не работает

Дык массив нулевого размера не допустим

Дык массив нулевого размера не допустим

только обращение к элементам, сам по себе - вполне

только обращение к элементам, сам по себе - вполне

нет

нет

глава 26.3.7.5, zero-sized arrays

Дык массив нулевого размера не допустим

Можна! There is a special case for a zero-length array (N == 0). In that case, array.begin() == array.end(), which is some unique value. The effect of calling front() or back() on a zero-sized array is undefined. An array can also be used as a tuple of N elements of the same type.

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

Где-то мне на глаза попадаласть статья, о том как в MSVC уменьшили размеры всех контейнеров на несколько байт и о том, как это круто

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

Какая-то жуткая фигня https://github.com/lnishan/vector/blob/master/vector.hpp#L123-L125 Супер жуткая: https://github.com/lnishan/vector/blob/master/vector.hpp#L297-L299

Где-то мне на глаза попадаласть статья, о том как в MSVC уменьшили размеры всех контейнеров на несколько байт и о том, как это круто

Блин вы это серьёзно сейчас? Если у вас 10кк маленьких векторов это уже серьёзный оверхед в 70мб 100кк вы потеряете на этом сраный гигабайт просто в некуда.

а где нужны 100кк мелких векторов?

Сейчас единственное оправдание плюсов это высоконагруженные проекты, где такие цифры в порядке вещей. А вы говорите, оверхед пл контейнерам не важен.

а где нужны 100кк мелких векторов?

sql движок например?

Сейчас единственное оправдание плюсов это высоконагруженные проекты, где такие цифры в порядке вещей. А вы говорите, оверхед пл контейнерам не важен.

А игры? :)

и сколько же памяти в целом будут съедать 100кк мелких векторов в сумме?

А игры? :)

А игры это и есть "высоконагруженные проекты"

Ну я видел each element is copy-initialized, тем не менее мой clang дает создать пустой список для элементов с удаленными конструкторами копирования, например

В общем на cppreference не оч написано. К элементам initializer_list - вообще нет требований все требования идут только для brace-initialization, как единственный(?) способ инициализации непустого списка

Где-то мне на глаза попадаласть статья, о том как в MSVC уменьшили размеры всех контейнеров на несколько байт и о том, как это круто

Ну пока я у них увидел только compressed pair под аллокатор

Блин вы это серьёзно сейчас? Если у вас 10кк маленьких векторов это уже серьёзный оверхед в 70мб 100кк вы потеряете на этом сраный гигабайт просто в некуда.

Ты знаешь что любой не пустой вектор кушает минимум 64 байта в x64?

Потому что align для new будет 64

sql движок например?

O_o, удивлен, а что в sql требует хранения такого количества векторов? индексы? метаинфа?

Ты знаешь что любой не пустой вектор кушает минимум 64 байта в x64?

Под векторами в данном случае я имел в виду +- любой контейнер.

Под векторами в данном случае я имел в виду +- любой контейнер.

Так любой контейнер будет память аллокать

Ты знаешь что любой не пустой вектор кушает минимум 64 байта в x64?

ну вообще говоря бывают оптимизации для маленьких векторов

ну вообще говоря бывают оптимизации для маленьких векторов

Вот вот.

ну вообще говоря бывают оптимизации для маленьких векторов

они запрещены для std::vector и любого контейнера

ну вообще говоря бывают оптимизации для маленьких векторов

не в стандартной либе вроде как

http://eel.is/c++draft/container.requirements.general#9 The expression a.swap(b), for containers a and b of a standard container type other than array, shall exchange the values of a and b without invoking any move, copy, or swap operations on the individual container elements

Ты знаешь что любой не пустой вектор кушает минимум 64 байта в x64?

Да и пусть даже так, 6гб это уже даже устаревшие стандарты оюъёмов памяти. Но факт остаётся фактом, мы проебали гигабайт в абсолютное ничего.

Так любой контейнер будет память аллокать

array/span

Да и пусть даже так, 6гб это уже даже устаревшие стандарты оюъёмов памяти. Но факт остаётся фактом, мы проебали гигабайт в абсолютное ничего.

Ты проебал 8 байт из 100+

Потому что align для new будет 64

На множестве платформ он 16, а не 64

На множестве платформ он 16, а не 64

Да не важно, все равно + запись в хипе

Зачем писать на плюсах если не упарываться оптимизацией?

Вы признаны троллем. Я поддержу вашу кандидатуру на выборах в комитет

Я же не говорю лезть в асм, или название переменных сокращать (лол). Но банальный оверхед у структуры убрать то можно? Или это уже тоже мувитон?

Названия классов вот практично сокращать

Я же не говорю лезть в асм, или название переменных сокращать (лол). Но банальный оверхед у структуры убрать то можно? Или это уже тоже мувитон?

А о каком именно оверхеде идёт речь, я немного пропустил обсуждение

Модулей не будет, а время компиляции от этого сокращается

Зачем писать на плюсах если не упарываться оптимизацией?

а зачем НЕ писать на плюсах?

А о каком именно оверхеде идёт речь, я немного пропустил обсуждение

Ну мол лишние 8 байт в векторе никому не помешают.

а зачем НЕ писать на плюсах?

зачем НЕ упарываться оптимизацией?

зачем НЕ упарываться оптимизацией?

потому что i9 хватит всем

потому что 90% кода можно на питоне писать

зачем НЕ упарываться оптимизацией?

Зпчем НЕ оптимизацией упарываться? - вот правильный вопрос.

потому что 90% кода можно на питоне писать

или всё же JS? ?

ни в одной системе никогда не будет создано 100млн std::vector-ов

потому что i9 хватит всем

У меня так брат миллиардером стал.

или всё же JS? ?

да хоть на чем, там производительность не нужна

вылизывается на практике 1% кода максимум

вылизывается на практике 1% кода максимум

А через пару тройку лет это становится помойкой кода, а не проектом.

Ну мол лишние 8 байт в векторе никому не помешают.

А как добились выиграша в 8 байт?

А как добились выиграша в 8 байт?

Вроде это невозможно :)

А как добились выиграша в 8 байт?

Хз, это там выше почитайте, меня просто зацепило что "это не важно"

У вектора оверхед в 1.5 раза врожденный, о чем мы вообще спорим?)

А как добились выиграша в 8 байт?

Не думаете там в boost.dll автоматик в demangle написать вместо boost.spirit.x3? :)

Не думаете там в boost.dll автоматик в demangle написать вместо boost.spirit.x3? :)

Яб с радостью. Желающих сделать это за меня - нет

Яб с радостью. Желающих сделать это за меня - нет

Ну... я на такое сразу пас, сам недавно разбирался со спиритом, чтобы не писать автоматики)

Вот и я не хочу :)

Модулей не будет, а время компиляции от этого сокращается

Шо прям 100% не будет? Или шансы есть?

Не будет же, уже объявляли...

Не, конечно, чудеса бывают...

Не будет же, уже объявляли...

а заседание по модулям прошло чтоль7

Ну вон Антон же выше. Он же писал, статья на Хабре.

Недели 3 наверно ещё назад

я пропустил

помянем модули

а заседание по модулям прошло чтоль7

нет

Боты в заблуждение вводят

ну че тогда похоронили?

потому что шанс их попадания в С++20 мал, ИМХО

ну че тогда похоронили?

никто не хоронил

Боты в заблуждение вводят

Ну, может быть я перепутал.

помянем модули

Не, поминать их рано, их же не похоронили, не отказались от них.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1108r0.html

а, уже было, окей

Что-то я туплю. struct Foo { Foo(int){}}; struct Bar : Foo {}; Возможно ли создать переменную типа Bar?

Что-то я туплю. struct Foo { Foo(int){}}; struct Bar : Foo {}; Возможно ли создать переменную типа Bar?

а какие с этим проблемы?

Что-то я туплю. struct Foo { Foo(int){}}; struct Bar : Foo {}; Возможно ли создать переменную типа Bar?

Не-а, конструктор в Bar должен быть

А стоп, не паблик наследование, тогда я пас

а какие с этим проблемы?

такие https://godbolt.org/g/rVnFsr

а, уже было, окей

"Сотрудники Яндекса будут представлять Россию в комитете по стандартизации C++ и продвигать Яндекс.Браузер в стандартную библиотеку".

А стоп, не паблик наследование, тогда я пас

паблик. структура же