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
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:

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

Mensajepor zup » 29 May 2020, 16:03

Y aquí va otra de mis protestas al universo en general...

Esta última semana le he estado dando un repaso a algunas cosillas, y me he centrado fundamentalmente en C. Ya he publicado un par de hilos acerca de las funciones de ficheros y la eficiencia de mis programas, pero la cosa no se detiene ahí. Así que aquí van otros pensamientos acerca de mis experiencias...

(Todo esto viene porque estuve organizando mis ROMs, y me encontré con que me hacían falta unas cuantas herramientas que seguro que existen pero no se me ocurre como buscar... así que me puse a programarlas. Más detalles un poco más adelante.)

Code::Blocks 20.03 es inútil para programar en 32 bits:
Estoy esperando a que me validen la cuenta en su foro, pero ya tienen que estar pitándoles los oídos. El caso es que me bajé la nueva versión de Code::Blocks y, como buen vago que soy, instalé la versión que incluye el compilador. Me pongo a programar y probar y cuando pongo los ficheros en un pendrive y me lo llevo a otra máquina... resulta que es todo código de 64 bits. Vale, máquina de 64 bits, entorno de 64 bits, compilador de 64 bits... normal. Intenté compilar el código como 32 bits (-m32) pero el compilador no lo permite (protesta ld porque no encuentra las librerías). Otra vez todo normal, ya que mingw-w64 (el compilador utilizado) no incluye librerías ni herramientas para generar código de 32 bits.

Siguiente paso: me bajo la versión portable de Code::Blocks de 32 bits (codeblocks-20.03mingw-32bit-nosetup), abro el mismo proyecto y compilo... ¿más código de 64 bits? Intento forzar a 32 bits y vuelve a protestar ld. A sugerencia de mi mujer, voy a la máquina de 32 bits e intento compilar. Esta vez cambia el error y protesta gcc. Así que intento ejecutar gcc desde la línea de comandos y entonces Windows protesta ya que han empaquetado un compilador de 64 bits en un entorno que supuestamente es de 32 bits. El IDE arranca pero luego no puede compilar nada.

Solución: Baja una versión más antigua de Code::Blocks que use TDM-GCC, copia la carpeta MinGW a alguna parte de tu equipo y en la configuración de Code::Blocks indica esta carpeta para el compilador). Ambos compiladores (mingw-w64 y TDM-GCC) pueden convivir si están instalados en diferentes carpetas), y puedes usar uno u otro para equipos modernos o más viejos.

32 y 64 bits... ¿en qué punto estamos ahora?
Pensando en todo esto, me doy cuenta de que (salvo un portátil de mi mujer) todas mis máquinas habituales son de 64 bits. Mi intención era generar los programas en 32 bits para ser lo más compatible posible, pero... ¿es un detalle o una obligación? Personalmente, creo que es un poco pronto para dejar de compilar a 32 bits... pero la realidad es que se puede considerar a Windows 7 como el último sistema de 32 bits (que ya está desapareciendo).

¿Qué GCC usar para 32 bits?
Actualmente el que tengo instalado es el que venía con Code::Blocks 17.12 (TDM correspondiente a GCC 5.1.0), pero he leído demasiadas cosas sobre GCC últimamente. Una de ellas dice que las versiones 4.9 (¿y las posteriores?) hinchan bastante el código generado en C++, otra dice que la última versión compatible con Windows 98 es la 4.7 (¿es eso importante? ¿es cierto? He leído también que LZDoom se ha compilado bajo GCC 5.x).

Así que... ¿importa mucho la versión que se use para compilar para Windows 32 bits? ¿Importa tanto como para que cambie mi GCC 5.1.0 por otra versión?

Code::Blocks parece estar limitado a un programa por proyecto
Una de las razones por las que empecé a usar Code::Blocks es por pereza. Concretamente por la pereza de no tener que aprender a hacer makefiles. El problema es que estaba intentando hacer un set de herramientas para trabajar con ROMs que me parece deberían estar en el mismo proyecto.

