Господа, загадка: чему равно ~uint16_t(0) >> 8 и почему?

0xFF?

0xFF?

нет

ffff?

Господа, загадка: чему равно ~uint16_t(0) >> 8 и почему?

Интегральное продвижение до инт?

Интегральное продвижение до инт?

угу

поэтому правильный ответ - implementation defined ?

поэтому правильный ответ - implementation defined ?

это пушо 8 интовая или пушо ~ сразу до инта кастит?

~

[cling]$ ~uint16_t(0) (int) -1

:)))

ахаха

Я на фотке как всегда плохо получился :)

Кто-то реализовывал двулучевую функцию отражательной способности Кука-Торренса на GLSL?

не могу понять, как собрать все это воедино

не могу понять, как собрать все это воедино

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

Кто-то реализовывал двулучевую функцию отражательной способности Кука-Торренса на GLSL?

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

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

У меня не очень бурная социальная жизнь, извините

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

Тематика: #Рендеринг, #Освещение, #Шейдеры

У меня не очень бурная социальная жизнь, извините

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

Тут скорее трудности с написанием алгоритма на С-подобном языке

Конкретно на языке шейдеров OpenGL

Тут скорее трудности с написанием алгоритма на С-подобном языке

а на каком языке нет проблемы с написанием этого алгоритма?

Конкретно на языке шейдеров OpenGL

t.me/prographon

t.me/prographon

Очень рекомендую. Там самая милая публика во всем телеграмме.

Если коротко, двулучевая функция отражательной способности, это функция которая принимает в качестве параметров, исходный свет(его направление), исходящее направление(угол между нормалью освещаемой поверхности и лучом исходящим из положения наблюдателя к точке к которой напрявляется исходящее освещение), матрицу нормальных векторов для спроэцированого обьекта на плоскость(его развертки, если точнее) и параметр а, специфический для материала поверхности, на который падает свет, который определяет "шершавость(неровность)" материала(усредненно). Эта функция должна количественно ценить влияние каждого конкретного луча на конечный отраженный от поверхности свет. Если наша поверхность идеально ровная, функция должна вернуть 0. По сути нам нужно оценить свойства отражение и рефракции поверхности, основываясь на предположении, что поверхность тела является не однородной стенкой, а множеством кругов(для упрощения скажем, что это молекулы). Для того что бы функция была хоть как-то физически обоснована, она должна расчитыватся исходя из законов сохранений(энергии, импульса(закон сохранения момента импульсов нам не нужен, его игнорируем)). Лучше всего нам подходится аппроксимизация Кука-Торренса. И я не совсем понимаю как же реализовать это дело на шейдерах

Извините, за немного длинное сообщение

И, быть может, за не строгие определения, попытался обьяснить суть как можно проще

Очень рекомендую. Там самая милая публика во всем телеграмме.

спасибо, задам вопрос там

Если коротко, двулучевая функция отражательной способности, это функция которая принимает в качестве параметров, исходный свет(его направление), исходящее направление(угол между нормалью освещаемой поверхности и лучом исходящим из положения наблюдателя к точке к которой напрявляется исходящее освещение), матрицу нормальных векторов для спроэцированого обьекта на плоскость(его развертки, если точнее) и параметр а, специфический для материала поверхности, на который падает свет, который определяет "шершавость(неровность)" материала(усредненно). Эта функция должна количественно ценить влияние каждого конкретного луча на конечный отраженный от поверхности свет. Если наша поверхность идеально ровная, функция должна вернуть 0. По сути нам нужно оценить свойства отражение и рефракции поверхности, основываясь на предположении, что поверхность тела является не однородной стенкой, а множеством кругов(для упрощения скажем, что это молекулы). Для того что бы функция была хоть как-то физически обоснована, она должна расчитыватся исходя из законов сохранений(энергии, импульса(закон сохранения момента импульсов нам не нужен, его игнорируем)). Лучше всего нам подходится аппроксимизация Кука-Торренса. И я не совсем понимаю как же реализовать это дело на шейдерах

поискать код, переписать на шейдэр

https://github.com/pboechat/cook_torrance

чем не подходит?

Я на фотке как всегда плохо получился :)

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

Кто-то реализовывал двулучевую функцию отражательной способности Кука-Торренса на GLSL?

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

Ребят, стоит ли плюсы выбирать как первый язык программирования?

Ребят, стоит ли плюсы выбирать как первый язык программирования?

нет :-)

нет :-)

+

Ребят, стоит ли плюсы выбирать как первый язык программирования?

y not

Ребят, стоит ли плюсы выбирать как первый язык программирования?

Хз, у меня плюсы первый ЯП и всё заябись.

@antoshkka можешь ли скинуть слайды с презентации по copy elision?

мне было бы интересно почитать лог нашего голосования)

есть мысль по поводу <=>: может ли наличие двух нулей на машинах с обратным и прямым кодом нарушить strong_ordering для integer типов?

Парни проект в каком направлении написать чтобы обмазаться спецификой c++ просто нужно попрактиковаться с управлением памятью

Напиши аналог valgrind например

Парни проект в каком направлении написать чтобы обмазаться спецификой c++ просто нужно попрактиковаться с управлением памятью

Компилятор же. Обмажешься спецификой по самое нехочу

@antoshkka можешь ли скинуть слайды с презентации по copy elision?

