Comparación entre Delphi y vc
Jajaja, pide prestadas flores para ofrecérselas a Buda
~v~
La "Comparación entre Visual C++ y Delphi" ha sido muy discutida recientemente en el foro CSDN. Este artículo Desde la perspectiva de un programador, desde los aspectos de nivel técnico, función, rendimiento, facilidad de uso, estabilidad, historial de desarrollo y perspectivas, tomando Visual C ++ 6 y Delphi5 como representantes, este artículo presentará Visual C ++. y Delphi de la forma más objetiva posible. Las ventajas y desventajas de estas dos herramientas de desarrollo principales implicarán lenguaje, marco de aplicación, control, compilación y conexión, interfaz integrada, depuración, COM, desarrollo de bases de datos, etc. Este artículo también proporcionará algunas sugerencias sobre cómo elegir entre estas dos herramientas de desarrollo.
Vale la pena mencionar que dado que C++Builder y Delphi son productos de Inprise, excepto por los lenguajes que utilizan, sus otras características son casi las mismas. Por lo tanto, este artículo también tiene un valor de referencia para los programadores y estudiantes de C++Builder.
Idioma: la existencia es razonable
En primer lugar, permítanme declarar algo que a menudo se confunde: VC y Delphi en sí no son lenguajes, sino plataformas de desarrollo. Los lenguajes que utilizan son C/C++ ligeramente extendido y Object Pascal respectivamente. A menudo veo personas preguntando en Internet si deberían aprender C/C++ o VC. Esta pregunta es fácil de responder: si aprendes VC, debes aprender C/C++, o si aprendes VC, también aprenderás C/C++. .
Volvamos al punto, comparemos las ventajas y desventajas de C++ y Object Pascal. Algunas personas piensan que Object Pascal es un "lenguaje de juguete" y C++ es un "lenguaje profesional". En cuanto al lenguaje en sí, Object Pascal y C++ pertenecen a la misma clase de peso. Ambos son lenguajes orientados a objetos totalmente compatibles y ambos tienen sus raíces en lenguajes procedimentales "establecidos desde hace mucho tiempo". C++ evolucionó a partir de C y Object Pascal evolucionó a partir de Pascal. Todos ellos tienen una gran flexibilidad y tienen sus propias fortalezas y debilidades. Por ejemplo, Object Pascal no admite herencia múltiple, plantillas, sobrecarga de operadores, definiciones de funciones en línea, preprocesamiento, macros, variables de clase estáticas globales, definiciones de clases anidadas, etc., todos los cuales son compatibles con C++. Pero de manera similar, C++ no admite los constructores ficticios de Object Pascal, el anidamiento de procedimientos, los tipos de colección integrados, los tipos de cadenas integrados, las construcciones "finalmente", etc. Object Pascal también funciona mejor que C++ en términos de RTTI. Pero esto no es importante, porque el mismo propósito se puede lograr de otras maneras. Por ejemplo, C++ puede admitir colecciones y cadenas a través de extensiones de clase, Object Pascal puede admitir herencia múltiple a través de "inte***ce", etc. El punto es que ambos funcionan bien para la tarea en cuestión, y eso es suficiente.
Sin embargo, no basta con comparar los lenguajes en sí, también hay que fijarse en su aceptación y popularidad, curva de aprendizaje, perspectivas de desarrollo, portabilidad, etc., además de un aspecto muy importante. Un punto que a menudo se ignora: el grado de "adaptación" al entorno de desarrollo (en referencia a VC y Delphi) y su marco de aplicación.
Como plataformas de desarrollo, un punto muy importante de VC y Delphi es proporcionar un marco de aplicación "integral": MFC de VC y VCL de Delphi. MFC está escrito en C++ y VCL está escrito en Object Pascal. Por supuesto, todos sabemos que C++ tiene un alcance de uso mucho más amplio que Object Pascal y es mucho más portátil. Esto es originalmente una ventaja, pero lo que es muy interesante es que debido a esto, Microsoft debe considerar minimizar los cambios en el lenguaje en sí al escribir MFC y centrarse en el nivel del código fuente para que pueda admitir estándares como ANSI tanto como sea posible. Como resultado, el empaquetado de MFC es complejo y poco intuitivo. (Especialmente su encapsulación de mensajes, que se mencionará a continuación). Demasiadas definiciones macro y comentarios vagos, generados automáticamente y que no se pueden cambiar, hacen que MFC e incluso VC sean intimidantes para muchos principiantes, que no se atreven a "meterse en el agua" para aprender en profundidad. Object Pascal es casi "exclusivo" de Inprise y no hay necesidad de considerar cuestiones de "estándares". Por lo tanto, cuando Inprise escribió VCL, centró toda su energía en la estructura y el rendimiento, como resultado, la integración entre el lenguaje y el. El marco era muy bueno. La estructura del marco VCL es clara y la legibilidad del código VCL es muy buena. Mucha gente dice que es más fácil empezar a utilizar Delphi por este motivo. No existe nada parecido a un almuerzo gratis. ¿Quieres estándares de la industria? ¿Quiere portabilidad (la portabilidad y la compatibilidad se compararán en detalle a continuación)? Entonces, enfrente el código del "Libro del Cielo" de MFC.
Compilación y vinculación: la necesidad de velocidad
Otra diferencia provocada por los diferentes lenguajes es la diferencia en la velocidad de compilación y vinculación, así como la diferencia en la velocidad de ejecución. La velocidad de compilación y conexión de Delphi es, sin exagerar, decenas de veces más rápida que la de VC. Incluso si la opción Enlace incremental de VC está activada, la velocidad de compilación y conexión de Delphi sigue siendo varias veces más rápida que la de VC.
No es que el compilador de Microsoft no sea bueno, esto está determinado por la complejidad de C++. El procesamiento de plantillas, el preprocesamiento y la expansión de macros requieren mucho tiempo. ¿No mencioné antes que Object Pascal no tiene plantillas, preprocesamiento ni macros? Esto es originalmente una desventaja, pero una de las ventajas es que la velocidad de compilación es extremadamente rápida. En cuanto al código binario compilado, cuando se activan las mismas opciones de optimización, no hay mucha diferencia en la velocidad de ejecución entre Delphi y VC.
Para superar el problema de la velocidad de compilación, los compiladores de C++ generalmente requieren conectores y mecanismos de preprocesamiento mejorados. Sin embargo, todavía existen varios problemas en el mecanismo de preprocesamiento: 1) La línea del punto de interrupción para la depuración del programa puede ser diferente de la línea de código 2) La información del código más reciente no está integrada 3) Es fácil generar lógica errónea; El error se produce debido a la lectura del encabezado del archivo incorrecto. Es fácil generar errores como "Fin de archivo inesperado".
Los dos compiladores tienen una cosa en común: ambos pueden identificar código "muerto" inútil, como una función inútil, etc. El programa compilado no contendrá esta información redundante. Delphi hace un trabajo aún mejor en este sentido. Le permite indicar visualmente qué línea de código está "activa" y qué línea de código está "muerta" en el editor. De esta manera puede organizar el código más optimizado. Después de compilar Delphi, se mostrará un pequeño punto azul a la izquierda para indicar que esta línea de código está "activa". Visual C++ no puede hacer esto.
El archivo ejecutable compilado por Delphi tiene al menos 200 K (si no usa VCL y solo usa WinAPI, el tamaño del archivo se reducirá considerablemente. Sin embargo, el archivo ejecutable compilado por programación Visual C++ usando MFC). Por lo general, solo hay unas pocas docenas de K, principalmente porque Microsoft ha incluido la biblioteca de tiempo de ejecución del sistema en el sistema Windows (Borland Company una vez negoció esta interfaz con Microsoft, pero Microsoft aprovechó el sistema operativo y no estaba dispuesto a hacerlo público). De la misma manera, los programas de bases de datos desarrollados con BDE deben incluir entre 3 y 5 millones de archivos de sistema adicionales, lo que también es muy inconsistente.
Lo que es muy interesante es que Delphi puede utilizar archivos OBJ creados por C++ Builder, pero su uso está sujeto a grandes limitaciones.
Finalmente, los mensajes de error durante la compilación y conexión de Visual C++ son mucho más detallados y específicos que los de Delphi. Esto es especialmente cierto cuando se desarrolla utilizando ATL.
Marco de aplicación: ¿MFC? ¿Es popular KFC?
Marco de aplicación (Application Frame), a veces también llamado marco de objeto. El marco utilizado por Visual C++ es MFC. MFC es más que una simple biblioteca de clases como la gente suele entenderla (de manera similar, VCL de Delphi es más que solo una biblioteca de control, aunque su nombre es "Biblioteca de control visual"). Si elige MFC, también elige una estructura de programa y un estilo de programación. MFC apareció ya en la era de Windows 3.x, cuando Visual C++ todavía era de 16 bits. Después de años de continua suplementación y mejora, MFC se ha vuelto muy maduro. Sin embargo, debido a que el prototipo apareció antes, MFC está una era detrás de VCL. Aunque Microsoft no ha dejado de actualizar MFC, a menudo leo artículos con opiniones como "Mientras Windows no se vuelva obsoleto, MFC no quedará obsoleto", pero al igual que la desaparición del marco OWL de Inprise (anteriormente Borland), El MFC está desapareciendo. También es cuestión de tiempo. De hecho, MFC es un producto de la misma época que OWL. OWL ya no existe, ¿cómo es posible que MFC no esté preparado para el peligro en tiempos de paz? Si MFC se mantiene joven para siempre, los desarrolladores de Microsoft no desarrollarán "privadamente" WTL basado en ATL. Por supuesto, el estado de WTL no se puede comparar con el de MFC. No es un marco oficialmente respaldado por Microsoft y sus funciones encapsuladas también son bastante limitadas. Pero al menos pone de relieve las deficiencias del MFC.
Creemos que lo que mejor refleja el avance de un marco de aplicación es su modelo de delegación, que es el mecanismo de encapsulación de los mensajes de Windows. No hace falta decir que no es necesario mencionar la encapsulación de la API de Windows. Casi igual, con poco contenido técnico. Si está satisfecho, también puede escribir una biblioteca de clases para encapsularla usted mismo. Pero encapsular el mecanismo basado en mensajes de Windows no es tan fácil. La forma más natural de encapsulación es utilizar funciones miembro virtuales. Si desea responder a un mensaje, sobrecargue la función virtual correspondiente. Pero para mi sorpresa, MFC utiliza el método de definición de macros "antiguo". La ventaja de utilizar el método de definición de macro es que ahorra la sobrecarga del sistema de la función virtual VTable (dado que Windows tiene muchos tipos de mensajes, la sobrecarga no es demasiado pequeña). Sin embargo, la desventaja es que el mapeo no es intuitivo. Para MFC, esto es "demasiado poco intuitivo". Aunque su código de mapeo de mensajes es visible, te aconsejo que no lo toques. Afortunadamente, ClassWizard de VC puede generar automáticamente código de mapeo de mensajes, lo cual es bastante conveniente de usar. Pero en comparación con el modelo de delegación de VCL, el método de mapeo de MFC parece demasiado atrasado. Object Pascal de Delphi no tiene una "carga estándar" y el lenguaje ha introducido nuevas características como componentes, procesamiento de eventos y propiedades. Dado que el trabajo se realiza a nivel de compilador, el código fuente generado es muy conciso.
Parece que VC es "dejar que el marco se adapte al lenguaje", mientras que Delphi es "dejar que el lenguaje se adapte al marco".
Me gustaría dar un ejemplo de encapsulación de operaciones de cadena para ilustrar las ventajas y desventajas de MFC y VCL. En MFC, la clase CStringList tiene funciones como agregar, obtener y eliminar, pero además de las funciones anteriores, la clase TStringList de VCL también tiene funciones como ordenar, leer cadenas separadas por comas y transmitir entrada y salida. Pero para la misma función de reemplazo de cadenas, StringReplace de VCL es 2-3 veces más lento que CString::Replace de MFC. En general, la encapsulación de VCL es de mayor nivel y más abstracta que MFC, pero el problema inevitable es que la eficiencia de ejecución de algunas partes es ligeramente menor que la de MFC. Esto es como si la eficiencia de ejecución de los lenguajes de bajo nivel (como el ensamblador) fuera mayor que la de los lenguajes de alto nivel (como el Básico), pero la eficiencia de la programación es menor. No puedes quedarte con tu pastel y comértelo también.
Otra ventaja de VCL sobre MFC es su soporte para el manejo de excepciones, pero una desventaja importante es su pobre soporte para subprocesos múltiples. La mayor parte del VCL no está optimizado para subprocesos múltiples. Aunque VCL proporciona clases para simplificar las operaciones de subprocesos múltiples, sólo los subprocesos de trabajo son relativamente simples de usar. Las cosas se ponen problemáticas si el hilo tiene que lidiar con la interfaz, porque ningún hilo que no sea el hilo principal de la aplicación puede acceder a ningún componente visual de VCL. Debe utilizar el método Synchronize para esperar a que el hilo principal procese sus mensajes y luego acceder al componente VCL en el hilo principal. MFC no tiene tales restricciones.
Estabilidad y perfección: VC es el hermano mayor
VC es más estable y perfecto que Delphi. VC tiene una historia de desarrollo más larga que Delphi y la fortaleza general de Microsoft es más fuerte que la de Inprise. El marco MFC de VC ha pasado por muchos años de desarrollo y mejora. Tiene funciones muy completas, es muy estable y tiene pocos errores. Es posible que encuentre menos errores. Y existen herramientas especializadas de terceros para ayudarle a evitar estos errores. No es fácil para una biblioteca de clases de este tamaño hacer esto. No subestimes esto, muchos programadores profesionales eligen VC por este motivo. Porque aunque VCL tiene un mayor nivel de abstracción y encapsulación de mayor nivel que MFC, la mejora resultante en la eficiencia del desarrollo después de todo se limita a los expertos. Y si encuentra un problema extraño y lo depura durante mucho tiempo, descubrirá que no es su código el que está mal, sino un error de VCL. ¿Cómo se sentiría? Aunque la posibilidad de encontrar este tipo de problemas es muy pequeña, el impacto en la imagen de VCL no es pequeño. El IDE de Delphi consume demasiados recursos, arranca demasiado lento, entra en conflicto con algunos controladores de tarjetas gráficas, tiene fallos en el VCL, el depurador no es lo suficientemente robusto y no tiene protección contra controles inestables de terceros... Hay muchos problemas, y Delphi no es tan bueno como VC en este sentido. Espero que Inprise pueda llevarlo al siguiente nivel. Por cierto, vimos a algunas personas en Internet decir que Delphi era extremadamente inestable y que ocurrieron más de 20 operaciones ilegales en unos minutos. De hecho, Delphi no es tan estable como Visual C++, pero no lo es. Supongo que el Delphi de ese amigo instaló algunos controles problemáticos de terceros, lo que provocó errores frecuentes en Delphi. ¿Por qué no intentar eliminar esos controles?
Portabilidad: Basado en la realidad, mirando hacia el futuro
Inprise está desarrollando una versión para Linux de Delphi, cuyo nombre en código es Kylix. Quizás a través de Kylix sea posible portar programas de Windows escritos con el marco VCL a Linux. Pero esto sólo es posible. Porque el trabajo de compatibilidad actual de Inprise no es muy bueno. Una versión inferior de Delphi no puede utilizar una versión superior de componentes VCL, y una versión superior de Delphi no puede utilizar una versión inferior de componentes VCL. Esto es realmente irrazonable. Rara vez vemos software que no sea compatible con binarios anteriores. Si Windows 98 no puede ejecutar programas 95, Windows 95 no puede ejecutar programas 3.x y Win 3.x no puede ejecutar programas DOS, ¿seguirá utilizando Windows? Si los programas de Windows 95 tuvieran que recompilarse para ejecutarse en 98, ¿se vendería tan bien 98? Los "hermanos" C++Builder y Delphi no pueden usar los componentes de cada uno, e incluso los nombres de archivos del mismo conjunto de bibliotecas VCL son diferentes. Por lo tanto, es común que un componente tenga diferentes versiones para D1/D2/D3/D4/D5/C1/C3/C4/C5, y puede aumentar a medida que se actualizan las versiones de Delphi y C++Builder. Espero que Inprise pueda resolver primero los problemas de compatibilidad con sus hermanos. El VC de Microsoft no tiene tales problemas. Los programas MFC1.0 también se pueden compilar y pasar bajo VC6.0 sin ningún obstáculo.
Interfaz integrada: macro y micro
En términos generales, la interfaz integrada de VC no es tan buena como la de Delphi. El único Inspector de objetos de Delphi se puede comparar con un montón de asistentes en VC, sin mencionar que también tiene Explorador de código, Lista de tareas pendientes, etc. Pero desde una pequeña perspectiva, se puede ver la inmadurez de Delphi.
Por ejemplo, la función "autocompletar" no es tan inteligente y detallada como VC, y su velocidad de respuesta no es tan rápida como VC.
El MSDN que viene con Visual C++ es una "enciclopedia para desarrolladores" con gran cantidad de información y fácil consulta. Es más profesional que Delphi en este sentido. Muchos elementos de ayuda tienen demostraciones del programa fuente.
OpenTools de Delphi es un sistema abierto completamente orientado a terceros. Los desarrolladores pueden modificar muchas de las funciones propias de Borland. Desde la perspectiva de la escalabilidad del IDE, Delphi es mejor.
Depuración: el verdadero poder proviene de las sutilezas
Las funciones de depuración de Visual C++ y Delphi son muy potentes y ambos tienen depuración visual en un solo paso, seguimiento de puntos de interrupción y cambio de variables durante tiempo de ejecución y mouse Se pueden obtener funciones como valores de variables. La entrada y salida de la DLL también se pueden administrar fácilmente y se puede realizar la depuración a nivel del código fuente.
Relativamente hablando, Visual C++ puede ver más fácilmente los cambios en las variables, incluida la capacidad de expandir la estructura en un árbol de datos, para comprender el valor de cada variable, depurar cada paso y cambiar el Las variables se resaltarán en rojo para que la depuración sea más conveniente. Además, la inspección de la memoria de bloques de Visual C++ es más conveniente que la de Delphi.
Por supuesto, Delphi también tiene muchos detalles considerados. Por ejemplo, al depurar subprocesos, Delphi puede observar fácilmente los cambios en los subprocesos, pero Visual C++ debe mostrar un cuadro de diálogo modal.
Desarrollo de bases de datos: Delphi destaca
El soporte de bases de datos es el punto fuerte de Delphi. Esto se refleja principalmente en la perfecta integración de Delphi y BDE, así como en la gran cantidad de controles operativos de bases de datos listos para usar que proporciona Delphi. Esto está fuera del alcance de los capitalistas de riesgo. Actualmente, Delphi admite tres métodos de acceso a bases de datos: BDE, ADO e InterBase. Todos los métodos se pueden arrastrar y soltar en la aplicación para una operación visual. Es precisamente gracias al empaquetado de clases de bases de datos de Delphi que los usuarios no tienen que intervenir desde el principio hasta el final para operar la base de datos como en Visual C++. Velocidad de desarrollo significativamente mejorada.
El uso del control WebBroker en Delphi también puede construir fácilmente una página web basada en una base de datos y administrar la base de datos web a través de HTML. Visual C++ accede a los datos principalmente a través de ADO y OLEDB, y muchos controles ActiveX también pueden agregar funciones de base de datos. Pero sin una base de datos de escritorio como Paradox, Access es relativamente débil. Quizás SQL Server sea una buena opción.
COM: El poder de las nuevas tecnologías
COM es la abreviatura de Component Object Model. Es la base de la tecnología OLE y ActiveX. COM define un conjunto de API y un estándar binario para permitir que objetos independientes en diferentes lenguajes de programación y diferentes plataformas se comuniquen entre sí.
COM es un estándar industrial desarrollado por Microsoft. Pero Delphi también proporciona un potente soporte de idiomas para COM. Admite funciones de interfaz, variante y cadena ancha. Esta encapsulación de COM es de hecho más conveniente que C++. Por ejemplo, al realizar programación COM en C++ (sin un marco de clases), la variante se define como la estructura VARIANT en el archivo oaidl.h. Para manejar variantes, debe ajustar manualmente las funciones API VariantXXXX() en oleaut32.dll para inicializarlas y administrarlas, como VariantInit(), VariantCopy(), VariantClear(), etc.
Existe una forma especial para que Visual C++ implemente la programación COM, que es utilizar ATL. ATL utiliza la herencia múltiple única de Visual C++ para implementar la interfaz COM. Aunque no es necesariamente más fácil implementar servicios y control COM, las interfaces de ATL y la última tecnología COM y la estructura basada en plantillas son mejores que las de Delphi. ATL es más propicio para crear programas de componentes COM compactos y rápidos.
Según el punto de vista general actual, Visual C++ tiene más ventajas cuando se aplica a programas de servicios COM, y Delphi es más adecuado cuando se aplica a programas de componentes COM.
Ayer, hoy, mañana
El progreso tecnológico a menudo tiene altibajos. Al principio, Turbo C y Borland C++ de Borland eran casi las únicas opciones para los programadores de C/C++. Quick C de Microsoft (¿alguien conoce todavía este producto?) y Microsoft C/C++ nunca se han generalizado. Pero, ¿cuántos años lleva siendo popular Borland C++? Pronto fue suprimido por el recién emergente Microsoft Visual C/C++. Entonces Inprise (anteriormente Borland) recogió la gloria de Turbo Pascal y Borland Pascal (de hecho, el famoso trabajo de Borland fue el primer compilador de Pascal) y lanzó Delphi con todas sus fuerzas.
Delphi fue llamado el asesino de VB cuando se lanzó por primera vez, pero VB todavía está vivo y coleando. Después de todo, Microsoft comenzó con Basic y VB no es tan fácil de derrotar. Inprise pensó por un tiempo y dejó de competir con VB. En cambio, utilizó el IDE y VCL de Delphi junto con el lenguaje C ++, lanzó C ++ Builder y lanzó un doble ataque en el mercado de Visual C ++. ¿C++Builder parece un buen compromiso? ¡Piensa de nuevo! C++Builder tiene las ventajas de Delphi, pero es posible que C++Builder no tenga las ventajas de Delphi. Por ejemplo, la velocidad de compilación de C++Builder es más lenta que la de VC, ¿cómo se puede comparar con Delphi? Y como VCL está escrito en Object Pascal, el lenguaje C++ y VCL no se llevan bien. C++Builder tiene más errores que Delphi e incluso hay errores en el código de muestra. Algunas funciones de VCL no se pueden utilizar y se debe acceder a ellas incorporando código Pascal. C++Builder tiene muchos menos controles de terceros que Delphi.
Por desgracia, el oro no existe. Microsoft o Inprise, ¿quién reirá último?
Un pez y una pata de oso: una elección difícil
La elección de una herramienta de desarrollo depende de muchos factores diferentes. Cualquier persona puede abandonar el aprendizaje o el uso de un idioma debido a un determinado defecto. idioma. Cualquier programador espera que sus herramientas favoritas puedan alcanzar el estado ideal. A través de la comparación imperfecta anterior, creo que todos tienen sus propias opiniones. Creemos que los factores que influyen en la elección del idioma de desarrollo de todos incluyen principalmente:
1) ¿Con qué idioma es más fácil comenzar?
Aprender un idioma requiere mucho tiempo y esfuerzo. El costo de desarrollar un programa es una realidad que vale la pena considerar. La eficiencia del trabajo de un programador experto de Delphi y de un programador de VC experto es la misma. Sin embargo, convertirse en un programador competente requiere dominar rápidamente las habilidades de un idioma. Desafortunadamente, los programadores expertos en Visual C++ de hoy en día son sólo uno de cada diez. Relativamente hablando, Delphi es más adecuado para principiantes.
2) ¿Qué idioma tiene más código heredable?
La reutilización del código del lenguaje es un aspecto obvio para acelerar la eficiencia del desarrollo, desde los primeros procesos y funciones hasta la tecnología de componentes actual, todos nos esforzamos por alcanzar este objetivo. Los dos lenguajes tienen diferentes comprensiones de la reutilización de código. Delphi implementa principalmente la reutilización de código a través de controles VCL, mientras que Visual C++ es más complicado de implementar.
3) La naturaleza del lenguaje mismo.
En términos de tecnología (principalmente marco de aplicaciones), Delphi está actualmente por delante de Visual C++. Pero la falta de estabilidad y robustez me hace decirle a Inprise: "No es fácil amarte". Aunque VC se ha desarrollado muy bien hoy en día, el marco MFC ya es cosa del pasado. Si no utiliza MFC, actualmente no existe ninguna alternativa adecuada. Haga su elección en función de sus necesidades y situación real. De hecho, Visual C++ y Delphi no están simplemente compitiendo. En muchos ámbitos no se superponen e incluso son complementarios. La forma de elegir depende de las características de tu proyecto. Si desarrolla cosas de bajo nivel en el sistema y necesita excelente compatibilidad y estabilidad, elija Visual C++. Puedes simplemente llamar a varias API de Windows sin MFC. Si escribe una aplicación de escritorio tradicional de Windows, el marco MFC de Visual C++ es la opción "ortodoxa" si la parte de la interfaz representa una gran proporción del código de la aplicación, o si hay controles con funciones relacionadas en Delphi, Delphi es la opción. opción de obtener el doble de resultado con la mitad del esfuerzo. Si desarrolla aplicaciones de alto nivel, como bases de datos y sistemas de gestión de información para empresas ("alto nivel" es relativo a "bajo nivel/nivel inferior", y no significa tecnología de alto o bajo nivel), y hay Los plazos son relativamente ajustados, es mejor elegir Delphi. Si el lenguaje con el que está familiarizado es Object Pascal y no planea aprender C++ complejo, entonces Delphi es casi la única opción. La visión tradicional es que Delphi es adecuado para escribir Internet/Intranet, dibujar tablas, operaciones de bases de datos, interfaces de usuario avanzadas, etc. Visual C++ es adecuado para escribir controladores de dispositivos, programas de servicios COM, informática científica, programas de consola, aplicaciones WinCE y algunas herramientas pequeñas, etc. La diferencia en el alcance de la aplicación requiere que los buenos programadores dominen ambos idiomas.
4) La perspectiva y escalabilidad del lenguaje.
Delphi es uno de los productos estrella de Inprise y sus perspectivas deberían ser relativamente optimistas. Además, Inprise ya está avanzando hacia Linux, mientras que Microsoft aún no ha dado ningún paso. Desafortunadamente, el fundador de Delphi de Inprise se mudó a Microsoft para albergar los proyectos de Visual J++ y C#. Con suerte, el impacto en Inprise no será demasiado grande.
¿Cuál es el futuro de Visual C++ de Microsoft? Visual Studio 7.0 llegará pronto.
Esta versión mejorará las funciones para el desarrollo web. Parece que aunque Microsoft ha sido condenada a la desintegración, su fuerza de desarrollo no se ha visto comprometida en absoluto.
Además, aunque MFC está ligeramente por detrás, no significa que no valga la pena aprenderlo. De hecho, no aprender MFC significa no aprender VC. El uso del marco MFC para desarrollar programas sigue siendo el modelo principal para desarrollar aplicaciones de escritorio y lo seguirá siendo durante mucho tiempo. El director ejecutivo de Microsoft, Steve Ballmer, dijo una vez que .NET tardará entre 2 y 3 años en volverse popular. Entonces, MFC todavía tiene al menos 2-3 años de vida útil. En el mundo de las tecnologías de la información, donde la tecnología cambia rápidamente, 2 o 3 años es realmente mucho tiempo. Aprovechalo. Incluso si no utiliza el marco MFC, será muy beneficioso tomarse un tiempo para observar el mecanismo de encapsulación de MFC para familiarizarse con el mecanismo de programación orientada a objetos de C++ y las funciones subyacentes de Windows. El código fuente de VCL es Object Pascal, que no tiene este efecto "extra" para los programadores de C/C++.