Comparación entre Delphi y vc
~v~
La "Comparación entre Visual C++ y Delphi" ha provocado recientemente una acalorada discusión en el foro CSDN. Este artículo comparará e introducirá objetivamente las ventajas y desventajas de Visual C++ y Delphi en términos de nivel técnico, función, rendimiento, facilidad de uso, estabilidad y perspectivas, representadas por Visual C++6 y Delphi5. Esto involucrará lenguaje y aplicación. marcos, controles, etc. Este artículo también brindará algunas sugerencias sobre cómo elegir y utilizar estas dos herramientas de desarrollo.
Vale la pena mencionar que dado que C++Builder y Delphi son productos de InEnterprise, tienen casi las mismas características excepto por los diferentes lenguajes. Por lo tanto, este artículo también tiene un valor de referencia para los programadores y estudiantes de C++Builder.
Lenguaje: la existencia es razonable.
En primer lugar, a menudo se confunde que VC y Delphi no son lenguajes en sí, sino plataformas de desarrollo. Sus lenguajes son C/C++ ligeramente extendido y Object Pascal. A menudo veo gente preguntando en Internet si aprender C/C++ o VC. Esta pregunta es fácil de responder: para aprender VC, debes aprender C/C++, o para aprender VC, debes aprender C/C++.
De todos modos, 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 términos del lenguaje en sí, Object Pascal y C++ pertenecen a la misma clase de peso pesado. Ambos son lenguajes totalmente orientados a objetos y tienen sus raíces en lenguajes orientados a procedimientos "establecidos desde hace mucho tiempo". C++ evolucionó a partir de C y Object Pascal evolucionó a partir de Pascal. Ambos tienen una gran flexibilidad y tienen sus propias ventajas y desventajas. 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 constructores ficticios, procedimientos anidados, tipos de colección integrados, tipos de cadenas integrados, construcciones "finalmente", etc. Object Pascal funciona mejor que C++ en RTTI. Pero esto no es importante, porque el mismo objetivo se puede lograr de otras maneras. Por ejemplo, C++ puede admitir colecciones y cadenas a través de extensiones de clase, Object Pascal puede heredar varias veces a través de "inte***ce", etc. La clave es que ambas personas sean buenas en la tarea que tienen entre manos, y eso es suficiente.
Pero no basta con comparar los idiomas en sí, sino también observar su aceptación y popularidad, curva de aprendizaje, perspectivas de desarrollo, portabilidad, etc. , y un punto muy importante pero que a menudo se pasa por alto: el grado de "encuentro" con el entorno de desarrollo (refiriéndose a VC y Delphi) y su marco de aplicación.
Como plataformas de desarrollo, VC y Delphi proporcionan 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++ es mucho más versátil y portátil que Object Pascal. Esto es originalmente una ventaja, pero lo interesante es que debido a esto, Microsoft debe considerar minimizar los cambios en el lenguaje en sí al escribir MFC. Para admitir ANSI y otros estándares tanto como sea posible, se centra en el nivel del código fuente. dando como resultado MFC. El empaque es sofisticado pero intuitivo. (Especialmente su encapsulación de mensajes, que se mencionará a continuación). Se generan automáticamente demasiadas definiciones macro ambiguas y comentarios que no se pueden cambiar. Esto hace que muchos principiantes se sientan intimidados por MFC e incluso VC y no se atrevan a "meterse en el agua" para aprender en profundidad. Object Pascal es casi "exclusivo" de InEnterprise y no es necesario considerar cuestiones "estándar". Por lo tanto, cuando InEnterprise escribió "VCL", centró toda su energía en la estructura y el rendimiento, haciendo que la integración del lenguaje y el marco fuera muy buena. El marco VCL tiene una estructura clara y el código VCL es muy legible. Mucha gente dice que Delphi es fácil de usar y esa es también la razón. No hay almuerzo gratis en el mundo.
¿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 "Libro del Cielo" de MFC.
Compilación y conexión: la necesidad de velocidad
Otra diferencia que provocan los diferentes lenguajes son las diferentes velocidades de compilación y conexión, así como las diferentes velocidades de ejecución. No es exagerado decir que la velocidad de compilación y conexión de Delphi es decenas de veces más rápida que la de VC. Incluso si la opción de enlace incremental de VC está activada, la velocidad de compilación y enlace de Delphi sigue siendo varias veces más rápida que la de VC. No es que el compilador de Microsoft no sea bueno, es la complejidad de C++ lo que lo determina. 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 un inconveniente, pero la ventaja es que la 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 de 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 hay algunos 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) Lógica propensa a errores; el encabezado de archivo incorrecto, es fácil que se produzcan errores de "Fin de archivo inesperado".
Lo que ambos compiladores tienen en común es que 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 mejor trabajo en este sentido. Le permite indicar visualmente en el editor qué líneas de código están "vivas" y qué líneas de código están "muertas". De esta manera puedes organizar el código lo más simplificado posible. Una vez compilado Delphi, se mostrará un pequeño punto azul a la izquierda, lo que indica 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), pero el archivo ejecutable compilado por MFC en programación Visual C++ es generalmente solo unas pocas docenas de K. Principalmente porque Microsoft ha incluido el tiempo de ejecución del sistema en el sistema Windows (Borland una vez negoció esta interfaz con Microsoft, pero Microsoft no estaba dispuesto a aprovechar el sistema operativo para hacerlo público). De manera similar, el programa de base de datos desarrollado por BDE debe venir con entre 3 y 5 millones de archivos de sistema adicionales, lo que también está muy descoordinado.
Lo interesante es que Delphi puede utilizar archivos OBJ creados por C++ Builder, pero su uso está muy restringido.
Finalmente, el mensaje de error al compilar y conectar Visual C++ es mucho más detallado y específico que el de Delphi. Especialmente desarrollando con ATL.
Marco de aplicación: ¿MFC? ¿Es popular KFC?
Marco de aplicación, a veces llamado marco de objetos. 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 Windows 3.x, cuando Visual C++ tenía 16 años. Después de años de continuas incorporaciones y mejoras, MFC se ha vuelto muy maduro. Sin embargo, debido a la temprana aparición de prototipos, MFC estuvo una era detrás de VCL. Aunque Microsoft nunca ha dejado de actualizar MFC, y a menudo veo artículos como "Mientras Windows esté desactualizado, MFC no estará desactualizado", pero al igual que el marco OWL de InEnterprise (anteriormente Borland) se desvaneció, MFC desaparecerá antes. o más tarde. De hecho, MFC y OWL son productos de la misma época. Sin el búho, ¿cómo podría el MFC no estar preparado para el peligro en tiempos de paz? Si MFC es inmortal, los desarrolladores de Microsoft no desarrollarán "privadamente" WTL basado en ATL. Por supuesto, la posición de WTL no se puede comparar con la de MFC. No es un marco compatible con Microsoft y las capacidades de empaquetado son bastante limitadas. Pero al menos refleja las deficiencias del MFC.
Creemos que el marco de aplicación más avanzado es su modelo de delegación, que es el mecanismo de encapsulación de mensajes de Windows. No hace falta decir que 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 encapsularlo. Pero no es tan fácil encapsular el mecanismo basado en mensajes de Windows. El método 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 adopta un método "antiguo" de definición de macros. La ventaja de utilizar el método de definición de macro es ahorrar la sobrecarga del sistema de la función virtual VTable (debido a que hay muchos tipos de mensajes en Windows, la sobrecarga no es pequeña). Sin embargo, la desventaja es que el mapeo no es intuitivo. Para MFC, "demasiado intuitivo". Aunque su código de mapeo de mensajes es visible, "no se recomienda tocarlo". 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 modo de delegación de VCL, el método de mapeo de MFC está demasiado atrasado. Debido a que Object Pascal de Delphi no tiene una "carga estándar", el lenguaje introduce nuevas características como componentes, manejo de eventos y propiedades. Debido a que Kung Fu está en el nivel del compilador, el código fuente generado es muy conciso. Parece que VC es "dejar que el marco se adapte al lenguaje", y Delphi es "dejar que el lenguaje se adapte al marco".
Me gustaría dar un ejemplo de encapsulación de operaciones de cadenas para ilustrar las ventajas y desventajas de MFC y VCL. En MFC, la clase CStringList tiene las funciones de agregar, obtener y eliminar, mientras que la clase TStringList de VCL 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 mayor y más abstracta que MFC, pero el problema inevitable es que algunas partes son ligeramente menos eficientes que MFC. Esto es como si los lenguajes de bajo nivel (como el ensamblador) tuvieran una mayor eficiencia de ejecución que los lenguajes de alto nivel (como el Básico), pero una menor eficiencia de programación. 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, mientras que una gran desventaja es su pobre soporte para subprocesos múltiples. La mayoría de las VCL no están optimizadas para subprocesos múltiples. Aunque VCL proporciona clases para simplificar las operaciones de subprocesos múltiples, sólo los subprocesos de trabajo son relativamente fáciles de usar. Las cosas se ponen problemáticas si los subprocesos tienen que manejar interfaces, porque ningún subproceso que no sea el subproceso 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, por el contrario, no tiene tales restricciones.
Estable y perfecto: VC es el hermano mayor.
VC es más estable y completo 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 InEnterprise. MFC, el marco de VC, ha experimentado muchos años de desarrollo y mejora. Sus funciones son muy completas y estables, y hay pocos errores. Entre ellos, es posible que encuentre menos errores. Los terceros cuentan con herramientas especializadas para ayudarlo a evitar estos errores. No es fácil hacer esto con una biblioteca de este tamaño. No subestimes esto, muchos programadores profesionales eligen VC por este motivo. Porque aunque VCL es más abstracto y tiene un nivel de encapsulación más alto que MFC, la mejora en la eficiencia del desarrollo que aporta es limitada para los expertos. 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 en la VCL. ¿Qué opinas? Aunque es poco probable que se produzca un problema de este tipo, tendrá un gran impacto en la imagen de VCL. El IDE de Delphi consume demasiados recursos, se inicia demasiado lento, entra en conflicto con algunos controladores de tarjetas gráficas, VCL tiene errores, el depurador no es lo suficientemente robusto y no tiene medidas de protección para controles inestables de terceros... Hay muchos problemas y Delphi no es tan bueno como VC en este sentido. Quiero un tramo de escaleras para llegar a mi negocio. Por cierto, vimos en Internet que alguien habló muy bien de la inestabilidad de Delphi, diciendo que hubo más de 20 operaciones ilegales en pocos minutos. Delphi no es tan estable como Visual C++, pero no necesariamente. Calculo que el Delphi de mi amigo tiene instalados algunos controles de terceros problemáticos, lo que provoca errores frecuentes en Delphi. ¿Por qué no intentas eliminar esos controles?
Portabilidad: Basado en la realidad y mirando al futuro.
InEnterprise está desarrollando una versión para Linux de Delphi, cuyo nombre en código es Kylix.
Quizás a través de Kylix, los programas de Windows escritos en el marco VCL se puedan portar a Linux. Pero esto sólo es posible. Porque la compatibilidad de InEnterprise aún no está lista. Las versiones inferiores de Delphi no pueden utilizar componentes VCL de versiones superiores, y las versiones superiores de Delphi no pueden utilizar componentes VCL de versiones inferiores. Es indignante que rara vez veamos software compatible no binario. 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 del otro, e incluso los nombres de archivo de la misma biblioteca VCL son diferentes. Por lo tanto, es común que un componente tenga diferentes versiones de D1/D2/D3/D4/D5/C1/C3/C4/C5, y esto puede aumentar a medida que se actualizan Delphi y C++Builder. Espero que InEnterprise pueda resolver primero los problemas de compatibilidad de los hermanos. El VC de Microsoft no tiene estos 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 general, la interfaz integrada de VC no es tan buena como la de Delphi. Delphi puede comparar varios asistentes de VC con un solo inspector de objetos, sin mencionar el navegador de código, la lista de tareas pendientes, etc. Pero desde un pequeño punto podemos ver la inmadurez de Delfos. Por ejemplo, la función "autocompletar" no es tan inteligente y detallada como VC, y la velocidad de respuesta no es tan rápida como VC.
MSDN presentado por Visual C++ es una "enciclopedia para desarrolladores" con una gran cantidad de información, consultas fáciles y más profesional que Delphi. Muchos proyectos de ayuda tienen demostraciones del programa fuente.
OpenTools de Delphi es un sistema abierto completamente orientado a terceros. Los desarrolladores pueden modificar muchas funciones de Borland y Delphi es mejor en términos de escalabilidad IDE.
Depuración: vea el trabajo real en detalle.
Visual C++ y Delphi tienen funciones de depuración muy poderosas, que incluyen depuración visual en un solo paso, seguimiento de puntos de interrupción, cambios de variables en tiempo de ejecución y adquisición de valores variables con el puntero del mouse. También puede administrar fácilmente la entrada y salida de la DLL y realizar la depuración a nivel de código fuente.
Relativamente hablando, Visual C++ puede ver más fácilmente los cambios en las variables, incluida la expansión de la estructura en un árbol de datos, para conocer el valor de cada variable. En cada paso de depuración, las variables modificadas se agregarán en rojo, lo que hará que la depuración sea más conveniente. Además, ver la memoria de bloque en Visual C++ es más conveniente que en Delphi.
Por supuesto, Delphi también tiene muchos aspectos considerados. Por ejemplo, al depurar subprocesos, Delphi puede verificar fácilmente los cambios de 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 es algo que los capitalistas de riesgo no pueden hacer. 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 lograr operaciones visuales. Es precisamente gracias al empaquetado de clases de bases de datos de Delphi que los usuarios no tienen que intervenir de principio a fin como en Visual C++ al operar la base de datos. La velocidad de desarrollo mejora significativamente.
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 principalmente a los datos 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, la funcionalidad relativa de Access es demasiado 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 las tecnologías OLE y ActiveX. COM define un conjunto de API y un estándar binario que permiten que objetos independientes en diferentes lenguajes de programación y 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 interfaces, variables y funciones de cadena amplia. Estos paquetes COM son de hecho más convenientes que C++. Por ejemplo, cuando se programa COM en C++ (sin un marco de clases), la variante se define como la estructura VARIANT en el archivo oaidl.h. Para manejar variantes, las funciones API VariantXXXX() en oleaut32.dll se deben ajustar manualmente para la inicialización y administración, como VariantInit(), VariantCopy(), VariantClear(), etc.
Visual C++ tiene una forma especial de implementar 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 controles y servicios COM, ATL tiene mejores interfaces con la última tecnología COM que Delphi en términos de construcción basada en plantillas. ATL es más propicio para crear programas de componentes COM pequeños y rápidos.
Según la opinión común actual, Visual C++ tiene más ventajas cuando se usa en programas de servicios COM, y Delphi es más adecuado cuando se usa en programas de componentes COM.
Ayer, hoy, mañana.
En muchos casos, el progreso tecnológico cambia. 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 este producto ahora?) y Microsoft C/C++ nunca han sido comunes. Pero, ¿cuántos años lleva siendo popular Borland C++? Rápidamente se vio superado por el nuevo Microsoft Visual C/C++. Entonces Enterprise (anteriormente Borland) tomó 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 jugar. Inprise pensó un rato y no discutió con VB. Utiliza Delphi IDE y VCL en lenguaje C++, lanza C++Builder e impacta el mercado de Visual C++. ¿C++Builder parece un buen compromiso? ¡Piensa de nuevo! Delphi tiene todas las ventajas de C++Builder, pero C++Builder no necesariamente tiene las ventajas de Delphi. Por ejemplo, la velocidad de compilación de C++Builder es más lenta que la de VC, entonces, ¿cómo se puede comparar con Delphi? Y debido a que VCL está escrito en el objeto Pascal, el lenguaje C++ y VCL no funcionan bien juntos. C++Builder tiene más errores que Delphi, e incluso el código de muestra tiene errores. Algunas funciones de VCL no se pueden utilizar y es necesario acceder a ellas incorporando código Pascal. Hay muchos menos controles de terceros disponibles en C++Builder que en Delphi.
Por desgracia, el oro no tiene precio. ¿Quién reirá el último, Microsoft o InEnterprise?
Ten el pastel y cómelo: una decisión difícil
La elección de una herramienta de desarrollo depende de muchos factores diferentes, y todo el mundo puede dejar de aprender o utilizar un idioma debido a algún tipo de deficiencia. . Todo programador espera que sus herramientas favoritas puedan alcanzar el estado ideal. A través de la comparación imperfecta anterior, creo que cada uno tiene su propia opinión. Creemos que los factores que influyen en la elección del idioma de desarrollo de las personas incluyen principalmente:
1) ¿Qué idioma es más fácil de aprender?
Aprender un idioma requiere mucho tiempo y esfuerzo. El costo de desarrollar una propuesta de desarrollo 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, para convertirse en un programador competente, debe dominar rápidamente las habilidades de un idioma.
Es una lástima que el número actual de programadores expertos en Visual C++ sea sólo uno de cada diez. En términos relativos, 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 entienden la reutilización de código de manera diferente. Delphi logra principalmente la reutilización del código a través de controles VCL, mientras que Visual C++ es más complejo 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 hace que mi "No es fácil decir te amo" mejore. Aunque el desarrollo de VC ha sido perfecto hoy en día, el marco MFC ya es cosa del pasado. Si no se utiliza MFC, actualmente no existe ningún sustituto adecuado. Haga su elección basándose en sus propias necesidades y situación real. De hecho, Visual C++ y Delphi no son puramente competitivos. En muchos ámbitos no se superponen ni se complementan entre sí. La forma de elegir depende de las características de tu proyecto. Si necesita una excelente compatibilidad y estabilidad al desarrollar sistemas subyacentes, elija Visual C++. Puede llamar directamente a varias API de Windows en lugar de MFC. Si escribe una aplicación de escritorio tradicional de Windows, el marco MFC de Visual C++ es una opción "ortodoxa" si la parte de la interfaz representa una gran proporción del código de la aplicación, o hay controles con funciones relacionadas en Delphi, entonces Delphi es una manera de obtener el doble de resultado con la mitad del esfuerzo. Si está desarrollando aplicaciones avanzadas, como bases de datos y sistemas de gestión de información para empresas ("avanzado" es relativo a "bajo nivel/bajo nivel", no significa que la tecnología sea avanzada o de bajo nivel), y hay En un plazo ajustado, Delphi es mejor. 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 algunos dispositivos. Las diferentes aplicaciones requieren que excelentes programadores dominen ambos idiomas.
4) La perspectiva y escalabilidad del lenguaje.
Delphi es uno de los productos estrella de InEnterprise y sus perspectivas deberían ser optimistas. Además, InEnterprise ha ido avanzando hacia Linux, pero Microsoft aún no ha dado ningún paso. Es una lástima que InEnterprise, el fundador de Delphi, se haya pasado a Microsoft para alojar proyectos de Visual J++ y C#. Esperemos que el impacto en InEnterprise no sea demasiado grande.
¿Cuál es el futuro de Visual C++ de Microsoft? Visual Studio 7.0 llegará pronto. Esta versión mejorará las funciones de 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é un poco atrasado, no significa que no valga la pena aprenderlo. De hecho, si no aprendes MFC, no aprendes 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. Dijo una vez el director ejecutivo de Microsoft, Steve Ballmer. NET tendrá que esperar 2-3 años. Entonces, al MFC todavía le quedan al menos 2-3 años de vida. En el campo de las tecnologías de la información, donde la tecnología cambia rápidamente, 2 o 3 años es realmente mucho tiempo. Aprovecha. Incluso si no utiliza el marco MFC, es beneficioso familiarizarse con el mecanismo de programación orientada a objetos de C++ y las funciones subyacentes de Windows, y echar un vistazo al mecanismo de encapsulación de MFC. El código fuente de VCL es Object Pascal, que no tiene ningún impacto "adicional" en los programadores de C/C++.