¿Por qué todavía se prefiere C ++ para construir aplicaciones GUI pesadas sobre los últimos lenguajes dinámicos? [cerrado]

46

Veo que la mayoría de las aplicaciones que incluyen contenido de GUI pesado generalmente se desarrollan en C ++. La mayoría de los juegos / navegadores están codificados en C ++.

¿No podemos desarrollar mejores aplicaciones GUI con los últimos lenguajes dinámicos? Sé que Java no sería una gran elección. Pero, ¿qué pasa con los lenguajes como Python que se construyen de forma nativa en C? ¿No se supone que los últimos idiomas son mejores que sus antepasados? ¿Por qué todavía tenemos que preferir el antiguo C ++ sobre los últimos lenguajes?

Y también me gustaría saber, ¿qué es lo que es responsable en C ++, de la mejor velocidad de procesamiento de la GUI? Por otro lado, ¿qué es lo que les falta a los otros idiomas más recientes?

programming-languages c++

— Vamsi Emani
fuente

22

Si crees que Java es un lenguaje 'dinámico', entonces estás profundamente confundido sobre lo que significa esa palabra en este contexto.

— Mike Baranczak

15

@ Mike Baranczak: Esa es una larga historia. Básicamente, hubo un proyecto de investigación primero en Stanford, luego en Sun Research llamado Self. Self es un lenguaje de programación en la familia Smalltalk que es más simple, más potente, más expresivo y, lo que es más importante, significativamente más dinámico que Smalltalk. Debido a que fue diseñado como un lenguaje de programación para desarrollar sistemas completos (como todos los dialectos de Smalltalk), incluidas (entre otras) aplicaciones de escritorio, servidores, sistemas operativos, controladores de dispositivos, tuvo que ser extremadamente rápido. Entonces, el equipo de Self inventó un montón de nuevos ...

— Jörg W Mittag

15

... técnicas de optimización, y cuando el Self VM salió en 1987 (y más aún la segunda generación en 1992), fue rápido. Fue más rápido que cualquier otra VM Smalltalk. El sistema Self se envió con una gran cantidad de código de ejemplo, y uno de esos ejemplos fue un intérprete Smalltalk escrito en Self, e incluso eso fue más rápido que cualquier otra VM Smalltalk. Self era más rápido que muchas implementaciones de C ++ en ese momento, e incluso era competitivo con C. Bueno, lo entiendes. Fue rapido . Sin embargo, Sun decidió que no necesitaban un lenguaje de programación orientado a objetos o una máquina virtual rápida, por lo que ...

— Jörg W Mittag

15

... básicamente mató de hambre el proyecto Self al agotar los fondos. Cuando los ingenieros de Self VM dejaron a Sun por frustración, fueron rápidamente recogidos por una startup de Smalltalk llamada LongView (más comúnmente conocido por el nombre de su mayor producto, un sistema de tipo estático opcional para Smalltalk: StrongTalk). LongView sabía que nunca podrían vender mecanografía estática para Smalltalk, por lo que pensaron que preferirían vender el Smalltalk más rápido del planeta y luego incluir StrongTalk en el paquete en una especie de juego de Trojan Horse. También se dieron cuenta de que ninguno de los geniales ...

— Jörg W Mittag

15