Un ejemplo es que tengo varios programas para "recortar" ROMs (remove_header quita los primeros bytes, remove_tail quita los últimos bytes, cut_file trunca el fichero a un tamaño determinado) que están relacionados... pero no pueden ir en el mismo proyecto ya que protesta porque main() existe en varios ficheros (que es lo que se pretende).

¿Alguien que haya utilizado Code::Blocks sabe si hay algún truco para pasar esta limitación?

itoa o mi vida es una mentira (dialectos de C).
En uno de mis programas, he intentado utilizar itoa para convertir un entero en una cadena e inmediatamente encontré que dicha función no existe. Resulta que es una función no estándar que tenía interiorizada porque aprendí a programar con Borland Turbo C++. El caso es que no es muy evidente ya que Google sigue repleto de resultados referentes a itoa... así que ¿existe un sitio donde consultar si algo pertenece al estándar de C o es una extensión propietaria?

(En este caso, la solución al problema es usar sprintf)

Otro ejemplo de esto... Code::Blocks en Windows me deja utilizar LONG_MAX, pero en Linux no. Aunque LONG_MAX está definido en limits.h, por algún extraño motivo MinGW lo deja pasar (¿tendrá alguna definición interna?) mientras que GCC no.

Así que el workaround aquí es crear el programa y depurarlo... y luego intentar compilarlo en Linux a ver si protesta por algo.

Miedo a C++: Dislexia de programador
Alguien me sugirió (debido a mis problemas con las funciones de ficheros) utilizar C++ en lugar de C. El problema es que tengo miedo a la "dislexia de programador"... un problema que me surgió cuando salí de mi primera FP II (aprendido Turbo Pascal) y en mi segunda FP II aprendí Turbo C. Por algún extraño motivo me pasé una buena temporada mezclando cosas de C on Pascal (curiosamente, nunca me ha pasado con BASIC o ensamblador).

¿Es esto una tontería (en teoría C++ debería tragar con lo mismo que C) o da problemas saltar de C a C++?

(En otro orden de cosas, también soy dado a sufrir "dislexia de teclado"... se manifiesta cuando me paso unos días manejando teclados con los símbolos en sitios diferentes como el del Spectrum y tiendo a buscar un símbolo pasando cíclicamente por su ubicación habitual, la ubicación en el Spectrum y la ubicación en el teclado inglés)

Conclusiones:
Me estoy haciendo viejo. Cuando estaba en FP, hacer todos estos miniprogramas (son 8 o 10) me hubiera entretenido durante un par de tardes... y ahora llevo echando juramentos dos semanas. ¡Qué lejos me han quedado los días del Turbo C++!
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 » 29 May 2020, 18:13

Yo dejé el Code::Blocks como imposible, hace años. Muy bonito, pero algunas cosas me parecían que estaban muy escondidas. Y limitado en otras. Hoy en día todo el mundo usa Visual Studio Code. En los vídeos de Fran Gallego verás cómo lo usa con sus alumnos.

itoa() sigue apareciendo en "algunas" stdlib.h. En mi ordenador, por ejemplo, lo veo en las bibliotecas para programar en AVR, Arduino, etc. pero no en las stdlib.h más actuales, pero no, no es una función estándar.

El último estándar de C, el C18, con número de referencia ISO/IEC 9899:2018 lo puedes comprar por 185,48 €. Incluye el estándar C17. Si no quieres soltar pasta, puedes consultar el estándar C17.

Pasar de programar de C a C++ es un rollo tremendo. Yo lo he intentado muchas veces, y cuando tengo que hacerlo por obligación, lo hago con una pinza en la nariz. La sintaxis de las clases, métodos, lo privado y lo público, bueno, es fácil. El problema es que hay códigos que son auténticos hijos del infierno y no hay por dónde meterles mano. Basta conque veas -otra vez- los últimos vídeos de Fran Gallego. Lo de las plantillas, la obligada gestión de la memoria, iteradores, métodos abstractos, virtuales, y la madre que los parió... Al final, si vas a hacer algo sencillo, pues tiras de lo sencillo. Si el proyecto es grande, pues entonces sí que merece la pena.

