Size: a a a

pro.graphon (and gamedev)

2021 April 10

d

disba1ancer in pro.graphon (and gamedev)
пример:
const int ct = 20;
void funcA(const int* ptr) {
 *const_cast<int*>(ptr) = 10;
}
void funcB(){
 int t;
 funcA(&t); // not causes UB
 funcA(&ct); // causes UB
}
источник

d

disba1ancer in pro.graphon (and gamedev)
соответственно если компилятор не может доказать отсутствие присвоения через const_cast, то ему поможет только restrict
источник

AP

Alexander Potapov in pro.graphon (and gamedev)
ну доказать то собственно не сильно сложно
источник

d

disba1ancer in pro.graphon (and gamedev)
да, но бывают случаи когда нельзя
источник

AP

Alexander Potapov in pro.graphon (and gamedev)
в принципе просто не использовать const_cast
источник
2021 April 11

d

disba1ancer in pro.graphon (and gamedev)
ну это понятно...
источник

D

Deathwish in pro.graphon (and gamedev)
В отдельный файл вынеси
источник

D

Deathwish in pro.graphon (and gamedev)
Я кстати по умолчанию везде делаю const &
источник

A

Arelav in pro.graphon (and gamedev)
Ну может иметь смысл что то в духе вызова конст метода из не конст и каст возвращаемого значения
источник

M

Mikhail in pro.graphon (and gamedev)
Для добавления конст – это норм.


void foo(const Foo& o) { /* ... */ }
void foo(Foo& o)
{
   foo(const_cast<const Foo&>(o));
   o.nonConstMethod();
}
источник

e

e in pro.graphon (and gamedev)
Я раньше так часто делал, а потом вдруг подумал - "а что говорит стандарт по этому поводу", после представил как требования размазаны по стандарту, причем бюрократическим языком. В итоге выкинул плюсы в форточку, вместе с монитором.
источник

A

Arelav in pro.graphon (and gamedev)
Добавить конст можно без конст каста std::as_const
источник

D

Deathwish in pro.graphon (and gamedev)
А ты не думал, что компиль сам может подставлять const, когда он посчитает нужным?
источник

A

Arelav in pro.graphon (and gamedev)
нет, не думал
источник

D

Deathwish in pro.graphon (and gamedev)
А вот я про это читал
источник

L

Lain-dono in pro.graphon (and gamedev)
Какая жесть. const который не const
источник

A

Arelav in pro.graphon (and gamedev)
Кто то пытался не выделять отдельный поток для vulkan рендера, может в принципе делал как то умнее чем поток который рендерит, и поток который грузят на гпу (у меня это имеет смысл так как формирование новых буферов долгое а рисование быстрое, если не так наверное просто один рендер тред)?
Ну несколько очередей command вообще выглядит немного бредом учитывая что на большинстве видях вроде реально 2-3 очереди комманд, ну и они специлизированны? Поидеи это может иметь смысл наверно для приоритетов каких то но это не мой кейс.

Кажется основная проблема с тем чтобы запихнуть это не в выделенный тред (помимо синхронизации, она решаема), что если мы делаем это в тредпуле не очень понятно: есть и много cpu работы, но в тоже время нужно ждать гпу после сабмита. Ну если мы не рисуем сразу н кадров. Как вариант сообщить тредпулу, о том что мы будем ждать. Но остался проблемы с запуском таски, так чтобы никто другой не мешал

Особенно интересно если вы сталкивались с вариантами где может быть статичная картинка, то есть камера не двигается, анимаций нет.
источник

D

Deathwish in pro.graphon (and gamedev)
Вообще, я бы сказал так, в некоторых компиляторах, слово const скорее означает то, что такие данные помещаются в область только для чтения. Возможно они могут быть быстрее для доступа, но это не точно.
источник

C

Crockett in pro.graphon (and gamedev)
Си++ лол чего ещё хотеть
источник

L

Lain-dono in pro.graphon (and gamedev)
Мне вас только пожалеть с таким
источник