... optimizaciones del Ser VM hizo fueron de ninguna manera particular de uno mismo, sino eran aplicables a casi cualquier lenguaje orientado a objetos (o incluso cualquier idioma en absoluto ). Entonces, los ingenieros de Self VM se pusieron a trabajar en una Smalltalk VM llamada Animorphic VM. Nuevamente, la VM Animorphic fue increíblemente rápida (y aún lo es, en realidad, aunque la base de código no ha sido tocada en 15 años más o menos, todavía puede competir con Smalltalks, JVM y .NET modernos de alto rendimiento, especialmente si toma en cuenta que usa muchos menos recursos que esos, ya que fue diseñado para 486s con 20 meg ...

— Jörg W Mittag

58

Soy una de esas personas que escriben aplicaciones GUI de C ++ (principalmente para Windows). Con Qt, para ser precisos. Mis razones:

Me gusta C ++ Soy un profesional independiente y generalmente puedo elegir mis herramientas (¡qué suerte!)
En un entorno administrado, puede tener dificultades cuando necesita usar algún código no administrado (¿declaraciones de WinAPI de largo aliento en C #, alguien?)
Menos dependencias que se implementan más fácilmente
Más control sobre todo.
RAII (vs. GC). E incluso si asigno new, rara vez hago deletealgo explícitamente, porque uso punteros inteligentes o la QObjectjerarquía.
C ++ es muy emocionante en estos días, no puedo esperar a que un compilador admita completamente el nuevo estándar.
Velocidad (solo al final de la lista. Sé que no es tan importante para la GUI en sí, pero tiende a ser más rápida porque los programas C ++ no sufren la sobrecarga que los tiempos de ejecución, la compilación de código de bytes JIT y tecnologías similares a el programa.)

Como puede ver, estas son principalmente preferencias personales. Me parece importante que mi trabajo sea agradable y C ++ me lo proporciona.

— Tamás Szelei
fuente

11

La velocidad +1 es definitivamente la razón principal aquí, aparte de la preferencia personal. Sin embargo, me gusta "C ++ es muy emocionante en estos días". Para responder al autor de la pregunta , no a @ Tamás Szelei: Claro, la informática cambia rápidamente con nuevas ideas, paradigmas, tecnologías, productos, pero lo último y lo mejor no es una virtud. C ++ ha existido por un tiempo y no significa que esté desactualizado, sino que tiene un historial probado en comparación con las tecnologías más nuevas. El texto original de Stroustrup (el libro del inventor) es pesado, pero hay algunos buenos libros por otros, consulte oreilly.com, por ejemplo.

— therobyouknow

1

@Tarnas, creo que "siempre será más rápido" es un poco estrecho / autoritario, pero no lo suficiente como para justificar un voto negativo ...

— Max

2

Como soporte anecdótico: he estado involucrado en diferentes proyectos para crear interfaces gráficas de usuario de gran tamaño en Windows usando C ++ y JavaScript. También he estado involucrado en diferentes proyectos de consola de juegos en C ++ y JavaScript. En ambos casos, hubo significativamente más problemas de velocidad y memoria con JavaScript.

— Gort the Robot

2

Tarde a la fiesta, pero ¿puedes explicar las "dependencias menos fáciles de implementar"?

— weberc2

2

He estado usando C ++ por más de 20 años. Se han agregado muchas características nuevas y excelentes desde 11, 14 y 17. Casi puede usar C ++ como lenguaje de script y aún así obtener el beneficio de la velocidad rápida. Cuando trabajo con GRANDES datos, casi tengo que usar C ++ porque en cualquier otro lenguaje habrá 10-1000 más lento.

— Kemin Zhou

32

Porque la velocidad importa.

Los juegos usan C ++ para las tareas principales, donde el rendimiento es importante. Utilizan lenguajes dinámicos para tareas de secuencias de comandos donde la flexibilidad es importante.
Aplicaciones GUI de escritorio : Visual Studio, por ejemplo, está escrito en .NET y no en C ++ nativo. Parece funcionar bastante bien para un IDE, ya que el IDE en sí no necesita realizar muchas tareas intensas de rendimiento. (El compilador, el enlazador y otras herramientas no están necesariamente escritos en .NET, aunque como wawa señala en un comentario, algunos parecen estarlo (por ejemplo, VB.NET))
Los navegadores también deben ser rápidos. Después de todo, son una especie de sistema operativo secundario. Por otro lado, puede argumentar que grandes partes de Firefox en realidad están "escritas" en JavaScript, ya que el marco de trabajo de Mozilla parece depender en gran medida de JavaScript.

En resumen: no diría que C ++ es necesariamente preferido, pero si tienes un cuello de botella en el rendimiento, tienes que acercarte al metal y luego te encuentras con C ++ (bueno, o C). A veces será más fácil hacer todo en C ++, un lenguaje.

— Martin Ba
fuente

1

+1 Mejor respuesta: tiene que ver únicamente con la velocidad como la razón principal para usar C ++. Incluso los propios Microsoft reconocen que C ++ es el mejor para el rendimiento en comparación con C # y Visual Basic: consulte en sus páginas de Visual Studio. Un segundo muy cercano es la portabilidad, si usa bibliotecas multiplataforma como Qt. La mejor respuesta también porque es objetivo en lugar de subjetivo.

— therobyouknow

2

Tu segundo punto no es del todo cierto. El compilador de VB.NET está escrito en VB.NET y el compilador de F # está escrito en F #. El compilador de C # no es, pero por lo que se ha publicado sobre el proyecto Roslyn, creo que el compilador de C # se está reescribiendo en C #.

— Wesley Wiser

55

La interfaz gráfica de estudio visual (el cromo) está escrita (desde vs2010) en C # y WPF. El explorador de soluciones, el sistema de compilación, el navegador de códigos y la caja de herramientas están escritos en c # / c ++ con winforms. El compilador está escrito en c ++.

— Martin Beckett

Para la mayoría de las aplicaciones de escritorio, solo los motores de representación y diseño (es decir, la Vista) deben ser rápidos. De todos modos, el Modelo no tiende a pasar mucho tiempo en él, y el Controlador pasa la mayor parte del tiempo esperando que el usuario haga algo (y pocos usuarios pueden hacer clic con frecuencia hasta 10 veces por segundo).

— Donal Fellows

@ MartinBa: Notaría que el compilador actual para C # y VB (Roslyn) está escrito en C #.

— jmoreno

18

Las aplicaciones GUI que ves escritas en C ++ generalmente se realizan debido a razones heredadas. Python (con Qt o Gtk) es muy viable para aplicaciones GUI, como lo es C # si trabaja en una casa de Windows. Al iniciar algo nuevo, o bien está muy preferido mucho a C ++ debido a la falta de trabajo de plomería que se tiene que hacer.

— Demian Brecht
fuente

55

El código existente de +1 es importante. Es raro comenzar completamente desde cero cuando se desarrollan nuevos programas

77

¿Cómo es preferible usar Python con Qt a usar C ++ con Qt? Si tuviera que comenzar un nuevo proyecto hoy, todavía usaría C ++ para la GUI. Porque: a) Es lo que sé, b) hace bien el trabajo. El hecho de que C ++ haya existido por un tiempo no lo hace "desactualizado".

