Code::Blocks, 32 y 64 bits, estándares

Cuestiones en general sobre tecnología e informática que no tengan cabida en el resto de foros.
Avatar de Usuario
robcfg
Amiga 2500
Amiga 2500
Mensajes: 2077
Registrado: 07 May 2009, 15:34
Sistema Favorito: Amstrad CPC
primer_sistema: Atari 800XL/600XL
Ubicación: Estocolmo
Gracias dadas: 506 veces
Gracias recibidas: 123 veces

Re: Code::Blocks, 32 y 64 bits, estándares

Mensajepor robcfg » 31 May 2020, 14:23

Para mi el concepto de Java es bueno, pero la implementación del mismo es un horror.

Yo para mis cosas con interfaz gráfica uso la librería FLTK (fltk.org), que funciona de perlas en todas las plataformas y se enlaza estáticamente.

Avatar de Usuario
zup
Amiga 2500
Amiga 2500
Mensajes: 2838
Registrado: 04 Sep 2009, 20:07
Sistema Favorito: Spectrum 16Kb/48Kb
primer_sistema: Spectrum 16Kb/48Kb
consola_favorita: Nintendo DS/3DS
Primera consola: Nintendo GameBoy
Ubicación: Navarra
Gracias dadas: 52 veces
Gracias recibidas: 233 veces
Contactar:

Re: Code::Blocks, 32 y 64 bits, estándares

Mensajepor zup » 31 May 2020, 18:51

Buuuf, aquí hay demasiado a lo que responder...

Empecemos por el principio: mi situación. Ahora mismo (parón de pandemia de por medio) soy técnico de reparaciones; lo de la programación es una afición. En mi pasado aprendí unos cuantos lenguajes de programación, pero no es algo a lo que me dedique todos los días.

Como técnico, entiendo la necesidad de tener la herramienta adecuada y saber manejarla. Por poner un ejemplo, en mi maletín hay una serie de herramientas habituales y alguna más exótica. La mayoría de la gente que quisiera poner un muelle en su sitio cogería mis alicates, muy pocos cogerían el más eficiente (cuando sabes utilizarlo) gancho para muelles, nadie usaría un destornillador para hacerlo. La elección de herramientas se basa en lo que sabes utilizar y la idoneidad para el trabajo a realizar.

En mi caso, si miráis los programas que he hecho, veréis que se pueden hacer con (prácticamente) cualquier lenguaje. De todo lo que un día supe, hubiera podido usar igualmente BASIC, Pascal o C. Descarto COBOL (lo aprendí, y es absolutamente inadecuado para mis pretensiones) y ensamblador (porque solo aprendí del Z80 y 8086... y ahora mismo Windows no ejecuta código de 16 bits). Otras opciones implicarían aprender otros lenguajes y, dado que no preveo cambiar de carrera profesional en breve, repasar qué lenguaje es más popular no ayuda mucho.

En mi lista de deseos estaba la compatibilidad a nivel de código fuente con Linux y Windows. En este caso, C cumple todos los propósitos. Si hubiera necesitado compatibilidad a nivel de código objeto, sí que hubiera tenido interés Java (aunque lo odio) o intentar usar C#.

¿Por qué odio Java? Porque a nivel de usuario es una castaña. Las intenciones del lenguaje son buenas, pero tiene unas características poco deseables:
- Requiere una runtime externa. Y además una runtime bastante gorda. Y lo peor de todo, es que acabas necesitando más de una.
- Al ser interpretado, o la runtime es hipereficiente (afortunadamente hay alguna de esas) o hay una cierta pérdida de rendimiento.
- Nadie parece seguir un manual de buenas prácticas, lo que implica que haya programas (estoy acusando directamente a la administración pública, aunque no son los únicos) que requiere tener determinadas runtimes instaladas (p.ej.: 1.4.x) además de la más reciente.
- Ha acabado en un monopolio de Oracle. Es decir, que prácticamente todo el mundo usa la runtime de Oracle y eso implica que Oracle no tiene que estar innovando, corrigiendo errores de seguridad o vigilando el rendimiento de la máquina virtual.

No digo que Java sea malo de por sí (hay proyectos muy majos corriendo en Java, como JDownloader o "el maincra"), pero resulta revelador que cada proyecto que veo en Java vaya acompañado de su runtime favorita (por ejemplo, en mi carpeta de Steam hay 4 runtimes de Java instaladas) en vez de usar la que está en el sistema.

Volviendo al tema de los 32 y 64 bits y la compatibilidad multiplataforma. Mi intención es distribuir solo binarios para Windows, pero que los usuarios de Linux puedan generarse sus propios binarios sin problemas. Mis problemas no han sido tanto hacer código que compile en esta situación, sino mis tropiezos con mi entorno de desarrollo. La duda en cuanto a los bits viene dada de esa incertidumbre (el futuro está en los 64 bits pero... ¿cómo están de enraizados los 32 bits en el presente?).

