Минус вектора значений — необходитмость писать мув конструктор

Плюс — потенциально другой алгоритм где мы ходим по нему в цикле будет работать на одну индирекцию меньше.

еще вроде задавал вопрос или нет, не помню

есть алиас для типа pair map'а?

аналогично vector::iterator

а то пока что это единственное место где я пишу авто

value_type

map<K,T>::value_type

ес, спасибо!

В auto нет ничего дурного, я практически всегда auto пишу.

просто в ряде компаний гайдлайны запрещают за исключением лямбд и ОЧЕ ДЛИННО

хотя я сам считаю что это глупость и трение

Это искуственное довольно ограничение, как по мне.

ну да, читать очевиднее, но...

Можно было бы сказать, что это мол дополнительнодокументирует код или что-то в таком духе, но на самом деле нет.

в сишарпе я отстаивал var всегда и везде

ну да, соображение именно в том, что документирует

А вот написание и всприятие затрудняет точно.

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

Угу.

во-во

так что я еще пока в сомнениях

в этом "проекте" на пробу избегаю авто, посмотрю какое отношение сложится

std::experimental::pmr::string::value_type

грегорий, а движок чего вы программировали?

рендер визуального DSL

std::experimental::pmr::string::value_type

для этого я алиасы прописываю

И то верно

что в общем-то тоже костыль

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

будет ругаться

Осмысленные имена спасают.

ну, я думаю это в рамках осмысленности и лаконичности

LPCWSTR

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

в винапи

они МАКСИМАЛЬНО краткие и информативные, не придерешься

но жутко уродливые

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

у меня тоже проблем не возникло

я правда не знаю что значит L

то ли лонг, то ли хрен знает что

на моей платформе это синонимы с PCWSTR

если лонг, тогда все с ними очевидно, да

long pointer to const wide string

Плюс — потенциально другой алгоритм где мы ходим по нему в цикле будет работать на одну индирекцию меньше.

если вектор содержит эл. последовательно то о какой индерекции речь?

по оффсету надо сходить всё равно

оператор []

Ты в паре вектор + оффсет, держишь указатель на вектор

тебе надо получить сам вектор — deref. взять его начало, прибавить offset и deref для получения элемента

Когда ты держишь указатель сразу на объект внутри uniq-а то для обращения к объекту только один deref

по ситаксису подскажите плиз

долбаный скобочки

как взять реф от (uint8_t*)data

от конкретно этого выражения

просто интересно

Это что за выражение?

data это уже имя

,А или ты имеешь в виду каст

как взять реф от скащеной переменной

где проставить скобочки

Ты на плюсах пишешь?

long pointer to const wide string

Именно так

Не надо так кастить.

Ты на плюсах пишешь?

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

вопрос конкретный есть

(uint8_t*)data

Так не надо кастить. Это может попросту не работать

&((uint8_t*)data)

о господи это просто указатель на чар

спасибо!

Но вообще это выглядит как что-то неправильное явно.

Не плюсовое.

ага

но мне пофиг на религию :))

плюсовые касты слишком долго набирать

Не.

если можно без них - попробую обходиться

Ты не понял.

Это просто ДРУГАЯ операция

у меня была одна ситуация когда компилятор не понял что я хочу сделать

с си-кастом

но понял с реинтерпретом

это был каст указателя на чар в лонг

Но я не об этом даже, боже мой.

но тут не та ситуация, это синонимичные типы

Я о том, что у тебя с кодом что-то не так

Если тебе вообще надо брать указатель на указатель

это был каст указателя на чар в лонг

ой

Еще и скастованный

Если тебе вообще надо брать указатель на указатель

о господи :)))

есть функция

в библиотеке

она принимает uint8_t**

Какая?

безо всякого зла, не занудствуй :)