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 utilizará Visual C 6 y Delphi 5 como representantes para comparar e presentar objetivamente las ventajas y desventajas de Visual C y Delphi desde los aspectos de nivel técnico, función, rendimiento, facilidad de uso, estabilidad y perspectivas, etc. lenguaje, marco de aplicación, controles, etc. Este artículo también brindará algunas sugerencias sobre cómo elegir y utilizar estas dos herramientas de desarrollo.
Cabe mencionar que dado que C Builder y Delphi son productos InEnterprise, tienen casi las mismas características excepto por los diferentes lenguajes. Por lo tanto, este artículo también tiene valor de referencia para los programadores y estudiantes de C Builder.
Lenguaje: La existencia es razonable.
En primer lugar, la gente a menudo confunde VC y Delphi no como lenguajes, sino como 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 los pros y los contras 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. Ambos son lenguajes totalmente orientados a objetos y tienen sus raíces en lenguajes procedimentales "establecidos desde hace mucho tiempo". C se desarrolla a partir de C y el objeto Pascal se deriva de Pascal. Todos ellos tienen una gran flexibilidad y 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 clases estáticas globales, definiciones de clases anidadas, etc. compatibles con C. Pero de manera similar, C no admite constructores virtuales, procedimientos anidados, tipos de colecciones integrados, tipos de cadenas integrados, construcciones "finalmente", etc. Object Pascal hace un mejor trabajo que C en RTTI. Pero nada de esto importa, 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, los objetos Pascal se pueden heredar varias veces a través de "inte***ce", etc. La clave es que ambos sean buenos en la tarea que tienen entre manos, y eso es suficiente.
Sin embargo, no basta con comparar los idiomas en sí, sino también observar la aceptación y popularidad del idioma, su curva de aprendizaje, sus perspectivas de desarrollo, su portabilidad, etc. , y un punto muy importante pero que a menudo se pasa por alto: el grado de "adaptación" al entorno de desarrollo (consulte 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 habría sido una ventaja, pero lo que es muy interesante es que debido a esto, Microsoft tuvo que considerar minimizar los cambios en el lenguaje mismo al escribir MFC y centrarse en el nivel del código fuente para soportar ANSI y otros estándares tanto como fuera posible, lo que resultó en en MFC Embalaje 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, lo que hace que muchos novatos se sientan intimidados por MFC e incluso VC y no se atrevan a "dar el paso" para aprender en profundidad. Object Pascal es casi "exclusivo" de InEnterprise y no es necesario considerar cuestiones "estándar".
Por lo tanto, InEnterprise puso todos sus esfuerzos en la estructura y el rendimiento al escribir VCL, lo que resultó en un muy buen grado de integración entre el lenguaje y el marco. 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 vinculación: la necesidad de velocidad
Otra diferencia que provocan los diferentes lenguajes son las diferentes velocidades de compilación y vinculació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 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, 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 mencionaste antes que Object Pascal no tiene plantillas, preprocesamiento ni macros? Esto es una desventaja, 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 los problemas de velocidad de compilación, los compiladores de C a menudo requieren enlazadores 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; Si utiliza el encabezado de archivo incorrecto, es fácil que se produzcan errores como "Fin de archivo inesperado".
Lo que estos dos compiladores tienen en común es que pueden identificar código "muerto" inútil, como funciones inútiles, etc. El programa compilado no contendrá esta información redundante. Delphi hace esto mejor. 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. Después de la compilación, Delphi 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), pero el archivo ejecutable compilado por MFC en programación Visual C es normalmente sólo unas pocas docenas de K. Principalmente porque Microsoft ha incluido el tiempo de ejecución del sistema en el sistema Windows (Borland había negociado esta interfaz con Microsoft, pero Microsoft no estaba dispuesto a utilizar 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 que es muy interesante es que Delphi puede utilizar archivos OBJ creados por C Builder, pero su uso está muy restringido.
Finalmente, los mensajes de error al compilar y vincular Visual C son mucho más detallados y específicos que los 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 una biblioteca de control, aunque su nombre es "Biblioteca de control visual"). Si elige MFC, también puede elegir la estructura del programa y el 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 adiciones 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, 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á tarde o temprano. 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 existiera para siempre, los desarrolladores de Microsoft no desarrollarían "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 sus capacidades de empaquetado son bastante limitadas. Pero al menos también 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. De todos modos, sin contenido técnico. Si está satisfecho, también puede escribir una biblioteca de clases para encapsularlo. Pero encapsular el mecanismo basado en mensajes de Windows no es tan fácil. El método más natural de encapsulación es utilizar funciones miembro virtuales. Si desea responder mensajes, 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 será demasiado pequeña). Sin embargo, la desventaja es que el mapeo no es intuitivo. Es "demasiado intuitivo" para MFC. Aunque su código de mapeo de mensajes es visible, se "recomienda no tocarlo". Afortunadamente, ClassWizard de VC puede generar automáticamente código de mapeo de mensajes, lo cual es muy conveniente de usar. Pero en comparación con el modelo de autorización de VCL, el método de mapeo de MFC está demasiado atrasado. Debido a que no existe una "carga estándar" en Object Pascal de Delphi, 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 entradas y salidas. 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 términos generales, la encapsulación de VCL es más avanzada y abstracta que MFC, pero el problema inevitable es que la eficiencia de algunas partes es ligeramente menor que la de 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.
En comparación con MFC, otra ventaja de VCL es su soporte para el manejo de excepciones, y una gran desventaja 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 los subprocesos tienen que manejar interfaces, ya que ningún subproceso que no sea el subproceso principal de la aplicación puede acceder a ninguno de los componentes visuales 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: el capital riesgo 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. Después de tantos años de desarrollo y mejora, el marco MFC de VC se ha vuelto muy completo y estable, casi sin errores. Entre ellos, es posible que encuentre menos errores. Los terceros cuentan con herramientas especializadas para ayudarle a evitar estos errores. No es fácil hacer esto con una biblioteca de este tamaño. No subestimes esto, muchos programadores profesionales han elegido VC para esto. Porque aunque VCL es más abstracto y tiene un mayor nivel de encapsulación que MFC, la mejora en la eficiencia del desarrollo que aporta se limita a los expertos. Si encuentra un problema extraño y lo depura durante mucho tiempo, encontrará que el problema no está en su código, sino en un error en la VCL. ¿Qué opinas? Aunque es poco probable que se produzca este tipo de problema, tendrá un gran impacto en la imagen de VCL.
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 está aquí. No es tan bueno como VC. Quiero que mi negocio sea accesible subiendo un tramo de escaleras. Por cierto, vimos en Internet que alguien valoró muy positivamente la inestabilidad de Delphi, diciendo que en pocos minutos se habían realizado más de 20 operaciones ilegales. Delphi es menos estable que Visual C, pero ese no es el caso. Supongo que el Delphi de mi amigo tiene instalados algunos controles problemáticos de terceros, 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 sea posible portar programas de Windows escritos con el marco VCL a Linux. Pero esto sólo es posible. Porque la compatibilidad de InEnterprise aún no está lista. 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. 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 de cada uno, e incluso los nombres de archivos de la misma biblioteca VCL son diferentes. Por lo tanto, es común que un componente tenga diferentes versiones 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. Microsoft Ventures 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 se puede comparar con un montón de asistentes en VC con solo un inspector de objetos, sin mencionar el explorador 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, ni tan receptiva como VC.
MSDN presentado por Visual C es una "enciclopedia para desarrolladores" con una gran cantidad de información y fácil consulta, que es 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 características de Borland, pero Delphi es mejor en términos de escalabilidad IDE.
Depuración: vea el trabajo real en detalle.
Las funciones de depuración de Visual C y Delphi son muy poderosas. Ambos tienen funciones como depuración visual en un solo paso, seguimiento de puntos de interrupción, cambios de variables en tiempo de ejecución y puntero del mouse para obtener valores de variables. 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 hace que la depuración sea más conveniente. Además, ver la memoria de bloques en Visual C es más conveniente que en Delphi.
Por supuesto, Delphi también tiene muchos aspectos considerados. Por ejemplo, al depurar un hilo, Delphi puede inspeccionar fácilmente los cambios del hilo, pero Visual C debe mostrar un cuadro de diálogo modal.
Desarrollo de bases de datos: Delphi lidera el camino
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 a la aplicación para su visualización. Es precisamente gracias al empaquetado de clases de bases de datos de Delphi que los usuarios no tienen que intervenir de principio a fin al operar la base de datos como en Visual C. La velocidad de desarrollo mejora significativamente.
El uso del control WebBroker en Delphi también puede crear fácilmente páginas web basadas en bases de datos y administrar bases 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, las funciones relacionadas de Access serían demasiado débiles. 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, al programar COM en C (sin un marco de clases), las variables se definen como estructuras de variables en el archivo oaidl.h. Para manejar variantes, debe ajustar manualmente las funciones API de la variante xxxx() en oleaut32.dll para inicializarlas y administrarlas, 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. Si bien no es necesariamente más fácil implementar controles y servicios COM, las interfaces entre ATL y las últimas tecnologías COM son mejores que las de 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 general actual, Visual C tiene más ventajas cuando se utiliza en programas de servicios COM, mientras que Delphi es más adecuado cuando se utiliza en programas de componentes COM.
Ayer, hoy, mañana.
En muchos casos, el progreso tecnológico está en constante cambio. Inicialmente, 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 el Borland C? Rápidamente se vio superado por el nuevo Microsoft Visual C/C. Entonces Enterprise (anteriormente Borland) recuperó 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ó un rato y no discutió con VB. Utiliza el lenguaje C Delphi IDE y VCL, lanza C Builder y ataca el mercado de Visual C.
¿C Builder parece un buen compromiso? ¡Piensa de nuevo! Delphi tiene todas las ventajas de C Builder, 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? Debido a que la VCL fue escrita en Object Pascal, el lenguaje C y la VCL no funcionaban bien juntos. Hay más errores en C Builder que en Delphi, incluso el código de ejemplo tiene errores. Algunas funciones de VCL no están disponibles y es necesario acceder a ellas incorporando código Pascal. Hay muchos menos controles de terceros disponibles en C Builder que en Delphi.
Ay, ya no hay oro. ¿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 determinado idioma debido a algún defecto. Cualquier programador quiere que sus herramientas favoritas funcionen como deberían. Con 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 un plan de desarrollo es una realidad que vale la pena considerar. Un programador experto en Delphi y un programador VC experto tienen la misma eficiencia en el trabajo. Sin embargo, para convertirse en un programador competente, debe dominar rápidamente las habilidades de un idioma. Desafortunadamente, actualmente sólo hay 1 de cada 10 programadores expertos en Visual C. 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 mejorar 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 frameworks de aplicaciones), Delphi está actualmente por delante de Visual C. Pero la falta de estabilidad y solidez hace que "no me resulte fácil decir te amo". Aunque VC se ha desarrollado a un nivel perfecto hoy en día, el marco MFC se ha convertido en una cosa del pasado. Si no 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 son más que simples competidores. No se superponen ni se complementan en muchos ámbitos. La elección depende de las características de su 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 forma de hacerlo; obtenga el doble de resultado con la mitad del esfuerzo de elección. Si está desarrollando 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/bajo nivel" y no significa tecnológicamente avanzado o de bajo nivel) y tiene plazos ajustados , Delfos 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 buenos 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 estado incursionando en Linux, pero Microsoft aún no ha tomado medidas. Desafortunadamente, InEnterprise, el fundador de Delphi, se mudó a Microsoft para albergar los proyectos de Visual J y C#. Espero que el impacto en InEnterprise no sea demasiado grande.
¿Cuál es el futuro del 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 afectada en absoluto.
Además, aunque MFC esté un poco por detrás, 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 mucho tiempo. Aprovecha. Incluso si no utiliza el marco MFC, estar familiarizado con el mecanismo de programación orientada a objetos de C y las funciones subyacentes de Windows le ayudará a comprender el 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.