— TZHX

2

@TZHX: "Es lo que sé" es un argumento viable. Si eso no se da, no tener que ocuparse más de la gestión de la memoria es un gran aumento del rendimiento, y puede compensar el esfuerzo de aprender Python incluso para un solo proyecto. Otra razón para usar Python sería la multiplataforma: con C ++, debe tener cuidado y tomar medidas especiales, mientras que es probable que python simplemente funcione.

— tdammers

44

No veo ninguna ventaja de usar PyQt en lugar de Qt con C ++ para alguien que conozca C ++.

— BenjaminB

13

Es probable que C ++ solo funcione, también. Con Python, debe preocuparse acerca de qué versión de Python ha instalado el usuario, o preocuparse por agruparlo. Realmente no hay mucho trabajo por hacer "cuidar la memoria" a menos que cometas errores estúpidos. Creo que muchas personas dan "gestión de memoria" como un gran obstáculo para trabajar con C ++ sin saber realmente la diferencia.

— TZHX

16

Porque no importa cuántas pruebas de rendimiento muestren .NET y las multitudes similares, no importa cuán cerca estén en los puntos de referencia, al final, la aplicación C ++ se destaca. Es más rápido en el arranque en frío, es más ágil y tiene más formas de mejorarlo.

He escuchado numerosas pruebas en las fases de inicio del proyecto de que .NET es el camino a seguir, pero una vez que se elige, siempre terminan siendo un gran obstáculo.

Además, C ++ hoy en día es bastante seguro y bastante fácil de usar, especialmente con marcos como Qt o WTL.

— Descifrador
fuente

2

+1: "Además, C ++ hoy en día es bastante seguro y bastante fácil de usar, especialmente con marcos como Qt ..." Estoy totalmente de acuerdo: creo que una gran fortaleza no es (solo) C ++ en sí mismo, sino el hecho de que (1 ) está compilado en código nativo, (2) tiene un conjunto razonable de características (OOP, plantillas), (3) tiene muy buenos marcos como Qt. Esto compensa el hecho de que el idioma es bastante grande y difícil de aprender: una vez que domine un subconjunto decente del idioma y algunas buenas bibliotecas, puede ser realmente productivo con él.

— Giorgio

10

La mayoría de los motores de juegos están codificados en C ++. También muchos motores de navegador están codificados en C ++. Pero la GUI del navegador a menudo se codifica utilizando algún script ligero (JavaScript, Python). Con la notable excepción de Source Engine, la mayoría de los motores de juegos también usan lenguajes de script (como Lua o Python). [para referencia: lista de juegos con guión de Lua ]

También tome la biblioteca de C ++ GUI popular como Qt. En la versión actual (4.7) usa QML para la GUI. QML es básicamente JavaScript con enlaces Qt.

Entonces, realmente no hay C ++ vs lenguajes dinámicos, es mixto.

— vartec
fuente

[Cita requerida]. Sé que muchos juegos usan lenguajes de scripting para permitir que los usuarios los extiendan, pero que yo sepa, en realidad no hay muchos juegos que usen lenguajes de scripting para su funcionalidad de lanzamiento binario.

