[PSP] ¿Por qué C y no C++?

yo programo en c++ y no hay tanta diferencia con c... creo que lo que pasa es que mucha gente prefiere malo conocido que bueno por conocer....

saulotmalo escribió:yo programo en c++ y no hay tanta diferencia con c... creo que lo que pasa es que mucha gente prefiere malo conocido que bueno por conocer....

Supongo que sí.

C es muchisimo más facil de aprender que C++, así que supongo que la gente prefiere tirar para C que para C++.

Un saludo.

Yo supongo q a la peña no le interesan las chorradas extra del c++, yo personalmente como muchos otros no veo ninguna utilidada al c++ para mi uso particular. Lo mismo me da tener una clase jugador y luego sus metodos jugador:mover(), jugador::disparo() que tener esas funciones separadas, idem con la herencia de demas cosas superfluas.
Tal vez si fuera a programar un juego rpg de esos 3d como los de hoy en dia, posiblemente elegiria c++ para usar las clases en la creacion de personajes, habilidades y esas cosas, pero para mis minijuegos con c voy sobrado.

Yo siempre he comparado c y c++ con los coches, c es mi seat leon con el q voy a todas partes, c++ es como un mercedes q no necesito para el dia a dia.

Eskematico escribió:Yo siempre he comparado c y c++ con los coches, c es mi seat leon con el q voy a todas partes, c++ es como un mercedes q no necesito para el dia a dia.

y para acablar de aclarar tus dudas: el LUA es como un kart: es pequeño y fácil de manejar, pero tiene inconvenientes: se queda en seguida sin gasofa (memoria) (*al menos me pasaba a mi, q sin cargar 1 mega en imágenes se petaban los programas), no es tan rápido como el seat leon o el mercedes y muy difícilmente se podra usar fuera de su circuito (osea, que en PSP y poco más)

zestt escribió:
y para acablar de aclarar tus dudas: el LUA es como un kart: es pequeño y fácil de manejar, pero tiene inconvenientes: se queda en seguida sin gasofa (memoria) (*al menos me pasaba a mi, q sin cargar 1 mega en imágenes se petaban los programas), no es tan rápido como el seat leon o el mercedes y muy difícilmente se podra usar fuera de su circuito (osea, que en PSP y poco más)

Hombre, LUA no deja de ser un lenguaje concebido como lenguaje de extension para extender otros programas como por ejemplo con World of Warcraft o Supreme commander, así que tampoco hay que pedirle un rendimiento extremo


Por otro lado si yo prefiero C++ en vez de C es por la POO que me encanta

Un saludo.

la peña que dice que la poo es una toneria... no saben lo que dicen... ahora mismo yo estoy con un programa del cual he hecho unas 50.000 líneas y un compañero 25.000 en c++. esto en c es casi inconcebible... el mareo de mirar cosas que no has hecho tu en c es una locura, pero en c++ yo tengo las clases de mi compañero con unas specs y las gasto y no me preocupo de la implementación.

Por otro lado, no os parece interesante el polimorfismo en tiempo de ejecución? en c no sé si se puede conseguir pero en c++ está tirao.

( ara el hermes me atacará por meterme con su c querido xD )

saulotmalo escribió:
( ara el hermes me atacará por meterme con su c querido xD )

No hombre ya te ataco yo, venga chulooooo eso no me lo dices en la calle ehhhh, te partire las piernas por meterte con el C

Si la aplicación no es en tiempo real o sobra potencia , C++ ayuda mucho al programador con la comprobación de tipos , operadores para la memoria dinámica , la STL, etc .... Además añade los espacios de nombre y la POO , con todo lo que conlleva.

Sin duda la mayor ventaja del C es el rendimiento.

La POO es un standard hoy en día en la industria del software y la perdida de velocidad frente a la programación estructurada con un mismo compilador es insignificante.

Los que dicen que es una tontería es porque nunca se han enfrentado a un proyecto medianamente grande o en equipo donde la gran versatilidad y la cantidad de líneas de código que te ahorra la herencia y el polimorfismo son indispensables.

