Hola
Estoy empezando con esto de la programacion para iPhone y me gustaría saber si se pueden programar cosas decentes usando solamente c++, usando el minimo posible de objetive-c (me parece horrible)
Un saludo.
Si, afortunadamente puedes. Pero que sea decente o no, depende de ti.
Si, puedes usar openGL para el tema de gráficos junto con C/C++
Y resulta conveniente hacerlo en C++? cuales serían los beneficios? digo, por ejemplo puede traer ventajas en cuanto a la velocidad o algo por el estilo? o es solo por no meterse con objecive c?
Que objetive C es solo usado en el ambiente Mac ... que es, te tenes que especificar, cuando lo que aprendas de C++ te va a servir para otras plataformas. (Igual se puede usar Objective C con algunas otras plataformas a traves de Gcc)
He estado leyendo 5 minutos respecto a la diferencia en performance que se puede lograr en el iphone, pero aun parece no haber mucho sobre el tema... o no encuentro mucho. Claro que por el momento estamos hablando entonces de portabilidad.. (lo que no es poco) segun me comentas pogacha
No es por portabilidad, es por especialización, es aprender a usar otra herramienta que para tales fines tiene ciertas ventajas pero dejando de lado el seguir perfecionandote con C++ que es mas universal.
No soy muy conocedor del tema pero por lo que se por comentarios de otra gente es que Objective C es mas productivo para tales plataformas.
En el tiempo que llevo trabajando con iPhone, he usado tanto C++ como Objective, ambos a saco, y mi sensación es que el código C++ es más eficiente. aunque no he hecho pruebas específicas para poder asegurarlo al 100%.
Por otro lado, no me gusta el hecho que en Objective, debido al Smalltalk, muchos errores en tiempo de compilación se trasladan a tiempo de ejecución. Por ejemplo, al enviar un mensaje a un objeto con parámetros mal tipados o un mensaje que simplemente el objeto no puede procesar, el error se produce al ejecutar el programa. Pienso que estas situaciones deberían provocar un error de compilación y no durante la ejecución. Es como si en un programa en C++ llamarás un método de un objeto que no existe o le pasaras parámetros mal tipados y en vez de dar un error al compilar, compilara correctamente pero fallara en su ejecución.
sync
Creo que esto se debe a que las clases puede ser extendidas en forma dinámica, aunque mucho no me meti en ese tema. De cualquier manera, si me parece bastante molesto, aunque si no me equivoco te advierte sobre la situación, pero a veces se me pasa :(.
esta info está directamente sacada de la página de apple, por las dudas que alguien no la conozca
How do I enable Objective-C++ compilation?
There are multiple ways to enable Objective-C++ functionality in your application. The preferred method is to change your file extension to .mm instead of .cpp. This will alert Xcode to set the correct runtime target for your project at build time.
If you want to retain your .cpp file extension, you can also manually set your Xcode project's OTHER_CFLAGS build setting to -x objectiveC++ or set the Compile Sources As build setting to Objective-C++.
Finally, you can change it on a file-by-file basis; select the file from Xcode's Groups & Files list, select File > Get Info, and change the File Type to "sourcecode.cpp.objcpp".
Cita de: synchrnzr en 15 de Agosto de 2009, 07:48:46 AM
En el tiempo que llevo trabajando con iPhone, he usado tanto C++ como Objective, ambos a saco, y mi sensación es que el código C++ es más eficiente. aunque no he hecho pruebas específicas para poder asegurarlo al 100%.
Por otro lado, no me gusta el hecho que en Objective, debido al Smalltalk, muchos errores en tiempo de compilación se trasladan a tiempo de ejecución. Por ejemplo, al enviar un mensaje a un objeto con parámetros mal tipados o un mensaje que simplemente el objeto no puede procesar, el error se produce al ejecutar el programa. Pienso que estas situaciones deberían provocar un error de compilación y no durante la ejecución. Es como si en un programa en C++ llamarás un método de un objeto que no existe o le pasaras parámetros mal tipados y en vez de dar un error al compilar, compilara correctamente pero fallara en su ejecución.
sync
ObjC deja para el tiempo de ejecucion ciertas decisiones. La mayoria de los problemas que provocan usar estas porquerias de mierda asquerosas y putrefactas de lenguajes de programación son el control de memoria, los buffer overrun y overflow. Utilizar ObjC le asegura a apple que la gente no hará que su device pete cada 2 x 3. Pero es que nadie quiere la porqueria del ObjC, que yo sepa todo el mundo lo odia. Es cierto?
Cita de: Prompt en 17 de Agosto de 2009, 04:19:50 PM
ObjC deja para el tiempo de ejecucion ciertas decisiones. La mayoria de los problemas que provocan usar estas porquerias de mierda asquerosas y putrefactas de lenguajes de programación son el control de memoria, los buffer overrun y overflow. Utilizar ObjC le asegura a apple que la gente no hará que su device pete cada 2 x 3. Pero es que nadie quiere la porqueria del ObjC, que yo sepa todo el mundo lo odia. Es cierto?
Objective-C es un lenguaje tipado dinámicamente, como otro montón de lenguajes que hay por ahí. Y como cualquier cosa tiene sus ventajas y sus inconvenientes, pero no creo que sean "mierdas asquerosas y putrefactas", simplemente otra forma de pensar y trabajar.
Aquí va un vídeo-tutorial de Pangea Software que aclara conceptos acerca de Objective-C, Cocoa y C/C++ en iPhone. Yo pienso que si fuera una mierda de lenguaje, Apple lo habría cambiado hace años no sólo para desarrollar en iPhone sino para el desarrollo para Mac en general... Qué injusta y fea es la vida, eh?
A partir de 2:27: http://www.youtube.com/watch?v=jjdJR_-ftns
Cita de: Vicente en 17 de Agosto de 2009, 07:36:49 PM
Objective-C es un lenguaje tipado dinámicamente, como otro montón de lenguajes que hay por ahí. Y como cualquier cosa tiene sus ventajas y sus inconvenientes, pero no creo que sean "mierdas asquerosas y putrefactas", simplemente otra forma de pensar y trabajar.
Si es cierto, es una porquería enorme y apestosa :o
Aun no conozco a nadie que no lo odie. Preferiría 100 veces C# a ObjC. Entiendo las pretensiones de Apple por temas de "petes", pero me da la sensación de que le ha salido algo regular en lo que a juegos se refiere. La gente adora aun más C++ despues de ver ObjC :D
jjaja, lo que pasa con objetive-c es que es bastante distinto en sintaxis con respecto a otros lenguajes, pero cuando uno se acostumbra en los mismo al resto XD.
lo que si que leí si no me equivoco, es q en temas de velocidad lo más rápido en c nativo, seguido de objective-c y luego c++. Lo leí en un artículo de Objective-c en la web de iphone developers pero no me acuerdo ahora cual era :S
CitarUtilizar ObjC le asegura a apple que la gente no hará que su device pete cada 2 x 3.
Mmm, si te relees mi mensaje, vengo a decir precisamente lo contrario :P
Siempre es más chungo detectar petadas en tiempo de ejecución que en compilación. En tiempo de compilación, los errores ya te los da el compilador al compilar. Los arreglas y cuando compila, la cosa más o menos funciona. Pero los errores en tiempo de ejecución sólo se detectan con un testeo exhaustivo. Desde mi punto de vista, el trasladar errores en tiempo de compilación a tiempo de ejecución es un :shit: como un puño.
Respecto a la sintaxis... para mi gusto es feo, porque introduce más símbolos no alfanuméricos y hace su lectura menos natural. Pero bueno... que sea más o menos feo me importa un bledo, comparado con lo anterior. Además es cuestión de gustos...
CitarObjective-C es un lenguaje tipado dinámicamente, como otro montón de lenguajes que hay por ahí.
¿El tipado de Objective se considera dinámico? ¿Por qué? Lo de tener que declarar los tipos de las variables explícitamente igual que en C no me parece muy dinámico precisamente... :P
sync
Cita de: Prompt en 18 de Agosto de 2009, 10:28:53 AM
Si es cierto, es una porquería enorme y apestosa :o
Aun no conozco a nadie que no lo odie. Preferiría 100 veces C# a ObjC. Entiendo las pretensiones de Apple por temas de "petes", pero me da la sensación de que le ha salido algo regular en lo que a juegos se refiere. La gente adora aun más C++ despues de ver ObjC :D
Pues en C# 4.0 van a añadir la palabra reservada "dynamic" para permitir código con tipado dinámico :p Y la gente de Microsoft ya lleva tiempo invirtiendo bastante en el DLR (Dynamic Language Runtime) para soportar IronPython y IronRuby en .NET.
Además hay mucha gente que está encantada con Python, Ruby, Lua, Javascript,... Puede que Objective-C sea una castañufa, no lo sé, pero lenguajes con tipado dinámico populares los hay a patadas :p
Cita de: synchrnzr en 18 de Agosto de 2009, 12:28:29 PM
¿El tipado de Objective se considera dinámico? ¿Por qué? Lo de tener que declarar los tipos de las variables explícitamente igual que en C no me parece muy dinámico precisamente... :P
Yo no sé Objective C, pero la wikipedia dice esto:
Citar
Objective-C, like Smalltalk, can use dynamic typing: an object can be sent a message that is not specified in its interface. This can allow for increased flexibility — in Objective-C an object can "capture" this message, and depending on the object, can send the message off again to a different object (who can respond to the message correctly and appropriately, or likewise send the message on again). This behavior is known as message forwarding or delegation (see below). Alternatively, an error handler can be used instead, in case the message cannot be forwarded. If the object does not forward the message, handle the error, or respond to it, the message is silently discarded; this is true even if messages are sent to nil (the null object pointer).
Static typing information may also optionally be added to variables. This information is then checked at compile time. In the following three statements, increasingly specific type information is provided. The statements are equivalent at runtime, but the additional information allows the compiler to warn the programmer if the passed argument does not match the type specified.
Un saludo!
Vicente
Acepto barco porque es verdad que el tipado de las variables pasadas a los mensajes de Smalltalk es dinámico u opcionalmente estático. Pero para todo lo demás es estrictamente estático, igual que el C++, no opcional como pone en esta descripción. Almenos por defecto, ignoro si habrá directivas u opciones del compilador para modificar ese comportamiento.
sync
Cita de: synchrnzr en 18 de Agosto de 2009, 12:28:29 PM
Mmm, si te relees mi mensaje, vengo a decir precisamente lo contrario :P
Si, lo se. Yo me refiero a 2 problemas comunes en tiempos de ejecución por lo que existe C# por ejemplo. Windows tiene un problema que los programadores, programan mal y rápido porque hay mucho jefe inutil o gente que no entiende bien la industria, bien no entremos ahí. En C# y otros el buffer overflow y overrun no ocurre, porque se dejan ciertas decisiones / comprobaciones etc... para el tiempo de ejecución que hace que al menos no pete o no se pueda inyectar código "malicioso".
Ejemplo:
char string[10]
sprintf(string, "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa");
En C/C++ al compilar esto dirá poco y petará mucho despues. Ya se sabe, si existe un array de char tu código es vulnerable. Existen funciones para que en tiempo de ejecución la cosa no sea tan grave, "sprintf_s(string, 10, "aaaaaaaaaaaaaaaaaaa")" por ejemplo.
Estos problemas de inyección de código no ocurren en C# y otros lenguajes similares. Para mi, la naturaleza de estos lenguajes es erronea ya que parten de una premisa básica. El programador es tonto o no hay remedio nos frien a programas chungos y no podemos arreglar el SO.
edito: y mira que amaba a las primeras versiones y concepto de C# pero el tiempo me quitó la razón.
Yo le he dado bastante al C# y he acabado odiandolo versión trás versión. Y todos los lenguajes similares en concepto no los quiero ni ver. Flames no, pero Java en multitud de sitios y sobre todo en "esta nuestra industria" está dejando de tener sentido de existencia. Por razones obvias para mi desde hace mucho. (Y mira que a mi me gusta el eclipse)
Cita de: Prompt en 20 de Agosto de 2009, 07:39:05 AM
Si, lo se. Yo me refiero a 2 problemas comunes en tiempos de ejecución por lo que existe C# por ejemplo. Windows tiene un problema que los programadores, programan mal y rápido porque hay mucho jefe inutil o gente que no entiende bien la industria, bien no entremos ahí.
La media de programadores malos de Windows es la misma que la de programadores de microcontroladores, de páginas web o de SQL. A ver con que datos puedes defender semejante afirmación.
Cita de: Prompt en 20 de Agosto de 2009, 07:39:05 AM
Estos problemas de inyección de código no ocurren en C# y otros lenguajes similares. Para mi, la naturaleza de estos lenguajes es erronea ya que parten de una premisa básica. El programador es tonto o no hay remedio nos frien a programas chungos y no podemos arreglar el SO.
C# no tiene GC u otras características porque los programadores sean tontos, las tienen porque hacen el lenguaje productivo (igual que tu defiendes el tipado estático, es lo mismo). Por esa misma razón añadieron en C# 3.0 un montón de características de los lenguajes funcionales, y eso normalmente no es fácil de entender para los programadores acostumbrados a C y similares (entender el concepto de Func<T>, funciones lambda o árboles de expresión no es tan trivial). Ya tienes un ejemplo de característica productiva que no está orientada a programadores "tontos".
Si te lees el blog de Eric Lippert (uno de los jefes de como evoluciona el lenguaje), verás que siempre añaden funcionalidades que den valor y productividad al lenguaje, independientemente de si son más fáciles o difíciles de entender (obviamente, si tienes algo que da mucho valor y fácil, pues seguramente se implementará primero).
Cita de: Prompt en 20 de Agosto de 2009, 07:39:05 AM
edito: y mira que amaba a las primeras versiones y concepto de C# pero el tiempo me quitó la razón.
Yo le he dado bastante al C# y he acabado odiandolo versión trás versión. Y todos los lenguajes similares en concepto no los quiero ni ver. Flames no, pero Java en multitud de sitios y sobre todo en "esta nuestra industria" está dejando de tener sentido de existencia. Por razones obvias para mi desde hace mucho. (Y mira que a mi me gusta el eclipse)
Otra afirmación debatible. Si no te gustan pues no los uses, pero para tu desgracia cada vez se van a usar más y con razón: nadie normalmente quiere hacer en 10 horas lo que se puede hacer en 5 con otras herramientas.
Edit 2: para reducir el flame.
Cita de: Prompt en 17 de Agosto de 2009, 04:19:50 PM
La mayoria de los problemas que provocan usar estas porquerias de mierda asquerosas y putrefactas de lenguajes de programación son el control de memoria, los buffer overrun y overflow. Utilizar ObjC le asegura a apple que la gente no hará que su device pete cada 2 x 3. Pero es que nadie quiere la porqueria del ObjC, que yo sepa todo el mundo lo odia. Es cierto?
No, todo lo que dices en el párrafo citado es rotundamente falso. No tienes ni idea de lo que hablas.
Cita de: Prompt en 20 de Agosto de 2009, 07:39:05 AM
Si, lo se. Yo me refiero a 2 problemas comunes en tiempos de ejecución por lo que existe C# por ejemplo. Windows tiene un problema que los programadores, programan mal y rápido porque hay mucho jefe inutil o gente que no entiende bien la industria, bien no entremos ahí.
...
Son muchas barbaridades juntas: eres el perfecto ejemplo de 'language zealot'. La contestación de Vicente es ejemplar, y correctísima.
Lenguajes modernos y mejor diseñados que C++, como C# o Python, tienen características en absoluto triviales de dominar. Bien harías en informarte antes de decir barbaridades como que su premisa básica es que "el programador es tonto". Porque lo único que haces es dar a entender que
tú eres el tonto aquí.
Uffff, como está el patio
CitarPorque lo único que haces es dar a entender que tú eres el tonto aquí.
Dejemos que se enfríe un poco la cosa antes de acabar en una guerra de descalificaciones personales sin sentido ¿ok? ;)
sync
Cita de: Vicente en 20 de Agosto de 2009, 11:37:46 AM
Cita de: Prompt en 20 de Agosto de 2009, 07:39:05 AM
Si, lo se. Yo me refiero a 2 problemas comunes en tiempos de ejecución por lo que existe C# por ejemplo. Windows tiene un problema que los programadores, programan mal y rápido porque hay mucho jefe inutil o gente que no entiende bien la industria, bien no entremos ahí.
La media de programadores malos de Windows es la misma que la de programadores de microcontroladores, de páginas web o de SQL. A ver con que datos puedes defender semejante afirmación.
Te respondo con una pregunta. Como puedes argumentar lo contrario mejor que yo? C# o Java reducen cierto tipo de errores y aumentan la productividad en contra de cierto rendimiento de la aplicación.
Cita de: Prompt en 20 de Agosto de 2009, 07:39:05 AM
Estos problemas de inyección de código no ocurren en C# y otros lenguajes similares. Para mi, la naturaleza de estos lenguajes es erronea ya que parten de una premisa básica. El programador es tonto o no hay remedio nos frien a programas chungos y no podemos arreglar el SO.
Citar
C# no tiene GC u otras características porque los programadores sean tontos, las tienen porque hacen el lenguaje productivo (igual que tu defiendes el tipado estático, es lo mismo). Por esa misma razón añadieron en C# 3.0 un montón de características de los lenguajes funcionales, y eso normalmente no es fácil de entender para los programadores acostumbrados a C y similares (entender el concepto de Func<T>, funciones lambda o árboles de expresión no es tan trivial). Ya tienes un ejemplo de característica productiva que no está orientada a programadores "tontos".
Sobre que el GC y demás existe para hacerlo más productivo, estoy totalmente de acuerdo contigo. Incluso en C++ existe el "__gc" pero hay otros lenguajes que aportan más ventajas productivas. Según para que cosa queramos desarrollar.
Func<T>, esto no existe en C++? Yo creo que te confundes. Yo no digo que los programadores de C# sean tontos, eso es algo que no casa con la realidad. Digo que C# existe por la existencia de una problematica global y una manera de funcionar, que hacen que existan programas que tienen problemas de malfuncionamiento. C# minimiza ciertos problemas críticos como la inyección de código. Buffer overrun, buffer overflow y hace que el código a parte de productivo sea seguro. Tambien existe un modo NoSafe para programar en C#.
En C# 1.0 y 1.1 a mi el lenguage me ecantaba, tengo ahí mi libro de justo cuando salió, tengo apps, he trabajado con el profesionalmente y tengo que decir que C# 2.0 no me gustó nada. C# 3.0 tiene cosas muy buenas. Entre ellas las que comentas, nada triviales ni para tontos. Recuerdo que hace poco en Java preocupados por el rendimiento general del lenguaje añadieron también templates. Hacer en tiempo de compilación cosas para no perder luego el tiempo. En el departamento de moviles me comentarón que era un 20-30% más rápido el código usando templates. Cosa que existe desde hace siglos en C++ y parece ser que el camino de C#, Java etc... no es el camino contrario a C++.
Cita de: Prompt en 20 de Agosto de 2009, 07:39:05 AM
edito: y mira que amaba a las primeras versiones y concepto de C# pero el tiempo me quitó la razón.
Yo le he dado bastante al C# y he acabado odiandolo versión trás versión. Y todos los lenguajes similares en concepto no los quiero ni ver. Flames no, pero Java en multitud de sitios y sobre todo en "esta nuestra industria" está dejando de tener sentido de existencia. Por razones obvias para mi desde hace mucho. (Y mira que a mi me gusta el eclipse)
Citar
Otra afirmación debatible. Si no te gustan pues no los uses, pero para tu desgracia cada vez se van a usar más y con razón: nadie normalmente quiere hacer en 10 horas lo que se puede hacer en 5 con otras herramientas.
Ya no lo uso activamente, de hecho comprobé yo mismo como de rápido era hacer una tool mezclada con un visor de render en C# y probé a usar algo que no fuera MFC. Qt y wxWidgets. Y para mi, extrañamente me atrapó Qt y me maravilló.
Dices que nadie quiere hacer algo en 10 horas si lo haces en 5. Claro, depende, no creo que haya tanta diferencia si hablamos de C++ y C# no obstante, si tu objetivo es el rendimiento entre otras cosas la gente no usa lenguajes como Java o C#. Hablando del contexto de videojuegos, existe XNA que es una gran idea pero eso tiene el mercado que tiene. Igual que C/C++ tiene el suyo. Y cada uno usará lo mejor para el y más productivo según los objetivos que se tengan.
Cita de: Prompt en 24 de Agosto de 2009, 12:46:31 PM
Recuerdo que hace poco en Java preocupados por el rendimiento general del lenguaje añadieron también templates. Hacer en tiempo de compilación cosas para no perder luego el tiempo. En el departamento de moviles me comentarón que era un 20-30% más rápido el código usando templates. Cosa que existe desde hace siglos en C++ y parece ser que el camino de C#, Java etc... no es el camino contrario a C++.
Solo puntualizar que si con esto te refieres a utilizar "generics" en j2me, no se puede ya que están disponibles a partir de 5.0 y al igual que el foreach la maquina virtual de j2me peta. Excepto que en la nueva kvm hayan hecho algo nuevo.
y decir también q los generics de java son un poco de palo ^_^, son más bien por comodidad que por rendimiento.
Cita de: flipper83 en 24 de Agosto de 2009, 01:11:11 PM
Solo puntualizar que si con esto te refieres a utilizar "generics" en j2me, no se puede ya que están disponibles a partir de 5.0 y al igual que el foreach la maquina virtual de j2me peta. Excepto que en la nueva kvm hayan hecho algo nuevo.
y decir también q los generics de java son un poco de palo ^_^, son más bien por comodidad que por rendimiento.
:) hehehe, no lo sé es lo que me comentaron. A mi me parece igualmente interesante usar Java o C# para ciertas cosas y sea de palo o no, entiendo que hacer cosas en tiempo de compilación aumenta el rendimiento. Ya no se si mucho o poco.
No obstante, yo probé Qt 4.2 hasta ahora la 4.5.2 (es muy buena y tiene correcciones de rendimiento) y a mi me va muy bien y me parece un framework muy productivo. A mi me viene genial para temas de GUI. Aunque Qt tiene de todo, red, sonido...
Cita de: Prompt en 20 de Agosto de 2009, 07:39:05 AM
Func<T>, esto no existe en C++? Yo creo que te confundes.
No existe: en C++ no hay delegados ni genéricos. Tenéis punteros a funciones y templates que son parecidos, pero no son lo mismo.
Cita de: Prompt en 20 de Agosto de 2009, 07:39:05 AM
Yo no digo que los programadores de C# sean tontos, eso es algo que no casa con la realidad. Digo que C# existe por la existencia de una problematica global y una manera de funcionar, que hacen que existan programas que tienen problemas de malfuncionamiento. C# minimiza ciertos problemas críticos como la inyección de código. Buffer overrun, buffer overflow y hace que el código a parte de productivo sea seguro. Tambien existe un modo NoSafe para programar en C#.
Pero es que si buscas porque MS creó .NET, no lo creo por eso, lo creó porque quería una nueva plataforma de desarrollo de aplicaciones empresariales moderna (que el VB6 ya estaba viejuno, además de querer comerse a Java), ya que hacer aplicaciones cada vez era más complicado, cada vez eran más grandes y lo último que quería un programador es pegarse con un memory leak cuando hay mil cosas más interesantes que hacer en temas de arquitectura o diseño (problemas interesantes de verdad).
MS quería proporcionar una plataforma unificada de desarrollo en Windows que soportara ventanitas, web, acceso a datos, xml,... En vez de tener 1000 librerías de diferentes equipos de producto cada cual con sus propias idiosincrasias. Si miras el desarrollo de Windows antes de .NET era un cacao de APIs. Pero no hicieron .NET porque la gente se ponía a petar Windows con buffer overflows y cosas así.
Cita de: Prompt en 20 de Agosto de 2009, 07:39:05 AM
En C# 1.0 y 1.1 a mi el lenguage me ecantaba, tengo ahí mi libro de justo cuando salió, tengo apps, he trabajado con el profesionalmente y tengo que decir que C# 2.0 no me gustó nada.
Esto me sorprende, ¿porqué no te gustó nada? En C# 2.0 así a grandes rasgos añadieron:
- Generics y constraints: MiClase<T> where T : new y similares (ya solo por esto 2.0 merece la pena).
- Nullable types: int?, float?, ... Pensados para interactuar con una BBDD ya que en una BBDD es posible que un int valga NULL.
- Palabra reservada yield: para implementar iteradores de forma más sencilla (y corrutinas y cosas así, se te puede ir la pinza mucho con esto).
- Delegados anónimos: para no tener que declarar tipos nuevos cada dos por tres, aunque la sintaxis es un poco fea.
Y luego ya sin contar que (por lo menos para mi) el VS2005 es bastante mejor que el VS2003.
Cita de: Prompt en 20 de Agosto de 2009, 07:39:05 AM
C# 3.0 tiene cosas muy buenas. Entre ellas las que comentas, nada triviales ni para tontos. Recuerdo que hace poco en Java preocupados por el rendimiento general del lenguaje añadieron también templates. Hacer en tiempo de compilación cosas para no perder luego el tiempo. En el departamento de moviles me comentarón que era un 20-30% más rápido el código usando templates. Cosa que existe desde hace siglos en C++ y parece ser que el camino de C#, Java etc... no es el camino contrario a C++.
Ves, pero es que las cosas no son así. En Java no añadieron generics (que no templates) por rendimiento, porque se implementan usando "type erasure". Mira en la Wikipedia (en Sun tienes bastantes papers si quieres más información):
Citar
Generics are checked at compile-time for type correctness. The generic type information is then removed via a process called type erasure. For example, List<Integer> will be converted to the raw type (non-generic type) List, which can contain arbitrary objects. However, due to the compile-time check, the resulting code is guaranteed to be type correct, as long as the code generated no unchecked compiler warnings.
Los generics se implementaron porque tener un ArrayList donde la posición 0 es un perro, la 1 una pera y la 2 un int es una locura (básicamente el mismo problema del que tú te quejabas con los tipos dinámicos). Y luego ya sin entrar que genéricos y templates no son lo mismo. Si quieres comparar templates con una característica de .NET, en mi opinión se parece mucho más a T4.
Cita de: Prompt en 20 de Agosto de 2009, 07:39:05 AM
Ya no lo uso activamente, de hecho comprobé yo mismo como de rápido era hacer una tool mezclada con un visor de render en C# y probé a usar algo que no fuera MFC. Qt y wxWidgets. Y para mi, extrañamente me atrapó Qt y me maravilló.
Qt está muy bien sip.
Cita de: Prompt en 20 de Agosto de 2009, 07:39:05 AM
Dices que nadie quiere hacer algo en 10 horas si lo haces en 5. Claro, depende, no creo que haya tanta diferencia si hablamos de C++ y C# no obstante, si tu objetivo es el rendimiento entre otras cosas la gente no usa lenguajes como Java o C#. Hablando del contexto de videojuegos, existe XNA que es una gran idea pero eso tiene el mercado que tiene. Igual que C/C++ tiene el suyo. Y cada uno usará lo mejor para el y más productivo según los objetivos que se tengan.
Claro que si quieres un motor que exprima el último frame de las máquinas no vas a usar C# seguramente, pero no todos los juegos tienen esa necesidad. Puede que a C# le quede mucho para ser el lenguaje de los videojuegos, o puede que nunca lo consiga, pero donde sí que destaca por encima de C++ es en la creación herramientas. Y cada vez va a ir a más.
Cita de: Vicente en 24 de Agosto de 2009, 05:04:26 PM
Claro que si quieres un motor que exprima el último frame de las máquinas no vas a usar C# seguramente, pero no todos los juegos tienen esa necesidad.
Que C# no sea el día de mañana un lenguaje para videojuegos está por ver. Si hacen de una vez CPUs muy potentes cada vez se notará menos que tiene menor rendimiento.
Cita de: Vicente
Puede que a C# le quede mucho para ser el lenguaje de los videojuegos, o puede que nunca lo consiga, pero donde sí que destaca por encima de C++ es en la creación herramientas. Y cada vez va a ir a más.
Esta es la comparación de OpenGL vs DirectX. C++ es un lenguage y C# un lenguaje + framework. Ciertamente dentro del standard de C++ han actualizado muchas cosas últimamente, pero nunca más allá de lo que es el lenguaje en si. Con lo cual si comparamos C++ y C# para hacer herramientas, no hay comparación que sirva. Si acaso C++ y Qt vs C#.
El problema de que C++ "sea de todos" es que aunque exista un "comité" para standarizar cosas nunca abrá unos intereses de evolucionar el lenguaje y hacer un framework standard.
Por eso hasta hace poco, me gustaba bastante la idea del lenguaje D. Es como un C++ limpio y evolucionado. Pero no deja de ser un lenguaje y no un framework pagado por una empresa para que evolucione como debe.
En cualquier caso, otra cosa que me gustó es que hace tiempo decidieron liberar las especificaciones de C# y así el proyecto Mono podrá evolucionar a mejor ritmo. Una de las cosas que no me gustan es usar tecnología que me prive de libertad. Como por ejemplo compilar en algún cacharro un programita en C para hacer cosas de robótica. GCC es muy extendido y allá donde esté mi código compilará. Esperemos que Mono siga ese ritmo y que C# evolucione. En definitiva los programadores queremos crear cosas no ser unos radicales de un lenguaje en concreto.
Cita de: Prompt en 24 de Agosto de 2009, 05:23:10 PM
En definitiva los programadores queremos crear cosas no ser unos radicales de un lenguaje en concreto.
La frase mas coherente que he leido en stratos XD
Cita de: Vicente en 17 de Agosto de 2009, 07:36:49 PM
Cita de: Prompt en 17 de Agosto de 2009, 04:19:50 PM
ObjC deja para el tiempo de ejecucion ciertas decisiones. La mayoria de los problemas que provocan usar estas porquerias de mierda asquerosas y putrefactas de lenguajes de programación son el control de memoria, los buffer overrun y overflow. Utilizar ObjC le asegura a apple que la gente no hará que su device pete cada 2 x 3. Pero es que nadie quiere la porqueria del ObjC, que yo sepa todo el mundo lo odia. Es cierto?
Objective-C es un lenguaje tipado dinámicamente, como otro montón de lenguajes que hay por ahí. Y como cualquier cosa tiene sus ventajas y sus inconvenientes, pero no creo que sean "mierdas asquerosas y putrefactas", simplemente otra forma de pensar y trabajar.
:D como me he reido con esto.
Cuanta razón tienes vicente.
La diferencia en eficiencia entre C++ y C# a estas alturas dista bastante de ser relevante (en codigos "decentes" para cada uno) es como entre ensamblador y C++, ya nos preocupamos por ello (en el 99.9% de los casos). Es mejor dedicar el tiempo extra que te dan estos lenguajes a optimizar ese 10% de codigo critico (ya sabeis la regla heuristica de que el 90% del tiempo se ejecuta un 10% del codigo), a decidir una buena arquitectura y a un mejor testeo.
Ademas intentar optimizar el codigo al extremo lleva a empeorar bastante su legibilidad (aunque me gusta bastante optimizar TTxTT).
Y con programadores "mancos" ambos se pueden volver igual de ineficientes, lo que pasa es que sabemos distinguir mucho mejor que codigos son aceptables en el lenguaje que usamos abitualmente, mientras que de otros lenguajes que no dominamos nos tragamos mas basura.
Es curioso que este tipo de post siempre acaben en una batalla C++ contra el resto del mundo, cuando todos sabemos que todos los lenguages tienen sus mas y sus menos.
Yo no he visto ningun problema de rendimiento usando objc frente a usar c++, la unica ventaja del iphone es que al dejarte usar c++ puedes seguir ampliando tus conocimientos y ganar experiencia, mientras que el objc si no te quedas en la plataforma mac, te sirve de bien poco en el mundo laboral
La que ha liado Angel con una simple pregunta de iPhone XDDD
Cita de: Lord Destiny en 25 de Agosto de 2009, 11:27:19 AM
La diferencia en eficiencia entre C++ y C# a estas alturas dista bastante de ser relevante (en codigos "decentes" para cada uno) es como entre ensamblador y C++, ya nos preocupamos por ello (en el 99.9% de los casos). Es mejor dedicar el tiempo extra que te dan estos lenguajes a optimizar ese 10% de codigo critico (ya sabeis la regla heuristica de que el 90% del tiempo se ejecuta un 10% del codigo), a decidir una buena arquitectura y a un mejor testeo.
Ademas intentar optimizar el codigo al extremo lleva a empeorar bastante su legibilidad (aunque me gusta bastante optimizar TTxTT).
Y con programadores "mancos" ambos se pueden volver igual de ineficientes, lo que pasa es que sabemos distinguir mucho mejor que codigos son aceptables en el lenguaje que usamos abitualmente, mientras que de otros lenguajes que no dominamos nos tragamos mas basura.
Recuerdo un paper de Epic Games, donde dicen que no han usado para UE 3 nada de ensamblador, no se si será cierto pero me lo creo. Invertir el tiempo en cosas más útiles:
- Lo demás
- Programar para el compilador
Qué es esto último? pues algo que leí en el libro Code Complete hace ya un tiempo. Hacer un código legible, pero no solo por que sea mantenible y extensible, sino hacer un código legible para el compilador:
for XXX
{
int valor = game.getStatus( )
...
}
Si valor nunca cambia:
for XXX
{
const int valor = game.getStatus( )
...
}
// Y obviamente:
const int valor = game.getStatus( )
for XXX
{
...
}
Y así con infinidad de cosas:
vector<Cosa*> vMiTest;
vMiTest.push_back( new Cosa( parametro) );
vMiTest.back()->queBurrada( 1 );
vMiTest.back()->queBurradaInmensa( 2 );
vMiTest.back()->queBurradaInnecesaria( 3 );
Yo soy un creyente de programar para humanos y para el compilador. Sobre el tema de usar ensamblador es por ejemplo muy optimo para multiplicar matrices, si. Pero y si usas un "truquito" y lo haces en GPU :)?
float mBone01[16] = { ... }
float mBone02[16] = { ... }
float mResult[16];
glMatrixMode( GL_MODELVIEW );
glLoadIdentity( );
glLoadMatrix( mBone01 );
glMultMatrix( mBone02 );
glGetMatrix( GL_MODELVIEW, mResult );
Quien lo hace más rápido la CPU en ASM o la GPU así! eh! :o
Está claro que no todo es optimizar de forma enfermiza, yo he pasado por eso y no se gana mucho.
Cita de: Prompt en 25 de Agosto de 2009, 12:44:56 PM
Yo soy un creyente de programar para humanos y para el compilador. Sobre el tema de usar ensamblador es por ejemplo muy optimo para multiplicar matrices, si. Pero y si usas un "truquito" y lo haces en GPU :)?
float mBone01[16] = { ... }
float mBone02[16] = { ... }
float mResult[16];
glMatrixMode( GL_MODELVIEW );
glLoadIdentity( );
glLoadMatrix( mBone01 );
glMultMatrix( mBone02 );
glGetMatrix( GL_MODELVIEW, mResult );
Quien lo hace más rápido la CPU en ASM o la GPU así! eh! :o
Está claro que no todo es optimizar de forma enfermiza, yo he pasado por eso y no se gana mucho.
Hombre, estoy de acuerdo contigo en casi todo, pero lo de la multiplicacion de matrices en la GPU no lo veo claro.
Es mas legible sin duda.
Pero no creo que se llegue a mandar ningun dato a la GPU, por lo menos en la operacion de multiplicacion, eso lo implementara el driver ejecutandolo en la CPU.
Y si fuese como dices, en todo caso la comunicacion con la GPU penalizaria mas que implementar la operacion en C++.
A mi me gusta al estilo XNA.
Matrix.Multiply(ref bone1, ref bone2, out result);
Bueno, habría que medirlo, si pasa por CPU como podría ser normal sería un chasco, pero también sería lo normal al no ser client side, quizás en un iPhone con OGL ES todo sea en GPU. En cualquier caso para animaciones etc... mejor usar un vertex shader con skinning :)
Cita de: blau en 25 de Agosto de 2009, 03:54:44 PM
A mi me gusta al estilo XNA.
Matrix.Multiply(ref bone1, ref bone2, out result);
Por suerte desde .NET 3.5 SP1 ya se puede multiplicar con "*" en vez de usar el método Multiply :)
Un saludo!
Vicente
Cita de: seryu en 25 de Agosto de 2009, 01:18:23 AM
Cita de: Vicente en 17 de Agosto de 2009, 07:36:49 PM
Cita de: Prompt en 17 de Agosto de 2009, 04:19:50 PM
ObjC deja para el tiempo de ejecucion ciertas decisiones. La mayoria de los problemas que provocan usar estas porquerias de mierda asquerosas y putrefactas de lenguajes de programación son el control de memoria, los buffer overrun y overflow. Utilizar ObjC le asegura a apple que la gente no hará que su device pete cada 2 x 3. Pero es que nadie quiere la porqueria del ObjC, que yo sepa todo el mundo lo odia. Es cierto?
Objective-C es un lenguaje tipado dinámicamente, como otro montón de lenguajes que hay por ahí. Y como cualquier cosa tiene sus ventajas y sus inconvenientes, pero no creo que sean "mierdas asquerosas y putrefactas", simplemente otra forma de pensar y trabajar.
:D como me he reido con esto.
Cuanta razón tienes vicente.
Re-leyendo esto (y ahora que ando con un libro de IronPython) he encontrado esta cita de Anders Hejlsberg (el creador de C#):
Citar
Go look at dynamic languages and meta-programming: those are really interesting concepts. Once you get an understanding of these different kinds of programming and the philosophies that underlie them, you can get a much more coherent picture of what's going on and the different styles of programming that might be more appropriate for you with what you're doing right now.
Anyone programming today should check out functional programming and meta-programming as they are very important trends going forward.