Почему C ++ все еще предпочитает создавать тяжелые приложения с графическим интерфейсом поверх последних динамических языков? [закрыто]

46

Я вижу, что большинство приложений, которые содержат тяжелый GUI-контент, обычно разрабатываются на C ++. Большинство игр / браузеров написаны на C ++.

Разве мы не можем просто разработать лучшие приложения с графическим интерфейсом на основе новейших динамических языков? Я знаю, что Java не будет отличным выбором. Но как насчет таких языков, как python, которые изначально созданы на C? Разве последние языки не должны быть лучше, чем их предки? Почему мы все еще должны отдавать предпочтение старому С ++ над последними языками?

И я также хотел бы знать, что отвечает за C ++ за лучшую скорость обработки GUI? С другой стороны, чего не хватает другим новейшим языкам?

programming-languages c++

— Вамси Эмани
источник

22

Если вы думаете, что Java является «динамическим» языком, то вы глубоко озадачены тем, что означает это слово в этом контексте.

— Майк Баранчак

15

@ Майк Баранчак: Это длинная история. По сути, сначала в Стэнфорде, а затем в Sun Research был исследовательский проект под названием Self. Self - это язык программирования в семействе Smalltalk, который является более простым, более мощным, более выразительным и, что наиболее важно, значительно более динамичным, чем Smalltalk. Поскольку он был разработан как язык программирования для разработки целых систем (как и всех диалектов Smalltalk), включая (но не ограничиваясь ими) настольные приложения, серверы, операционные системы, драйверы устройств, он должен был быть невероятно быстрым. Итак, команда Self изобрела целую кучу новых ...

— Йорг Миттаг

15

... методы оптимизации, и когда Self VM появилась в 1987 году (и тем более во втором поколении в 1992 году), это было быстро. Это было быстрее, чем любая другая виртуальная машина Smalltalk. Система самообслуживания поставляется с большим количеством примеров кода, и один из этих примеров был переводчик Smalltalk написан в Себе, и даже , что было быстрее , чем любой другой Smalltalk VM. Self был быстрее, чем многие реализации C ++ в то время, и даже конкурировал с C. Ну, вы поняли. Это было быстро . Однако Sun решила, что им не нужен объектно-ориентированный язык программирования или быстрая ВМ, поэтому они ...

— Йорг Миттаг

15

... в основном голодал проект Self, иссякнув финансирование. Когда инженеры Self VM покинули Sun из-за разочарования, они были быстро подхвачены стартапом Smalltalk под названием LongView (более широко известным по названию своего большинства продуктов, опциональная система статического типа для Smalltalk: StrongTalk). LongView знал, что они никогда не смогут продавать статическую типизацию для Smalltalk, поэтому они думали, что они скорее продадут самый быстрый Smalltalk на планете, а затем включат в пакет StrongTalk в своего рода игре типа «Троянский конь». Они также поняли, что ни один из крутых ...

— Йорг W Mittag

15