Выложу на свой сайтик на след неделе До того момента буду не у компа :(

Я хотел попрактиковаться в GLSL и С++, начал пилить проект на базе гугловского ANGLE. А в нем самом утечек немеряно. Есть мысль взять "С++17 Cookbook" и каждый пример скомпиллировать.

В чем сокральный смысл писать ключевое слово override для деструкторов?

В чем сокральный смысл писать ключевое слово override для деструкторов?

Самодокументирумость кода. Что виртуальная функция объявлены выше по иерархии, а не вводится на этом уровне.

Деструктор отличается от обычной виртуальной функции, ub не будет?

Деструктор отличается от обычной виртуальной функции, ub не будет?

Деструктор не отличается от обычной виртуальной функции. Откуда здесь уб.

Деструктор не отличается от обычной виртуальной функции. Откуда здесь уб.

Для деструкторов core guidelines не рекомендуют override - https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rh-override. https://github.com/isocpp/CppCoreGuidelines/issues/721 - тут обсуждение. Я лично за override на деструкторах.

Деструктор не отличается от обычной виртуальной функции. Откуда здесь уб.

https://github.com/isocpp/CppCoreGuidelines/issues/721

"override was added mainly to help avoid bugs from spelling mistakes when writing virtual functions. I am yet to see misspelled destructor pass compilation." Неужели эти люди не сталкивались с ошибкой, когда деструкторы объявлены без virtual. Рука-лицо.

Для деструкторов core guidelines не рекомендуют override - https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rh-override. https://github.com/isocpp/CppCoreGuidelines/issues/721 - тут обсуждение. Я лично за override на деструкторах.

Я тоже за override.

ERROR: S client not available

В любом случае, override в деструкторе говорит о том, что ты понимаешь контракт класса, предполагающий полиморфное удаление через базу.

"override was added mainly to help avoid bugs from spelling mistakes when writing virtual functions. I am yet to see misspelled destructor pass compilation." Неужели эти люди не сталкивались с ошибкой, когда деструкторы объявлены без virtual. Рука-лицо.

Логика такая - единственное чем здесь поможет override это если вдруг базовый деструктор стал невиртуальным, и твой деструктор без virtual и override. Ну если ты сделал базовый деструктор невиртуальным, проверь что это безопасная операция.

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

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

Конкретно с чем не согласен?

ещё интересно, кто какой вариант использует из virtual + override или просто override у переопределённых виртуальных методов

На моей памяти такого не случалось, чтобы базовый деструктор вдруг стал невиртуальным. А вот когда решают унаследовать класс с невиртуальным деструктором и ничего не меняют — такое было часто.

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

Это только в том случае, если предусмотрено полиморфное удаление через базу. Во всех остальных случаях я спокойно могу наследоваться от классов без виртуального деструктора.

Это детали.

Это детали.

Это понимание контракта, а не детали.

Ты не платишь за то, что не использушь.

ещё интересно, кто какой вариант использует из virtual + override или просто override у переопределённых виртуальных методов

virtual + override

virtual + override

+1

так как-то нагляднее

+1

Как-то совсем избыточно, зачем добавлять virtual если override и так это гарантирует?

Как-то совсем избыточно, зачем добавлять virtual если override и так это гарантирует?

Читам слева на право, только для этого

Как-то совсем избыточно, зачем добавлять virtual если override и так это гарантирует?

мне так визуально лучше воспринимается - но это исключительно дело привычки)

На моей памяти такого не случалось, чтобы базовый деструктор вдруг стал невиртуальным. А вот когда решают унаследовать класс с невиртуальным деструктором и ничего не меняют — такое было часто.

Проблема в этом случае в базовом классе а не в унаследованном. Если класс полиморфный, не final, и в нем публичный невиртуальный деструктор - то это ошибка дизайна. Могу порекомендовать использовать какую-нибудь умную ide или анализатор кода, они помогут в работе с такими разработчиками :)

Проблема в этом случае в базовом классе а не в унаследованном. Если класс полиморфный, не final, и в нем публичный невиртуальный деструктор - то это ошибка дизайна. Могу порекомендовать использовать какую-нибудь умную ide или анализатор кода, они помогут в работе с такими разработчиками :)

но при этом, если не предусмотрено полиморфное удаление, то и проблемы нет. struct foo { void boo() {doboo();} private: virtual void doboo() = 0; }; void callboo(foo& f){f.boo();} struct der : foo { private: virtual void doboo() override { /// } ... der d; callboo(d);

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

но при этом, если не предусмотрено полиморфное удаление, то и проблемы нет. struct foo { void boo() {doboo();} private: virtual void doboo() = 0; }; void callboo(foo& f){f.boo();} struct der : foo { private: virtual void doboo() override { /// } ... der d; callboo(d);

Мне кажется в этом случае есть оно или нет это уже не так важно, важно что оно разрешено :) Тем более если класс уже полиморфный, добавить еще одну виртуальную функцию недорого.

+1

Проблема в этом случае в базовом классе а не в унаследованном. Если класс полиморфный, не final, и в нем публичный невиртуальный деструктор - то это ошибка дизайна. Могу порекомендовать использовать какую-нибудь умную ide или анализатор кода, они помогут в работе с такими разработчиками :)

Проверил VS2017 — никаких ворнингов.

Проверил VS2017 — никаких ворнингов.

w4?

w4?

Тоже без ворнингов. https://pastebin.com/Qxe9tvLr

а что гцц?

clang на dogbolt тоже без ворнингов, и тоже вызывает ~A() в листинге.

а, не, там gcc