C y C++... personalmente no opino que usar C++ como un "Super C" sea un error, sino una opción. En mis programas no veo la necesidad de usar objetos; como se ha dicho puedo dejar a un lado esas herramientas. Otra cosa es que haya un proyecto que se beneficie enormemente de usar objetos (por ejemplo, un videojuego) y se empeñe en usar programación tradicional. Aunque todo depende de la planificación... tengo la intuición de que tanto Java como C++ requieren dedicar bastante tiempo a diseñar diagramas con los objetos y sus relaciones antes de empezar a hacer nada. Creo que si ese trabajo no está bien hecho vas a disfrutar tanto de C++ como de programar el videojuego entero en ensamblador (ya se ha mencionado lo divertido que es tener un proyecto en C++ programado al buen tun tun).

En cuanto a lo de enlazar el código con MSVCRT... ya he mencionado por qué no me parece del todo malo (compatibilidad directa sin instalar más runtimes). Entiendo la postura de que se queda obsoleta y que sea insuficiente para determinadas cosas... supongo que será un problema si algún día llego a ese extremo (también supongo que en algún momento MinGW-w64 empezará a enlazar contra runtimes más modernas). En ese contexto, ¿a qué te refieres con MinGW RT? He mirado mis ejecutables y solo dependen de MSVCRT.DLL y KERNEL32.DLL... ¿es una librería que hay que incluir en la cabecera? (NOTA: No he visto que ninguno de mis programas haya petado sin que haya sido por una cagada mía).

(Curiosidad: En teoría, mingw-w64 debería soportar enlazar contra UCRT pero le falta el fichero libucrt.a... no he encontrado este fichero en ninguna parte salvo en los paquetes que ofrece Debian para compilación cruzada mediante mingw.)
I have traveled across the universe and through the years to find Her. Sometimes going all the way is just a start.
Además vendo cosas!

Avatar de Usuario
explorer
MSX Turbo R
MSX Turbo R
Mensajes: 307
Registrado: 11 May 2014, 17:10
Sistema Favorito: Atari ST
primer_sistema: Atari 800XL/600XL
consola_favorita: Atari 2600
Primera consola: Atari 2600
Ubicación: Valladolid, España
Gracias recibidas: 75 veces
Contactar:

Re: Code::Blocks, 32 y 64 bits, estándares

Mensajepor explorer » 31 May 2020, 20:17

[mensaje retirado]
Última edición por explorer el 01 Jun 2020, 02:16, editado 1 vez en total.

Avatar de Usuario
dondiego
Atari 1040 STf
Atari 1040 STf
Mensajes: 843
Registrado: 30 May 2013, 22:05
Sistema Favorito: PC
primer_sistema: Spectrum 16Kb/48Kb
consola_favorita: Sony PlayStation 2
Primera consola: Atari 2600
Ubicación: Granada
Gracias dadas: 9 veces
Gracias recibidas: 50 veces

Re: Code::Blocks, 32 y 64 bits, estándares

Mensajepor dondiego » 31 May 2020, 20:47

No veo problema en hacer esas herramientas en C, una ventaja de usar TDM-GCC es que las librerias de MinGW están enlazadas estáticamente en el ejecutable. Si usas MinGW-w64 tendrias que hacerlo o incluir todas las librerias porque de lo contrario en otro ordenador no te funcionaria si no tienes instalado el entorno. Eso del RT es el runtime chungo de MinGW. Yo creo que no lo llegué a hacer, hay que modificar el script del CMake. Se me habia olvidado comentar esto.
Pero vamos ya ves que el doom compila con el 5.1 asi que para unas herramientas sencillas te sobra o prueba el nuevo 9.2 de 32 bits si quieres que sea más compatible porque 64 bits no te van a hacer falta para lo que quieres hacer.
Pero "es java todavia una cosa"? Is Java still a thing? :)

ZX-81
Commodore 128
Commodore 128
Mensajes: 125
Registrado: 04 Ene 2013, 16:43
Sistema Favorito: Spectrum +2
primer_sistema: ZX81
consola_favorita: Nintendo DS/3DS
Primera consola: Sega Genesis/Megadrive
Ubicación: La orilla del mar Mediterráneo
Gracias dadas: 16 veces
Gracias recibidas: 28 veces
Contactar:

Re: Code::Blocks, 32 y 64 bits, estándares

Mensajepor ZX-81 » 31 May 2020, 22:14

Para bien o para mal, si hay algo que después de 25 años sigue sin ser entendido, es Java. El nivel de desconocimiento a veces roza el absurdo, y la cosa se mueve más por los derroteros de los simples prejuicios que por los hechos. No intentaré desmentir cada falsedad sobre Java, porque con cada demostración de, sin acritud, ignorancia supina, alguien se empeñará en demostrar que la ignorancia no tiene límites.