Actualmente me encuentro programando un juego considerablemente grande en C++ como proyecto para segundo de carrera (calculo que unas 30.000 líneas tirando hacia abajo). Pues bien, esto hubiese sido imposible sin una clase básica "Sprite" que es la encargada de linkar con el motor (propio, también incluido en el proyecto y usando Dx9) de la que hereda absolutamente todo el resto cosas que aparezcan en el juego o sin una lista de "Enemigo"s en la que gracias al polimorfismo y las funciones virtuales se puede almacenar cualquier tipo de enemigo sea del tipo que sea y tratarlos de la misma manera para que cada cual se comporte dependiendo de su tipo.

Esto son dos ejemplos aislados de la gran cantidad de veces que se usa la POO en cualquier proyecto mas o menos grande. Ahora mismo en ninguna empresa profesional (ya sea de juegos como de aplicaciones de gestión) se utiliza la programación extructurada. Absolutamente todo se hace en POO (Bueno vale, Id no, pero es la excepción que confirma la regla).

kbks escribió:
Los que dicen que es una tontería es porque nunca se han enfrentado a un proyecto medianamente grande o en equipo donde la gran versatilidad y la cantidad de líneas de código que te ahorra la herencia y el polimorfismo son indispensables.

Efectivamente es lo q yo digo, para mis minijuegos c++ no me aporta absolutamente nada como para q me sea util. El dia q me ponga con un juego mas grande y serio no dudare en usar c++.

Eskematico escribió:

Efectivamente es lo q yo digo, para mis minijuegos c++ no me aporta absolutamente nada como para q me sea util. El dia q me ponga con un juego mas grande y serio no dudare en usar c++.

para tus minijuegos te podría ofrecer abstracción lo cual es muy importante desde mi punto de vista yo ahora mismo quiero programar un juego de minijuegos para psp y estoy intentando que se abstraiga lo más posible si puedo haré clase juego x y luego lo inicializaré con new y me lo cargaré con delete y au

¿Por qué siempre presuponéis que no es posible realizar OOP en C?
http://ldeniau.home.cern.ch/ldeniau/html/oopc/oopc.html

saulotmalo escribió:
( ara el hermes me atacará por meterme con su c querido xD )

No, no te voy a atacar por una sencilla razon: las dos vertientes tienen su razon de ser.

Si hablamos de un problema complejo, con una gran abstraccion del hardware y donde el sistema trabaja con una cola de mensajes, como ocurre con una aplicacion de Windows (por ejemplo, mi programa de creacion de sprites) resulta mas comodo, limpio y claro, trabajar con C++, sobre todo si hablamos de Visual C.

Si hablamos de una aplicacion mas sencilla y directa en su uso del hardware, probablemente sea mejor trabajar con C y tambien mas rapido.

A mi el C me gusta mas como lenguaje de programacion en consola, donde muchas veces, el uso de una clase no tendría tanto sentido porque no la vas a derivar o utilizar mas de una vez (y no me vale ese supuesto entendimiento que comentas de una clase, pues al fin y al cabo, una clase es como una libreria cualquiera de C, solo que en C las funciones estan sueltas y en C++ estarian apiñadas en una clase, para un unico uso, tanto monta, monta tanto)

Pero bueno, es cuestion de mentalidades.

Para mi el principal problema es que la mayoria de las cosas que hago en consola, me piden una variacion en el acceso al hardware que hace que rara vez pudiera suplirla con una clase, aparte de que muchas veces, las librerias de asignacion de memoria trabajan fatal y me fio mas bien poco de un programa que tenga que construir/destruir objetos.

Al final C++ se traduce en una forma de trabajar estandar en un mundo de librerias imperfectas y donde salirse de la norma es lo habitual y solo con C se puede trabajar de una forma tan caotica y conservar cierta estabilidad

Yo recomendaría trabajar de ambas formas y proceder con el lenguaje con el que nos sintamos mas comodos y obtengamos mejor resultado, para la tarea en cuestion. Lo demas, son mamonadas

Hombre, no se yo si la POO se puede resumir en "agrupar funciones en una clase"... yo creo que eso solamente se cumple con ciertas funciones y clases estáticas muy puntuales.

