Изучение C++ поможет для Создания Настольных приложений Fast/No-Additional-Requirements? [закрытый]
inttypes красная сельдь, вы получаете то же предупреждение от myPrintf("%lld", 1LL);. Он предупреждает об использовании ll, который в вашей программе (правильно) доставляется макросом inttypes.
Это похмелье от более старых версий MinGW, где форматирование printf было перенаправлено через MSVCRT, который не обрабатывал %lld, поэтому было уместно предупредить.
Вы можете решить проблему, добавив новую верхнюю строку в файл (до включения любого стандарта):
#define __USE_MINGW_ANSI_STDIO 1
и затем используя следующий атрибут:
__attribute__((format(__MINGW_PRINTF_FORMAT, 1, 2)))
static void myPrintf(const char* fmt, ...)
[ 1115] Это инструктирует mingw-w64 использовать собственную реализацию printf, которая соответствует стандартам ISO, и соответственно получать -Wformat предупреждений. Ссылка на документацию
В моей системе (g ++ 8.2.1) использование %lld и т. Д. На самом деле работает правильно даже без первой строки, поэтому я подозреваю, что они могут иметь по умолчанию исправлено использование ISO stdio вместо MS stdio. Или, возможно, теперь MS stdio знает о %lld.
Возможно, стоит сообщить об ошибке, чтобы указать, что __attribute__((format(printf должен автоматически работать должным образом в зависимости от используемого stdio, без необходимости делать этот обходной путь.
9 ответов
Если Вы хотите создать Приложения Windows, которые будут работать без платформ, таких как.NET или виртуальные машины/интерпретаторы, то Ваш единственный действительно жизнеспособный выбор будет Visual Basic или C/C++
Я записал некоторые маленькие Приложения Windows прежде в коде C++, и существует определенно преимущество с точки зрения скорости и простоты развертывания, за счет трудности, повышающейся для разработки. C++ может быть очень быстрым, исходно компиляции, имеет много функций современного языка и широкой поддержки. Компромисс - то, что вероятно, что необходимо будет написать больше кода в определенных ситуациях или искать библиотеки, любят Повышение, которые обеспечивают функциональность, которая Вы после.
Как программист, работающий в C++ и особенно в C, хороший опыт для помощи Вам понять что-то просто немного ближе к машине, чем говорят.NET, Java или язык сценариев как VBScript, Python, Perl и т.д. Это не обязательно сделает Вас лучшим программистом, но если Вы открыты для извлечения новых уроков из него, можно найти, что это помогает Вам получить новое представление о программном обеспечении. В конце концов, большинство платформ и систем, от которых Вы зависите, записаны в чистом C, таким образом, Вам никогда не будет причинять боль понимать основы. C++ является другим животным от прямого C, но если Вы разработаете в C++ для Windows, то Вы будете, вероятно, работать в соединении C и C++ для работы с Windows APIs, таким образом, это будет иметь эффект струйки вниз.
да, C++ является абсолютно большим. Проверьте QT. Это имеет большой Python, связывающий также, таким образом, можно легко моделировать в Python, и когда/если Вам нужна дополнительная производительность, портирование на C++ главным образом 1:1 перевод.
Но на самом деле, запись C++ не так трудна также, когда у Вас есть большая платформа, худшая часть пишет все объявления класса :-)
Я записал приложения Windows C++ в течение 10 лет и переключился на c# приблизительно 2 года назад для работы над последним продуктом. Я смущен тем, насколько вызывающий жалость приложение C#. Требуется 20 секунд для запуска, необходимо ожидать приблизительно секунда его для переключения между экранами. Я использовал некоторое третье лицо библиотека программ управления GUI, и это пропускает память как решето! Мое выполнение приложения в 150 meg и его выполнение едва что-либо.
Я надеюсь возвращаться к C++.
Можно использовать MFC, это будет намного более быстро, чем .NET. Или, если Вы действительно хотите гореть, проверить WTL - хотя, нет большого количества документации для этого. Я предлагаю, чтобы Вы пошли или с MFC или с QT, потому что Вы найдете много хорошей информации и учебных руководств для них.
Я вижу, что C# может быть более быстрым для разработки с, и возможно в некоторой будущей версии это будет более быстрым и меньшим.
Вы будете ненавидеть мой ответ:
Самые большие узкие места в разработке GUI обычно не из-за языка. В конце концов, большую часть времени в большинстве приложений UI бездействует, ожидая некоторого ввода данных пользователем. Я уже могу услышать Ваши крики, но я сказал в большинстве приложений.
Давайте поместим его этот путь: Я вполне уверен, что можно разработать хороший UI сверху.Net CLR. Изучение C++ является хорошей вещью, но не решит свойственные проблемы разработки хорошего UI.
Как всегда. Это зависит. Пока Вы избегаете microsofts больших Платформ, как MFC, .NET и т.д., Ваши приложения могут сверкать быстро, но трудно кодировать. Ваше преимущество: Вы действительно изучите, как окна работают позади его хорошей (?) поверхности. Просто изучите код инициализации для COM-объектов, и Вы знаете то, что я имею в виду. Вы никогда не будете видеть такие вещи в VB или C#
Необходимо программировать каждую кнопку, каждое окно и каждое управление собой, отправляя глупые сообщения окна, однако Ваши приложения являются небольшими, очень маленькими. Это - искусство, о котором забывают:
Запишите маленькие, быстрые программы
Удачи!
Если Вы будете стремиться изучать сырые данные, песчаные детали Win32, то C++ получит Вас там. Если Вы не будете, то Вы закончите тем, что использовали набор оберток так или иначе. Для чего-то как маленькая утилита или особенно что-то как расширение оболочки (где попытка использовать.NET вызовет Вас проблемы так или иначе), C++ позволит Вам написать эффективный код с абсолютным минимумом во внешних зависимостях. Для объемного приложения YMMV - большая медлительность UI там прибывает из плохого дизайна: наивные алгоритмы, нежелание отделить нетривиальные операции на отдельный поток (потоки), уверенность в плохо записанных сторонних компонентах вместо пользовательских элементов управления... Ошибки легко сделаны на любом языке.
Вот мой честный ответ на это.
Во-первых, я думаю, что каждый программист должен изучить C/C++ только для того, что путем изучения C++ Вы узнаете о программировании. Это - язык системного уровня. Необходимо рассмотреть более прекрасные детали управления памятью и т.д. Я потрясен в том, сколько программистов не понимает основополагающих аспектов языка программирования или компьютерной системы. Путем изучения C/C++ Вы вынуждаете себя понять программирование на более близком уровне. Вдобавок ко всему, если Вы изучаете, как программировать в C/C++, можно программировать почти в чем-либо.
Это не должно говорить, что C/C++ всегда является правильным инструментом для задания. Это может быть общая боль, чтобы отладить и занять больше времени для написания большего количества значимого кода. Однако это идеально подходит для тех ситуаций, где Вам нужен неограниченный контроль того, как программа выполняется.
Это идет для высказывания, я не предпочитаю C/C++ для программирования UI. Все еще необходимо использовать платформу работы с окнами, характерную для ОС, на которой Вы работаете (MFC, Win32, Мотив, GTK, QT, и т.д.). Эти платформы не предоставляют себя легким кривым обучения. По крайней мере, для разработки Windows.NET является действительно будущим разработки UI (даже при том, что удивительно MFC получил главную перестройку для Vista, которая наполняет.NET еще, даже не делает). Если Вы пишете свой UI в.NET, легче поддержать и для других для поддержания.
Я обычно пишу свой UI в.NET и бэкенд в C++.
Да и нет. Это - все об оптимизации... И так как C++ позволяет Вам работать на более низком уровне, который C++ является одним из лучших языков для записи быстрых приложений. Однако те, которые механика низкого уровня, реализованная в C++, могла быть очень раздражающей, если Вы привыкли к более абстрактным подходам к ООП. Тестирование Вашего программного обеспечения в C++ обычно является долгим процессом. При поиске скорости так или иначе C++ определенно был бы одним из лучшего выбора.
C ++ действительно потенциально может дать вам более компактное, более эффективное и быстрое приложение (если вы все сделаете правильно).
Однако платформа .NET создана для удобства с точки зрения разработчика; значительное улучшение по сравнению с Win32 API или MFC, которое может показаться тяжелым по сравнению с этим. Поэтому подумайте, как вы будете реализовывать аспекты, для которых ваше приложение зависит от .NET (есть другие доступные фреймворки, которые могут быть проще, чем MFC или Win32 API) , а также рассмотреть стоимость и лицензионные вопросы использования таких фреймворков; например, бесплатная версия VC ++ Express Edition, например, не включает поддержку MFC.
Если вы знаете, в каком месте ваше приложение тормозит, решением может быть C ++ / CLI; позволяя вам смешивать управляемый и собственный код для ускорения работы тех частей, которые в нем нуждаются. Однако если по сути медленнее графический интерфейс, а не обработка приложения; это не может быть полезным путем.