Еще вопрос.
Где можно посмотреть качественный код на современном С++? Чтобы там использовали всякие умные указатели и так далее?
Желательно, чтобы это был какой-то движок, рендерер, игра.

Я видал соурсы Квейка3 и прочего, но там пишут в стиле сишки.

>>274244 (OP)
Тестировать никак. Можешь протестировать то, что имеет явный ввод-вывод. Например, математику или сеть. Рендер уже никак.

>>274248
Ну, тот же пример с пересечением примитивов. Как мне с руки пощитать что-то там, чтобы составить тест? Я же там сам скорее с калькулятором ошибусь.

>>274250
ну координаты ты же можешь получить. с их помощью и пересечения определить и вывести все это говно, предварительно сложив

Сейчас случайно заглянул в /gd. Обрадовался, увидев этот тред. Сам я веб-программист. И опыт тестирования веб-приложений подсказывает, что иногда протестировать какой-то код можно лишь сильно изменив его способ взаимодействия с другим кодом. И обычно код, который пишется после тестов (TDD/BDD) оказывается лучше.

Во-первых, надо максимально проводить unit-тестирование. Unit-тесты 1) простые 2) быстрые 3) поддерживаемые. Значит надо максимум выносить в независимые модули.

Во-вторых, если что-то невозможно вынести в автономный модуль, то можно попробовать сделать это как композицию автономных модулей. Аналогия из веба - тонкие контроллеры. Обычно действие контроллера комбинирует действия нескольких модулей - изменения в БД, запуск фоновых задач и т.д. Это очень легко протестировать, особенно если стаббить большую часть комбинируемых модулей (т.е. код не вызывается, а лишь имитируется его вызов). Тесты контроллеров тоже очень простые, быстрые и поддерживаемые.
Попробуй найти что-то подобное веб-контроллерам в своём игровом движке. наверняка у тебя что-то отвечает за обработку большей части игровых событий, как встроенных в движок, так и кастомных (из скриптов).

И только потом уже переходить к интеграционным тестем, которые я всей душой ненавижу и не пишу вообще.

>>274244 (OP)
Очень просто, всякие пересечения -преобразования считаешь вручную на калькуляторе или каком-нибудь математическом пакете. Можно использовать другой движок как эталон, и в нем посчитать ожидаемые результаты для тестов.

>>274285
>>274261
>>274260
>>274248
Спасибо всем.

>>274244 (OP)
Годная тема! Только на C++ тут далеко не уедешь, будет адов гемморой делать мокапы. Лично сижу на Юнити с NSpec для тестов. И надо сразу писать код так чтобы он был тестируемым.
> Чтобы для каждого преобразования придумать пусть даже по 5 тестов
По идее такое не нужно. Нужно "типичный случай" и "крайние случаи". Остальные будешь добавлять если баги найдёшь.
> Как мне составить юнит тест для точки пересечения треугольников и чтобы еще там с точностью не было проблем?
Такие тесты обычно делают с определённой точностью. Если расхождение например не более 0.001 то считается что совпало.
>>274248
Сам рендер нет. Но можно например определить что в рендер уходят нужные команды.

>>274244 (OP)
Используй интеграционные тесты, в твоем случае это самый нормальный вариант. Если пишешь что-то серьезное, то лучше сразу садись за TDD. Тесты после кода писать крайне уныло и быстро заебет, плюс это тупо неэффективно. Я работаю на юнити, и вместо тестов просто запускаю сцену и проверяю, код же мне в консоль пишет как себя чувствует. Так себе метод работы, но тдд я не стал вводить сразу, а писать на уже работающий код тесты... конечно это неплохо, но пиздец как влом. Да и не весело это.

>>274246
> но там пишут в стиле сишки.
Потому что умные указатели - говно для инвалидов, не умеющих в простую логику и вообще код. Насрал всем за шиворот, кто использует умные указатели и прочие ненужные навороты, которые реализовываются за двадцать секунд.