kbks escribió:Hombre, no se yo si la POO se puede resumir en "agrupar funciones en una clase"... yo creo que eso solamente se cumple con ciertas funciones y clases estáticas muy puntuales.

No, por supuesto que no. Pero si utilizas clases estaticas o metodos donde en la practica, la clase se comporta como si fuera una caja contenedora de funciones, te da exactamente lo mismo utilizar clases que funciones sueltas en C.

kbks escribió:Hombre, no se yo si la POO se puede resumir en "agrupar funciones en una clase"... yo creo que eso solamente se cumple con ciertas funciones y clases estáticas muy puntuales.

Claro, a eso me refiero, que el agrupar funciones solamente es una caracterísitca menor en la que se saca poca ventaja respecto al C pero que al programar usando la POO en su totalidad se gana muchísimo en todos los aspectos.

Eso si, como dices depende del hardware y de la "profundidad" a la que se encuentre nuestra aplicación, si lo que quiero es programar un PIC por supuesto que lo escribiré en C o incluso en ASM pero hablando de desarrollo para consolas o PCs actuales ni me lo plantearía, por mui sencillo que fuese el programa.

Yo estoy trabajando en un proyecto que sin contar las herramientas y utilidades necesarias para su realizacion, pasa del medio millon de lineas. Esta escrito completamente en C y ensamblador, y no tiene problema alguno. Trabajando en sistemas muy potentes la diferencia entre C y C++ es absolutamente personal, programar orientado a objetos o no. Yo despues de haber utilizado ambos durante muchos años me quedo con C, por generar codigo mas rapido y compacto, y facilitar el trabajo a bajo nivel con el hardware. Mis motivos para no utilizar C++ son sobretodo la dificultad que en mi opinion supone para trabajar en grupo. La sobrecarga de operadores hace que codigos aparentemente iguales se comporten de forma completamente inesperada, las herencias de muchos niveles hacen muy complicado enterarse de la pelicula, y en mi trabajo la memoria y cpu extra que requiere lo hacen inviable. Por tanto, me quedo con los proyectos escritos un 90% en C y un 10% en ensamblador

kbks te citas a ti mismo ¿? Trastorno bipolar ¿? es broma xD


Hombre supongo que C tendra unas ventajas y desventajas respecto a C++ y biceversa y que sera mejor para lo que tu hagas. Es como java es lentisimo pero si quieres multiplataforma es lo que hay ...


PD: Yo creo que deberias quedar para pegaros.

kYp escribió:kbks te citas a ti mismo ¿? Trastorno bipolar ¿? es broma xD

Lol, no me había dado cuenta La cosa era citar a Hermes.

kYp escribió:PD: Yo creo que deberias quedar para pegaros.

cuando y donde? xD

Buenas. Soy nuevo por estos foros. ¿Qué tal todo el mundo?

Pues yo quería dar mi opinión sobre C vs C++ y en concreto de la orientación a objetos en particular, que tanto defendéis algunos.

Si bien me parece que el estilo de C++ orientado a objetos es una mejora sobre la programación estructurada en C, la verdad es que la programación a objetos también tiene sus propios problemas.

Los principales objetivos de la programación orientada a objetos son:

1.- Ocultación de la información y acceso a través de interfaces.
2.- Reutilización de código.

A su vez ésto redunda en una mayor mantenibilidad del código, ya que si cambias la implementación, la interfaz se mantiene y no hay problemas, entre otras cosas, pero para no enrollarme,
Desde mi punto de vista, el punto 1 se cumple, pero el 2 es un auténtico fracaso.

Voy a describirlo con un breve ejemplo:

Yo tengo un toolkit en el que tengo una clas Monstruo. Mi monstruo puede atacar, puede reposar y puede chillar. A partir de ese monstruo, creo monstruo feo, monstruo muy malo y monstruo casi invencible, derivadas de monstruo.

Muy bien. Ahora, cuando quiera otro monstruo para mi toolkit de monstruos, puedo derivar de Monstruo y heredo código que puedo usar. Hasta ahí todo bien, más bonito que C.