Es falso que haya falta tener instalado más de un JRE o JDK. De hecho, y a diferencia de putoNET donde sí tiene casi todo el mundo instaladas librerías para aburrir, cualquier programa se ejecuta sin modificaciones en todos los JRE mayores que el que lo compiló. Harto estoy de hacer eso. Otra cosa es que se distribuyan programas con la maldita costumbre de poner un JRE en lugar de ponerlo como requisitos previos. Pero eso no es responsabilidad del lenguaje.

Mala opción sería escoger C# que, en definición de M$ es "abierto porque se ejecuta en todos los Windows". Ridículo.

Lo de que Java es ineficiente es haberse quedado en... 1996. Desde Java 1.2 tiene JIT, y probablemente algunos de los avances más importantes en áreas como los JIT y el Garbage Collector vienen de la mano de Java. Sin entrar en demasiados detalles, decir que una JVM actual tiene, al menos, 4 niveles de compilador JIT distintos, desde el más rápido y menos eficiente, al más costoso y que genera código exactamente para la CPU en la que en ese momento se está ejecutando el programa, cosa imposible de hacer para un compilador estático. Muchísimo peor es Python en cuanto a rendimiento y ahí está la gente, más feliz que una perdiz con un lenguaje que parece el COBOL del sXXI.

Oracle tiene su JVM, pero se desarrolla a a partir del OpenJDK, que sí es totalmente libre. Nadie te obliga a pasar por el aro de Oracle (que a mi tampoco me gusta).

La discusión banal acerca de la "verbosidad" de un lenguaje siempre se me antoja absurda. En cualquier caso, antes que Perl, escogería AWK, donde va a parar.

Cada cosa tiene su uso. Exactamente los mismos programas sin recompilar, los ejecuto en Solaris 10 x86/Sparc, Linux 32/64, varias versiones de Windows, MacOS-X y hasta en una ocasión he tenido que ejecutar un programa concreto en una Raspberry PI-2, sin tocar ni una línea de código y funcionando perfectamente en 24x7, haciendo tareas serias. Obviamente, hay para cosas que no usaría Java, ni Python, ni Perl, ni JodeScript que tan de moda está últimamente, y no será porque no sea una catástrofe de lenguaje. Pero si lo que quiero es portabilidad máxima, la única opción ahora mismo es Java.

Para hacerte lo que necesitabas, habría que ver si no bastaría con unos pocos scripts de shell y las herramientas estándar de Unix. Pero como en Windows tienes lo que tienes, pues a jorobarte.

Si tampoco te dedicas a programar profesionalmente, apegarte a C para tus cosillas lo veo correcto, salvo que te metas en berenjenales de portabilidad. Hay muchas maneras de hacer las cosas, incluso de usar ficheros de más de 4GB en un sistema de 32 bits, pero las cosas se complican un poco si solo lo haces en plan aficionado, para utilidades de andar por casa. Conseguir la portabilidad entre sistemas y arquitecturas no es trivial y te aseguro que, por desgracia, sé bien de lo que hablo.

Por otro lado, confundes crear un par de clases o tres para una cosa de andar por casa con una aplicación con centenares de clases y relaciones complejas. Para algo sencillo, no hacen falta dos docenas de diagramas UML (que es un horror en sí mismo, proclamo). Lo complicado es empezar a pensar de otra forma y eso le cuesta a todo el mundo, especialmente si viene de la programación procedural. Mi humilde opinión es que, para usar C++ como C, usa C y san se acabó.

Pero oye, cada cual que use lo que más le guste y con lo que se sienta más feliz. Y las burlas, producto de la ignorancia más ignominiosa, mejor las dejamos para los simples, que se conforman con cualquier memez.
Todo espacio de dimensión finita distinta de cero con producto interno tiene una base ortonormal. Tiene sentido, cuando no piensas sobre ello.
Profesor de Matemáticas U.C. Berkeley

Empieza a jugar sin tener que compilar: JSpeccy
Emulador bare-metal para la Raspberry PI 2/3: ZXBaremulator

Avatar de Usuario
zup
Amiga 2500
Amiga 2500
Mensajes: 2838
Registrado: 04 Sep 2009, 20:07
Sistema Favorito: Spectrum 16Kb/48Kb
primer_sistema: Spectrum 16Kb/48Kb
consola_favorita: Nintendo DS/3DS
Primera consola: Nintendo GameBoy
Ubicación: Navarra
Gracias dadas: 52 veces
Gracias recibidas: 233 veces
Contactar:

Re: Code::Blocks, 32 y 64 bits, estándares

Mensajepor zup » 01 Jun 2020, 09:46

ZX-81 escribió:Es falso que haya falta tener instalado más de un JRE o JDK.

