Так я про это и веду речь - я не могу найти этого в Стандарте

Вот и вопрос почему это написано на c++ reference и как на самом деле

потому что CopyAssignment требуется по причине пользовательского кода, а не реализации std::vector::insert

https://godbolt.org/g/J7cgbV - вот код. MSVC компилит, все остальные нет. Вопрос кто прав и почему

неудивительно что специалисты джаваскрипта лучше оплачиваются, пока вы выясните что надо, чтобы в динамический массив элемент положить, на джаваскрипте можно три фреймворка написать

https://godbolt.org/g/J7cgbV - вот код. MSVC компилит, все остальные нет. Вопрос кто прав и почему

Еще раз. Вы для вставки используете синтаксис, который не подразумевает возможность перемещения и копирование произойдет синтаксически. Я не вижу на cppreference или в стандарте указаний на способ реализации insert. MSVC реализует insert через swap, и в вашем примере будет CopyCtor и потом swap

стандартный swap требует MoveAssignment

Вот непонятно, почему все не могут так реализовать. Получается, что есть все необходимое, но из-за реализации внутри билиотеки оно не работает.

Еще раз. Вы для вставки используете синтаксис, который не подразумевает возможность перемещения и копирование произойдет синтаксически. Я не вижу на cppreference или в стандарте указаний на способ реализации insert. MSVC реализует insert через swap, и в вашем примере будет CopyCtor и потом swap

Смотри, перегрузка insert определяет требования для типов итератора и соответственно T. Все требования соблюдены, однако реализация не работает

http://eel.is/c++draft/sequence.reqmts

http://eel.is/c++draft/sequence.reqmts

Есть кто расшифрует :)?

я сейчас сделаю

a.insert(p,i,j) iterator Requires: T shall be Cpp17EmplaceConstructible into X from *i. For vector and deque, T shall also be Cpp17MoveInsertable into X, Cpp17MoveConstructible, Cpp17MoveAssignable, and swappable ([swappable.requirements]). Each iterator in the range [i, j) shall be dereferenced exactly once. Requires: i and j are not iterators into a. Inserts copies of elements in [i, j) before p

Просто тут либо один из компиляторов не соответствует стандарту, либо cppreference врет

Можно попробовать еще свой swap специализировать тогда, мб заведется.

может там какие-то действительно спец. требования, чтобы быть swappable?

http://eel.is/c++draft/swappable.requirements

Насколько я понял что swappable значит что внезапно можно вызвать swap и он действительно свапнет

А вот какие требования у swap в стандарте написано?

http://eel.is/c++draft/utility#swap

Requires: Type T shall be Cpp17MoveConstructible (Table 25) and Cpp17MoveAssignable (Table 27).

yep

про копирование ни слова

Про копирование есть выше: Requires: T shall be CopyInsertable into X and CopyAssignable. но там про другой метод. Кажется что GCC не прав и реализоввывают через assignment вместо unitialized move

Про копирование есть выше: Requires: T shall be CopyInsertable into X and CopyAssignable. но там про другой метод. Кажется что GCC не прав и реализоввывают через assignment вместо unitialized move

Это где?

a.insert(p,n,t) iterator Requires: T shall be Cpp17CopyInsertable into X and Cpp17CopyAssignable.

Но это же другая перегрузка

которая n элементов t

a.insert(p,n,t) iterator Requires: T shall be Cpp17CopyInsertable into X and Cpp17CopyAssignable.

не, это не то

@antoshkka тут действительно забавная фигня, я не знаю, как называется требование, но, видимо, нужно указать, что выражение result = *iterator все-таки валидно

CopyIteratorAssignable? ?

я где-то не так давно такое требование, только не вспомню, как оно назвается

@antoshkka тут действительно забавная фигня, я не знаю, как называется требование, но, видимо, нужно указать, что выражение result = *iterator все-таки валидно

Не обязательно, можно же реализовать через position->~T(); new (position) T(*iterator);

Не обязательно, можно же реализовать через position->~T(); new (position) T(*iterator);