Ahora, veo otro toolkit en otra página. Es un juego de rol online de fantasía, al que quien quiera puede hacer código para crear monstruos, personajes, o lo que sea. Mis Monstruos irían que ni pintado para el juego, pero resulta que MIS Monstruos derivan de MI clase Monstruo, y no de la clase monstruo del código del juego de rol. Por lo tanto, mis clases, como tal, ya no se pueden reutilizar, porque para ello deberían de heredar de JuegoRol::Monstruo. Fracaso de reutilización de código.

La programación orientada a objetos, mientras tienes sólo un framework, es muy bonita y cómoda, pero a la hora de empezar un nuevo proyecto, es realmente imposible coger clases viejas que tenías, y, sin tocarlas, poder reusarlas.

Pero, mira tú por dónde, existe algo mejor que la programación orientada a objetos, y que el próximo estándar de C++, C++0x, va a soportar directamente en el lenguaje. Se llaman conceptos.

Para empezar, los conceptos entran dentro del paradigma de la programación genérica, bastante más potente que la Orientada a Objetos en mi opinión. Olvidaros de tener que heredar de una u otra clase.

En un paradigma genérico, el Monstruo de vuestro toolkit tendrá una serie de requerimientos, y no tendrá que heredar de una clase en concreto. Por ejemplo, vuestro monstruo puede: atacar y dormir.

Ahora, el monstruo del Juego de Rol, suponiendo que ha sido modelado con programación genérica, puede reposar y pegar, que son cosas equivalentes a atacar y dormir en el toolkit que yo escribí. Pues bien, con programación genérica sólo tendrías que decirle al toolkit del juego de rol que tu función atacar es su función pegar y que tu función dormir es su función reposar. Se acabó. Todo ésto sin tocar una mísera línea de código de ninguno de los dos toolkits.

Obviamente ésto es un ejemplo chorra, pero para que os hagáis una idea, es lo que se hace en librerías genéricas como la STL y la BOOST hoy día, en la que si tus iteradores, o clases cumplen una serie de requisitos, puedes usar todos los algoritmos, por ejemplo. La única diferencia, es que C++0x lo soportará directamente con los conceptos.

Espero no haber aburrido mucho. Para quien quiera estar al día de lo que va a llevar el próximo estándar de C++. Llevará: conceptos, enumerados fuertemente tipados, soporte para hilos, static assert, inicialización de contenedores al estilo de los arrays de c, plantillas que varían en número de parámetros; deducción de tipos con la palabra auto, un nuevo loop for al estilo for_each de C#, aliases de plantilla, expresiones constantes generalizadas y "move semantics" con nuevas referencias a objetos temporales, entre otras cosas.

En la parte de la librería: tablas de hash (unordered_map), tuplas, números aleatorios, generalización de bind...

Para quien le interese:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2169.html

Y para quien quiera ir practicando con los nuevos conceptos del lenguaje C++ futuro, puede pasarse por aquí, ya que ya hay una implementación experimental:

http://www.generic-programming.org/software/ConceptGCC/

Es que en los juegos las arquitecturas de herencia de objetos están pasando a mejor historia. Hace unos años que se llevan utilizando arquitecturas por componentes, más complejas y mucho mejores.

webez escribió:Es que en los juegos las arquitecturas de herencia de objetos están pasando a mejor historia. Hace unos años que se llevan utilizando arquitecturas por componentes, más complejas y mucho mejores.

¿Puedes explicar/dar link sobre eso?

germandiago, esta claro que la POO no es perfecta, yo no la defiendo ante todo sino ante la programación estructurada, pon el mismo ejemplo con programación estructurada donde tienes todo lo relaccionado a cada monstruo en decenas de funciones y estructuras repartidas por el código y ya veremos como pasar un mostruo de un proyecto a otro.

Yo creo que C, en el terreno de los juegos está medio acabado, (al menos en el sector profesional, no en el scene).
Más que nada porque los juegos por lo general son bases de código muy grandes
para ser manejadas en un lenguaje con tan poco nivel de abstracción como C.