... оптимизации, которые делала Self VM, были в какой-то степени специфичны для Self, но были применимы практически ко всем объектно-ориентированным языкам (или даже к любому языку вообще ). Итак, инженеры Self VM приступили к работе над Smalltalk VM, называемой Animorphic VM. Опять же, Animorphic VM была ослепительно быстрой (и до сих пор, на самом деле, даже несмотря на то, что кодовая база не была затронута в течение 15 лет или около того, она все еще может конкурировать с современными высокопроизводительными Smalltalks, JVM и .NET, особенно если принять с учетом того, что он использует гораздо меньше ресурсов, чем те, поскольку он был рассчитан на 486 с 20 мегабайтами ...

— Йорг Миттаг

58

Я один из тех, кто пишет приложения для C ++ GUI (в основном для Windows). С Qt, если быть точным. Мои причины:

Мне нравится C ++. Я фрилансер и обычно я могу выбирать свои инструменты (повезло мне!)
В управляемой среде вам может быть трудно использовать неуправляемый код (длинные WinAPI-объявления в C #, кто-нибудь?)
Меньше зависимостей, которые легче развернуть
Больше контроля над всем.
RAII (против GC). И даже если я выделяю с помощью new, я редко когда-либо deleteчто-либо явно, потому что я использую умные указатели или QObjectиерархию.
C ++ очень интересен в наши дни, я не могу дождаться, пока компилятор полностью поддержит новый стандарт.
Скорость (только в конце списка. Я знаю, что это не так важно для самого графического интерфейса, но он имеет тенденцию быть быстрее, потому что программы на C ++ не страдают от накладных расходов, которые увеличивают время выполнения, компиляция байтового кода и подобные технологии. программа.)

Как видите, это в основном личные предпочтения. Я считаю важным, чтобы моя работа была приятной, и C ++ предоставляет мне это.

— Тамас Селеи
источник

11

+1 Скорость, безусловно, главная причина, кроме личных предпочтений. Тем не менее, мне нравится "C ++ очень захватывающий в наши дни". Чтобы ответить на вопрос , а не @ Tamás Szelei: Конечно, вычисления быстро меняются благодаря новым идеям, парадигмам, технологиям, продуктам, но новейшие и лучшие из них не являются достоинством. C ++ существует уже некоторое время, и это не значит, что он устарел, скорее, он имеет давно доказанный послужной список по сравнению с новыми технологиями. Оригинальный текст Страуструпа (книга изобретателя) очень трудоемкий, но есть и другие хорошие книги, например, на oreilly.com.

— therobyouknow

1

@Tarnas Я думаю, что «всегда будет быстрее» немного узколобый / авторский, но недостаточно, чтобы оправдать понижение голоса ...

— Макс

2

В качестве неофициальной поддержки: я участвовал в различных проектах по созданию графических интерфейсов значительных размеров в Windows с использованием C ++ и JavaScript. Я также участвовал в различных проектах игровых приставок на C ++ и JavaScript. В обоих случаях было значительно больше проблем со скоростью и памятью в JavaScript.

— Gort the Robot

2

Опоздал на вечеринку, но можете ли вы рассказать о «менее / легко развертываемых зависимостях»?

— weberc2

2

Я использую C ++ более 20 лет. С 11, 14 и 17 добавлено много новых и замечательных функций. Вы можете почти использовать C ++ в качестве языка сценариев и при этом пользоваться преимуществами быстрой скорости. Когда я работаю с БОЛЬШИМИ данными, мне почти приходится использовать C ++, потому что любой другой язык будет работать на 10-1000 раз медленнее.

— Кемин Чжоу

32

Потому что скорость имеет значение.

Игры используют C ++ для основных задач, где важна производительность. Они используют динамические языки для задач сценариев, где важна гибкость.
Настольные приложения с графическим интерфейсом : Visual Studio, например, написан на .NET, а не на собственном C ++. Похоже, что он отлично работает для IDE, так как сама IDE не должна выполнять много задач, требующих высокой производительности. (Компилятор, компоновщик и другие инструменты не обязательно написаны на .NET - хотя, как указывает wawa в комментарии, некоторые, похоже, (например, VB.NET))
Браузеры тоже должны быть быстрыми. Ведь они как бы второстепенные ОС. С другой стороны, вы можете утверждать, что большие части Firefox фактически «написаны» на javascript, поскольку среда Mozilla, кажется, сильно зависит от javascript.

Подводя итог: я бы не сказал, что C ++ обязательно предпочтительнее, но если у вас есть узкое место в производительности, вам нужно подойти ближе к металлу, а затем вы встретите C ++ (ну, или C). Иногда будет проще сделать все на C ++ - на одном языке.

— Мартин Ба
источник

1

+1 Лучший ответ: это просто связано со скоростью как основной причиной использования C ++. Даже сами Microsoft признают, что C ++ лучше по производительности по сравнению с C # и Visual Basic - см. Их на страницах Visual Studio. Очень близким моментом является переносимость - если вы используете кроссплатформенные библиотеки, такие как Qt. Лучший ответ также потому, что это объективно, а не субъективно.

— therobyouknow

2

Ваш второй пункт не совсем верно. Компилятор VB.NET написан на VB.NET, а компилятор F # написан на F #. Компилятор C # не является, но из того, что было выпущено о проекте Roslyn, я думаю, что компилятор C # переписывается в C #.

— Уэсли Уайзер

5

Визуальный графический интерфейс студии (хром) написан (из vs2010) на c # и WPF. Обозреватель решений, система сборки, браузер кода и набор инструментов написаны на c # / c ++ с winforms. Компилятор написан на с ++.

— Мартин Беккет

Для большинства приложений для настольных компьютеров только механизмы рендеринга и компоновки (т. Е. Представление) должны быть быстрыми. В любом случае, модель обычно не проводит много времени, и контроллер тратит большую часть своего времени, просто ожидая, что пользователь что-то сделает (и лишь немногие пользователи могут щелкать 10 раз в секунду с какой-либо надежностью).

— Донал Феллоуз

@MartinBa: я бы отметил, что текущий компилятор для C # и VB (Roslyn) написан на C #.

— Jmoreno

18

Приложения с графическим интерфейсом, которые вы видите написанными на C ++, обычно делаются по устаревшим причинам. Python (с Qt или Gtk) очень жизнеспособен для приложений с графическим интерфейсом, как и C #, если вы работаете в Windows. При запуске чего-то нового, любой из них очень предпочтителен для C ++ из-за отсутствия необходимой сантехнической работы.

— Демиан Брехт
источник

5

+1 существующий код важен. Редко начинать с нуля при разработке новых программ

7

как использование Python с Qt более предпочтительно, чем использование C ++ с Qt? Если бы я начал новый проект сегодня, я бы все еще использовал C ++ для GUI. Потому что: а) это то, что я знаю, б) хорошо справляется со своей работой. То, что C ++ уже давно существует, не делает его «устаревшим».

