ты предлагаешь в классе rawptr держать на тот, что лежит в юнике в векторе?

к указателям у меня вопросов и претензий нет

с указателями мне все очевидно

ты предлагаешь в классе rawptr держать на тот, что лежит в юнике в векторе?

Разумеется. Или еще лучше reference

я просто хотел аллоцировать пачку структур, а не каждую структуру отдельно - поэтому не очень хотел иметь вектор указателей.

std:ref

никакой магии?

Если знаешь верхнюю границу на количество своих архивов, или чётко знаешь, сколько их, делаешь reserve и тебе гарантируется, что они никуда не уедут.

std:ref

При чем тут это? он тебе не поможет ну никак.

Если знаешь верхнюю границу на количество своих архивов, или чётко знаешь, сколько их, делаешь reserve и тебе гарантируется, что они никуда не уедут.

нет, не знаю, длина воистину динамическаям

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

Очень странная задача, тогда.

В общем не вижу проблем в хранении вектор + индекс.

Напиши обёртку, если хочется.

ну, сейчас так и есть. ок

задача не странная

ты мне скажешь почему она странаая если пояснишь как иметь вектор указателей И ПРИ ЭТОМ каждое значение указателя аллоцировать локально подряд

тогда это будет убийством обоих зайцев

А зачем тебе надо именно подряд в памяти?

Обычно это надо, если тебе вообще-то размер известен.

А зачем два вектора? Используй пары, всё равно тебе отдельно эти вектора не нужны?

размер структуры мне безусловно известен

да структура не при чём тут.

Я про размер вектора.

А зачем два вектора? Используй пары, всё равно тебе отдельно эти вектора не нужны?

нет, нужны, у них не один к одному отношение.

Ты что заранее не можешь посчитать количество архивов?

А потом выделить ровно столько, сколько надо.

громоздко, но можно

там бывают архивы в архивах

не то чтобы они были мне сильно нужны впрочем...

Да ничего громоздкого, наоборот. По перформансу будет оптимально зато.

угу, это норм решение

тогда вектор один раз аллоцируется и никуда не уедет, раз

Если надо часто бегать по массиву этому особенно.

можно будет иметь указатели, два

вот и все

Да.

Да ничего громоздкого, наоборот. По перформансу будет оптимально зато.

так о чем и речь, я почему про локальность-то и спрашиваю

мне в принципе насрать на производительность тут, но интерес на будущее есть

задача довольно типовая

в общем индексов буду избегать потому что как познал на своей жопе это сложно рефакторить и не наделать дел

потому что сложно читается

потому и поднял вопрос

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

Друзья, кто из вас занимается бизнесом, стартапами, или является тимлидом, HR. В общем нужны рекрутеры, как в душе так и на яву. Ответьте, пожалуйста, на один вопрос https://vk.cc/6syV26 Статистику открою после сбора ответов у себя на странице https://vk.com/sannikovdmitry

язабан

плюс плюс

Блин, идиотская ошибка. Надо было в скобки засунуть просто место где вызывается метод. interpPoints[i].y = (this->*interpFn)(interpPoints[i].x);

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

да и сам в голове не скажу куда скобки

да я проглядел

Блин, идиотская ошибка. Надо было в скобки засунуть просто место где вызывается метод. interpPoints[i].y = (this->*interpFn)(interpPoints[i].x);

Самое забавное, что скобки - это универсальный вид магии. Они даже защищают от редефайнутых функций, типа min() в windows.h

лол

будем обращать большее внимание на это

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

если возникает необходимосит ставить скобки в типах

это прямой путь в алиас

и все нуль проблем

не виноваты до тех пор, пока не влияют на производительность!

вдруг это медленные зайцы.

еще скажите такую штуку

что можно использовать вместо чар поинтеров для буферов данных?

просто чар вектор?

или есть специализированные штуки?

Для фиксированной длины std::array можно

о, спасибо

(да, я именно настолько не в курсе STL)

да, это годится.

(да, я именно настолько не в курсе STL)

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

@micktu по поводу вектора и ссылок на его элементы - а как вы эту задачу решали в других ЯП?

в других языках программирования у меня нет выбора

это всегда рефренс

там не бывает значения у массива

там не бывает значений у его элементов

я всегда могу взять референс на элемент и он доступен

фактически то же самое поведение тут дает вектор указателей

но у меня есть опция иметь вектор значений... ну и понеслась

Ок, понял. Бывали у нас подобные задачи когда требовалось линейного расположения и при этом ссылки на элементы. Колво элементов заранее не было известно, элементы только добавлялись. Вектор был обернут классом гарантирующим только добавление элементов. В качестве ссылки на элемен ы возвращалась оболочка ссылка на вектор + да, да, индекс. О чем уже говорили Ничего плохого тут нет

Две эти оболочки просто дают нужные гарантии

По производительности плохо, а так ничего, конечно.

в цикле по "ссылкам" этим никто не ходит - есть же оригинальный вектор и пефоманс там