Mi experiencia es justo la contraria. Para configurar un router de fibra Brocade, se accede a su dirección IP y después de eso toma el control una aplicación Java. Un día se me ocurrió desinstalar todos los Java salvo el más reciente... y al siguiente cliente que quise acceder al Brocade, daba error.

(Menos mal que tenía discos de instalación de aplicaciones con runtimes anteriores)

¿Culpa de Java? ¿Malas prácticas de programación? ¿Habría otro workaround para hacerlo funcionar? Vete a saber, pero la solución más rápida en ese momento era instalar otra runtime de Java.

ZX-81 escribió:Otra cosa es que se distribuyan programas con la maldita costumbre de poner un JRE en lugar de ponerlo como requisitos previos.

De nuevo, puede que sean malas prácticas de programación. A diferencia de los videojuegos antiguos (donde el instalador comprueba que DirectX esté instalado, o pregunta si quieres instalar el que viene en el disco), parece que nadie se molesta en preguntar si quieres Java y te lo mete a martillazos.

O bien resulta que lo de que el bytecode se ejecute en cualquier JRE no es tan cierto, o les resulta más fácil incluir su propia runtime que hacer un programa ejecutable en cualquier JRE.

ZX-81 escribió:Mala opción sería escoger C# que, en definición de M$ es "abierto porque se ejecuta en todos los Windows". Ridículo.

La teoría es que el bytecode también es ejecutable en cualquier máquina. La práctica es que el SDK está tan ligado a los SO Windows que es prácticamente imposible tener una runtime en otro sistema operativo que funcione al 100% (está libmono, pero la clave está en "al 100%").

ZX-81 escribió:Para hacerte lo que necesitabas, habría que ver si no bastaría con unos pocos scripts de shell y las herramientas estándar de Unix. Pero como en Windows tienes lo que tienes, pues a jorobarte.

Pues sí. Antes de hartarme y escribir esos programas, cortaba ficheros a base de dd (y así lo tengo puesto en el código fuente de algunos programas). Si he escrito esas utilidades es porque me estaba hartando de tener que reiniciar a Debian o de pasar por SFTP los ficheros a mi Raspberry Pi y hacerlo ahí (tengo una Raspberry Pi a 24x7, muchas veces la utilizo para probar cosas de Linux sin tener que reiniciar mi PC).

ZX-81 escribió:Por otro lado, confundes crear un par de clases o tres para una cosa de andar por casa con una aplicación con centenares de clases y relaciones complejas.

Lo que son buenas prácticas sirven igual para proyectos pequeños que para grandes. Cuando escribí eso, pensaba en mi caso y (por ejemplo) en un videojuego. En ese caso concreto, podría tener una clase gráfico y otras dos (protagonista, enemigo) que heredan y extienden a gráfico.

Conociéndome, tener el árbol (no hablo de algo tremendamente detallado, sino un par de cuadrados con el nombre de la clase y flechas) servirá para decidir si un cambio lo hago arriba o abajo, o para detectar que cambio arriba me va a causar problemas por abajo. Como aficionado, muchas veces me lanzo entusiasmado a escribir código... y es cuando me acuerdo que debería planificar las cosas mejor.

Ahora mismo, mi siguiente proyecto es coger el sna2transtape y reorganizar todo el código para que sea más claro digerirlo (el objetivo final es crear sna2phoenix y extenderlo a snapshots de 128k). Cualquiera que lea el código va a tener la impresión de que en algunas partes está bastante claro y en otras está claramente improvisado. Ahí hay otro ejemplo de lo de las buenas maneras.
I have traveled across the universe and through the years to find Her. Sometimes going all the way is just a start.
Además vendo cosas!

Avatar de Usuario
GXY
Amiga 1200
Amiga 1200
Mensajes: 1238
Registrado: 05 Oct 2013, 08:21
Sistema Favorito: Commodore Amiga
primer_sistema: Spectrum +2
consola_favorita: Sony PlayStation 1
Primera consola: Sony PlayStation 1
Gracias dadas: 29 veces
Gracias recibidas: 60 veces

Re: Code::Blocks, 32 y 64 bits, estándares

Mensajepor GXY » 01 Jun 2020, 18:27

yo a nivel general diria que el estandar actual es 64bit.

32bit es legacy, con lo que conlleva.

pd. hablo en general, no solo de code::blocks

edit. @robcfg

pues me parece que en la nave esa de spaceX tienen metido java+chromium... calidad henkel :mrgreen:

aunque me quiero imaginar que para sistemas criticos usaran linux o alguna solucion embedded bastante fiable.
RetroPescando... :mrgreen:


Volver a “Tecnología e informática”

¿Quién está conectado?

Usuarios navegando por este Foro: No hay usuarios registrados visitando el Foro y 3 invitados