No me malinterpretéis, C es magnífico, me gusta, pero claro...
Yo creo que C sirve más para escribir programas que interactúen con el hardware. A pesar de ello, nada le impide a C++ hacer lo mismo que C.

Mi voto va por C++, definitivamente, al menos para hacer juegos. Para progamar pics, microcontraloderes y esas cosas, C y ensamblador es el estándar, aunque como digo, yo a C++ no le hago ascos para ninguna tarea, porque es tan flexible como uno quiera.

kbks escribió:A Data-Driven Game Object System

Mirate el de A Data-Driven Game Object System

http://www.drizzle.com/~scottb/gdc/

Y luego se que hay algo en el libro Game Programming Gems 6 , artículo "A Data-Driven Game Object System"

No hay excesiva información por ahi. Basicamente la idea se resume en que un enemigo en realidad es un GameObject formado por GameObjectComponents que podrían ser desde los más básicos gráfica, física hasta otros como animación, pathfinding, etc. De este modo vas formando GameObjects a base de componentes, con lo que la reusabilidad es enorme y la potencia aun más. Ésto unido con un binding a un lenguaje script para la lógica de alto nivel (comportamientos, etc) es parte de la programación moderna de videojuegos. En PC y consolas de sobremesa no se le ocurre a ni blas usar C. En portátiles todavía (en PSP dudo que haya ni un 5% que lo haga).

Curiosamente donde parece que se programara en C es en móviles j2ME que se hace una programación en java que casi parece estructurada.

La eterna lucha entre C y C++.
En consolas cada bit es un tesoro, y por tanto, hay que optimizar en memoria. Hay que ser muy deficiente funcional para tener una Clase Polígono 3D, pudiendo tener todo en un array empaquetado.
Además el 75% de los programas tienden a declarar como public los datos, por tanto, para que tanta abstracción con métodos, si aunque se declare private, se tiende a poner el método get_dame_el_dato_privado_que_tenia_que_ser_publico?
Y para la duda de por qué a la mayoría le gusta el C++, es muy fácil, y se resume en, según he visto a lo largo de la vida:
- No tengo ni remota idea de quien ha hecho este programa, pero como veo una clase con métodos como DibujaPunto, RellenaCirculo y VuelcaPantalla, doy por supuesto, que hace exactamente eso (abstracción), cuando en realidad a lo mejor, no hace nada de lo citado, pero cuando se lo suelto a los colegas, quedan flipando porque en 30 segundos ya se lo que hace el programa, cuando en realidad, sigo sin tener ni idea.
Y la industria profesional, usa lo que tenga que usar. Si ahora compran un motor de juego 3D que estubiera hecho en Cobol, pues todos a programar en Cobol. Pero si se ponen a implementar un motor desde 0, como que tirarían hasta de ensamblador.

ackerman escribió:La eterna lucha entre C y C++.
En consolas cada bit es un tesoro, y por tanto, hay que optimizar en memoria. Hay que ser muy deficiente funcional para tener una Clase Polígono 3D, pudiendo tener todo en un array empaquetado.
Además el 75% de los programas tienden a declarar como public los datos, por tanto, para que tanta abstracción con métodos, si aunque se declare private, se tiende a poner el método get_dame_el_dato_privado_que_tenia_que_ser_publico?
Y para la duda de por qué a la mayoría le gusta el C++, es muy fácil, y se resume en, según he visto a lo largo de la vida:
- No tengo ni remota idea de quien ha hecho este programa, pero como veo una clase con métodos como DibujaPunto, RellenaCirculo y VuelcaPantalla, doy por supuesto, que hace exactamente eso (abstracción), cuando en realidad a lo mejor, no hace nada de lo citado, pero cuando se lo suelto a los colegas, quedan flipando porque en 30 segundos ya se lo que hace el programa, cuando en realidad, sigo sin tener ni idea.
Y la industria profesional, usa lo que tenga que usar. Si ahora compran un motor de juego 3D que estubiera hecho en Cobol, pues todos a programar en Cobol. Pero si se ponen a implementar un motor desde 0, como que tirarían hasta de ensamblador.

