address sanitizer меняет расположение блоков в памяти

Это объясняет почему с включенным addresssanitizer данные не портятся. Но я не понимаю почему он при этом сам не находит ошибку

Блин, я дибил. Сохранил указатель на элемент коллекции

Который инвалидируется при её расширении

Это конечно печально, придется вместо vector<T> делать vector <shared_ptr<T>> , хотя вектор является unique овнером

Или есть какой-то более правильный способ?

Почему вектор не поддерживает move-only типы?

эм, vector<unique_ptr<T»

нет, его нельзя расширять

почему-то

почему он не может мувнуть их при расширении?

кого нелья расширить

и как ты умудрился хранить в векторе что-то что оно инвалидировалось?

Оно не инвалидировалось. Я просто хранил указатель на элемент вектора и он инвалидировался при расширении вектора

Обычные грабли

ну есть простое решение, не храни указатель

Хранить указатель нужно. Класс дает его другому погонять на время. Причем гарантировано что время жизни пользователя меньше времени жизни объекта в векторе

В общем переделал на vector<shared_ptr>, всё ок. Хотя по сути мне нужен vector<unique_ptr>

deque

deque

И правда: push_front, push_back, emplace_front and emplace_back do not invalidate any references to elements of the deque.

Интересный юзкейс получается: выбор коллекции исходя из invalidation rules :)

vector<unique_ptr> вполне себе расширяется

vector<unique_ptr> вполне себе расширяется

И правда

Такой вопрос. Есть код который выводит лишний мусор в консоль. Как найти то место где это происходит? Т.е. как называется самая низкоуровневая функция для вывода на которую есть смысл поставить bp

Похоже это putc

write() как ни странно

Да, я начал с write, выше него putc , дальше уже streams

Хм нет. printf write не вызывает

Хм нет. printf write не вызывает

Не фигню сказал. Просто не флашнул. Поэтому и не вызывал

никто не знает либы для создания DJVU на С/С++?

Почему вектор не поддерживает move-only типы?

если я правильно понял вопрос, то конструкторы перемещения типа нужно объявлять как noexcept, иначе вызываются конструкторы копирования

если я правильно понял вопрос, то конструкторы перемещения типа нужно объявлять как noexcept, иначе вызываются конструкторы копирования

Конкретно тогда я просто тупанул :) Но ты меня смог отмыть путём такой более глубокой интерпретации

Конкретно тогда я просто тупанул :) Но ты меня смог отмыть путём такой более глубокой интерпретации

Хотя нет, всё равно можно: If T's move constructor is not noexcept and T is not CopyInsertable into *this, vector will use the throwing move constructor. If it throws, the guarantee is waived and the effects are unspecified.

Просто emplace_back не дает strong exception safe гарантии если move-ctor throws

Хотя нет, всё равно можно: If T's move constructor is not noexcept and T is not CopyInsertable into *this, vector will use the throwing move constructor. If it throws, the guarantee is waived and the effects are unspecified.

этого не знал. Вижла вообще в любом случае move конструктор вызывает

Вообще интересная тема получается с deque : если стоимость перемещения объекта высокая, то лучше использвать deque вместо vector если делаешь много push_back?

Вообще интересная тема получается с deque : если стоимость перемещения объекта высокая, то лучше использвать deque вместо vector если делаешь много push_back?

никогда не задумывался, но получается да. deque блоками все хранит, то там наверное и перемещения нет

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

Да, так и есть: https://baptiste-wicht.com/posts/2017/05/cpp-containers-benchmark-vector-list-deque-plf-colony.html

Любопытно что list сливает вектору и деку на random insert маленьких объектов

128 байт, deque всё ещё лучше чем list на random insertion

конечно сливает, там BidirectionalIterator

Ну и что? Всё равно ведь вектор должен O(n) копирований сделать

Т.е. по сути копировать дешевле чем итерировать по куче

rep mov

если я правильно понял, то там не только итерировать по куче, но ещё и создавать новые маленькие объекты на куче

а вектор на маленьких объектах просто уложится в кэш, и отработает в мгновение ока

если я правильно понял, то там не только итерировать по куче, но ещё и создавать новые маленькие объекты на куче

Не понял? списку нужно создать O(1) объектов

я про то, что список на каждом добавлении будет выделять память, а вектор - только когда у него закончится буфер ну и маленькому вектору маленьких объектов будет быстрее переложить рядом лежащие объекты, чем списку полезть в кучу и там разгребать место по-крайней мере так я себе это представляю

Проблема исключительно в стоимости итерации по куче, всё остальное несущественно

список получит кучу кеш миссов пока дойдет до нужного нода

rep mov видимо вообще включит какой-нибудь аппаратный префетчер

rep mov

только для подов

только для подов

О них речь и шла там

Беркус, ты тоже в штатах сидишь? Или ночами работаешь?

беркус 24/7 по-моему, лол

Беркус, ты тоже в штатах сидишь? Или ночами работаешь?

нет, и нет

Ну я так или иначе, думаю, что Беркус много работает :)

Такой вопрос, у меня есть void * на полиморфный объект. Можно ли получить RTTI?

Беркус, ты тоже в штатах сидишь? Или ночами работаешь?

неа, он не в штатах. И беркус тоже бывает, что спит 😊

Такой вопрос, у меня есть void * на полиморфный объект. Можно ли получить RTTI?

нет

Почему так сделано? Что мешает положить rtti в начало объекта для всех полиморфных типов?

Почему так сделано? Что мешает положить rtti в начало объекта для всех полиморфных типов?

https://stackoverflow.com/questions/4131091/dynamic-cast-from-void

не читал, но вроде как там есть коммент

Там не написан ответ на мой вопрос. Но его можно вывести путем дальнейших рассуждений

Там не написан ответ на мой вопрос. Но его можно вывести путем дальнейших рассуждений

Хотя.. нет. Думаю дальше. Пока не понял :)

Там приведен пример layout'а объекта в памяти для которого работать не будет

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

А всё, понял. Сейчас сформулирую

Мы хотим чтобы указатель на VTBL был всегда в начале класса. Например можно раскладывать объекты так: class derived1 : virtual_base layout: [VPTR][virtual_base][derived1] class derived2 : nonvirt_base, derived1 layout: [VPTR][nonvirt_base][virtual_base][derived1][derived2] Проблема в том что теперь нельзя создать указатель derived1* на объект derived2 Можно её решить путём дублирования указателя на VTBL: layout: [VPTR][nonvirt_base][VPTR][virtual_base][derived1][derived2] Но это overhead который будет накапливаться по мере разрастания иерархии типов

В общем это плата за множественное наследование

а вот почему бы не ввести в c++ java-подобные интерфейсы (они даже в аде есть, где нет классов в традиционном понимании) и не deprecate множественное наследование от классов?

Java-подобные интерфейсы уже есть

public virtual метод

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

Просто сейчас компактнее кодить с множественным наследованием, чем с интерфейсами и композицией

Java-подобные интерфейсы уже есть

ну это классический вопрос с собеседования: "чем абстрактный класс отличается от интерфейса". вот первые в с++ есть, вторых нет

Чем отличается абстрактный класс с public pure virtual методами и без data members от интерфейсов?

pure*

pure*

Спасибо

Ничем, кажется.