Ver la versión completa : [Programación] C vs C++
Hola a todos.
Desde que comencé a conocer SDL he estado haciendo un montón de pruebas y programitas de ejemplo en C. Tengo ganas de empezar algo un poco más serio, de más nivel, y mi duda es sobre qué lenguaje de programación utilizar. Dudo si debo hacerlo en C o C++. C me gusta mucho y sé que en cuestión de rendimiento va a ir de lujo, pero creo que en C++ me sería más cómodo hacer las cosas con la orientación a objetos, aunque no conozco C++ y tendría que aprenderlo casi desde 0.
Entonces teniendo en cuento que lo que pretendo hacer es un videojuego mis preguntas son:
¿Hay mucha diferencia de rendimiento entre C y C++?
¿Es mucho más fácil programar en C++ que en C?
Saludos.
1. La diferencia de rendimiento se acerca a cero. Pero siendo quisquillosos, aunque no se note la diferencia, en teoría C rinde más, pero eso exige que el programa esté muy bien hecho.
2. Probablemente sea al contrario. Yo llevo muchos años programando en C y en C++. Mientras que en C tengo la sensación de conocerlo suficientemente, C++ en tan inmenso que muchas veces me frustra el no estar seguro de si habría una forma más óptima de hacer algo que como lo estoy haciendo en este momento.
Si tengo que programar en uno de los dos, normalmente suelo usar C. Si quiero programar con orientación a objetos, hay alternativas que me gustan más que C++. D es un lenguaje genial, aunque no existan entornos tan cómodos como Visual C++ para trabajar con él. Java también es bastante elegante, y compilando con GCJ te genera .exes nativos más rápidos y que no requieren de la máquina virtual de Java.
Ñuño Martínez
15/09/2008, 15:33
Yo también programo C y C++, y coincido con Jedive en que hay alternativas que suelen gustar más que C++ en eso de los objetos. No he probado D, pero suelo programar Object Pascal (Compiladores más utilizados son Delphi, FreePascal (con o sin Lazarus), Oxygen...) y me gusta mucho más que C++. Eso sí, cualquier parecido con C es (casi) pura coincidencia. Si te va más el estilo C prueba con Objective-C, el cual se diferencia mucho de C++ al utilizar un modelo de objetos al estilo Small-Talk, y aunque apenas lo he utilizado para poco más que un "Hola mundo" también me gusta más que C++. Para que te hagas una idea, el entorno gráfico de MacOS X está escrito en Objective-C.
creo que entre C y C++ esta claro, si por narices tu sistema es de cajon que es orientado a objetos pues obviamente habra que usar C++ pero para todo lo demas programa en C ;)
Aiken
Pues yo te recomiendo C++, porque siempre estás a tiempo de usar C en C++, pero no al reves.
Bien usado el C++ es equivalente en velocidad al C, y mal usado es simplemente un poco mas lento.
Pasar de C a C++ está chupao siempre y cuando entiendas...
a) que, en C++, las estructuras ademas pueden contener funciones. y a esto lo llaman objetos.
b) que una clase y una estructura en C++ es lo mismo, si bien la estructura por defecto tiene sus componentes publicos y la clase los tiene privados.
c) que cada objeto tiene una funcion que se llama automaticamente al crear un objeto (constructor) y otra al eliminarlo (destructor). y que estas funciones se pueden personalizar a tu gusto.
d) que el polimorfismo y la herencia son maneras de ahorrarte escribir mucho codigo parecido, y que se aprenden en un pispas a pesar de sus nombres.
e) que tienes que seguir usando los punteros clásicos *, que siguen siendo igual de monos que antes, y de hecho yo recomendaria usarlos en vez de los nuevos &, que son incluso mas lentos (pues se pasa una copia del objeto y no una referencia a él).
f) que no tienes que andar con templates hasta que lleves unos cuantos meses con C++, y casi que diria lo mismo del STL.
Muchas gracias a todos.
Mi idea de utilizar C++ en vez de C es que yo programo en Java, y creo que el código en Java lo tendría más ordenado que en C y me sería más comodo trabajar con objetos. Nunca he tocado C++ pero supongo que será más parecido a Java que C.
... Mientras que en C tengo la sensación de conocerlo suficientemente, C++ en tan inmenso que muchas veces me frustra el no estar seguro de si habría una forma más óptima de hacer algo que como lo estoy haciendo en este momento.
Esto es una cosa que me echa un poco para atrás, tengo entendido que C++ es un lenguaje bastante vasto.
Teniendo en cuenta vuestras respuestas, de momento va ganando C
e) que tienes que seguir usando los punteros clásicos *, que siguen siendo igual de monos que antes, y de hecho yo recomendaria usarlos en vez de los nuevos &, que son incluso mas lentos (pues se pasa una copia del objeto y no una referencia a él).Esto es falso. Un objeto recibido con cualificador "&" se pasa por referencia, lo cual quiere decir que el objeto recibido en el método de destino es un alias del original, o una variable que referencia al mismo objeto que fue enviado.
Así que, aunque a nivel téorico una referencia no es un puntero, digamos que en la práctica lo que recibe el método es un puntero a un objeto, aunque no necesitas saberlo ya que se maneja como si fuera el objeto original y no un puntero al mismo.
josepzin
15/09/2008, 20:38
Que interesante, yo siempre quise aprender C y nunca uve claro cuales eran las diferencias entre uno u otro.
Esto es falso. Un objeto recibido con cualificador "&" se pasa por referencia, lo cual quiere decir que el objeto recibido en el método de destino es un alias del original, o una variable que referencia al mismo objeto que fue enviado.
Así que, aunque a nivel téorico una referencia no es un puntero, digamos que en la práctica lo que recibe el método es un puntero a un objeto, aunque no necesitas saberlo ya que se maneja como si fuera el objeto original y no un puntero al mismo.
Quise decir 'se pasa *el* objeto y no una referencia *de* él' pero me he liado al reescribir la linea, q alteré el orden de la frase. Gracias por la aclaración de todas formas.
Siguiendo el tema pedagógico del asunto y adelantándome a lo q pudiera venir acabo de hacer un test y resulta que por referencia corre un pelín mas q por valor. Qué extraño. Juraría que hace unos años hice el mismo test y por referencia iba bastante más lento.
Que alguien me corrija si me equivoco. Es normal que vaya más rápido por referencia que por valor ya que no necesita crear una copia de la variable/objeto. Seguramente si el test de hace unos años lo hicites pasando enteros no había diferencia, pero si lo haces con estructuras y objetos complejos el rendimiento por valor posiblemente será menor.
hola a todos ,tengo una duda que es posible sea una burrada (no me comais ) bueno la cosa esqeu me gustaria hacer un emulador de cybiko para gp2x o un emulador de gameboy para cybiko (no se si la cybiko da para tanto ) pero la cosa esque mis conocimientos en programacion son nulos y uso xp (no se si eso da igual) ¿es posible que alguien sin conocimientos sea capaz de hacer una de esas dos cosas?(leyendo previamente algun manual)o va a ser que lo que digo es una (pulmonia) XD . gracias de antemano por la respuesta
Pues yo te recomiendo C++, porque siempre estás a tiempo de usar C en C++, pero no al reves.
Bien usado el C++ es equivalente en velocidad al C, y mal usado es simplemente un poco mas lento.
Pasar de C a C++ está chupao siempre y cuando entiendas...
a) que, en C++, las estructuras ademas pueden contener funciones. y a esto lo llaman objetos.
b) que una clase y una estructura en C++ es lo mismo, si bien la estructura por defecto tiene sus componentes publicos y la clase los tiene privados.
c) que cada objeto tiene una funcion que se llama automaticamente al crear un objeto (constructor) y otra al eliminarlo (destructor). y que estas funciones se pueden personalizar a tu gusto.
d) que el polimorfismo y la herencia son maneras de ahorrarte escribir mucho codigo parecido, y que se aprenden en un pispas a pesar de sus nombres.
e) que tienes que seguir usando los punteros clásicos *, que siguen siendo igual de monos que antes, y de hecho yo recomendaria usarlos en vez de los nuevos &, que son incluso mas lentos (pues se pasa una copia del objeto y no una referencia a él).
f) que no tienes que andar con templates hasta que lleves unos cuantos meses con C++, y casi que diria lo mismo del STL.
Pues leyendo esto, no parece tan feo el ogro como lo pintan. De hecho yo he empezado a programar en C++, pero lo que he hecho podría haber estado en C perfectamente, lo básico: bucles, funciones, listas enlazadas... De hecho nos hacían implementar "clases", entre comillas porque eran simples funciones que manejaban la lista, y no existía conceptos de zonas publicas o privadas :D
Con todo y con eso, la conversación está interesante.
Respecto a hacer un emulador, primero a ver si eres capaz de programar, porque conozco literalmente cientos de personas que sólo lo básico se les atraganta (la asignatura de programación de mi facultad es de las más temidas). Luego tienes que conocer el hardware a emular, así como el juego de instrucciones de la CPU a emular, y eso es solo el principio... y hasta aqui lo que he leido.
unm vale , lo dejamos como algo muy avanzado xd ,de todas maneras y aun sin tener idea me llama mucho la atencion la programacion asi que quien sabe a lo mejor un dia vemos algo que programe yo por aqui ,de nuevo muchas gracias por responder y saludos ;)
Que alguien me corrija si me equivoco. Es normal que vaya más rápido por referencia que por valor ya que no necesita crear una copia de la variable/objeto.Exactamente, es como tu dices.
Y en relación a otro mensaje más arriba, la verdad que Objective-C tiene cosas bastante chulas, sí. Yo las pegas que veo a programar en Objective-C fuera de OS X son las siguientes:
1) Cuando usas Objective-C en Mac OS X o iPhone, la sensación de estar usando un lenguaje tan elegante no viene tanto del Obj-C en sí como de las APIs de Cocoa, que son una maravilla de la ingeniería. Incluso, el compilador del Obj-C de Mac tiene algunos añadidos que se agradecen, como las properties. En otra plataforma, hay que tener en cuenta que no tienes recolección de basura, ni todas esas clases chulas de Cocoa.
2) Cuando se diseñó C++, se hizo como una extensión natural de C, añadiendo orientación a objetos a un lenguaje que ya tenía una sintaxis concreta. Así, si conceptualmente diseñaron las clases como una extensión de las estructuras de C, el acceso a los métodos se hacía de la misma manera que el acceso a los campos de una estructura, y con la sintaxis de una llamada a función para los parámetros, quedando en general un léxico coherente. En Objective-C, en cambio, se trató de coger un compilador de C y hacer que "se tragase" programas que tenías las características de orientación a objetos de Smalltalk, un lenguaje orientado a objetos bastante antiguo. No se molestaron en adaptar la sintaxis, si no que cosas se escriben al estilo C, y la parte relativa a objetos, con estilo Smalltalk (y si ves un programa en Obj-C, las llamadas a métodos son MUY DIFERENTES a C++ o Java). Si realmente te interesa usar Objective-C y quieres saber más sobre la implementación de estas clases, entonces puedo expicarlo más detenidamente, pero es un poco largo y si no lo vas a usar me ahorro tiempo xD.
Yo ahora estoy haciendo pruebas con Java, usando el compilador GCJ que viene como parte de GCC (un compilador que, entre otros lenguajes, soporta también C, C++ y Objective-C, y con el que se han compilado cosas como Linux, FreeBSD, o Mac OS X). Lo bueno de este compilador es que, además de la compilación "estándar" de Java (generar ficheros .class que se pueden ejecutar sobre la máquina virtual) puede compilar código nativo, es decir, que te genera un .exe normal y corriente como el que puede hacer C++, sin necesidad de máquina virtual para ejecutarlo. Además de esto, se puede mezclar en un mismo proyecto código de C++y código Java, con lo que se permite importar librerías de C++ para usarlas en Java.
No sé por qué este compilador no es más utilizado, porque verdaderamente parece una maravilla (aún no he hecho mucho con él).
Por curiosidad Jedive, ¿sabes si hay diferencia en el rendimiento entre los ejecutables generados a partir de código C++ y los generados con Java con el GCJ?
Puck2099
16/09/2008, 13:08
Por curiosidad Jedive, ¿sabes si hay diferencia en el rendimiento entre los ejecutables generados a partir de código C++ y los generados con Java con el GCJ?
Los de C++ corren del orden de 1,5 a 2 veces más rápidos que los de Java.
Pues vaya, pensé que al prescindir de la máquina virtual rendiría mucho más. Pero lo cierto es que tampoco obtiene un gran beneficio a parte de no necesitar la JVM.
Exactamente, es como tu dices.
Y en relación a otro mensaje más arriba, la verdad que Objective-C tiene cosas bastante chulas, sí. Yo las pegas que veo a programar en Objective-C fuera de OS X son las siguientes:
1) Cuando usas Objective-C en Mac OS X o iPhone, la sensación de estar usando un lenguaje tan elegante no viene tanto del Obj-C en sí como de las APIs de Cocoa, que son una maravilla de la ingeniería. Incluso, el compilador del Obj-C de Mac tiene algunos añadidos que se agradecen, como las properties. En otra plataforma, hay que tener en cuenta que no tienes recolección de basura, ni todas esas clases chulas de Cocoa.
2) Cuando se diseñó C++, se hizo como una extensión natural de C, añadiendo orientación a objetos a un lenguaje que ya tenía una sintaxis concreta. Así, si conceptualmente diseñaron las clases como una extensión de las estructuras de C, el acceso a los métodos se hacía de la misma manera que el acceso a los campos de una estructura, y con la sintaxis de una llamada a función para los parámetros, quedando en general un léxico coherente. En Objective-C, en cambio, se trató de coger un compilador de C y hacer que "se tragase" programas que tenías las características de orientación a objetos de Smalltalk, un lenguaje orientado a objetos bastante antiguo. No se molestaron en adaptar la sintaxis, si no que cosas se escriben al estilo C, y la parte relativa a objetos, con estilo Smalltalk (y si ves un programa en Obj-C, las llamadas a métodos son MUY DIFERENTES a C++ o Java). Si realmente te interesa usar Objective-C y quieres saber más sobre la implementación de estas clases, entonces puedo expicarlo más detenidamente, pero es un poco largo y si no lo vas a usar me ahorro tiempo xD.
Yo ahora estoy haciendo pruebas con Java, usando el compilador GCJ que viene como parte de GCC (un compilador que, entre otros lenguajes, soporta también C, C++ y Objective-C, y con el que se han compilado cosas como Linux, FreeBSD, o Mac OS X). Lo bueno de este compilador es que, además de la compilación "estándar" de Java (generar ficheros .class que se pueden ejecutar sobre la máquina virtual) puede compilar código nativo, es decir, que te genera un .exe normal y corriente como el que puede hacer C++, sin necesidad de máquina virtual para ejecutarlo. Además de esto, se puede mezclar en un mismo proyecto código de C++y código Java, con lo que se permite importar librerías de C++ para usarlas en Java.
No sé por qué este compilador no es más utilizado, porque verdaderamente parece una maravilla (aún no he hecho mucho con él).
Pues a mi me suena poco amigable respecto a Java o Python.
Puck, ¿estás hablando de los programas Java estándar que corren sobre la máquina virtual, o de los compilados a código máquina nativo con GCJ? Porque si son más lentos, puede deberse al recolector de basura (el cual compensa la pérdida de velocidad aumentando considerablemente la productividad), o bien a que la implementación de GNU Classpath que se usa en GCJ sea más lenta que la implementación de las STL de C++. Vamos, que el manejor de listas y demás sea menos eficiente.
Es que el código generado en sí del programa se supone que es el mismo que el de la clase C++ equivalente, de hecho a nivel de código objeto son intercambiables.
Puck2099
16/09/2008, 19:49
Puck, ¿estás hablando de los programas Java estándar que corren sobre la máquina virtual, o de los compilados a código máquina nativo con GCJ? Porque si son más lentos, puede deberse al recolector de basura (el cual compensa la pérdida de velocidad aumentando considerablemente la productividad), o bien a que la implementación de GNU Classpath que se usa en GCJ sea más lenta que la implementación de las STL de C++. Vamos, que el manejor de listas y demás sea menos eficiente.
Es que el código generado en sí del programa se supone que es el mismo que el de la clase C++ equivalente, de hecho a nivel de código objeto son intercambiables.
No lo sé, eso lo leí en un libro de Java de la Facultad de hace unos cuantos años (cuando yo estudiaba allí). Se refería a compilado con GCJ, pero también era de Java 1.2, así que igual las cosas han cambiado...
Eso sí, yo no quiero el recolector de basura ni loco, no sea que salte en un momento crítico... ¿se puede evitar explícitamente con regiones críticas o similares?
El recolector de basura tiene un "heap", y salta cuando éste se llena. La única manera de evitar la recolección sería haciendo System.gc() antes de entrar en una sección crítica.
Creo que también se puede definir el tamaño del heap.
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions Inc. All rights reserved.