>>274761
Ты долбоёб и кукаретик. Умные указатели различным образом ограничивают твои возможности. Это нужно, чтобы случайно не сделать какую-нибудь хуйню. Это средство автоматической проверки кода на корректность. Как статическая типизация. Ты можешь быть супер задротом и мега программером, но случайно допустить опечатку, из-за которой разыменуется нулевой указатель или ещё какая-нибудь хуйня произойдёт. Умные указатели гарантируют корректность кода на этапе компиляции.

>>274979
Ты понимаешь, о чём говоришь? Умные указатели - это не статик_ассерты, которые дают пизды за неверный код. Это немного другой инструмент, который мешает писать чистый код и напрямую работать с памятью. Если кому-то они по душе - эти программисты могут уйти в крайность и обмазаться джавой. В моём представлении у C++ не должно быть таких ограничителей, которые больше похожи на костыли для инвалидов без ног.

>>275089
>Мне это не нужно, значит это не должно существовать. НЕЛЬЗЯ Я СКАЗАЛ! УБЕРИТЕ!

>>275109
Зачем убирать? Пидоры, которые не умеют программировать, смогут нагородить костылей и без STL. Я же, являясь опытным программистом, высказал своё мнение о них.

>>275150
>Я же, являясь опытным программистом, высказал своё мнение о них.
Пока что ты высказал, что предпочитаешь ловить ошибки доступа к памяти в рантайме вместо того, чтобы управлять памятью статически. Дай угадаю, ты считаешь, что Rust НИНУЖЕН?

>>275172
Управлять памятью статически? Чего? Нет же, это не тот инструмент, который позволял бы так делать. Раст я не использовал, поэтому могу сказать, что сейчас он мне не нужен.

>>274761
Кто-то пытается писать на С++ как на С, и этот кто-то - идиот.

>>275220
>Кто-то пытается писать на С++ как на С, и этот кто-то - идиот.
Кармак идиот? Ясно.
>>275213
>Юнит-тесты - это дно.
>В игорях тестировать нужно только алгоритмы и ...
И как ты собрался алгоритмы тестировать не юнит-тестами?
>Причем тест должен быть сразу как типичный юзкейс использования функциональности - т.е вызов кода определения пересечение луча и треугольника будет таким же как и везде в использовании.
А, всё таки юнит-тестами? Складывается впечатление, что ты о тестировании вообще ничего не знаешь.
>НЕ ПИШИТЕ ТЕСТОВ РАДИ ТЕСТОВ. ОНИ НЕ НУЖНЫ.
Так какие именно тесты не нужны? Юнит? Тесты, которые легко пишутся, естественно выглядят и позволяют отловить 90% ошибок кода - не нужны?

>юнити
>юнит тесты
>алгоритмы
Только почему гуглплей и стим говном завален, а, кармаки?

>>275263
Ну я свою первую программу на рельсах тоже написал не зная о тестировании вообще. Правда мне хватило мозгов не отдавать её заказчику в таком виде, а засесть за учебники. Видимо, вау-эффект от современных средств разработки действует. "Ого, я написал программу, которая работает. Ну всё, пора выкладывать в стор, через месяц буду миллионером"

>>274244 (OP)
эм. во-первых нахуя ты в математику самопальную полез? вроде есть готовые неплохие решения. по твоему сабжу - юнит тестированию графика вообще почти не поддается. теоретически _можно_ устроить типизированные тесты, скажем, для пересечения моделек, но овчинка не стоит выделки и кучка макак "на глазок" протестирует эффективнее. в студиях, судя по всему, примерно так. дебаггер твой лучший друг, кирилл.

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

>>275364
> в случае падения твоего дерьма память не будет освобождаться
То есть я запускаю четыре кириллодвижка, роняю их, а потом в диспетчере задач у меня 90% оперативной памяти забито... Чем? System yoba Application? Idle?

>>275422
если у тебя винда, вряд ли тебе диспетчер или процесс експлорер правильную картину нарисуют. даже неправильно закрытые окна могут давать охуенные утечки (постквитмесседж или вм_дестрой). на линухах с этим лучше. такие дела.

>>275437
Вопрос можно отвязать от оси. Если после закрытия приложения память по-твоему не чистится, то на что она выделяется?