— ProdigySim

1

@ProdigySim: Sé de varios que sí. Fuera de mi cabeza, World of Warcraft (Lua + XML), Naughty Dog's Uncharted series (Lisp), Unreal series (UnrealScript), juegos basados en los motores Torque y Unity, Dungeon Siege, NeverWinter Nights y muchos otros. Los juegos basados en datos se están convirtiendo en la norma, donde el host de secuencias de comandos se hace cargo de la mayoría (si no todas) las características de la interfaz de usuario y el estado del juego de arriba a abajo.

— greyfade

@ProdigySim: incluso si está oculto para los usuarios normales, no significa que internamente no usen motores de secuencias de comandos. Básicamente, los desarrolladores de juegos tienen dos opciones: crear su propio lenguaje de script para modelos o usar uno de uso general. Lua es especialmente bueno para juegos, ya que generalmente es bueno para sistemas en tiempo real.

— vartec

El motor de origen utiliza el lenguaje de secuencias de comandos Squirrel.

— cubuspl42

6

La primera razón será: hábito (antiguo)

Segunda razón: menos confiabilidad en máquinas virtuales, intérpretes que deben instalarse, etc.

Y todavía hay algunos IDE excelentes para desarrollar código en C ++.

— Roalt
fuente

1

' IDEs todavía excelentes' ... Diría que Visual Studio y Eclipse son de vanguardia y lo han sido durante mucho tiempo.

— JBRWilkinson

@JBRWilkinson: No dije que otro idioma no los tenga también.

— Roalt

6

La razón es que tienes mucho más control sobre todo lo que sucede. Si fuera a escribir Photoshop en C #, tendría serios problemas de rendimiento para algunas tareas. En un lenguaje de nivel inferior con más control, puede tomar atajos, optimizar donde sea necesario para cosas que son más intensas. Por supuesto, esto supone que está utilizando C ++ en código no administrado, no C ++ en .NET.

Vea aquí para un ejemplo rápido.

— Ricardo
fuente

2

Adobe Lightroom, que es básicamente un subconjunto de Photoshop, está escrito en Lua.

— Jörg W Mittag

44

@ Jörg: y el resto es C ++. de hecho, esa es probablemente la mejor combinación disponible, C ++ para la base, Lua para el resto (aunque todavía prefiero C sobre C ++ para cosas de bajo nivel).

— Javier

2

@Javier: Sí, Lightroom es básicamente los algoritmos de manipulación de imágenes de Photoshop (que probablemente están escritos principalmente en el ensamblaje MMX / SSE) y SQLite3 (que está escrito en ANSI C prehistórico para la portabilidad) pegados junto con Lua. Adobe también desarrolló su propio Lua IDE, completamente en Lua. ¿Alguien sabe qué kit de herramientas gráficas utilizan? AFAIR Photoshop es anterior a casi todos los kits de herramientas modernos, por lo que probablemente sea algo de cosecha propia.

— Jörg W Mittag

44

sin ofender, pero si cree que ANSI C es prehistórico, ha estado leyendo los ejemplos de código incorrectos

— Javier

6

C ++ está estáticamente tipificado. Esto permite optimizar la ejecución del código de antemano al hacer que un compilador ajuste sus abstracciones al proceso del sistema disponible en una plataforma determinada. Hasta ahora, los lenguajes dinámicos necesitan una capa de software adicional (= el intérprete) que ralentiza el acceso a los recursos del sistema.

— poseid
fuente

4

La mayoría de las razones dadas son técnicas o "sobre la mesa" ... aquí hay razones comerciales o "debajo de la mesa":

distribuir código compilado vs distribuir código fuente. cuando se desarrolla en c / c ++, distribuye los binarios. si está desarrollando en uno de los idiomas modernos, distribuya la fuente. Es difícil vender la idea de ofuscadores a la gerencia que tiene que responder a los accionistas / inversores, así que no se moleste.

usuarios estúpidos: al menos en la mente de la gerencia. todavía perciben que sus usuarios apenas pueden hacer doble clic en un "setup.exe". Si incluye la instalación de un intérprete como parte de la configuración, sacudirán la cabeza de lado a lado.

desarrolladores antiguos: la mayoría de las personas con experiencia han existido durante mucho tiempo y no se han actualizado. programan en C ++ y no en los lenguajes más nuevos, porque no conocen los lenguajes más nuevos.

— Kinjal Dixit
fuente