Del paso de 32 bits a 64 bits... Yo uso Linux en exclusiva desde 1998, y ya no recuerdo, pero ni idea, de cuándo hice el cambio a 64 bits. Sí que recuerdo que me sorprendió enterarme que los Windows todavía estaban en 32 bits.

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 » 30 May 2020, 11:00

Creo que ayer me pasé un poco con Code::Blocks...

Personalmente, creo que Code::Blocks no es una mala opción, con sus ventajas y desventajas. Las ventajas que he encontrado hasta ahora:
- Es gratis.
- Tiene todo lo que se espera de un IDE moderno.
- Incluye (según paquete) el compilador, con lo que tienes el entorno ya listo para funcionar.
- Es sencillo de manejar (al menos para lo básico).

Como inconvenientes:
- Está pensado para proyectos sencillos, así que es fácil toparse con limitaciones.

En el caso de mi post anterior, lo de que es inútil para 32 bits no es algo achacable a Code::Blocks directamente, sino un error de empaquetado. Si se indica a Code::Blocks que utilice un compilador de 32 bits (en mi caso, usé el TDM-GCC de una versión anterior de Code::Blocks), no hay problemas en ese sentido... pero aún así es un error bastante gordo de empaquetado.

El otro problema con Code::Blocks (tener múltiples programas independientes en un mismo proyecto) seguramente es una limitación debido a que Code::Blocks parece para principiantes... pero me sorprende que no haya algún tipo de workaround.

(Creo que dondiego usaba Code::Blocks para su Doom... me pregunto qué opina sobre todo esto)

Usar Visual Studio Code me da un poco de miedo... al margen de que no sé si su IDE integra tan bien el debugger de GCC, lo que me da pánico son las licencias. Ya me pasó echando un ojo a las licencias de las versiones gratuitas de los nuevos "Turbo" de Borland Embarcadero (duraron más bien poco) y Visual Studio. Vale, el producto es gratuito... pero la lista de prohibiciones de uso y limitaciones era suficientemente preocupante para descartarlos de cualquier uso.

Si Visual Studio Code es tan popular, supongo que han levantado las restricciones... pero aún así me pone en alerta.

El resto de cosas son ya más genéricas del universo C/C++...

El problema del estándar de C es que en muchos sitios encuentras referencia a las funciones, sintaxis y ejemplos... pero nadie te avisa de que algo no es estándar o puede no existir (salvo casos muy claros). Mi objetivo no es hacer código C demasiado estándar, sino ofrecer algo que se pueda compilar tanto en Windows como en Linux (supongo que tendré que poner que mi código es "GCC friendly").

Los tres ejemplos que ya he mencionado:
- itoa: Llama la atención que atoi sea estándar, pero itoa no. En cualquier caso, como es una función "tradicional" (se ha usado durante años en los compiladores Borland) es muy fácil encontrar ejemplos... pero nadie te avisa que no es estándar (salvo que busques "itoa gcc").
- MAX_LONG: Ya lo he mencionado, parece que MinGW admite esta macro sin problemas, pero GCC protesta. Afortunadamente, el error/warning que suelta en este caso indica que MAX_LONG está definido en <limits.h> y no tienes que buscarlo a mano.
- ftell y sus parientes: ya mencioné en otro post que el estándar define ftell como un long int... lo que limita a averiguar la posición de un fichero de menos de 2 gigas. GCC define otras dos funciones en stdio (ftello y ftello64 que retornan tipos de 32 y 64 bits) para suplir esta carencia... pero nos encontramos que Visual C define _ftelli64. En este caso no hay manera estándar... si quieres hacer un programa compilable tanto en GCC como VC necesitarás usar #ifdef creativamente.

(Cuando tengo dudas en estos casos, lo que hacía era buscar ficheros .h que contuvieran el nombre de mi función, macro o definición. Para el uso no académico/no comercial/esporádico/aficionado que le doy, esos 180€ están mejor gastados en otras cosas.)

