A traves de Borland Developer Network (BDN) y Mundo Delphi, me entero que finalmente si que habrá una nueva versión de C++ Builder.
Una noticia que por un lado me alegra enormemente, y que por otro viene a rectificar la mala política que ha seguido Borland últimamente.
Por lo que se puede ver, todo indica que C++ Builder será un Addon que se montará sobre el actual IDE común usado en Delphi 2005 para generar aplicaciones Delphi, Delphi.NET, y C# Builder. Probablemente se hagan diferentes ediciones, con todos, o solamente con alguno de estos lenguajes, a los que evidentemente habrá que añadir el C++. Así tendremos el Borland Developer Studio, con todos ellos, y cada producto por separado utilizando el mismo IDE.
Se aprecia también que la Visual Component Library (VCL), es la versión 9.0, la misma que hay en Delphi 9 (2005).
Con todos estos datos preliminares, me aventuro a conjeturar, que C++ Builder 7.0/9.0/2005 aparecerá antes de la nueva revisión de Delphi, de forma que se sigue el ciclo de versiones que ha existido siempre: Se desarrolla una nueva versión de Delphi, se desarrolla una nueva versión de VCL compilada con ese Delphi, y se lanza la nueva versión de Delphi. Posteriormente, se desarrolla una nueva versión de C++ Builder (ahora también de C# Builder) capaz de utilizar la nueva VCL, y se lanza ese C++ Builder. El proceso vuelve a comenzar con la nueva versión de Delphi, … Si la memoria no me falla, el tiempo que ha transcurrido desde el lanzamiento de un Delphi hasta su homónimo C++ Builder, ha estado entorno a los 6 meses, por lo que la espera no será demasiado larga.
No espero grandes mejoras en el compilador de C++, un componente que siempre me ha parecido flojo. De forma similar a Delphi 2005, se le añadirá soporte de ensamblador en linea SSE, SSE2 y SSE3, pero poco más. No creo que la calidad del código generado mejore notablemente.
Con este movimiento, Borland sigue teniendo la única herramienta de desarrollo RAD basada en C++, pero esta vez, puesta al día. ¿Obligará esto que Microsoft añada capacidades visuales reales en Visual C++? Ojalá que así sea.
C++ Builder es maravilloso en cuanto a facilidad de desarrollo visual, y rapidez de compilación. En cambio Visual C++ destaca por la calidad del código generado, y la calidad en la documentación. Ambos productos tienen mucho en lo que mejorar, pero esta vez, y por suerte, Borland ha dado el primer paso.
Podeis ver una demo de esta nueva versión aquí.
¿La "única herramienta de desarrollo RAD basada en C++"? Echa un vistazo:
Visual C++ 2005
http://lab.msdn.microsoft.com/express/visualc/default.aspx
Visual C++ 2003
http://msdn.microsoft.com/visualc/
Y si buscas un "buen" compilador, prueba y veras, esto no es el compilador gratuito de borland:
Visual C++ Toolkit 2003
http://msdn.microsoft.com/visualc/vctoolkit2003/
The GNU Compiler Collection (GCC)
http://gcc.gnu.org/
A mi opinión, y coincidiendo contigo, la gente de borland hizo dos o tres amagos y luego la cagó estrepitosamente en algunas cosas. ¿Qué pasa con Kylix? Parecia una muy buena idea…
Luis, Visual C++ 2005 no lo he tocado, pero el 2003 y anteriores si, y no me parecen una herramienta de desarrollo rápido. Al menos lo que yo entiendo por desarrollo rápido. Esto no es ni más ni menos que poder diseñar las interficies de usuario de forma visual, copiando y pegando, arrastrando y moviendo controles.
Esto no es posibile con lo que yo conozco de Visual C++, siempre es necesario hacer un proceso manual, que va desde tratar con la API de Windows, o cualquier biblioteca de widgets, hasta mapear los recursos del formulario en instancias de clases MFC.
En cambio Visual Basic, Delphi, C++ Builder, Visual C#, Visual J#, Visual Basic .NET, si que permiten hacer todo esto. Como digo, el principal problema de estos entornos, es la falta de rendimiento de su compilador, que lamentablemente no está a la altura del GCC/GPP, y mucho menos de Visual C++ de Microsoft. En resumen, años luz del líder Intel C++ compiler.
Durante la versión 4.5 de Borland C++, se distribuyó un compilador alternativo basado en el Intel C++ 4 de aquellos días. La velocidad de ejecución era excepcional, por desgracia la compatibilidad con la sintaxis Borland no daba la talla.
Por ello, no es una solución aceptable reemplazar el compilador por el de otros, manteniendo las herramientas de Borland. También se probó esto mismo con el C++ BuilderX (un frontend Java, con el GCC). La alternativa que yo veo, es que Borland, implemente más y mejores optimizaciones en el backend del compilador compartido entre Delphi y C++ Builder, y luego a ser posible, también en el frontend.
Bueno, quizá la versión que tengas de Visual C++ no este completa. Te paso una screenshot y veras como si.
Visual C++ 2003 (23kb)
El compilador de Borland, ha sido y sigue siendo un clasico. La gente de Borland tiene sobrada experiencia en herramientas de desarrollo y eso se nota. Pero su gente de administración no parece saber ejecutar muy bien la adopción de esas tecnologías.
MFC está destinado a desaparecer, porque realmente no cubre (y creo que nunca ha cubierto) las espectativas que deberia cubrir. Si te fijas, Microsoft va a cambiar de hecho todo su sistema de desarrollo en las próximas versiones de Windows, por lo que parece que .NET es una apuesta bastante real. Echale un vistazo al centro de desarollo de longhorn, si buceas algo entre el código, esta impregnado de .NET.
Longhorn Developer Center
Tanto tanto que hasta gente de Linux, como Miguel de Icaza, por ejemplo, ha considerado la adopción de .NET para Linux mediante el proyecto Mono::, y ahora Novell simplemente está volcada en ello desde que compro Ximian. La alternativa, existir, existe. De hecho, algunas fuentes de noticias apuntan a que Icaza esta considerando .NET como la "evolución natural" de GNOME.
The Register (UK)
Antes de que la palabra "rendimiento" te salte a la cabeza, despojala. No hay ningun problema, algún dia que tenga tiempo me armo de valor y te dedico un post en mi blog (eso si, te lo tendre que justificar con ejemplos bajo linux, sino no vale ok?)
GCC (con mayusculas, y luces de colores alrededor parpadeando) es el mejor. Y punto. No voy a entrar en discusiones, para mi es de religión. 😉 El de Intel no lo he tocado suficiente como para opinar, pero el HECHO es que GCC se utiliza para compilar las aplicaciones y sistemas de medio planeta, entre Linux, FreeBSD, MacOSX, etc, etc, etc..
Me gusta tu blog, no hay mucha gente que se atreva a hablar de compiladores valientemente. Siento mi intromisión, en ningún momento quisé ofender a nadie y entiendo que con estos temas es fácil, pero me gustó el tema de debate.
Por cierto, estaría interesado en probar codigo generado por Delphi (.NET) sobre linux. ¿Crees que se podrá? Ya me cuentas algo y escribimos un articulo de interoperabilidad ok?.
(¿como está eso de la velocidad de ejecución de los compiladores? uysss…)
Parece ser que la campaña de marketing de Microsoft funciona de maravilla, ya que hace creer a la gente que su compilador de C++ es visual cuando lo unico que hacia era poder diseñar los cuadros de dialogo que iban en la aplicacion como recursos.
(…) la mie%$?#$A de MFC… Ya estamos con otro con MFC…
Tranquilos… que no ¡funda el pánico! 🙂
Primero de todo Luis, aclararte que no es ninguna intromisión tu comentario en este blog, al revés, lo considero una contribución, y de las buenas.
En cuanto a lo del diseño visual, por lo que veo en tu pantallazo, lo que se está generando es una aplicación .NET en Visual C++, no una nativa. Quizás me expliqué mal, pero me refería a compiladores nativos. ¿Es posible con Visual C++ generar aplicaciones Win32 de forma visual? Yo pensaba que no, pero tal vez me equivoco.
Lo primero que me ha venido a la cabeza, ha sido el tema del rendimiento, no soy experto en Linux, pero me servirá tu comparativa. En cuanto a las pruebas que yo hice, decirte que el compilador de Borland está a la par del Watcom C++ (un producto de hace 8 años), después venía GCC/GPP, luego Visual C++ (un 5% más rápido que GCC), y por último Intel C++ (algo así como un 15% más que VC).
Por cierto, aquí teneis un benchmark, algo antiguo, pero en mi opinión muy riguroso de diferentes compiladores de C++:
http://www.willus.com/ccomp_benchmark.shtml.
Entre otros, se prueban Borland C++, Visual C++, GCC, e Intel C++.
No cunde el panico 😉 Me encanta el tema xDDD
Antes de irme a cenar, dos comentarios y feliz navidad a todos.
Razón tienes en cuanto a la captura de pantalla que envié, es de una aplicación C++ de código gestionado, lease .NET ("utilizar" codigo no gestionado con codigo gestionado es sumamente fácil, por cierto)
En cuanto a lo de "nativa", tal como dices, es cierto que no existe opción alguna para trabajar visualmente con el IDE y Win32 (o MFC). Pero también es cierto que tampoco hay necesidad por las siguientes razones:
1. "Nativas" son los dos tipos de aplicaciones, tanto las generadas para .NET como las que no. La diferencia está en que el código .NET se compila especificamente para la máquina donde se ejecuta en LA PRIMERA EJECUCIÓN en dicha máquina. Luego nativas nativas, son las dos. El formato del ejecutable de cualquier ensamblado .NET es exactamente un PE estandar de toa' la vida. Al igual que Borland con VLC, CLX, etc. Microsoft hecha mano de la biblioteca de clases de .NET.
Es verdad que tal como te referias antes, no es posible generar aplicaciones "nativas" o mejor dicho "no gestionadas" (supongo que te referirias a Win32 o a aplicaciones con MFC, pero estamos en el mismo caso que Borland).
2. El rendimiento de .NET es menor que el rendimiento de una aplicación Win32 estandar, pero no porque el compilador JIT sea lento (recordemos que ya hemos dicho que solo hay una compilación por trozo de código a ejecutar y luego se queda en la caché de ensamblados YA COMPILADO para dicha máquina), sino porque hoy por hoy el runtime de .NET esta en un nivel bastante más "superior" que el actual API de windows y demás, por lo que se organiza bastante trasiego entre la biblioteca de clases y lo que hoy por hoy conocemos como windows. Es de esperar que veamos en futuras versiones de Windows como Microsoft "acerca" esas dos partes (o incluso sustituye partes completas) y el rendimiento logicamente aumenta. No olvidemos que VLC, también es una biblioteca y como tal, le toca sufrir. Una por otra, a mi me parecen lo mismo.
3. Hoy en dia, las aplicaciones tienen "demasiadas formas". Existen aplicaciones para PDA, aplicaciones Web, y cada dia la interfaz de usuario toma nuevas formas. Las necesidades no estan cubiertas y es normal que los lenguajes evolucionen para adaptarse a esas necesidades. Sino, aún pregonariamos con Turbo Pascal o Ensamblador puro y duro. A quien le de miedo el cambio que perfore una tarjeta como antaño.
FELIZ NAVIDAD A TODOSSSS!!!
Perdon por utilizar un lenguaje tan plano, se que hablar de "nativo", "biblioteca", etc. es peligroso y mis comentarios parten de lo que he podido ver y probar, lo cual no dice que sea asi exactamente.
Me parece bien el matiz que le haces a lo de aplicaciones nativas y no nativas. Vamos a llamarlas tal y como propones, gestionadas y no gestionadas (espero que nadie lo traduzca como manageadas).
En cuanto al rendimiento, tu principal argumento, me parece muy lógico, son más lentas, porque la librería de clases hace muchas cosas, y es de muy alto nivel. Cosa que como notas, también pasa con la VCL de Borland.
El caso es que por lo poco que he tocado de .NET (nunca con C++), pero si con C#, VB.NET y J#, la velocidad de ejecución es similar a la de VB 6, y por debajo de la de Delphi, C++ Builder, Visual C++ (no gestionado), …
Aquí van mis argumentos:
1) El compilador just-in-time, es decir, el que la primera vez que se enjecuta el aplicativo se encarga de transformar el byte code a código nativo en la memoria, no optimiza tanto como los compiladores tradicionales. Y tienes sentido, compilar una aplicación C++ (sin contar el enlazado), es un proceso que lleva segundos. Incluso Delphi, que es el compilador más rápido que he visto (ya desde los tiempos de Turbo Pascal), necesita de uno o dos segundos para el proceso. En cambio, grandes aplicaciones en .NET, como Elephant, se ejecutan con bastante celeridad incluso la primera vez. Se que el compilador JIT, puede decidir no compilar todo el binario, sino solamente lo que va a hacer falta en ese momento, y el resto compilarlo poco a poco. Aún así, todo se ejecuta muy rápido como para que puedan aplicarse optimizaciones serias. Es decir, poco tiempo para compilar, pocas optimizaciones.
2) El garbage collector, va consumiendo ciclos de reloj en segundo plano para gestionar la memoria. Aunque usemos C++, si es gestionado, las clases del runtime .NET que usamos están en C#, que es gestionado, por tanto el GC no se encarga de liberar objetos de nuestro programa C++, pero si de las clases intermedias que crea el framework. Aunque comparado con el GC de Java, el de .NET hace un excelente trabajo, esto consume algo de tiempo.
3) Las comprobaciones en tiempo de ejecución también necesitan ciclos de reloj. Cada vez se tiende a que programar sea más fácil, y con más mecanismos que vigilen nuestros errores. Para protegernos de los buffer over/underruns, las aplicaciones gestionadas, ofrecen la comprobación de límites en los datos que usamos, lo que requiere tiempo. En C++ Builder/Delphi no gestionado, no existe esa posibilidad. En VC++ es opcional. El caso es que si atacamos a aplicaciones gestionadas, ese control existe, y penaliza levemente el rendimiento.
Todo esto, solamente viene a argumentar, porque las aplicaciones gestionadas, son y serán siempre algo más lentas que las no gestionadas.
Pero, como tu mismo indicas, en efecto esta es la tendencia de futuro por la que apuesta Microsoft, y de la que todos chuparemos.
Aquí unos argumentos a favor:
1) A medida que el hardware se hace más potente, y las memorias y discos más grandes, que algo vaya un poco más lento, no es apreciable.
2) El desarrollo de software es cada vez más caro, porque el proceso es largo. Añadiendo facilidad de programación, y control de errores por el propio lenguaje, el proceso se abarata.
3) El rendimiento es importante, pero en la mayoría de aplicaciones, el cuello de botella, no está en el propio lenguaje, sino en otros recursos: bases de datos, conexión a internet, …
Estos 3 argumentos, y más que podríamos sacar, seguramente nos ayudarán a entender, porque mucho código del nuevo Longhorn es código gestionado con C#. En cambio, el nucleo, y la mayoría de controladores, serán código no gestionado C/C++.
Hola
He probado varios entornos de desarrollo, estuve como dos años picandole al Visual C++ pero descubri el C++ Builder y la diferencia fue impresionante en rapidez de dearrollo, variedad de componentes, sistemas de depuracion, creacion de reportes link con bases de datos, quede pasmado con el dinamismo de C++ Builder, tal vez visual c++ sea un mejor compilador pero eso es obvio ya que microsoft es el unico que posee los codigos con lo que se genero el windows, no es por habilidad de los programadores, o el otro compilador al que se refieren el de Intel c++ otro compilador, es obvio que intel conoce a sus propios procesadores asi que hacer un compilador para ellos sera facil, conocen su construccion, pero intel no hace entornos de desarrollo para negocios con su compilador, asi que se queda solo para aplicaciones muy especificas, me quedo con C++Builder y lo corono como el unico entorno de desarrollo RAD de C++ , las otras opciones se quedan muy pobres comparados con el, ademas Borland es famoso por sus compiladores y sus herramientas de trabajo, dicen que microsoft ya es dueño de una parte de Borland asi que tal vez en un futuro visual C++ deje de existir y microsoft apoye a borland en la programacion, sobre la NET no la he manejado y dificilmente la reconozco, problema que ya se ha mencionado, nadie sabe lo que es con exactitud, creo que es la respuesta de microsoft a JAVA SUN