>>275439
к сожалению, нельзя отвязать. насчет окошек - если просто внезапно послать постквитмесседж или вм_дестрой, во-первых, "ошметки" от окна будут занимать память, потому что в силу того что это винда есть еще системный код, который по вм_клоз освобождает память на контролы, во-вторых, код на вм_клоз в вндпроке не будет выполнен, а там обычно освобождают память. тк процесс завершится, хер ты уже увидишь где-то в диспетчере память. чтобы проверить напиши прогу которая в цикле делает и ломает неправильно окно и посмотри будет ли потом система тормозить. в линуксе иксы тебе сами все освободят правильно.

>>275447
это просто пример, вообще у тебя никаких гарантий что память будет освобождена правильно в случае сбоя, так что лучше перестраховываться птрами.

>>275262
>И как ты собрался алгоритмы тестировать не юнит-тестами?
Чувак просто плохо понимает, что такое юнит-тестирование.

>>275452
В случае сбоя вся память принадлежащая процессу освобождается, а вот память, которая была занята другими процессами и системой вследствие запуска и падения этого приложения может быть не освобождена. Вот только забивать этим готову не стоит.

>>275493
>Ты совсем еблан, если после new забываешь написать delete?
Ты еблан, если считаешь, будто в более-менее крупном проекте это не происходит периодически. Дали вам shared_ptr, который как обычный указатель, только сам освобождается - нет, хотят говно жрать и удивлятсья утечкам памяти. Только полный долбоеб считает, будто контроль корректности программы на этапе компиляции бывает лишним.

>>275493
>>птры хоть неплохо повышают шанс что память освободится.
>Мы тут рулеточку крутим, или всё же программируем?
Ты слышал про такую штуку как Valgrind? Ты слышал, что Rust НИКОГДА не будет гарантировать отсутствие утечек памяти. Никто не может на 100% определить отсутствие утечек памяти на этапе компиляции, это невозможно в реальном мире. Поэтому да, вероятности решают.

>>275509
> сам освобождается
Нихуя себе! А откуда мне знать, как он освободится? Почему я должен вникать в подробности этого костыля, если я могу просто удалить в цикле сырые указатели? Такой код будет легче восприниматься и быстрее работать, а это очевидные плюсы. А минусы видят только рулеточники, у которых shared_unique_scoped_ptr удаляются сами с какой-то вероятностью. Вообще охуеть, если честно. Я понимаю, что они работают не так, но ты их описал именно так.

>>275510
Я могу на 100% определить отсутствие утечек памяти на этапе компиляции.

>>275509
>будто в более-менее крупном проекте
Мы о киррилоигре тут говорим, не забыл? Все данные обычно трех типов - большие данные, меши, текстуры, и т.п., которые загружаются менеджером ресурсов, убиваются им же. Данные сцены - компоненты, которые менеджерятся сценой, создаются убиваются в одном месте. Данные рендера, обычно несколько больших буферов, куда из сцены каждый кадр собирается стейт для отрисовки. В результате владелец каждого ресурса строго определен, время жизни тоже, умные указатели нахуй не нужны. Даже наоборот, без них можно убивать/забирать память большими кусками, не вызывая сотни раз деструкторы.

Умные указатели нужны, когда явного владельца у ресурса нет, например, в какой-нибудь редактор хранит ссылки на старые копии ресурсов в недрах котроллера анду/реду, да и там обычно лучше явного владельца прописывать, и контролировать расход памяти.

>>275575
А для произвольной программы сможешь сказать, остановится она или зациклится?

>>275583
Я знаю, что такое проблема остановки и да, я могу сказать, зациклится программа или нет. Когда я пишу циклы - я задаю им какие-то интервалы, на которых они выполняются. Это демонстрация моего навыка.

>>275582
И чем такой проект плох? Чётко определённая архитектура, явные легкоразличимые связи, большая скорость работы. Я думаю, все движки примерно так и работают.