Hablando de C++, si intento pasar a C++ no espero meterme a la programación orientada a objetos. Simplemente espero usar algunas funciones más útiles que existan en C++ desde un enfoque "normal". Supongo que lo propio es, con tiempo, explorar esas posibilidades... pero mis utilidades (por ejemplo, para truncar un fichero) no necesitan objetos por ninguna parte.

En cuanto a 32 y 64 bits... la pregunta es para Windows. En principio no voy a compilar para Linux (habría que mantener demasiados paquetes), pero sí que voy a comprobar si mi código es utilizable directamente compilando en Debian o en mi Raspberry Pi. Como ya dije, siento que hace años que prácticamente no se venden nuevos sistemas de 32 bits, pero creo que todavía existe una fuerte carga de sistemas antiguos de 32 bits. Siendo aficionado, creo que tardaré mucho tiempo (si es que alguna vez llego a eso) en hacer programas que requieran CPUs de 64 bits. La cuestión es si poner descargas de 32 bits es un detalle para el público en general o una obligación para no dejarlos de lado.
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
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 » 30 May 2020, 11:43

Si, yo soy el autor del RUDE y el LZDoom. El LZDoom compilaba hasta hace no mucho con TDM-GCC y hasta funcionaba en win98 el problema eran las librerias de sonido y lo mismo para procesadores sin SSE2. Al meter cosas mas modernas ya no compila el LZDoom. Pero el ZDoom32 si que compilaba con TDM-GCC.
Con el RUDE sigo usando Code::Blocks, el 17, y tampoco es un proyecto muy sencillo, esta en c.
Pues si la han cagao segun parece, necesitas la version de 32 bit de MinGW-w64. Este es el paquete correcto: i686-8.1.0-release-posix-sjlj-rt_v6-rev0.7z que es el equivalente al del TDM-GCC que venia. Y para 64 bit x86_64-8.1.0-release-posix-seh-rt_v6-rev0.7z.
Pero MinGW-w64 se ha quedado obsoleto, apenas lo mantienen y tiene problemas como que peta al salir con segun que cosas. Bueno eso ha pasado siempre con MinGW pero ahora es peor. El problema es que usa el CRT de Visual C++ 6, creo que se puede usar el CRT moderno ya si compilas tu mismo el compilador. Y luego las cabeceras incompletas y algunas librerias que no son muy alla.
Para el LZDoom principalmente uso Visual Studio 2017 que todavia es compatible con XP, MinGW no es adecuado para producción o sea hacer releases. Pero para el ZDoom si que iba bien como con el ZDoom32. Vamos que para C++ moderno ya no, aquel usaba C++ 11.
Para C++ moderno VS y para lo demas te apañas con el TDM-GCC. Visual Studio code no es un IDE es un editor de texto.
Hay un parametro en VS que es permissive- para conformidad con los standares.
Este esta compilado con Code::Blocks y TDM-GCC:
https://github.com/drfrag666/RUDE/relea ... 3.1.0pre6b

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 » 30 May 2020, 22:03

Vaaale... otra preocupación más.

Ya he comentado que aspiro a que mi código sea compilable tanto en Linux como en Windows, así que no me muevo mucho de GCC. El problema es que ahora (por lo que comentáis) no parece que haya una variante decente de GCC para Windows.

TDM-GCC dice estar actualizado a la 9.2.0 (Marzo de 2020), pero los de Code::Blocks dicen que no integra tan bien como versiones anteriores. MinGW-w64 es un fork debido a que MinGW no estaba demasiado actualizado... y ahora parece que MinGW-w64 tampoco lo lleva demasiado bien. ¿Qué opciones quedan por ahí para usar un GCC en Windows?

Personalmente, lo de enlazar contra MSVCRT no lo veo como una desventaja sino al contrario. Al estar instalada en el 100% de los equipos, no tienes que incluirla en tus propios programas. Hay que ver la de preguntas en foros porque un programa necesita una msvcrt concreta... y la de sitios dudosos que se ofrecen a proporcionartela.

En cuanto a Visual Studio... habría que ver (con mucha desconfianza) la licencia de ese Visual Studio gratuito que comentan. Veo que han pasado las versiones profesionales al modelo de pago periódico... lo que me produce todavía más mal rollo (quería averiguar cuánto si Visual C++ se sigue vendiendo por separado, y cuanto cuesta la broma).
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, 02:34