Diría que está distribuyendo el código fuente cuando lanza una aplicación .NET. Mire a Visual Studio, gran parte de la interfaz está diseñada con formularios WPF. Algunos de sus puntos son, por supuesto, válidos, gran parte de la administración de hoy eran desarrolladores de ayer, las malas noticias son poco probables de que los marcos de hoy sean válidos debido a los cambios en las computadoras de hoy.

— Ramhound

Muchas personas con mucha experiencia han ganado su experiencia manteniéndose actualizados. Tienden a no aprender nuevos idiomas interesantes (como Pascal a principios de la década de 1980) solo porque son atractivos, pero solo si tienen un uso para ellos o si tienen ideas interesantes (Haskell, por ejemplo).

— David Thornley

4

Extendería el alcance del problema desde la GUI al software que se espera sea competitivo. C ++ no impone impuestos a la plataforma de destino, ya que se refiere a la potencia de procesamiento, el tiempo de ejecución instalado, los marcos, etc. Por lo tanto, funcionará en hardware de cliente más limitado que una solución similar escrita en un lenguaje administrado / interpretado. En el caso de un software comercial exitoso, el costo de desarrollo (potencialmente más alto en el caso de C ++) se amortiza por el número de ventas.

Además, C ++ generalmente ofrece acceso directo a las API del sistema (como GUI), lo que brinda la mejor oportunidad para optimizar la utilización y diferenciarse de soluciones similares.

— jszpilewski
fuente

3

Creo que mucho tiene que ver con las API para los kits de herramientas GUI. Todos ellos tienen una API C / C ++, pero no todos tienen (digamos) enlaces de Python. Y a veces, los kits de herramientas en sí se escribieron teniendo en cuenta C ++, por lo que incluso si tienen soporte para otros lenguajes, no los admiten por completo (por ejemplo, no admitirán Python tuplecomo argumento).

— TMN
fuente

Oh, no los apoyan completamente, porque no quieren o no tienen tiempo para implementar eso. No porque eso sea imposible.

— cubuspl42

2

Estás mencionando navegadores y juegos como ejemplos. Ambas son aplicaciones bastante críticas para el rendimiento, por lo que tenerlas en un lenguaje de bajo nivel para la velocidad tiene sentido.

Muchas otras aplicaciones están menos relacionadas con el rendimiento y podrían escribirse fácilmente en otros idiomas. C # en particular parece ser usado mucho. (Y Obj-C, pero realmente no califica como de alto nivel, supongo. Sin embargo, es mejor que C ++).

Sin embargo, existe una cierta falta de marcos para los últimos lenguajes de programación. Por ejemplo, en realidad no hay una biblioteca GUI nativa viable para Python. Claro, puede usar PyQt o PyGtk y funcionan bien, pero al final, eso solo está interactuando con el código C nuevamente. Nuevamente, C # (y posiblemente Obj-C) parece ser la excepción y tal vez, MacRuby o IronPython podrían cambiar ese juego.

— Bastibe
fuente

0

Para que un lenguaje reemplace C ++ o Java, tiene que hacer lo que se echa mucho de menos en estos lenguajes además de ejecutarlos con sus propios puntos fuertes. Además, se han realizado grandes inversiones en estos idiomas. Eso significa que hay una biblioteca C ++ estándar en muchas plataformas, que los navegadores, los juegos y dichos programas pueden usar fácilmente. Entonces seguramente habrá algo de inercia. Los idiomas tienden a despegar lentamente a diferencia de otras piezas de software.

Si lo miras, Anaconda (el programa de instalación de RedHat) ha existido durante aproximadamente 10 años, escrito en Python desde el principio. Python no era tan popular cuando Anaconda era nueva.

Google's Go (golang.org) está evolucionando muy rápido. El compilador aún no se ha arrancado. Para que despegue su popularidad, su biblioteca tiene que estabilizarse, el compilador debe ser arrancado y cada vez más personas deben usarlo. Escuché que un programa de producción fuera de Google está escrito en Go y se informa que aún no ha tenido tiempo de inactividad en su vida de poco más de un año.

— vpit3833
fuente

1

En realidad, no es un compilador comercial Go para Windows que está escrito en Ir, por lo que es un compilador de bootstrap para Go. (Sin embargo, todavía está en beta cerrada.)

— Jörg W Mittag

Oh, estaba fuera de contacto, entonces. Gracias por contar :)

— vpit3833 01 de

2

Se llama erGo y es producido por una compañía llamada Newquist Solutions .

— Jörg W Mittag