Tras la intervención que hice en otro post, he estado investigando un poco y haciendo mis propias pruebas sobre este tema.
De todas las webs que he encontrado, la que da una información más apañada para el caso es la siguiente:
http://unthought.net/c++/c_vs_c++.html
Si estais interesados, es una lectura muy buena (pero esta en inglés).
De esta página web se deducen una idea importante, referente al asunto "C vs C++ (u oop vs estructurado)".
- C++ no es un lenguaje orientado a objetos, si no que da la posibilidad de programar con objetos. Por lo tanto, C++ no fuerza la utilización de objetos, y si no se usan, el consumo asociado a estos no se suma. Asi que si búscamos eficiencia evitando el uso de características de c++, podemos programar en c++ directamente sin usarlas.
CONCLUSIONES (que me aplicaré a mi mismo en el futuro):
1 - Mandar C a tomar por saco definitivamente y usar C++...
2 - Utilizar características de C++ (oop, templates, exceptions) o no usarlas cuando los algoritmos planteados así lo requieran, considerando siempre que esten bien diseñados y analizados.
3 - Procurar siempre seguir un control intensivo sobre las interfaces que diseñamos para que puedan ser manejadas desde C o C++ (hay muchas cosas hechas ya en C y sería un error ponerse a actualizarlo todo).
Java, C#, Makers... eso es otra guerra, aquí estoy hablando de los 2 Gigantes, y de 2 métodos de diseño de algoritmos, no nos vayamos por ahi que desvariamos ...
En fin, si alguien ha leido el artículo podría dar su opinión por aquí.
Saluditos.
PDT: A mi me va el diseño, asi que si la lio no me hago responsable :P
http://gamearchitect.net/Articles/WhyC++.html
Bueno, creo que todos los que estamos en C++ es por que en realidad nos aprovechamos de eso.
Para todo lo que no requiera optimización trabajamos en el mas alto del nivel del lenguaje y para lo que lo requiera nos bajamos a C o incluso hace unos años se iba hasta ensamblador.
Saludos.
Tira de C++ o sino de C# :idea:
para usar c# usa java :)
Si solo vas a trabajar sobre windows usa C# que va bastante mejor que Java (si es solo para Solaris usa Java y si necesitas multiplataforma depende).
Cita de: "Pogacha"Bueno, creo que todos los que estamos en C++ es por que en realidad nos aprovechamos de eso.
Para todo lo que no requiera optimización trabajamos en el mas alto del nivel del lenguaje y para lo que lo requiera nos bajamos a C o incluso hace unos años se iba hasta ensamblador.
Saludos.
Hoy en día es muy importante trabajar con ensamblador para optimizar código que se ejecuta bastantes veces en cada proceso del motor de juego.
Como por ejemplo la multiplicación de matrices, etc... es realmente importante leer articulos sobre x86 o x64 sobre estas cuestiones.
Mi experiencia me dice, que trabajar con OOP y ensamblador en C++ es lo más normal en nuestra industria. Sueles usar OOP y cuando necesitas un rendimiento extremo utilizas ensamblador.
Por otra parte si miras el código fuente de quake3, ves como programan en estructurado y ensamblador y solo cuando es estrictamente necesario utilizan OOP. Esto... da un alto rendimiento como todos los que hemos jugado a los juegos de Id o usado su motor hemos podido comprobar.
Aunque puede que esto último hoy en dia sea más por ser muy friki! programar en OOP da muchas ventajas aunque pierdes rendimiento ( teorico ).
Saludos a todos :)
...
Cita de: "Vicente"si necesitas multiplataforma depende.
cierto, depende de si quieres que sea multiplataforma o no :)
Cita de: "MrK"Cita de: "Vicente"si necesitas multiplataforma depende.
cierto, depende de si quieres que sea multiplataforma o no :)
No creo que C# y TAO tengan nada que envidiar a Java + loquesea sobre Linux ;) Y como supongo que a mi no me crees, pues te vas a la página de TAO y aprendes un poco :)
http://www.taoframework.com/Home
...
Cita de: "Lex"Es que todos sabemos que Mono Project (http://www.mono-project.com/) no existe, es solo una loca fantasía de esos malditos invasores adoradores del Windows que quieren ensuciar linux XD
A ver. yo puedo, salvando problemas tecnicos, escribir un interprete de .net
para spectrum teniendo la certeza que no vendra un dia microsoft y me va a
patear el culo? que yo sepa, no. Cosa que si que puedo hacer con LUA (por
poner un ejemplo). Pues sinceramente, no me parece que eso sea multiplataforma
porque el dia que microsoft quiera cerrar el grifo, lo hara. Pero bueno, por
suerte microsoft no es una de esas empresas que se caracterizan por
hacer este tipo de cosas xDDD
a mi no me preocupan(en el caso que lo usara, claro) las implementaciones, sino
la licencia que hay detras, y que un dia pueda usar un programa que me guste
mucho y al dia siguiente para hacerlo tenga que cambiar de operativo.
Pues estas muy mal informado ;) Sí puedes implementar el estandar de .NET porque está liberado. Nada puede evitar que nadie lo coja y lo implemente. Es cierto que MS podría decidir no liberar próximas versiones (pero al menos hasta la 3.5 no va a ser el caso porque ya están en proceso). Pero lo que ya está liberado ya está liberado (aplicate este mismo cuento con SUN, que si no es por .NET no liberan Java y si que te podrían haber jodido sin problemas).
Y si aún así piensas que con lo del acuerdo de MS y Novell hay una conspiración oculta para hundir a la gente que usa mono, usa dotGNU. Mira, copio y pego:
"# DotGNU Portable.NET, an implementation of the Common Language Infrastructure (CLI), more commonly known as ".NET", includes everything that you need to compile and run C# and C applications that use the base class libraries, XML, and Systems.Windows.Forms. Currently supported CPUs: x86, ppc, arm, parisc, s390, ia64, alpha, mips, sparc. Supported operating systems: GNU/Linux (on PCs, Sparc, iPAQ, Sharp Zaurus, PlayStation 2, Xbox,...), *BSD, Cygwin/Mingw32, Mac OS X, Solaris, AIX."
"DotGNU is part of GNU and thereby protected from coming under the control of any single company."
Aunque el precio que te tocaría pagar por no fiarte es que dotGNU va bastante más retrasado que Mono...
Pues eso, buscate un argumento mejor ;) Un saludo!
Vicente
Varias cosas.
Alguien podría explicarme brevemente y para idiotas (no estoy para pensar) ¿q es Tao? Un enlace para usar OpenGL y algunas otras librerias en NET?
Vicente esta va para ti.¿Sabes donde puedo encontrar las especificacones liberadas de NET 3.5??
Mono es un poco contrasentido para el espiritu de los Linuxeros ¿no? Son todos AntiMS y van a permitir correr o programar en un invasor??
CitarAunque puede que esto último hoy en dia sea más por ser muy friki! programar en OOP da muchas ventajas aunque pierdes rendimiento ( teorico ).
Pues esto es lo que yo pensaba al principio, que el rendimiento se notaba, pero es que resulta que no ... (y debido a esto cree el post y puse el link)
De todas formas todo depende de la técnica y el algoritmo, lo que yo venía ha decir es que usar c es innecesario, puedes usar c++ sin tocar nada de oop y te va hasta mejor.
Y ya que bajas niveles para hacer operaciones más rápido, te bajas hasta ASM sin pasar por C (o como mucho usas c++ sin tocar la oop).
Y por cierto, hay que ser muy pero que muy genio para programar en ASM mejor que un compilador, que por muy práctico que lo veamos los compiladores lo hacen mejor que nosotros (salvo excepciones). Y con respecto a las operaciones con matrices y operaciones relacionadas con el mundillo de los videojuegos, la mayoría de las gráficas ya te las hacen por hardware (y ojalá el OpenGl triunfe y empiecen a desarrollar interfaces y APIs cada vez mejores, porque muchas de estas optimizaciones por hardware se quedan sin uso ... )
TAO son bindings para .NET de muchas librerias (OGL, SDL,...). Así puedes acceder a ellas desde .NET (antes tenías también CsGl, pero está muerto).
Las especificaciones de .NET 3.5 no están aún liberadas (están en proceso). Te busco el draft (son menos de 10 páginas creo). Recuerda que 3.5 son solo mejoras a nivel de sintaxis: métodos extensionales, LINQ, árboles de expresiones, expresiones lambda,...
Respecto a si Mono es un contrasentido para linux no me meto.
Un saludo!
Vicente
Que haya linuxeros que no puedan ver a Microsoft en nada de lo que hace no convierte Mono en un contrasentido. En mi opinión más contrasentido era Java, realmente, hasta que lo liberaron.
Lo que ya no sé es hasta que punto se puede programar en C# una aplicación y que sea directamente multiplataforma sin ningún tipo de cambios, y si es comparable a hacer una aplicación con Java. Y no es una acusación ni una opinión: es una pregunta.
Lo que si es importante en la comparación Java-.Net en cuestiones multiplataforma es que en el primer caso es la misma Sun la que saca la máquina virtual, mientras que para .Net hemos de esperar, por lo que siempre se va con retraso con respecto a Windows.
Hola,
Fran:
Estos links he encontrado:
http://msdn2.microsoft.com/en-us/vcsharp/aa336745.aspx
Te puedes bajar el doc llamado "C# 3.0 Language Specification" que es la nueva especificación del lenguaje (al genio del marketing que se le ocurrió sacar el framework 3.0 con el cli 2.0 habría que fusilarlo...).
Respecto a estandares tenéis más información por aquí:
http://msdn2.microsoft.com/en-us/netframework/aa569283.aspx
http://www.ecma-international.org/publications/standards/Ecma-335.htm
http://isotc.iso.org/livelink/livelink/fetch/2000/2489/Ittf_Home/PubliclyAvailableStandards.htm
Respecto a lo de estar el cli 3.0 en proceso de estandarización me colé, parece ser que aún no lo está (Wikipedia http://en.wikipedia.org/wiki/C_Sharp#C.23_3.0_new_language_features):
"C# 3.0 was unveiled at the 2005 Professional Developers Conference. A preview with specifications is available from the Visual C# site at Microsoft. It is not currently standardized by any standards organisation, though it is expected that it will eventually become an ECMA and then ISO standard, as did its predecessors."
Respecto al tema de las licencias (de la wikipedia http://en.wikipedia.org/wiki/.NET_Framework#Criticism):
"The Microsoft .NET Framework is the predominant implementation of .NET technologies. Other implementations for parts of the framework exist. Since the runtime engine is described by a ECMA/ISO specification, other implementations of it are unencumbered by copyright issues. It is more difficult to develop alternatives to the base class library (BCL), which is not described by an open standard, and may be subject to copyright restrictions. Additionally, parts of the BCL have Windows-specific functionality and behavior, so implementation on non-Windows platforms can be problematic."
El acuerdo de Novell y Microsoft se refiere a la BCL (ya que ellos están portando la BCL a Mono).
lord_taran: respecto a multiplataforma sin cambios: una aplicación de Mono en Linux correrá igual en Mono en Windows (o debería), pero de una aplicación Mono Linux a una aplicación .NET Windows lo mismo te sale alguna cosa (que no debería). De .NET Windows a Mono Linux según que uses te dará problemas (por funcionalidad que no esté aún implementada). Si tienes mucho interés me informo (porque yo lo he usado de pasada, con chorradas).
Por cierto que se me había olvidado otra opción, la "Shared Source Common Language Infrastructure", la implementación libre no comercial de la propia Microsoft del CLI para Windows, FreeBSD, y MacOS (http://en.wikipedia.org/wiki/Shared_Source_Common_Language_Infrastructure).
Un saludo!
Vicente
...
Pues si, si puedes infórmate, aunque tampoco corre prisa :P Vamos, si puedes darme una visión general... Me parece que Windows.Forms es lo que aun necesita mucho desarrollo ¿no? De todas formas ya miraré un poco más a fondo cuando tenga tiempo.
De todas formas vuelvo a decir lo mismo que antes: el problema real de .Net con respecto a java, hablando de ser multiplataforma, es que para cuando Microsoft saque el .Net 3.0 con suerte estará casi todo el 2.0 implementado en Mono, mientras que al ser Sun la que implementa todas las versiones de la máquina virtual de java pues no existe ese retraso (que yo sepa)
Cita de: "Vicente"
Pues eso, buscate un argumento mejor ;) Un saludo!
mi ordenador se muere cuando ejecuto algo en .net XDDD
bromas a parte, no confio en microsoft ni en nadie que haga lo mismo
(tal y como tampoco confiaba mucho en sun para java antes que sacaran el codigo)
para cualquier cosa que le digan multiplataforma y no den el codigo, ofrezcan un
programa con el que te "ayuden" a portar dicho interprete a cualquier maquina,
y te aseguren cierta continuidad. Por que? Pues porque puedes estar haciendoles
programas con su .NET, y un dia pueden decidir que cierran el grifo al resto
de plataformas, y entonces TU les has ayudado a expandir su lenguaje, y posteriormente
a crear una dependencia entre tus usuarios y su sistema operativo (de que me
sirve que yo haga un gestor de correo en .NET que se puede ejecutar en Mac OS,
si despues al pasar a la version 3.0 los de Mac OS no pueden usarlos, y ya tienen
una razon mas para pasarse a windows. No en mi nombre.)
Con Sun puede pasar, pero veo mas posible que microsoft use como caballo de troya
el .NET para 'absorbir' usuarios de otros sistemas operativos hacia el suyo. De todas
formas nunca he sido un amante de estos lenguajes autodenominados multiplataforma.
Excepto para cosas embedded (navegadores y cosas de estas), veo mucho mas
practico usar C/C++ estandar y portable, y usar alguna libreria estilo GTK
que tiene implementaciones libres para la mayoria de sistemas conocidos.
Si te has estado 2 anyos para hacer una aplicacion, la excusa de que "no hace
falta compilarlo 4 veces" me parece muy pobre. Es como la gente que hace un
juego chapeau y despues ponen los menus con Comic Sans MS.
Todo esto lo digo acerca del "codigo multiplataforma", si uno ya directamente
quiere hacerlo solo para windows, eso es otra cosa.
lord_taran: te lo miro y te contesto por privado.
MrK: que más da que MS no libere el CLI 3.0? El que desarrolle en Mono se ceñirá normalmente a Mono y su máquina virtual, y no a la de Microsoft (y aunque no lo hiciera, lo podría hacer si las cosas se ponen malas). Si tu haces una aplicación ahora en Mono, que más te da lo que haga MS? Tu programa seguirá funcionando y a correr.
Si te miras la especificación de Mono, igual que en ciertas cosas va por detrás de la de .NET (principalmente WinForms aunque creo que ya están bastante al día), en otras cosas han currado más que MS. Ejemplo: el draft del CLI 2.0 incluía tipos de retorno covariantes, cosa que Mono implementó pero que MS al final decidió no hacer. O en el tema de certificados, donde la librería de Mono provee más funcionalidad.
Lo liberado y estandarizado, liberado y estandarizado está. Si en el futuro MS corta el grifo, nada impedirá a Mono crecer como algo independiente en vez de portar las librerías de MS (como por ejemplo han hecho con TAO, GTK#,...). Otra cosa es argumentar si Novell tendría fuerza para hacer despegar Mono como hizo Sun con Java como plataforma individual.
Nos podemos poner a especular, pero para mi que el liberar la especificación fue simplemente para que llegara a más sitios (es algo que sabían que la gente pedía a SUN y hacerlo les daba puntos). Es igual que sacar VB.NET para no perder a la gente de VB6 (o más en general el tema de multilenguaje para que la gente trabaje sobre su plataforma). Pero vamos, esto último es opinión totalmente personal ;)
Un saludo!
Vicente
...
Yo por lo poco que he salseado con Visual C# Express, puedo decir que me alegraria sobremanera que fuese multiplataforma. Es una herramienta cojonuda :)
Cita de: "Lex"Vicente deja de perder el puto tiempo, y haz el editor, que al menos eso lleva a alguna parte.
nah, es mucho mas divertido evangelizar al personal, o hacer ver a la gente lo tonta que es por empezar a programar juegos con una cosa que no sea un pacman :)
Cita de: "Lex"Por cierto, lo estamos haciendo en C# así que tened cuidado, que podríamos estar conspirando contra todos vosotros.
por cierto, el juego sera multiplataforma? :)
Es un poco offtopic, pero ¿qué cachos de programa exactamente puede hacer un humano de forma más óptima en ensamblador que un compilador?
No sé, yo también pienso que los compiladores de hoy en día son la releche, y además alguien que sepa cómo ensamblar "guay" también tendrá nociones de cómo programar para que el compilador no ensamble mal, ¿no?
Cita de: "Mars Attacks"Es un poco offtopic, pero ¿qué cachos de programa exactamente puede hacer un humano de forma más óptima en ensamblador que un compilador?
No sé, yo también pienso que los compiladores de hoy en día son la releche, y además alguien que sepa cómo ensamblar "guay" también tendrá nociones de cómo programar para que el compilador no ensamble mal, ¿no?
Por mi experiencia personal los ultimos tiempos (ensamblador ARMs, no se como estara el tema en x86,mips o powerpc), el compilador la caga a la hora de asignar los registros para diferentes tareas y de reordenar la memoria para poder trabajar mejor. Dificilmente encontraras un compilador que te cargue/descargue un bloque de memoria con un stmfd o ldmia (unas instrucciones para guardar/cargar registros a memoria y viceversa, una especie de ?pushad? selectivo) ni que tengas 4 instrucciones consecutivas que le digan que carguen los registros con esas mismas posiciones consecutivas.
La gran ventaja que tienes haciendo ensamblador, es que sabes lo que quieres hacer, y puedes reordenar los datos de tal forma que despues los puedas cargar mas rapidamente, o decidir cuales quieres retener cuando te faltan registros y cuales guardas en memoria. Un compilador hace muy buen trabajo, pero no deja de ser un "programa tonto" que hace su faena .
Por poner un ejemplo, una vez tuve que escribir un texture mapper para ARM y la funcion en C optimizada me tardaba un 60% aproximadamente mas que la misma funcion en ASM, una vez todo traducido y reordenando los datos para que fuera mas rapido. Despues intente aplicar esas optimizaciones al C y no hubo forma.
Un 60% mas en una rutina que se ejecuta 3 veces por frame y gasta un 0.01% de cpu es una chorrada hacerla en asm, pero una rutina que se tira el 90% del tiempo ahi,es la diferencia entre ir a 15 fps e ir a 25 fps.
Gracias para la aclaración. Mi cerebro lo ha traducido como "magia oscura de programadores de verdad, que no puedes alcanzar a comprender". Yo aún sigo siendo más tonto que los compiladores XD