Son dos programas distintos...

Visual Studio es un IDE completo. Hay tres versiones:
  • Community. Gratis, para Windows
  • Professional. 45 $/mes o 1200 $/año
  • Enterprise: 250 $/mes o 6000 $/año
Visual Studio Code. Gratis, para los 3 sistemas operativos.
Es un editor, no un IDE, pero con miles de extensiones que lo mejoran bastante.

Es de este Visual Studio Code del que hablo. Y Fran Gallego lo usa en Linux Ubuntu con GCC para sus clases de C++.

Yo lo he usado para programar en ensamblador del z80 y del 6502.

Avatar de Usuario
jltursan
Amiga 2500
Amiga 2500
Mensajes: 4023
Registrado: 13 Oct 2006, 19:45
Sistema Favorito: MSX
primer_sistema: Dragon
Ubicación: Serracines, Madrid, España
Gracias dadas: 56 veces
Gracias recibidas: 129 veces
Contactar:

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

Mensajepor jltursan » 31 May 2020, 09:57

Yo desde hace tiempo y precisamente por lo que decís, por no complicarme la vida cuando quiero hacer algo en C puro y duro, empleo el Dev-C++. El proyecto está un pelín desangelado y hace años que se abandonó el desarrollo original; pero todavía da bastante juego:

Dev-C++ v5.9.2

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, 11:21

Y por que no crees que sea una desventaja linkar contra un CRT anciano en 2020? Para extender la muy limitada funcionalidad de ese esta el MinGW RT que tiene problemas graves. Hombre el problema de la petada al salir es serio, si quieres que tu aplicacion guarde la configuracion o que no haya pérdida de datos en algunos casos. Aparte de que queda feo y eso. Pero eso solo pasa si usas codigo moderno.
Ahora se dice que se puede linkar contra UCRT, el universal, que es ya un componente de windows pero romperia la compatibilidad con versiones antiguas. Tendrias que compilar tu propia version de MinGW-w64.
Por ejemplo el GZDoom compila con MinGW, yo lo arreglaba, pero ahora no es funcional y peta al arrancar. Usa C++ 14 y el LZDoom tambien y funciona pero aparte de la petada al salir tiene fallos gráficos. Meti un hack para que no petara pero luego lo quite. En OpenAL soft han metido otro hack al pasarse a C++ moderno. C++ 11 y C no problemo.

Me ha sorprendido que todavia exista el TDM-GCC y el MinGW original todavia, se supone que el MinGW-w64 era la continuacion de aquel porque estaba abandonado. El TDM-GCC de 64 bit esta basado en MinGW-w64.
La versión community de VS no se puede usar en proyectos comerciales, no tienes por que desconfiar de la licencia. Muchos proyectos libres lo usan. Pero eso si es muy gordo el entorno o sea muchos gigas y el MinGW con CodeBlocks es muy ligero. Y ademas los proyectos grandes engordan mucho, por ejemplo el LZDoom en su carpeta con todos los archivos del entorno son varios gigas.
Aqui hablabamos del tema, por cierto LZDoom sigue funcionando en XP.
https://forum.zdoom.org/viewtopic.php?f=7&t=67657

Avatar de Usuario
robcfg
Amiga 2500
Amiga 2500
Mensajes: 2079
Registrado: 07 May 2009, 15:34
Sistema Favorito: Amstrad CPC
primer_sistema: Atari 800XL/600XL
Ubicación: Estocolmo
Gracias dadas: 510 veces
Gracias recibidas: 125 veces

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

Mensajepor robcfg » 31 May 2020, 11:40

Yo para que mis programas andes en Mac, Linux y Windows, estoy usando CMake para generar los proyectos y lo compilas en las plataformas de destino con los compiladores que haya.

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, 12:27