Можно реализовать как вижак на самом деле, там фокус что делается insert в конец и потом вращение

Ну да, либо через swap, либо через uninitialized_move/copy

а вращение вот так: 123 45678 321 87654 45678 123

тремя реверсами)

GCC вот тут юзает std::copy. От него то и проблемы vector<_Tp, _Alloc>:: _M_range_insert(iterator __position, _ForwardIterator __first, _ForwardIterator __last, std::forward_iterator_tag) { if (__first != __last) { const size_type __n = std::distance(__first, __last); if (size_type(this->_M_impl._M_end_of_storage - this->_M_impl._M_finish) >= __n) { const size_type __elems_after = end() - __position; pointer __old_finish(this->_M_impl._M_finish); if (__elems_after > __n) { std::__uninitialized_move_a(this->_M_impl._M_finish - __n, this->_M_impl._M_finish, this->_M_impl._M_finish, _M_get_Tp_allocator()); this->_M_impl._M_finish += __n; _GLIBCXX_MOVE_BACKWARD3(__position.base(), __old_finish - __n, __old_finish); std::copy(__first, __last, __position); } else { _ForwardIterator __mid = __first; std::advance(__mid, __elems_after); std::__uninitialized_copy_a(__mid, __last, this->_M_impl._M_finish, _M_get_Tp_allocator()); this->_M_impl._M_finish += __n - __elems_after; std::__uninitialized_move_a(__position.base(), __old_finish, this->_M_impl._M_finish, _M_get_Tp_allocator()); this->_M_impl._M_finish += __elems_after; std::copy(__first, __mid, __position); } } else

GCC вот тут юзает std::copy. От него то и проблемы vector<_Tp, _Alloc>:: _M_range_insert(iterator __position, _ForwardIterator __first, _ForwardIterator __last, std::forward_iterator_tag) { if (__first != __last) { const size_type __n = std::distance(__first, __last); if (size_type(this->_M_impl._M_end_of_storage - this->_M_impl._M_finish) >= __n) { const size_type __elems_after = end() - __position; pointer __old_finish(this->_M_impl._M_finish); if (__elems_after > __n) { std::__uninitialized_move_a(this->_M_impl._M_finish - __n, this->_M_impl._M_finish, this->_M_impl._M_finish, _M_get_Tp_allocator()); this->_M_impl._M_finish += __n; _GLIBCXX_MOVE_BACKWARD3(__position.base(), __old_finish - __n, __old_finish); std::copy(__first, __last, __position); } else { _ForwardIterator __mid = __first; std::advance(__mid, __elems_after); std::__uninitialized_copy_a(__mid, __last, this->_M_impl._M_finish, _M_get_Tp_allocator()); this->_M_impl._M_finish += __n - __elems_after; std::__uninitialized_move_a(__position.base(), __old_finish, this->_M_impl._M_finish, _M_get_Tp_allocator()); this->_M_impl._M_finish += __elems_after; std::copy(__first, __mid, __position); } } else

clang тоже юзает в одной из веток

Засада в том, что если реализоввывать не через Copy, тогда получим просадку по перфу - придётся либо вызывать деструкторы, либо свапать

тут можно поставить deinitialize и emplace ctor, вопрос только что скорее надо стандарт в этом месте поправить

требование copyctor без copyassign это все-таки серьезное извращение

Не, со стандартом там все ОК. Требования Cpp17EmplaceConstructible, Cpp17MoveConstructible, Cpp17MoveAssignable как раз об этом и говорят

Надо еще специализацию для move итераторов посмотреть, с ней все нормально работает.

Жаль, что на godbolt.org нельзя по исходникам ходить.

Не, со стандартом там все ОК. Требования Cpp17EmplaceConstructible, Cpp17MoveConstructible, Cpp17MoveAssignable как раз об этом и говорят

ну я бы разрешал по стандарту реализацию, вызывающую copy :)

ну я бы разрешал по стандарту реализацию, вызывающую copy :)

ага, кажется что будет пошустрее

Хорошо оставить как fallback если тип копируемый

А то сейчас получается что стандарту не соответствует

ага, кажется что будет пошустрее

Угу. Вот представьте, что в текущей реализации типа gcc/clang мы заменим copy на destroy + uninitilized_copy и там vector<vector<int» с типичным внутренним размером 16, привет деаллокации с последующими аллокациями памяти. И этим платим за то, что пользователь универсальную реализацию CopyAssignment через swap with copy не хочет писать

Надо еще специализацию для move итераторов посмотреть, с ней все нормально работает.

Решил посмотреть. Если кому интересно, то в libstdc++ везде используется std::copy, просто в случае move итераторов будет вызвана специализация std::copy, которая в цикле делает не assign, а move assign. Я надеялся, что там что-нибудь более интересное будет.

btw позабавило количество различных вариантов *_copy_* в libstdc++: __copy_move __copy_m __copy_move_a __copy_move_a2 Это только те, которые относятся к std::copy, там такие наборы еще для backward и т.д.

Куда можно писать пропосалы? Хочу излить свою боль. Я хочу, чтоб алгоритмы из algorithms умели принимать Container, а не пару итераторов. Под конец дня у меня от этого бессмысленного и беспощадного бройлерплейта на всю ширину экрана уже глаз дёргаться начинает.

Куда можно писать пропосалы? Хочу излить свою боль. Я хочу, чтоб алгоритмы из algorithms умели принимать Container, а не пару итераторов. Под конец дня у меня от этого бессмысленного и беспощадного бройлерплейта на всю ширину экрана уже глаз дёргаться начинает.

1) на stdcpp.ru 2) это порешается через range

