Quiero desarrollar una aplicación de Windows. Si uso C++ nativo y MFC para la interfaz de usuario, la aplicación será muy rápida y pequeña. Pero usar MFC es muy complicado. Además, si utilizo C#, la aplicación será más lenta que el código nativo y requiere .NET framework para ejecutarse. Pero desarrollar GUI es muy fácil usando WinForm. ¿Cuál prefieres?¿Qué plataforma debo usar: C++ nativo o C#?
"rápido" y "lento" son subjetivos, especialmente con las PC de hoy en día. No estoy diciendo que deliberadamente haga que la cosa sea lenta, pero no hay casi tanto sobrecarga al escribir una aplicación administrada como podría pensar. El JIT, etc., funciona muy bien para que el código se ejecute muy rápido. Y también puede NGEN para una velocidad de arranque adicional si realmente lo necesita.
En realidad, si usted tiene tiempo para aprender, es posible que desee considerar la posibilidad de WPF en lugar de WinForm - este es un conjunto de habilidades diferentes, pero le permite hacer muy buen uso de hardware de gráficos, etc.
también - .NET Framework viene con nuevas instalaciones del sistema operativo, y sigue siendo muy común en las anteriores. Entonces para mí sería una opción bastante clara desarrollar con C#/.NET. El tiempo para desarrollar una aplicación robusta y completamente probada C++ (sin fugas, etc.) es (al menos para mí) mucho mayor que la misma con C#.
Sí, C# .net parece ser una opción mucho más práctica aquí. – Kon
No creo que la "lentitud subjetiva" esté determinada por la sobrecarga, sino principalmente por la capacidad de respuesta de la IU. – peterchen
Hacer una aplicación sin fugas es una cosa fácil. Si estructura ... No he tenido una filtración en años. Dicho eso ... Yo también iría con C#. Solo un mercado más grande. – baash05
Las aplicaciones de C# son más lentas para iniciar que las aplicaciones de MFC, pero es posible que no note una diferencia de velocidad entre las dos una vez que se carga la aplicación.
Eso es cierto, pero CLR 4 (.NET 4.0) debería mejorar significativamente el tiempo de inicio en frío de una aplicación .NET. –
Tenga cuidado de no optimizar demasiado pronto; mencionas la velocidad del código, pero para la mayoría de las operaciones de la interfaz de usuario de Windows, la diferencia no se nota, ya que los principales cuellos de botella del dibujo y el acceso al disco no son diferentes para ninguno de los enfoques.
Mi recomendación es que utilice C# y WPF o WinForms para su interfaz de usuario. Si encuentra algunas bajas, use un generador de perfiles para determinar dónde y luego considere reemplazar alguna lógica de negocios con código nativo, pero solo si hay un beneficio.
Hay una gran cantidad de posibles aplicaciones de Windows, y cada una tiene sus propios requisitos.
Si su aplicación necesita ser rápida (y lo que yo trabajo en ella), entonces C++ nativo es un buen camino a seguir.
Si su aplicación necesita ser pequeña (quizás para una transmisión muy rápida sobre líneas lentas), utilice lo que sea que sea pequeña.
Si es probable que su aplicación se descargue mucho, es probable que desee desconfiar de las versiones posteriores de .NET, que los usuarios aún no tienen.
Si, como la mayoría, será lo suficientemente rápido y pequeño de todos modos en los sistemas en los que es probable que se use, utilice lo que le permitirá desarrollarse más rápido y mejor.
En casi todos los casos, lo correcto para optimizar es el esfuerzo del desarrollador. Use lo que sea que haga un trabajo de alta calidad de la manera más rápida y mejor.
Al no tener información sobre la aplicación que planea desarrollar, yo voto por WPF.
La elección de un idioma o herramienta debe estar determinada por los requisitos funcionales y de rendimiento de su proyecto y experiencia. Si el rendimiento es una consideración real para usted y ha realizado un análisis para preferir C++ sobre C#, entonces ya tiene una decisión. Sin embargo, tenga en cuenta que tener una aplicación basada en MFC tampoco es muy eficiente. Por otro lado, los gastos generales enLas aplicaciones NET están sobre declaradas.
El rendimiento es algo que realmente depende de qué tan bien escriba su código y qué requisitos de escalabilidad existen. Si solo tuviera que trabajar con un cliente con un registro de base de datos máximo de 1K, entonces no deberíamos hablar de rendimiento.
Si la facilidad de desarrollo y la mantenibilidad es más importante, sin duda C# sería la opción.
Así que no estoy seguro de si esta es una pregunta a la que se puede dar una respuesta como la opción A o B con los datos que ha proporcionado. Debe hacer el análisis de los requisitos funcionales y no funcionales y decidir.
Tenga en cuenta también que la mayoría de las computadoras con Windows ya tienen .NET instalado en ellas, por lo que realmente no debería ser una preocupación.
Además, aparte de la instalación .NET, las aplicaciones .NET tienden a ser bastante pequeñas.
Y para la mayoría de las aplicaciones con interfaz de usuario, la velocidad del usuario es el factor de tiempo realmente limitante.
En mi opinión, los requisitos deberían ayudarlo a decidir la plataforma. ¿Qué es más importante: tener una aplicación que sea fácil de mantener o que sea extremadamente rápida y pequeña?
Actualmente, una gran clase de aplicaciones se puede escribir usando .NET y código administrado, y esto es en general beneficioso para el desarrollo a largo plazo. Según mi experiencia, las aplicaciones .NET suelen ser lo suficientemente rápidas para la mayoría de los casos de uso y son más fáciles de crear. Nativo C++ todavía tiene su uso, pero solo por ser "más rápido y más pequeño", cuando "lo suficientemente rápido y lo suficientemente pequeño" es suficiente no suena lo suficiente como una justificación.
También Si utilizo C# y luego la aplicación será más lento que el código nativo y lo reqiures marco .NET para ejecutar
un MFC aplicación requiere MFC DLL de ejecutar (y probablemente el tiempo de ejecución VC, así !), por lo que es posible que necesiten instalarse, o si están vinculados estáticamente, agregue el tamaño del exe.
El argumento de la velocidad entre el código nativo y el código administrado es, en gran medida, un problema en este momento. Cada lanzamiento de .NET Framework mejora el rendimiento con respecto a los anteriores y el rendimiento de la aplicación siempre es una prioridad muy alta para los equipos de desarrollo de .NET.
Comenzando con Windows Vista y Windows Server 2008, .NET Framework se instala como parte del sistema operativo. También es parte de la Actualización de Windows, por lo que casi todos los sistemas de Windows XP también lo tendrán instalado. Si el requisito de que el marco se instale en la máquina de destino es realmente un gran problema, también existen compiladores que esencialmente incorporarán las porciones de tiempo de ejecución necesarias en su aplicación para generar un solo exe, pero son caros (y en mi opinión, realmente no vale la pena el costo).
cita en bloque
.NET es más fácil trabajar con ellos. A menos que pierda usuarios al usarlo o tenga problemas con la migración del código, probablemente deba usar .NET. Es muy poco probable que la velocidad sea un problema para esto. El tamaño probablemente tampoco importe tanto.
MFC no es difícil de aprender, en realidad es muy fácil.
Casi igual a C#.
de acuerdo ... Diría que es fácil ... Y aún mejor puedes profundizar en las cosas si es necesario. – baash05
totalmente en desacuerdo, cada proyecto de MFC que he visto es un desastre sangriento. que sí le dice algo a las herramientas, no solo al desarrollador. –
¿Con qué tecnología está más familiarizado?
La información que proporcionó no incluye nada que pueda ayudar a decidir. Sí, las aplicaciones de MFC tienden a ser más pequeñas (si incluye el tamaño del tiempo de ejecución, que no es una medida adecuada a largo plazo), más receptivas y más costosas de desarrollar. ¿Y qué?
Primero .. (aunque soy un codificador de C++ duro) Tengo que admitir que C# está en la mayoría de los casos perfectamente bien en lo que se refiere a velocidad y tamaño. En algunos casos, la aplicación es más pequeña, porque la parte interpretada ya está en el sistema de destino. (No me spamm en eso, una aplicación con un dll es más pequeña que la aplicación, todo en uno. Windows simplemente se envía con el "DLL" ya allí).
En cuanto a la codificación ... Sinceramente, don No creo que haya una diferencia significativa. No paso mucho tiempo escribiendo código. La mayor parte está pensando en un problema. La parte del código es bastante pequeña. Guardar algunas líneas aquí y allá ... Blahh no es una discusión para mí ... Si lo fuera, estaría trabajando en APL. Aprender el STL, MFC y lo que es probable es tan intenso como aprender las bibliotecas de C#. Al final son todos iguales.
C# tiene una sola característica ... Un mercado. Es la última habilidad "caliente" y, por lo tanto, hay un mercado para ella. Los trabajos son fáciles de encontrar. Ahora, tenga en cuenta que java fue una habilidad "candente" hace unos años y que ahora es una pijama y Harry lo tiene en su currículum. Eso hace que sea más difícil para usted mismo.
Ok ... todo eso dicho .. ME ENCANTA C++ .. No hay nada como ensuciarse cuando realmente lo necesito. Cuando las librerías de MFC no hacen el trabajo, echo un vistazo a lo que están sentados, etc., etc. Es un lenguaje perenne y creo que todavía está en o cerca del idioma más usado del mundo. Yah C++, Yah !.
¿Qué tipo de aplicación de Windows? ¿Cuáles son tus sistemas operativos objetivo? La respuesta dependerá mucho de cuáles sean tus objetivos. –