Creo que no has captado el mensaje de la OOP, la abstracción es muy buena, es bueno tener atributos privados ya que a ti realmente no te hacen falta ver. Los metodos get y set no estan muy bien vistos en C++ jejje. Si una clase tiene esos metodos que dices, harán exactamente eso que dicen hacer, si no es asi, se ha diseñado mal la clase. Y si, es la idea, saber rápido lo que hace el programa. Prefiero tener varias clases sobre lo que me haga falta, que tener que rescribirlo y ciertamente a nadie le interesa los atributos y metodos privados. La cosa es, ¿Funciona este metodo? Si, pues perfecto, me da igual como lo hizo y que variables usó.

Un saludo.

Fox escribió:Creo que no has captado el mensaje de la OOP

Pues va a ser eso, o el riego, o que hace un día muy bueno de sol, y ya hace más de 10 años que se debate sobre estos temas, y no se aporta nada nuevo.
La OOP está muy bien en el mundo PC en el que no se tiene ni el control ni se sabe casi nada sobre su hardware o el Sistema Operativo, pero en las consolas, es distinto.
Sin embargo, como cada vez más programadores de PC se están pasando al mundo de consolas, se está creando esta nueva lucha entre técnicas de programación. El siguiente paso, será el intento de explicación de cuales son los motivos de que JAVA vaya mal en una game boy, cuando en el PC va un poco mejor.

Fox escribió:a nadie le interesa los atributos y metodos privados

Más filosofía del mundo PC. A quien le importa como funcionan las cosas o como hice el programa? Luego vienen los fallos, y las manos a la cabeza.

A si, se me olvidaba, lo más importante:
A la gente de a pie, le da igual si usaste OOP, C, ensamblador, python, etc... Sólo quieren ver el juego en tiempo real, es decir, a 50 fps, y que les tire a la primera, y si no lo hace, no vale para nada.
Y no es la primera vez que se hace un juego para una máquina superior alegando que la inferior no da la potencia suficiente, cuando en realidad es porque se programa mal. Esto me recuerda cuando intentaron portar al 100% el DOS a C++, y consumía 10 veces más de recursos que su homólogo en C.
Ya tenemos bastantes problemas en el mundo PC, para que las consolas se empiecen a parecer a él.

Por qué es el hilo especifico de psp?
Es que en psp solo se puede programar en C o que?

capitanazo escribió:Por qué es el hilo especifico de psp?
Es que en psp solo se puede programar en C o que?

Pues porque desconozco el estado de la scene de las demás consolas. Así que es exclusivo para PSP ya que es la que me interesa para programar.

Y no, se puede programar en C, C++, LUA y python (pero no sé como estará python en PSP, y eso que es mi lenguaje favorito!)

Un saludo.

Fox escribió:
Creo que no has captado el mensaje de la OOP, la abstracción es muy buena, es bueno tener atributos privados ya que a ti realmente no te hacen falta ver. Los metodos get y set no estan muy bien vistos en C++ jejje. Si una clase tiene esos metodos que dices, harán exactamente eso que dicen hacer, si no es asi, se ha diseñado mal la clase. Y si, es la idea, saber rápido lo que hace el programa. Prefiero tener varias clases sobre lo que me haga falta, que tener que rescribirlo y ciertamente a nadie le interesa los atributos y metodos privados. La cosa es, ¿Funciona este metodo? Si, pues perfecto, me da igual como lo hizo y que variables usó.

Un saludo.

Je ¿te acuerdas el problemilla que teniamos ayer con lo de llamar a plugin.exe desde mi aplicacion sprite_gen utilizando Wine?


Pues la culpa la tiene esa abstraccion tan buena que me aisla de los parametros que recibe la aplicacion y la clase que los trata, los maneja a su antojo y no entiende el simbolo '/' como separador de los directorios.

Al final, para no tener que liarla, tuve que usar un truco del almendruco para obtener la ruta del ejecutable mediante otro sistema ( a ver si subo luego la actualizacion sin que muestre la ventana esa que añadí)