Всего через 2 годика)

И будет так же передавать пару итераторов, только теперь не в алгоритм, а в конструктор диапазона

посмотрите, как сделано в Boost.Algorithm

"Бройлерплейт" это метко сказано, надо запомнить

не могу понять как сделать перегрузку структуры или констэкспр функции на базе того, существует ли тип или нет. Например, у меня есть некий тип Container<Args...>, хочется чтобы, если есть Container<Args...>::value_type, то вызвать эту же структруру/функцию для него, иначе sizeof...(Args). Короче этакий подсчет количества дырок в контейнере, без учета всяких аллокаторов (которые в тот же вектор вторым тайп-параметром передаются)

enable_if?

+detection idiom

enable_if говорит что нет такого типа для тех контейнеров, где его нет

Sfinae)))

не могу пока доехать как. decltype(value_type(), int()) тоже ругается при наличии рядом перегрузки с параметром более базового типа и без такой проверки

есть подозрение что потому что оно констэкспр

ERROR: S client not available

А можно какой-нибудь минимальный пример?

ща попробую перенести. Я прост пишу с личного ноута, код весь на рабочем компе (я туда телегу не ставлю)

А можно какой-нибудь минимальный пример?

https://gist.github.com/dkormalev/bdf4134355469bd1c44271f64189fc3a

вот оно как раз говорит что no type named value_type для контейнеров, где нет такого типа

Куда можно писать пропосалы? Хочу излить свою боль. Я хочу, чтоб алгоритмы из algorithms умели принимать Container, а не пару итераторов. Под конец дня у меня от этого бессмысленного и беспощадного бройлерплейта на всю ширину экрана уже глаз дёргаться начинает.

Это Ranges!

Куда можно писать пропосалы? Хочу излить свою боль. Я хочу, чтоб алгоритмы из algorithms умели принимать Container, а не пару итераторов. Под конец дня у меня от этого бессмысленного и беспощадного бройлерплейта на всю ширину экрана уже глаз дёргаться начинает.

Скоро будут в стандарте! Ещё 2 годика потерпи! (ну, или уже сейчас boost::ranges, ranges v2 или v3)

И будет так же передавать пару итераторов, только теперь не в алгоритм, а в конструктор диапазона

Нихера не надо передавать. У рэнжа есть конструктор от контейнеров, он сам берёт всё.

https://gist.github.com/dkormalev/bdf4134355469bd1c44271f64189fc3a

Если правильно понял, чего вы хотите добиться, то: https://godbolt.org/g/ykbGED