— TZHX

2

@TZHX: «Это то, что я знаю» - это жизнеспособный аргумент. Если этого не сделать, то больше не нужно заботиться об управлении памятью, это огромный прирост производительности, и это может свести на нет усилия по изучению Python даже для одного проекта. Другой причиной использования Python является кросс-платформенность - с C ++ вы должны быть осторожны и принимать особые меры, тогда как python, скорее всего, будет работать.

— tdammers

4

Я не вижу никаких преимуществ использования PyQt вместо Qt с C ++ для тех, кто знает C ++.

— BenjaminB

13

С ++, скорее всего, тоже будет работать. С Python вам нужно беспокоиться о том, какую версию Python установил пользователь, или беспокоиться о его комплектации. На самом деле не нужно так много работы, чтобы «заботиться о памяти», если вы не делаете глупых ошибок. Я думаю, что многие люди считают «управление памятью» большим препятствием для работы с C ++, даже не зная, насколько это важно.

— TZHX

16

Потому что независимо от того, сколько тестов производительности показывают .NET и тому подобное, независимо от того, насколько они близки в тестах, в конце концов, приложение C ++ выходит на первое место. Это быстрее при холодной загрузке, это быстрее, и есть больше способов, которые можно улучшить.

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

Кроме того, C ++ в настоящее время довольно безопасен и довольно прост в использовании, особенно с такими фреймворками, как Qt или WTL.

— кодировщик
источник

2

+1: «Кроме того, C ++ в настоящее время довольно безопасен и довольно прост в использовании, особенно с такими фреймворками, как Qt ...» Я полностью согласен: я думаю, что большая сила не только в C ++, но в том, что (1 ) он скомпилирован в нативный код, (2) имеет разумный набор функций (ООП, шаблоны), (3) имеет очень хорошие фреймворки, такие как Qt. Это компенсирует тот факт, что язык довольно большой и трудный для изучения: если вы освоите приличное подмножество языка и несколько хороших библиотек, вы сможете по-настоящему продуктивно его использовать.

— Джорджио

10

Большинство игровых движков написаны на C ++. Также многие браузерные движки написаны на C ++. Но графический интерфейс браузера часто кодируется с использованием некоторого облегченного скрипта (JavaScript, Python). За исключением заметного Source Engine, большинство игровых движков также используют скриптовые языки (например, Lua или Python). [для справки: список игр со скриптами Lua ]

