Поздравляю вас)
Но хочу сказать, что всё-таки у каждого языка своя ниша и не стоит противопоставлять C++ и Rust.
Меня поразило, как часто код на Rust работает правильно с первого раза, и как просто на нем писать асихронные и многопоточные приложения.
С++ и не задумывался как язык, который позволяет писать элементарный многопоточный код. Напоминаю, что девиз языка «Не плати за то, что не используется», поэтому С++ напоминает конструктор из бесконечного числа мельчайших деталей. Тем-более, в языке изначально не было заложено таких концепций, как «асинхронность» и «потоки», и были притянуты за уши в std лишь в C++11.
Со своими задачами C++ прекрасно справляется. Его стоит использовать там, где требования согласуются с его философией. С Rust точно так же…
И ничего удивительного нет в том, что в Rust X-фича сделана грамотнее, чем в плюсах.
При этом, я уверен, что в обоих языках есть свои плюсы и минусы. Но сравнивать их не нужно. У них абсолютно разная философия и область применения.
Можно поинтересоваться, что дают итераторы алгоритмам? Я не против std::array, сам его и использую, если что) Просто любопытно. С алгоритмами std и им подобными можно ведь и обычный С-массив юзать. Там так же и размер последовательности узнаем, и тип значения (вместо InputIt::value_type, используем decltype(*it)). Что еще требуют алгоритмы от итераторов? P. S. Напоминаю, что мне просто любопытно)
Итак, нужно признать, что для управления циклом игры мне пришлось прибегнуть к другому языку. Хотя технически ничто не мешало мне написать эту часть кода на C++. К тому же это не отменяет того факта, что 90% логики моей игры выполняется внутри команды компиляции g++, что довольно-таки потрясающе!
QuadTree стоило бы заменить на AABBTree. При правильном подходе AABBTree предоставляет впечатлительную производительность. Например, на ноуте с CoreI3 2.3 GHz на одном потоке 3к тел проверяет за 0.25 мсек при полном отсутствии движения, а если заставить все эти 3к двигаться, то за ~0.7 мсек формирует список пар. Но это 3 тысячи объектов, а не одна сотня.
в С++, кстати, даже используя возврат bool/int, в качестве флага ошибки, вместо исключений, можно делать это изящно без передачи «выходного» аргумента, с возвратом флага и значения, через структурированные привязки:
auto [result, data] = obj.CalculateSomething();
Также есть std::optional…
И в С++ препроцессор — это зло, особенно огорчает его наплевательское отношение к namespace. Для условной компиляции, есть if constexpr (compile-time) и шаблоны. Для макро-функций, есть constexpr выражения, которые не подставляют тупо строку, а вычисляют выражения, плюс делают это с учётом типов.
Ну так там C++/CX, а тут C++17) Можете почитать здесь. Там же можно в статьях найти сравнение производительности с С++/CX и с C#, посмотреть выступление с конференции CPPCON2017, ну и почитать прочие подробности. Проект еще не вышел в свет. Пока доступен только инсайдерам.
А сейчас на чём бы посоветовали писать GUI? Желательно ещё с хорошим и современным стилем программирования конкретно на C++11/14/17. Вот вот, кстати, должен выйти C++/winRT (обычный/стандарт С++17 без всяких модификаций, по типу C++/CLI, C++/CX), но это сугубо под Win 8.1 — 10. Короче, библиотека Windows Runtime во всей своей красе и без лишнего оверхэда, станет доступной в чистом С++17. Планируют включить её в VisualStudio 2017 v15.7.
чёт вы тут напутали всё напрочь. Вы знаете о существовании итераторов, контейнеров vector, list, и прочих в С++ и об аналогах в С#. Вы знаете о том, что с массивами в голом виде не работают? Знаете о том, что в шарпе утечку памяти получить сложнее, чем в С++ (не используя умные указатели)? Знаете о существовании в С++ std::array и скором появлении std::dynarray и о том, что подобные штуки люди сами пишут?
Вы не совсем верно поняли мой комментарий. Про то, что это обёртка winAPI я итак в курсе… MFC был сделан давным давно, с использованием далеко не самых лучших практик. WinAPI там так и лезет на ружу. Хоть этот MFC и призван упростить разработку GUI приложений под Win, но он всё-равно придерживается концепций, принятых в голом winAPI, и эти все передачи всяких кодов, определенных константами целочисленного типа… Помимо этого — это уже морально устаревший код (какой-то СИ с классами, а не С++11/14/17). Да, там есть множество фич, по типу сплиттеров и Docked-окон. Но выполнено это всё в ужасной, по сегодняшним меркам, манере.
MFC ужасен. Тот же winAPI, только с еще большей кучей грязи и не самого лучшего стиля программирования. Уж если упрощать взаимодействие с GUI для разработчиков, то путём полнейшей инкапсуляции всяких HWND и прочей ереси.
На en.cppreference.com посмотрите. Реализации пока нет и быть не может. Без макро-костылей и какой-нибудь другой вуду-технологии невозможно стащить source_location вызывающего в compile-time.
Вот после своего сообщения и пошел читать об proposal и попал в этот реп)
Так-то на этой неделе просто понадобился подобный календарь и с поддержкой constexpr выражений.
И тут такие новости)
Причем тут "рабочая память", когда ПО пишут команды разработчиков. Код должен быть понятным и храниться в памяти компьютера, а не в голове конкретного разработчика. Тем-более код по статистике чаще читается, а не пишется. И читается он не только автором, но и его коллегами и т.д.
Длина метода в 100+ строк — это уже не есть хорошо. По этому поводу Макконелл еще давно писал. А его книга "Совершенный код" — это классика, к которой все прислушиваются. У него по поводу размера метода отдельный раздел есть, где он пишет, что метод в идеале должен полностью помещаться на экране монитора (50-80 строк).
Плюс к этому, рекомендуется заменять комментарии, методами с подходящим названием.
А держать методы в уме (что вылетит из бошки очень быстро) — это не правильно, как по мне.
Но хочу сказать, что всё-таки у каждого языка своя ниша и не стоит противопоставлять C++ и Rust.
С++ и не задумывался как язык, который позволяет писать элементарный многопоточный код. Напоминаю, что девиз языка «Не плати за то, что не используется», поэтому С++ напоминает конструктор из бесконечного числа мельчайших деталей. Тем-более, в языке изначально не было заложено таких концепций, как «асинхронность» и «потоки», и были притянуты за уши в std лишь в C++11.
Со своими задачами C++ прекрасно справляется. Его стоит использовать там, где требования согласуются с его философией. С Rust точно так же…
И ничего удивительного нет в том, что в Rust X-фича сделана грамотнее, чем в плюсах.
При этом, я уверен, что в обоих языках есть свои плюсы и минусы. Но сравнивать их не нужно. У них абсолютно разная философия и область применения.
Также есть std::optional…
И в С++ препроцессор — это зло, особенно огорчает его наплевательское отношение к namespace. Для условной компиляции, есть if constexpr (compile-time) и шаблоны. Для макро-функций, есть constexpr выражения, которые не подставляют тупо строку, а вычисляют выражения, плюс делают это с учётом типов.
В C++ также разделяются разряды:
Перечисления в С++ также существуют строготипизированные. Вообще вам не стоило в статью втягивать С++
Так-то на этой неделе просто понадобился подобный календарь и с поддержкой constexpr выражений.
И тут такие новости)
Аналог календаря на днях, как раз, начинал писать вокруг chrono…
Причем тут "рабочая память", когда ПО пишут команды разработчиков. Код должен быть понятным и храниться в памяти компьютера, а не в голове конкретного разработчика. Тем-более код по статистике чаще читается, а не пишется. И читается он не только автором, но и его коллегами и т.д.
Длина метода в 100+ строк — это уже не есть хорошо. По этому поводу Макконелл еще давно писал. А его книга "Совершенный код" — это классика, к которой все прислушиваются. У него по поводу размера метода отдельный раздел есть, где он пишет, что метод в идеале должен полностью помещаться на экране монитора (50-80 строк).
Плюс к этому, рекомендуется заменять комментарии, методами с подходящим названием.
А держать методы в уме (что вылетит из бошки очень быстро) — это не правильно, как по мне.