Если правильно понял, чего вы хотите добиться, то: https://godbolt.org/g/ykbGED

С телефона не оч читабельно, но ты вроде там считаешь внутренний тип и только для контейнеров с велью тайп. Моя идея в том, что у меня есть как с велью тайп (стд, где у вектора это сам тип, у мапы - пара), так и контейнеры без велью тайп (qmap). Для вторых я хочу считать через сайзоф. Для первых так нельзя из-за доп тайп параметра у стд контейнеров для аллокатора. Но у них можно считать по велью тайп (считая 0 за 1)

А, ну не суть, там можно подправить так, как вам будет нужно. Детектор для value_type std контейнеров там есть, остальное на ваше усмотрение.

А, ну не суть, там можно подправить так, как вам будет нужно. Детектор для value_type std контейнеров там есть, остальное на ваше усмотрение.

Аа, нашел, да, чот я не подумал так зачекаиь, спасибо

Господа можете помочь как в visual studio начать выполнекние програмы по действиям(f10) с определёногоместа?

Аа, нашел, да, чот я не подумал так зачекаиь, спасибо

Не за что. Для вашей задачи, наверное, так: https://godbolt.org/g/pZkQGU

Господа можете помочь как в visual studio начать выполнекние програмы по действиям(f10) с определёногоместа?

Брейкпоинт поставить в нужном месте.

а как это сделать?

а как это сделать?

https://youtu.be/0ebzPwixrJA?t=262

спасибо

Сразу скажу: вакансии в отдельный канал, пожалйуста, через @AlexFails

Вопрос по порядку инициализации глобальных переменных и константных static членов класса. Я так понимаю, что порядок их инициализации не определен в рамках разных единиц трансляции. Но если их инициализация написана в одном cpp файле, то они и инициализироваться будут по порядку их объявления?

Вопрос по порядку инициализации глобальных переменных и константных static членов класса. Я так понимаю, что порядок их инициализации не определен в рамках разных единиц трансляции. Но если их инициализация написана в одном cpp файле, то они и инициализироваться будут по порядку их объявления?

Не определён. Если в одной -- в АЛФАВИТНОМ порядке. Но я бы на это не закладывался. Потому что ЭТО НЕ ТОЧНО!

Вопрос по порядку инициализации глобальных переменных и константных static членов класса. Я так понимаю, что порядок их инициализации не определен в рамках разных единиц трансляции. Но если их инициализация написана в одном cpp файле, то они и инициализироваться будут по порядку их объявления?

Также, хочу заметить, что ОБЪЯВЛЕНИЙ у одной переменной может быть МНОГО в рамках одной единицы трансляции. Поэтому закладываться на порядок этих объявлений было бы странно, не было бы просто этого порядка.

Не определён. Если в одной -- в АЛФАВИТНОМ порядке. Но я бы на это не закладывался. Потому что ЭТО НЕ ТОЧНО!

если в одной единице в порядке определения.

просто статические члены класса вроде как должны быть обязательно объявлены в *.cpp

если в одной единице в порядке определения.

Ну кстати кажется алфавитный порядок отменили...

Ну кстати кажется алфавитный порядок отменили...

нет, ты его придумал

просто статические члены класса вроде как должны быть обязательно объявлены в *.cpp

Не объявлены, а определены

нет, ты его придумал

Да я так объодил всякие траблы в 90х. Точно было. Может, не по стандарту

Не объявлены, а определены

да, определены

спасибо!

Вопрос по порядку инициализации глобальных переменных и константных static членов класса. Я так понимаю, что порядок их инициализации не определен в рамках разных единиц трансляции. Но если их инициализация написана в одном cpp файле, то они и инициализироваться будут по порядку их объявления?

https://en.cppreference.com/w/cpp/language/initialization 3) Ordered dynamic initialization, which applies to all other non-local variables: within a single translation unit, initialization of these variables is always sequenced in exact order their definitions appear in the source code. Initialization of static variables in different translation units is indeterminately sequenced. Initialization of thread-local variables in different translation units is unsequenced.