Также возьмите популярную библиотеку C ++ GUI, такую как Qt. В текущей версии (4.7) он использует QML для GUI. QML - это в основном JavaScript с привязками Qt.

Так что на самом деле нет C ++ против динамических языков, это смешано.

— Vartec
источник

[Нужна цитата]. Я знаю, что во многих играх используются языки сценариев, чтобы позволить пользователям расширять их, но, насколько я знаю, на самом деле не так много игр, использующих языки сценариев для своей функциональности release-binary.

— ProdigySim

1

@ProdigySim: я знаю несколько, которые делают. Помимо всего прочего, World of Warcraft (Lua + XML), серия Uncharted Dog от Naughty Dog (Lisp), серия Unreal (UnrealScript), игры, основанные на движках Torque и Unity, Dungeon Siege, NeverWinter Nights и многие другие. Игры, управляемые данными, становятся нормой, когда хостинг сценариев берет на себя большинство (если не все) функции пользовательского интерфейса и игровое состояние сверху вниз.

— Greyfade

@ProdigySim: даже если он скрыт от обычных пользователей, это не значит, что внутри они не используют скриптовые движки. По сути, разработчики игр имеют два варианта - создать свой собственный язык сценариев для моделей или использовать один из них общего назначения. Lua особенно хорош для игр, как правило, для систем реального времени.

— vartec

Исходный движок использует скриптовый язык Squirrel.

— cubuspl42

6

Первая причина будет: (старая) привычка

Вторая причина: меньшая надежность на виртуальных машинах, интерпретаторы, которые должны быть установлены, и т. Д.

И еще есть несколько отличных IDE для разработки кода на C ++.

— Roalt
источник

1

« все еще отличные IDE». Я бы сказал, Visual Studio и Eclipse являются передовыми и уже довольно давно.

— JBRWilkinson

@JBRWilkinson: я не говорил, что на других языках их тоже нет.

— Roalt

6

Причина в том, что у вас гораздо больше контроля над всем, что происходит. Если вы собираетесь писать фотошоп на C #, у вас будут серьезные проблемы с производительностью для некоторых задач. На более низком уровне языка с большим контролем вы можете использовать ярлыки, оптимизировать, где это необходимо, для более интенсивных задач. Конечно, это предполагает, что вы используете C ++ в неуправляемом коде, а не C ++ в .NET.

Смотрите здесь для быстрого примера.

— Ричард
источник

2

Adobe Lightroom, который является в основном подмножеством Photoshop, написан на Lua.

— Йорг Миттаг

4

@ Jörg: остальное - C ++. на самом деле это, вероятно, лучшая комбинация из доступных, C ++ для основы, Lua для остальных (хотя я все же предпочитаю C, а не C ++ для низкоуровневых вещей).

— Хавьер

2

@Javier: Да, Lightroom - это в основном алгоритмы обработки изображений из Photoshop (которые, вероятно, написаны в основном в сборке MMX / SSE) и SQLite3 (который написан в доисторическом ANSI C для переносимости), склеенные вместе с Lua. Adobe также разработала свою собственную Lua IDE, полностью на Lua. Кто-нибудь знает, какой графический инструментарий они используют? AFAIR Photoshop предшествует почти всем современным инструментам, так что это, вероятно, что-то домашнее?

— Йорг Миттаг

4

без обид, но если вы думаете, что ANSI C является доисторическим, вы читаете неправильные примеры кода

— Хавьер

6

C ++ статически типизирован. Это позволяет заранее оптимизировать выполнение кода, если компилятор подгонит ваши абстракции к доступным системным процессам на данной платформе. До сих пор динамическим языкам нужен дополнительный программный уровень (= интерпретатор), который замедляет доступ к системным ресурсам.

— poseid
источник

4

Большинство приведенных причин являются техническими или «над таблицей» ... вот причины бизнеса или «под таблицей»:

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

тупые пользователи: по крайней мере, в головах руководства. они по-прежнему считают, что их пользователи едва ли могут дважды щелкнуть «setup.exe». Если вы включите установку переводчика как часть установки, они будут качать головами из стороны в сторону.

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

