Size: a a a

cxx.Дискуссионная

2020 April 27

O

Ofee in cxx.Дискуссионная
/dev/urandon ¯\_(ツ)_/¯
У тебя есть либо
1. unique_ptr с концепцией единственного владельца и мув-семантикой
2. borrow checher
3. Голые поинтеры, use after free, double free, утечка ресурсов, сигфолты в рантайме и порча памяти
Есть 4 вариант — не делать delete, проблем не возникает 100%
источник

АК

Александр Караев... in cxx.Дискуссионная
Roy Mustang
Не знаю, я придерживаюсь тактики, юзать shared_ptr и unique_ptr только если нет другого варианта (и нет, я не призываю использовать голые new/delete)
ты знаешь, что одно лишь использование vector в твоём коде по сравнению с сырым контролем памяти в сотни раз превышает оверхед от передачи юника в функции?
источник

RM

Roy Mustang in cxx.Дискуссионная
Щас взорвутся пуканы и побегут орать "а что если данные из контейнера удалятся, указатель будет висячим"
источник

АК

Александр Караев... in cxx.Дискуссионная
или не знаю, один вызов логгера с форматированием строки превышает такой оверхед в десять тысяч раз
источник

O

Ofee in cxx.Дискуссионная
Roy Mustang
Щас взорвутся пуканы и побегут орать "а что если данные из контейнера удалятся, указатель будет висячим"
Нормальная практика — использовать ссылки. Ну или итератор, может...
источник

RM

Roy Mustang in cxx.Дискуссионная
Александр Караев
ты знаешь, что одно лишь использование vector в твоём коде по сравнению с сырым контролем памяти в сотни раз превышает оверхед от передачи юника в функции?
Тогда давай используем unique_ptr<std::vector>
источник

АК

Александр Караев... in cxx.Дискуссионная
или мис-предикшн бранча компилятором примерно такой же оверхед вносит - ты уже начал расставлять [[likely]] и [[unlikely]]
источник

/dev/urandon ¯\_(ツ)_... in cxx.Дискуссионная
Artöm Bakri Al-Sarmini
3 можно дозировать
Героин тоже можно дозировать
источник

АК

Александр Караев... in cxx.Дискуссионная
или например использование std::string - это сразу хренакс и динамическая аллокация (иногда) и целый иф на любое обращение к символу (всегда) по сравнению с char*
источник

RM

Roy Mustang in cxx.Дискуссионная
Александр Караев
или не знаю, один вызов логгера с форматированием строки превышает такой оверхед в десять тысяч раз
Ну с таким подходом ты к концу релиза получишь целый мешок оверхедов
источник

/dev/urandon ¯\_(ツ)_... in cxx.Дискуссионная
Roy Mustang
Щас взорвутся пуканы и побегут орать "а что если данные из контейнера удалятся, указатель будет висячим"
Использовать индексы вместо поинтеров?
источник

RM

Roy Mustang in cxx.Дискуссионная
Казалось бы, вроде каждый оверхед по отдельности микроскопический, а в совокупности?
источник

AB

Artöm Bakri Al-Sarmi... in cxx.Дискуссионная
/dev/urandon ¯\_(ツ)_/¯
У тебя есть либо
1. unique_ptr с концепцией единственного владельца и мув-семантикой
2. borrow checher
3. Голые поинтеры, use after free, double free, утечка ресурсов, сигфолты в рантайме и порча памяти
Чтобы использовать 1 вместо 3 нужен еще non_owning_ptr<T>
источник

/dev/urandon ¯\_(ツ)_... in cxx.Дискуссионная
/dev/urandon ¯\_(ツ)_/¯
Использовать индексы вместо поинтеров?
Или слишком сложная концепция?
источник

/dev/urandon ¯\_(ツ)_... in cxx.Дискуссионная
Artöm Bakri Al-Sarmini
Чтобы использовать 1 вместо 3 нужен еще non_owning_ptr<T>
observer_ptr уже есть в stl
источник

RM

Roy Mustang in cxx.Дискуссионная
/dev/urandon ¯\_(ツ)_/¯
Использовать индексы вместо поинтеров?
Да не, у меня чуть другой случай, просто не хотел лишний раз тратить время на поиск по хеш карте базовых параметров
источник

АК

Александр Караев... in cxx.Дискуссионная
или вот тут, обращение к NextID каждый раз ифает инициализацию счётчика (двойная проверка)
источник

RM

Roy Mustang in cxx.Дискуссионная
/dev/urandon ¯\_(ツ)_/¯
observer_ptr уже есть в stl
Вот такой мне не помешал бы
источник

RM

Roy Mustang in cxx.Дискуссионная
Я ранее спрашивал, есть ли какой нибудь указатель, который способен наблюдать за данными на которые он указывает чтоб в случае если объект разрушился, указатель стал nullptr
источник

АК

Александр Караев... in cxx.Дискуссионная
Roy Mustang
Я ранее спрашивал, есть ли какой нибудь указатель, который способен наблюдать за данными на которые он указывает чтоб в случае если объект разрушился, указатель стал nullptr
хер тебе
источник