Por cierto, si mi aplicacion estuviera programada en C, sería bastante mas facil de portar a Linux (gracias a las MFC, habría que reescribir todo el codigo que hace uso de esas clases, mientras que el codigo que he escrito al estilo C, podria ser portado rapidamente sustituyendo unas pocas funciones, a cualquier sistema)

Hermes escribió:
Je ¿te acuerdas el problemilla que teniamos ayer con lo de llamar a plugin.exe desde mi aplicacion sprite_gen utilizando Wine?


Pues la culpa la tiene esa abstraccion tan buena que me aisla de los parametros que recibe la aplicacion y la clase que los trata, los maneja a su antojo y no entiende el simbolo '/' como separador de los directorios.

Al final, para no tener que liarla, tuve que usar un truco del almendruco para obtener la ruta del ejecutable mediante otro sistema ( a ver si subo luego la actualizacion sin que muestre la ventana esa que añadí)

Por cierto, si mi aplicacion estuviera programada en C, sería bastante mas facil de portar a Linux (gracias a las MFC, habría que reescribir todo el codigo que hace uso de esas clases, mientras que el codigo que he escrito al estilo C, podria ser portado rapidamente sustituyendo unas pocas funciones, a cualquier sistema)

Y por qué no la interfaz separada del código, MVC y simplemente cambiar la vista?

La verdad es que de C++ aún no se casi nada (aún busco un libro para mi nivel ), pero en python eso se arreglaría fácil jeje.

Un saludo

PD: El error de sprite_gen sigue en win, pero en linux no

Fox escribió:
PD: El error de sprite_gen sigue en win, pero en linux no

No: desde Windows, funciona perfectamente (lo se porque lo tengo probado, con mi plugin.exe y ahi te visualiza bien el parametro y se queda esperando a que pulses una tecla)

C o C++, he ahi el dilema.

No voy a favor ni en contra de ninguno, simplemente son filosofias distintas. Solamente hago un comentario de todo lo leido en este foro:

Por cosas como la abstracción, que a mi modesta opinión no es mas que agregar capas de codigo sobre mas capas de código, es que hoy por hoy, para ejecutar cualquier aplicación es necesario un PC muy potente.

Hsta hace 7 años aún desarrollaba en C bajo MSDOS en un PC con procesador 8086 y 640 k de RAM y no veas la cantidad de funcionalidad que podria agragarse a una velocidad de respuesta muy pero que muy interesante.

Claro que para desarrollar un juego este ejemplo no vale pero os habeis puesto a pensar en algo: La PSP es un ordenador mas que portatil, potente con posibilidad de comunicaciíon WIFI y USB (creo que infrarojo tambien), una pantalla excelente. Que demonios de diseñar solamente juegos, pueden hacerse cosas mucho mas interesantes que en una PDA, por ejemplo.

Jejeje, lo dicho, no es mas que una opinion general acerca del tema

Joder, si C y C++ son idénticos, sólo que tienen cosas cambiadas y C++ tiene cosas añadidas...

Identicos, ya, quizas se te olvida el "puequeño detalle" de que son diferentes estilos de programación (Estructurada vs POO).

kbks escribió:Identicos, ya, quizas se te olvida el "puequeño detalle" de que son diferentes estilos de programación (Estructurada vs POO).

No tiene por qué, yo puedo programar perfectamente de manera estructurada en C++, pero no en C. Por eso, son los mismos lenguajes, pero con cosas cambiadas y añadidos en C++ (justo lo que dije en mi anterior respuesta).

Programar de manera estructurada en C++ es programar en C, no en C++, por mucho que el fichero sea un .cpp. Ademas, no creo que catalogar toda la teoría de la POO como "añadidos" sea correcto.

Yo lo diría al revés: C++ es un lenguaje POO que utiliza la sintaxis del C.

C++ es un lenguaje multiparadigma, perfectamente puedes programar estructuradamente y usar muchas caracteristicas que no tenía C ( comprobacion de tipos, operadores de memoria dinámica, referencias etc...) , además del paradigma orientado a objetos y programación genérica.