— Кинджал Диксит
источник

Я бы сказал, что вы нарушаете исходный код, когда выпускаете приложение .NET. Посмотрите на Visual Studio, большая часть интерфейса разработана с формами WPF. Некоторые из ваших утверждений, конечно, верны, многие из сегодняшнего руководства были вчерашними разработчиками, плохие новости о том, что большинство сегодняшних фреймворков вряд ли будут действительны из-за сегодняшних изменений в компьютерах.

— Ramhound

Многие люди с большим опытом приобрели свой опыт, постоянно обновляясь. Они стремятся не изучать новые горячие языки (например, Паскаль в начале 1980-х) только потому, что они горячие, но только если они их используют или у них есть интересные идеи (например, Haskell).

— Дэвид Торнли

4

Я бы расширил сферу проблемы от GUI до программного обеспечения, которое, как ожидается, будет конкурентоспособным. C ++ не облагается налогом на целевую платформу, поскольку он касается вычислительной мощности, установленного времени выполнения, сред и т. Д. Таким образом, он будет работать на более ограниченном клиентском оборудовании, чем аналогичное решение, написанное на управляемом / интерпретируемом языке. В случае успешного коммерческого программного обеспечения стоимость разработки (потенциально выше в случае C ++) амортизируется количеством продаж.

Кроме того, C ++ обычно предлагает прямой доступ к системному API (например, GUI), что дает лучшую возможность оптимизировать использование и дифференцировать себя от аналогичных решений.

— jszpilewski
источник

3

Я думаю, что многое из этого связано с API для GUI-инструментариев. Все они имеют C / C ++ API, но не все имеют (скажем) привязки Python. И иногда сами наборы инструментов были написаны с учетом C ++, поэтому даже если они поддерживают другие языки, они не поддерживают их полностью (например, они не поддерживают Python tupleв качестве аргумента).

— TMN
источник

О, они не полностью их поддерживают, потому что они не хотят или не имеют времени это реализовать. Не потому что это невозможно.

— cubuspl42

2

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

Многие другие приложения менее привязаны к производительности и могут быть легко написаны на других языках. C #, в частности, кажется, часто используется. (И Obj-C, но на самом деле он не считается высокоуровневым. Хотя лучше, чем C ++.)

Тем не менее, существует определенное отсутствие рамок для последних языков программирования. Например, на самом деле нет жизнеспособной библиотеки GUI для Python. Конечно, вы можете использовать PyQt или PyGtk, и они работают хорошо, но, в конце концов, это снова только взаимодействие с кодом C. Опять же, C # (и, возможно, Obj-C) кажется исключением, и, возможно, MacRuby или IronPython могут изменить эту игру.

— bastibe
источник

0

Чтобы язык заменил C ++ или Java, он должен делать то, чего очень не хватает в этих языках, кроме того, что он выполняет их в своих силах. Кроме того, огромные инвестиции пошли в эти языки. Это означает, что на многих платформах есть стандартная библиотека C ++, которую браузеры, игры и такие программы могут легко использовать. Так что неизбежно будет некоторая инерция. Языки имеют тенденцию медленно развиваться в отличие от других программ.

Если вы посмотрите на это, Anaconda (программа установки RedHat) существует уже около 10 лет, написана на Python с самого начала. Python не был так популярен, когда Анаконда была новичком.

Google Go (golang.org) развивается очень быстро. Компилятор еще не загружен. Чтобы его популярность снизилась, его библиотека должна стабилизироваться, компилятор должен быть загружен, и все больше людей должны использовать его. Я слышал, что одна производственная программа за пределами Google написана на Go, и, как сообщается, у нее еще не было простоев в течение чуть более года.

— vpit3833
источник

1

На самом деле, есть коммерческий Go компилятор для Windows , которая написана на Go, так что это бутстрапируемые компилятор Go. (Это все еще в закрытой бета-версии, однако.)

— Йорг W Mittag

О, тогда я был не в курсе. Спасибо, что рассказали :)

— vpit3833

2

Он называется erGo и производится компанией Newquist Solutions .

— Йорг Миттаг