>>275446
>если просто внезапно послать постквитмесседж
Это идиоматичный способ завершать своё приложение. И не послать, а вызвать.
>вм_дестрой
Это идиоматичный способ закрывать свои открытые окна, не выходя из программы.
>тк процесс завершится
, то встроенный в систему сборщик мусора очистит всю память процесса. Ты думаешь, за двадцать лет, которые винда существует, она ещё не научилась это делать? По завершению процесса, даже если это падение, все хэндлы, открытые этим процессом, закрываются. Сие даже в мсдне было написано где-то. Более того, существует quick'n'dirty стиль написания утилиток - когда ты делаешь одноразовый скрипт, который открывает файлы, выделяет память, делает ещё что-то и сразу закрывается, то рекомендуется не ебать себе мозг, и не закрывать файлы/освобождать память, потому что система всё равно это сделает.
>>275447
Вот оно как. Достаточно лишь набросать много типа умных слов в одном сообщении, и ты уже охуенный специалист.

>>276236
> И не послать, а вызвать.
И как от этого изменится смысл?

>>276243
Ты не посылаешь функции, а вызываешь. И для того, кто понимает разницу, то сообщение перестаёт выглядеть таким умным.
Собственно, в винде есть лишь два один легитимный способ взаимодействия между окнами - сообщения (файлы, пайпинг и прочее тсп рассматривать не буду, потому что). Причём окна не обязательно должны быть от одного процесса. Сообщения можно ставить в очередь (для этого есть PostMessage) или вызывать оконную функцию напрямую (SendMessage). Первое используется для того, чтобы рассказать окну о чём-то, и тебе насрать, когда (может и несколько секунд пройти) и как окно на это отреагирует - "тётя Ася приехала" говоришь ты ему, а дальше - его проблемы. Второе используется, когда реакция окна на сообщение тебе важна, например, это edit, с которого ты хочешь получить строку. Причём есть куча типовых сообщений, которые ты посылаешь часто и много, например, те же WM_GETTEXT и WM_SETTEXT, для них были придуманы свои функции (GetWindowText, SetWindowText в данном случае), которые просто вызывают SendMessage. Как ты уже, наверное, догадался, функция PostQuitMessage "posts quit message", то есть, добавляет в очередь сообщений окна сообщение WM_QUIT, что, собственно, ничем таким страшным не является и происходит каждый раз, как ты нажимаешь на крестик в правом углу единственного окна программы. После получения WM_QUIT окно последовательно получает WM_CLOSE и WM_DESTROY, потом всё закрывается. Там ещё что-то происходит, но я уже не помню, что и в каком порядке. Так вот, как видишь, в свете вот этого, написанное в том посте является полной хуйнёй.
По-моему, в туториалах по винапи от Icszelion, был жизненный цикл виндового приложения расписан в подробностях - можешь поискать и почитать. На мсдн тоже есть, но там хуй что найдёшь, и слов многовато. А что тот наркоман читал - хуй его знает. Возможно, у него была-таки утечка памяти, поэтому он умудрился загнать систему в своп, после чего сделал вывод про плохой WM_DESTROY из-за которого всё тормозит.

>>276210
>И чем такой проект плох?
Я и говорю, что в играх умные указатели обычно излишни, поскольку архитектура обычно простая.

>>276205
>Я знаю, что такое проблема остановки и да, я могу сказать, зациклится программа или нет. Когда я пишу циклы - я задаю им какие-то интервалы, на которых они выполняются.
А если вместо цикла рекурсия?

>>275493
ты в глаза долбишься? нет, альтернативно одаренный, я не имею в виду забытые delete (кстати обычно использовать нью пиздец дебильная идея, только для мелочей он подходит). в случае краша твоего дерьма память, выделенная процессу, должна бы освободиться, но совсем не факт, что на винде это произойдет нормально.

>>275574
ты ведь понимаешь, что всегда есть шанс что делеты твои не будут вызваны? а тут у тебя память освободится при любом раскладе и непредвиденной ситуации.

>>276236
хехех, а может и не всегда очистит. семерка вроде таким страдала, насчет 8 и 10 хз. речь о памяти на сами нарисованные окна, кнопочки и т.д. там немного, конечно, но все равно это плохо.

>>276606
>семерка вроде таким страдала, насчет 8 и 10
8. На 7 все норм.

>>276262
чувак, сначала посылается вм_клоз, потом вм_дестрой и вм_квит (последние 2 автоматом). на вм_дестрой у тебя должна вроде еще и память на нарисованное окно с контролами освободиться, поэтому лучше использовать вм_клоз, а не вм_дестрой или вм_квит.

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