El caso es que cuando uno quiere hacer un programa portable entre S.O., sin complicaciones, e inmediatamente compatible con 32/64 bits, la solución existe hace casi 25 años y se llama Java. Se inventó precisamente para eso. El problema es que si todavía no eres capaz de programar en C++, que te deja usarlo (mal) como un C, en Java lo tienes crudo porque solo puedes usar OOP. Si quieres hacer algo más fácilmente portable usando C++, tienes que tirar de algo como la Qt. De C, ni hablamos.

A mi en su momento, pasar de C, que probablemente siga siendo el lenguaje en el que más líneas de código he tirado en mi vida, a C++ me costó un poco de adaptación. El problema lo tengo ahora, que si tengo que mantener un programa en C, tira que te va, pero como tenga que hacerlo nuevo, o lo hago en C++ o dimito. No me imagino empezando algo desde cero sin algo como Java o C++. Usar C++ no significa emplear todas las características del lenguaje porque sí, de la misma manera que un pintor no utiliza todos los colores de la paleta en un mismo cuadro solo porque los tiene. Pero usar C++ como un C es un grave, diría que gravísimo, error. Y a estas alturas, opino que usar C en un programa nuevo sin que esté fuertemente justificado, es tan arcaico como seguir insistiendo con el propio Windows. Usar Windows para desarrollo es como insistir en usar un ábaco para llevar la contabilidad del Banco de España. Pero oye, cada uno se flagela como quiere. Yo no me planteé en serio hacer el emulador bare-metal para la PI hasta que no encontré una librería C++ en la que apoyarme. Cuando se trata de C, lo considero superado hace años por C++. No solo por el lenguaje, la cantidad de recursos que pone a tu disposición una librería como la STL es, simplemente, brutal. Gracias a ello, el emulador tiene un navegador de ficheros razonable, no te digo más.

El otro día leía que, según el equipo de desarrollo de Chrome, el 70% de los problemas de seguridad del navegador vienen de errores en la gestión de la memoria, y eso que utilizan C++ y son gente experta. Como para meterse en C a estas alturas. En el curro tengo unos programas en C que me tienen harto, precisamente por problemas con la gestión de la memoria. Intentaron, hace más de 25 años, implementar rutinas para crear árboles, listas y cosas así, y están llenas de errores, diría que todas pierden memoria y se les va la pinza con los punteros. Para colmo, en lugar de implementar una librería y usarla, repitieron el código no sé cuantas veces aquí, allá y acullá. Un jodido infierno. Clásica demostración de que no todo el mundo debería programar en C/C++. Encima, conocían un pimiento el Unix, así que los programas dan miedo.

Para programar en C++ uso Visual Studio Code de unos meses a esta parte. Antes que eso, usé Eclipse, pero no me gusta mucho ese entorno. Antes que eso empleé KDevelop, pero lo veo muy verde y petón. Si tengo que editar C, ya que en el curro tengo de todo, C, C++ y Java, VSC o incluso gvim, si la edición es corta y rápida. Y para Java, estoy acostumbrado al Netbeans, aunque también lo he usado alguna vez para programar en C++, pero reconozco que no es lo mejor.

En cualquier caso, insisto, si lo que quieres es un programa portable entre plataformas y que funcione igual de bien en 32/64 bits, sin complicaciones de vida, la solución se llama Java, por mucho que a algunos ignorantes les salga sarpullido solo de oír el nombre, aunque no tengan ni guarra de qué va la phiesta. A día de hoy, determinadas herramientas solo las programo en Java. En el s.XXI, quedarse en C++ para ciertos programas es improductivo, de C ya ni hablamos. El hecho es que en el año 94, el que programaba en C era el rey del Mambo, incluso aún en el 98 programaba yo en C bajo VMS para un banco, en una planta del edificio en la que el 99% de los programadores lo hacían en COBOL. Unos pocos años después, simplemente las ofertas de C desaparecieron. Actualmente, ver una oferta de trabajo para C o C++ es rarísimo, y casi siempre para entornos embebidos con microcontroladores y similares. Para PC, muy poco. Por algo será (hay muchas razones, pero esa es otra historia y deberá ser contada en otra ocasión).
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


Volver a “Tecnología e informática”

¿Quién está conectado?

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