Я люблю C#. После университета моим первым настоящим проектом по программированию была игра, написанная на Unity. И я сразу же влюбился в этот язык: он казался таким свежим. И был похож на Java… если бы в Oracle по-настоящему заботились о Java, это вернуло бы короткий золотой век Java. Слышал, что с тех пор они перешли на цикл ещё быстрее, так что всё могло измениться.
Я по-прежнему люблю этот язык. Может, он и не самый модный, но всё равно способен делать что угодно. Пример — многопоточность. Думаете, это сложно? Тогда попробуйте в Dart поиграть с Isolate и поймёте, как хорошо иметь C#.
В последние несколько лет меня стала очень беспокоить судьба языка. Я поделился своими мыслями в комментарии здесь. И раз уж комментарий привлёк так много внимания — решил конкретизировать его идеи.
Если вы пишете на C++, то скорее всего сталкивались с тем, что компиляция, кодогенерация и компоновка проектов, написанных на нём, занимают время и с развитием проекта начинают мешать как CI конвейеру так и итерации разработки на рабочем месте. Наша команда не понаслышке знает об этих проблемах, и в этой статье мы хотим поделиться опытом внедрения широко известного в узких кругах инструмента - сборочной системы FASTBuild.
Так уж случилось, что я пишу код для разных IoT-железок, связанных с электричеством, типа зарядных станций автомобилей. Поскольку аппаратных ресурсов, как правило, вполне достаточно, то основным фокусом является не экономия каждого байта и такта процессора, а понятный и надежный код. Поэтому в проекте разрабатывают под Embedded Linux и в качестве основного языка используют C++ в его современном варианте - C++17, активно поглядывая на фичи из стандарта 20-го года и новее.
Иногда запускаются новые проекты на той же платформе, с теми же процессами и с переиспользованием многих уже существующих компонентов, и тогда в эти проекты мы ищем программистов, с учетом вышесказанного - программистов на C++. В embedded, тем не менее, чистый C все еще очень популярен, и нередко собеседоваться на вакансию C++ Developer'а приходят именно сишники. Логика у человека простая: языки, на первый взгляд, довольно близкие, базовый синтаксис одинаков, про ООП кандидат что-то слышал, и значит, основная база уже есть и он сможет легко освоить C++ за 21 день в процессе работы, поэтому можно наплести про "с C++ тоже работал", начать писать на "Си с классами" и все получится.
Уже скоро стартует С++ Russia. И в преддверии конференции хотим поделиться с хабражителями описаниями докладов.
С++ Russia — это всегда хардкор. В этот раз поговорим про ассемблер, асинхронные движки с корутинами, исключения, GPGPU и многое другое. Будут и низкоуровневые оптимизации, и метапрограммирование, и «кишочки», и конкурентность с многопоточностью.
Среди спикеров будут члены комитета по стандартизации C++, контрибьюторы известных проектов, один из авторов языка Swift (внезапно!), авторы книг и курсов, разработчики из крупных компаний. А также Антон Полухин @antoshkka, сочетающий в себе почти все перечисленное.
Под катом программа с описанием докладов, для вашего удобства разбили ее на тематические блоки.
Прим. Wunder Fund: В статье описаны базовые подходы к работе с корутинами в 20м стандарте С++, на паре практических примеров разобраны шаблоны классов для промисов и фьючеров. По нашему скромному мнению, можно было бы реализовать и поизящнее. Приходите к нам работать, если имеете сильные мнения о корутинах хе-хе.
Возникает такое ощущение, что тема реализации корутин в C++20 окутана серьёзной неопределённостью. Полагаю, это так из-за того, что в проекте технической спецификации C++20 сказано, что работа над механизмами корутин всё ещё ведётся, в результате в данный момент нельзя ожидать полной поддержки этих механизмов компиляторами и стандартной библиотекой.Множество проблем, вероятно, возникает из-за отсутствия официальной документации по работе с корутинами. Нам дали синтаксическую поддержку корутин в C++ (co_yield и co_return), но не всё то, что я счёл бы признаками их полной библиотечной поддержки. В стандартной библиотеке имеются хуки и базовый функционал поддержки корутин, но нам приходится самостоятельно встраивать всё это в наши собственные классы. Я ожидаю, что полная поддержка корутин-генераторов появится в C++23.
Если вы — Python- или C#-разработчик и ожидаете увидеть в C++ простую механику работы с корутинами, то вас ждёт разочарование, так как фреймворк общего назначения C++20 недоработан. Учитывая это, можно отметить, что в интернете имеется множество публикаций, в состав кода, обсуждаемого в которых, входит шаблонный класс, поддерживающий корутины-генераторы. В этом материале вы найдёте шаблон корутины, применимый на практике, а также примеры кода. Всё это предваряется общими сведениями о корутинах.
В публикации Ленивые операции над множествами в C++ я показал, как можно проектировать ленивые операции над несколькими диапазонами. Теперь я хочу подробнее рассказать о важном решении, делающем такие операции удобными в использовании.
Один из основных моментов в интерфейсе ленивых операций над диапазонами — это возможность следующей записи
burst::merge(std::tie(range1, range2, ...));То есть возможность работать с произвольным набором исходных диапазонов.
В коде это будет выглядеть как-то так:
const auto odd = std::vector{1, 3, 5, 7};
const auto even = std::list{0, 2, 4, 6, 8};
const auto merged_range = burst::merge(std::tie(odd, even));
const auto expected = {0, 1, 2, 3, 4, 5, 6, 7, 8};
assert(merged_range == expected);Почему же это так важно, и что стоит за этой записью?
Ответ на вопрос "почему это важно" понятен. Во-первых, это красиво. Кроме того, удобно.
А вот что за этим стоит — и есть суть данной публикации.
Недавно наши ребята из движковой команды выпустили статью о том, как мы навели, «красивостей» в нашем внутреннем движке. Речь шла о концепциях и том, что было важно для нас при улучшении визуальной составляющей. В этой статье я хочу рассказать, как все работает с технической стороны.
В этом уроке мы научимся запускать программу в несколько потоков, создавать полноценные уровни из мини изображения, так же научимся открывать несколько окон, скрывать и выводить вперед.
В прошлой статье мы начали рассказ о рецептах, посвященных переводу Qt-приложений на рельсы High DPI, то есть адаптации этих приложений к мониторам высокой четкости.
Суть в том, что в ОС Windows давно есть такие настройки, как масштабирование шрифта и изображений (масштаб экрана), которые применяются для увеличения слишком малых элементов GUI на мониторах с высокой чёткостью (High DPI). Однако не каждое приложение, написанное на Qt, способно адекватно учитывать, применять этот самый масштаб экрана. Частая ситуация – приложение хорошо выглядит на Full HD (1920x1080), но стоит поставить монитор 4K (3840x2160) и увеличить масштаб экрана, то появляются многочисленные артефакты.
В этой статье мы продолжим разбор примеров и изложение рецептов. Будем делать это для более сложных случаев, связанных с сохранением размеров между запусками приложения, а именно с сохранением тех настроек пользователя, что связаны с размерами.
Данный текст является переводом недавнего поста Бена Крейга - одного из членов комитета С++. TL;DR для нетерпеливых: Networking TS/Asio (P2444) не получает общего одобрения комитета, модель Senders/Receivers (P2300) становится основным направлением развития асинхронного программирования в С++.
Всем привет.
Возможно, вы слышали обо мне по моей работе над freestanding C++, но я также вице-председатель Library Evolution Working Group (LEWG). Хотел бы поделиться с вами результатами недавнего голосования комитета по поводу будущего асинхронного программирования в C++. Опрос касался "Senders and Receivers"/S&R (P2300) и Networking TS/Asio (P2444).
Данная статья посвящена параллелизму в C++, сопутствующим сложностям и как их можно обойти, используя библиотеку oneAPI Threading Building Blocks (oneTBB) для упрощения параллельного программирования.
В этой статье я хочу поделиться несколькими нестандартными алгоритмами для быстрого возведения числа в степень, а также продемонстрировать их реализацию и сравнить их быстродействие в C++, C# и Java.
Сравнить точность алгоритмов можно прямо сейчас на этой странице.
В конце будет краткая памятка по тому, где и когда лучше применять какой из методов. При правильном выборе можно добиться увеличения скорости вычислений в 5 раз при погрешности ~1%, а иногда и вовсе без неё.
В своих предыдущих постах я описывал задачи, которые были решены скорее в академических целях. Сегодня я хочу поделиться реальным примером, который работает в продакшене. Речь пойдет о написании сопрограмм, которые можно прервать извне. Изначально мне это понадобилось для реализации механизма deadline или timeout (кому как больше нравится). Согласитесь, довольно часто возникающая задача. На этом примере я продемонстрирую использование еще нескольких возможностей, предоставляемых С++. Речь пойдет об await_transform и конструкторе объекта promise_type.
в этом уроке научимся запускать таймер выводить на экран, считать фреймы в секунду
обнулять таймер и ускорять /замедлять FPS
Как и любой другой инструмент, POSIX-сигналы имеют свои правила, как их использовать грамотно, надежно и безопасно. Они испокон веков описаны в самом стандарте POSIX, в стандартах языков программирования, в manpages, однако и по сей день я нередко встречаю связанные с этим грубые ошибки даже в коде опытных разработчиков, что в коммерческих проектах, что в открытых. Поэтому давайте поговорим о важном еще раз.
Размер современных приложений и сложность языка C++ превышают возможности людей по всестороннему анализу текста программ на обзорах кода. Компенсационная методология – статический анализ кода.