>>276610
Такое ещё до XP было. Примерно тогда, когда придумали концепцию страничной памяти.

>>276629
Вообще, на вм_клоз можно забить, и обрабатывать только вм_дестрой, и в этот момент освобождать память и постить квит месседж. Чего вы тут усираетесь - не пойму.

И да, не нужно освобождать контролы, которые являются чилдренами закрываемого окна, это винда делает сама. Есть смысл освобождать левые объекты, типа шрифтов и всего такого.

>>276599
> шанс что делеты твои не будут вызваны
Что? Космические лучи, что-ли? Квантовые флуктуации? Чудеса?

>>276579
> кстати обычно использовать нью пиздец дебильная идея, только для мелочей он подходит
Можно спросить, чем ты его заменяешь? Просто создаёшь объекты и берёшь их адреса?

>>277089
тк я пишу под виндой, для маленьких временных объектов нью, для объектов на несколько кб делаю свою кучу и выделяю память в ней, если надо невъебенно большой буфер - виртуалаллок.

>>277087
внезапное падение, например. алсо если у тебя 2+ потоков, и наебнется тот, что без делетов, они не будут вызваны (если не отловить падение)

>>276803
есть немного.

>>276702
оказывается много народа удаляет объекты в вм_клоз, поэтому лучше не рисковать.

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

>>277239
Ну тогда наебнётся всё приложение и ось сама всё освободит

>>277323
пойми, это винда, у тебя на самом деле нет гарантий что все освободится правильно, хотя в документации написано обратное. на линухе, кстати, освободится нормально.

>>277338
Бля венде посрать, какие данные ей освобождать, она работает с такой абстракцией, как страницы памяти. Она просто освобождает все страницы, которыми обладало приложение. Суперпримитивная конструкция гарантирует отсутствие утечек памяти после завершения процесса. И в линуксе сделано так-же.

>>275150
Лол. Посмотрите на него.

ВНИМАНИЕ!! ACHTUNG!! WARNING!! POZOR!!
В треде детектирован потенциальный пердосектант! Без паники! Всем разойтись по каютам и вставить консолечку в срачечку, бгггг!

>>278297
>2016
>кодить не под линкусом
Дай угадаю, ты флешер? Жнитиребенок?

>>279227
>любой год
>пользоваться прыщами

>>274248
>Рендер уже никак
Ну почему, рендеришь сцену в текстуру и сравниваешь с референсным рендером, сохраненным в картинке. Для одной сцены желательно сделать несколько скриншотов в разные моменты (имеет смысл если есть какая-нибудь анимация на сцене, или партиклы) и с разных ракурсов.

Имеешь два таргета в твоем проекте. Один тебе запустит тесты и просто сохранит скриншоты в файлы (чтобы использовать как референсы), другой - собственно тест, запустит все и сравнит результаты со взятыми из файла, если нашлись расхождения более чем в N пикселей то тест фейлится, а скрины (референс, реальный и разница) сохраняются рядом.

Ебли много, конечно. Но если ты движок именно делаешь то без такого никуда.

>>277087
Исключения. В С++ практически все потенциально может бросить исключение.
Незапланированный выход из функции (ну тип ретурн который вообще не должен вызываться, но вызывается).

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

>>279227
Кек, когда под Линуксы будет вижуал студия и все тулзы от АМД и НВидиа, тогда можно их использовать. И дрова для видеокарт когда можно будет без ебли ставить.

>>280743
>И дрова для видеокарт когда можно будет без ебли ставить.
У меня давно уже такой проблемы нет, за последние 10 лет линукс в плане юзабельности сильно прогрессировал.
Но вот студии нет, беда. Жалко даже не столько студии (нетбинс тот же вон усиленно пытается на нее походить), сколько вижуал ассиста, вот его аналогов на линуксе нет.

>>275574
А если ты рассылаешь указатель на владение нескольким объектам, например. И время жизни владельцев неизвестно (точнее, не известно, в каком порядке удалятся владельцы или окончат использовать сырой указатель), как ты в таком случае будешь определять, надо ли удалить объект или нет?