Discussion:
Bjarne Stroustrup
(demasiado antiguo para responder)
Olaf "El Blanco"
2005-09-28 21:11:46 UTC
Permalink
Los que dominen la programación en C/C++ si tienen un poco de tiempo
expliquen esto!

Jajaja soy un novato que viene de Pascal, estudiando C y luego C++ (?) No es
bueno para los novatos leer estas cosas...

Saludos!





ENTREVISTA A BJARNE STROUSTRUP

------------------------------------------

Traducción

El 1 de Enero de 1998, Bjarne Stroustrup dio una entrevista a la
revista de informática del IEEE. Naturalmente, los editores pensaron
que el estaba dando una vision restrospectiva de los siete anos de
diseno orientado a objetos, usando el lenguaje que el mismo Había
creado.

Al finalizar la entrevista, el entrevistador consiguió mas de lo que
Había pactado en un principio, y consecuentemente, el editor decidio
suprimir los contenidos 'por el bien de la industria'. Pero como suele
suceder, la informacion se filtro...

Aquí esta una completa transcripción de lo que se dijo, no editado, no
ensayado, es decir que no es como las entrevistas planeadas...

Lo encontrareis interesante...



Int: Bien, hace unos pocos anos que cambio el mundo del diseno de
software, como se siente mirando atras?

BS: En este momento estaba pensando en aquellos dias, justo antes de
que llegases. Los recuerdas? Todo el mundo escribia en C y el problema
era que eran demasiado buenos... Las Universidades eran demasiado
buenas ensenandolo también. Se estaban graduando programadores
competentes a una velocidad de vértigo. Esa era la causa del problema.

Int: Problema?

BS: Si, problema. Recuerdas cuando todos programaban en Cobol?

Int: Desde luego. Yo también lo hice.

BS: Bien, al principio, esos tipos eran como semidioses. Sus salarios
eran altos, y eran tratados como la realeza...

Int: Aquellos fueron buenos tiempos, eh?

BS: Exacto. Pero, que paso? IBM se canso de ello, e invirtio millones
en entrenar a programadores, hasta el punto que podias comprar una
docena por medio dolar...

Int: Eso es por lo que me fui. Los salarios bajaron en un ano hasta el
punto de que el trabajo de periodista esta mejor pagado.

BS: Exactamente. Bien, lo mismo paso con los programadores de C...

Int: Ya veo, pero adonde quiere llegar?

BS: Bien, un dia, mientras estaba sentado en la oficina, pensaba en
este pequeno esquema, que podria inclinar la balanza un poquito. Pense
'Que ocurriria si existiese un lenguaje tan complicado, tan difícil de
aprender, que nadie fuese capaz de inundar el mercado de
programadores?'
Empece cogiendo varias ideas del X10, ya sabes, X windows. Es una
autentica pesadilla de sistemas graficos, que solo se ejecutaba en
aquellas cosas Sun 3/60... tenia todos los ingredientes que yo
buscaba.
Una sintaxis ridiculamente compleja, funciones oscuras y estructuras
pseudo-OO. Incluso ahora nadie escribe en código nativo para las
X-Windows. Motif es el unico camino a seguir si quieres mantener la
cordura.

Int: Esta bromeando?

BS: Ni un pelo. De hecho, existe otro problema... Unix esta escrito en
C, Lo que significa que un programador en C puede convertirse
facilmente
en un programador de sistemas. Recuerdas el dinero que un programador
de sistemas solia conseguir?

Int: Puede apostar por ello. Es lo que solia hacer yo...

BS: Ok, por lo tanto, este nuevo lenguaje tenia que divorciarse por si
mismo de Unix, ocultando las llamadas al sistema. Esto podria permitir
a tipos que solo conocían el DOS ganarse la vida decentemente...

Int: No me puedo creer que haya dicho eso...

BS: Bueno, ha llovido mucho desde entonces. Ahora creo que la mayoria
de la gente se habra figurado que C++ es una perdida de tiempo, pero
debo decir que han tardado mas en darse cuenta de lo que pensaba.

Int: Entonces, que hizo exactamente?

BS: Se suponia que tenia que ser una broma, nunca pense que la gente
se tomase el libro en serio. Cualquiera con dos dedos de frente puede
ver que la programación orientada a objetos es anti intuitiva, ilogica
e ineficiente...

Int: Que?!?!

BS: Y como el código reutilizable... cuando has oido de una compania
que reutilice su código?

Int: Bien, nunca, pero...

BS: Entonces estas de acuerdo. Recuerda, algunos lo intentaron al
principio. Había esa compania de Oregon, creo que se llamaba Mentor
Graphics, que revento intentando reescribir todo en C++ en el 90 o
91. Lo siento realmente por ellos, pero pense que los demas
aprenderían de sus errores.

Int: Obviamente no lo hicieron, verdad?

BS: Ni lo mas minimo. El problema es que la mayoria de las empresas
se callaron sus mayores disparates, y explicar 30 millones de dolares
de perdidas a los accionistas podria haber sido dificil... Demosles el
reconocimiento que merecen, finalmente consiguieron hacer que
funcionase

Int: Lo hicieron? Bien eso demuestra que la OO funciona...

BS: Casi. El ejecutable era tan gigantesco que tardaba unos cinco
minutos en cargar en una estacion de trabajo de HP con 128 MB de RAM.
Iba tan rapido como un triciclo. Crei que seria un escollo insalvable
pero nadie se preocupo. SUN y HP estaban demasiado alegres de vender
enormes y poderosas maquinas con gigantescos recursos para ejecutar
programas triviales. Ya sabes, cuando hicimos nuestro primer
compilador
de C++, en AT&T, compile el clásico 'Hello World', y no me podia creer
el tamano del ejecutable. 2.1 MB.

Int: Que ?!?!. Bueno, los compiladores han mejorado mucho desde
entonces...

BS: Lo han hecho? Inténtalo en la ultima verision de g++, la
diferencia
no sera mayor que medio mega. Además existen multitud de ejemplos
actuales en todo el mundo. British Telecom tuvo un desastre mayor en
sus manos, pero, afortunadamente, se deshicieron de ello y comenzaron
de nuevo. Tuvieron mas suerte que Australian Telecom. Ahora he oido
que Siemens esta construyendo un dinosaurio y se empiezan a preocupar
porque los recursos hardware no hacen mas que crecer para hacer
funcionar ejecutables tipicos. No es una delicia la herencia multiple?

Int: Bien, pero C++ es un lenguaje avanzado ...

BS: Realmente crees eso ?!?!?! Te has sentado alguna vez y te has
puesto a trabajar en un proyecto C++? Esto es lo que sucede: Primero
he puesto las suficientes trampas para asegurarme de que solo los
proyectos mas triviales funcionen a la primera. Coge la sobrecarga de
operadores. Al final del proyecto casi todos los modulos lo tienen,
normalmente los programadores sienten que deberían hacerlo asi porque
es como les ensenaron en sus cursos de aprendizaje. El mismo operador
entonces significa cosas diferentes en cada modulo. Intenta poner
unos cuantos juntos, cuando tengas unos cientos de modulos. Y para la
ocultacion de datos. Dios, a veces no puedo parar de reirme cuando
oigo
los problemas que algunas empresas han tenido al hacer a sus modulos
comunicarse entre si. Creo que el termino 'sinergetico' fue
especialmente creado para retorcer un cuchillo en las costillas del
director de proyecto...

Int: Tengo que decir que me siento bastante pasmado por todo esto.
Dice que consiguió subir el salario de los programadores? Eso es
inmoral.

BS: No del todo. Cada uno tiene su opcion. Yo no esperaba que la cosa
se me fuese tanto de las manos. De cualquier forma acerté. C++ se esta
muriendo ahora, pero los programadores todavía conservan sus sueldos
altos. Especialmente esos pobres diablos que tienen que mantener toda
esta majaderia. Comprendes que es imposible mantener un gran modulo en
C++ si no lo has escrito tu mismo?

Int: Como?

BS: Estas fuera de juego, verdad? Recuerdas 'typedef'?

Int: Si, desde luego.

BS: Recuerdas cuanto tiempo se perdia buscando a tientas en las
cabeceras sola para darse cuenta de que 'RoofRaised' era un numero
de doble precision? Bien, imagina el tiempo que te puedes tirar para
encontrar todos los typedefs implicitos en todas las clases en un
gran proyecto.

Int: En que se basa para creer que ha tenido exito?

BS: Te acuerdas de la duracion media de un proyecto en C?. Unos 6
meses. No mucho para que un tipo con una mujer e hijos pueda
conseguir un nivel de vida decente. Coge el mismo proyecto,
realizalo en C++ y que obtienes? Te lo dire. Uno o dos anos. No es
grandioso? Mucha mas seguridad laboral solo por un error de juicio.
Y una cosa mas. Las universidades no han estado ense_ando C desde
hace mucho tiempo, lo que produce un descenso del numero de buenos
programadores en C. Especialmente de los que saben acerca de la
programación en sistemas Unix. Cuantos tipos sabrian que hacer con
un 'malloc', cuando han estado usando 'new' durante estos anos y
nunca se han preocupado de de chequear el código de retorno?. De
hecho la mayoria de los programadores en C++ pasan de los códigos que
les devuelven las funciones. Que paso con el '-1'? Al menos sabias
que tenias un error, sin enredarte con 'throw', 'catch', 'try'...

Int: Pero seguramente la herencia salve un monton de tiempo?

BS: Lo hace? Te has fijado en la diferencia entre un proyecto en C y
el mismo en C++? La etapa en la que se desarrolla un plan en un
proyecto en C++ es tres veces superior. Precisamente para asegurarse
de que todo lo que deba heredarse, lo hace, lo que no, no. Y aun asi
sigue dando fallos. Quien ha oido hablar de la perdida de memoria en
un programa en C? Ahora se ha creado una autentica industria
especializada en encontrarlas. Muchas empresas se rinden y sacan el
producto, sabiendo que pierde como un colador, simplemente para
reducir el gasto de buscar todas esas fugas de memoria.

Int: Hay herramientas...

BS: La mayoria escritas en C++.

Int: Si publicamos esto, probablemente le lincharan. Se da cuenta?

BS: Lo dudo. Como dije, C++ esta en su fase descendente ahora y
ninguna compania en su sano juicio comenzaría un proyecto en C++
sin una prueba piloto. Eso debería convencerles de que es un camino
al desastre. Si no lo hace, entonces se merecen todo lo que les pase.
Ya sabes?, yo intente convencer a Dennis Ritchie a reescribir Unix en
C++...

Int: Oh Dios. Que dijo?

BS: Afortunadamente tiene un buen sentido del humor. Creo que tanto
el como Brian se figuraban lo que estaba haciendo en aquellos dias, y
nunca empezaron el proyecto. Me dijo que me ayudaría a escribir una
version en C++ de DOS, si estaba interesado...

Int: Lo estaba?

BS: De hecho ya he escrito DOS en C++, te pasare una demo cuando
pueda. Lo tengo ejecutandose en una Sparc 20 en la sala de
ordenadores.
Va como un cohete en 4 CPUs, y solo ocupa 70 megas de disco...

Int: Como se comporta en un PC?

BS: Ahora estas bromeando. No has visto Windows '95? Creo que es mi
mayor exito. Casi acaba con la partida antes de que estuviese
preparado

Int: Ya sabes, la idea de Unix++ me ha hecho pensar. Quizás haya
alguien ahí fuera intentandolo.

BS: No despues de leer esta entrevista.

Int: Lo siento, pero no nos veo capaces de publicar esto.

BS: Pero es la historia del siglo. Solo quiero ser recordado por
mis compañeros programadores, por lo que he hecho por ellos. Sabes
cuanto puede conseguir un programador de C++ hoy dia?

Int: Lo ultimo que oi fue algo como unos $70 - $80 la hora para uno
realmente bueno...

BS: Lo ves? Y se los gana a pulso. Seguir la pista de todo lo que
he puesto en C++ no es facil. Y como dije anteriormente, todo
programador en C++ se siente impulsado por alguna promesa mistica
a usar todos los elementos del lenguaje en cada proyecto. Eso
ciertamente me molesta a veces, aunque sirva a mi proposito original.
Casi me ha acabado gustando el lenguaje tras todo este tiempo.

Int: Quiere decir que no era asi antes?

BS: Lo odiaba. Parece extrano, no estas de acuerdo? Pero cuando los
beneficios del libro empezaron a llegar... bien, te haces una idea...

Int: Solo un minuto. Que hay de las referencias?. Debe admitir que
mejoro los punteros de C...

BS: Hmm. Siempre me he preguntado por eso. Originalmente crei que lo
Había hecho. Entonces, un dia estaba discutiendo esto con un tipo que
escribe en C++ desde el principio. Dijo que no podia recordar cuales
de sus variables estaban o no referenciadas, por lo que siempre usaba
punteros. Dijo que el pequeno asterisco se lo recordaba.

Int: Bien, llegados a este punto suelo decir 'muchas gracias' pero
hoy no parece muy adecuado.

BS: Prométeme que publicaras esto. Mi conciencia esta dando lo mejor
de mi mismo estos dias.

Int: Se lo hare saber, pero creo que se lo que dira mi editor...

BS: Quien se lo creeria de todas formas?... De todos modos, puedes
enviarme una copia de la cinta.?

Int: Descuide, lo hare.



--------------------------------------------------------------------------

¿Crees que esta entrevista es mentira?

Es mentira Es verdad
Pedro Maicas
2005-09-29 08:22:23 UTC
Permalink
Post by Olaf "El Blanco"
¿Crees que esta entrevista es mentira?
Es verdad, yo estaba allí.



Saludos :-) -Pedro-

http://www.maicas.net/

e-mail en www.maicas.net
Julián Albo
2005-09-29 14:20:58 UTC
Permalink
Post by Olaf "El Blanco"
Los que dominen la programación en C/C++ si tienen un poco de tiempo
expliquen esto!
Pues es fácil de explicar: hay gente que se cree cualquier cosa que
encuentra por Internet o le envían, y ni se molesta en investigar un poco.
La naturaleza humana, y esas cosas.

Además esta historia ni siquiera es original, es una mala imitación de otra
muy anterior, una supuesta entrevista con Kernighan sobre C.
--
Salu2
McLeod / IdeaFix
2005-09-29 15:34:24 UTC
Permalink
Post by Olaf "El Blanco"
Los que dominen la programación en C/C++ si tienen un poco de tiempo
expliquen esto!
Sí. Se llama "hoax", o sea, bulo. :D
Oscar Garcia
2005-09-29 17:48:23 UTC
Permalink
El Wed, 28 Sep 2005 23:11:46 +0200, "Olaf \"El Blanco\""
...s. Ya sabes, cuando hicimos nuestro primer compilador
de C++, en AT&T, compile el clásico 'Hello World', y no me podia
creer el tamano del ejecutable: 2.1 MB.
Int: Que ?!?!. Bueno, los compiladores han mejorado mucho desde
entonces...
BS: Lo han hecho? Inténtalo en la ultima verision de g++, la
diferencia no sera mayor que medio mega...
hola.c:
#include <stdio.h>

int main (void) {
printf("Hola mundo\n");
}

hola.cpp
#include <iostream>
using namespace std;
int main()
{
cout << "Hola mundo\n";
}
***@deathstar:~/prueba$ g++ -o cplusplus hola.cpp
***@deathstar:~/prueba$ gcc -o cnormal hola.cpp
***@deathstar:~/prueba$ ls -l c*
-rwxr-xr-x 1 redstar users 7339 2005-09-29 19:44 cnormal
-rwxr-xr-x 1 redstar users 9042 2005-09-29 19:44 cplusplus

Creo que 7k de base para C y menos de 9k para C++ no es gran cosa. ¿En
qué se basa todo este mensaje?

Creo recordar que los compiladores de Microsoft bajo entornos visuales
sí que tienen la fea costumbre de crear unos ejecutables bastante
gorditos. Quizá sea debido a que los infla a base de referencias a
DLLs o similares. En Linux el tamaño de los ejecutables es mínima.

Un saludo.
--
Óscar Javier García Baudet
LinaresDigital
http://redstar.linaresdigital.com/
McLeod / IdeaFix
2005-09-29 22:32:40 UTC
Permalink
Post by Oscar Garcia
Creo recordar que los compiladores de Microsoft bajo entornos visuales
sí que tienen la fea costumbre de crear unos ejecutables bastante
gorditos. Quizá sea debido a que los infla a base de referencias a
Pos va a ser que no...

( mismo holamundo.c que el ejemplo anterior, compilado con Visual .NET
2003 )

C:\proy\holamundo\Release>dir
ease>dir
El volumen de la unidad C no tiene etiqueta.
El número de serie del volumen es: C498-0EB3

Directorio de C:\proy\holamundo\Release

30/09/2005 00:13 <DIR> .
30/09/2005 00:13 <DIR> ..
30/09/2005 00:13 2.482 BuildLog.htm
30/09/2005 00:13 1.613 hola.obj
30/09/2005 00:13 3.584 holamundo.exe
30/09/2005 00:13 60.416 holamundo.pdb
30/09/2005 00:13 19.456 vc70.idb
30/09/2005 00:13 45.056 vc70.pdb
6 archivos 132.607 bytes
2 dirs 4.589.875.200 bytes libres


Y desde luego, la traducción a ensamblador no puede ser más directa:

main:
push ebp
mov ebp,esp
push offset ___xt_z+10Ch (415B40h)
call printf (401030h)
add esp,4
xor eax,eax
pop ebp
ret

Lo demás, código de inicialización del runtime, y referencias a la DLL
del equivalente en Windows (MSVCR71.dll) del libc.so

Portable Executable (PE) File

Header base: 000000E8

CPU type 80386
Flags 10F [ fixed executable backwards 32bit ]
DLL flags 0000 [ ]
Linker Version 7.A
Time stamp 433C6908 : Fri Sep 30 00:22:00 2005
O/S Version 4.0
User Version 0.0
Subsystem Version 4.0
Subsystem 0003 [ Windows character ]
Object count 00000003
Symbols offset 00000000
Symbols count 00000000
Optional header size 00E0
Magic # 10B
Code size 00000400
Init Data size 00000600
Uninit Data size 00000000
Entry RVA 0000100F
Image base 00400000
Code base 00001000
Data base 00002000
Object/File align 00001000/00000200
Reserved 00000000
Image size 00004000
Header size 00000400
Checksum 00000000
Stack reserve/commit 00100000/00001000
Heap reserve/commit 00100000/00001000
Number interesting RVAs 00000010
Name RVA Size
------------------ -------- --------
Exports 00000000 00000000
Imports 00002194 0000003C
Resources 00000000 00000000
Exceptions 00000000 00000000
Security 00000000 00000000
Fixups 00000000 00000000
Debug 00002060 0000001C
Description 00000000 00000000
Global Ptr 00000000 00000000
TLS 00000000 00000000
Callbacks 000020B8 00000048
Bound Imports 00000000 00000000
Import Addr Table 00002000 00000058
Delayed Imports 00000000 00000000
COM Runtime 00000000 00000000
reserved 00000000 00000000

Object table:
# Name VirtSize RVA PhysSize Phys off Flags
-- -------- -------- -------- -------- -------- --------
01 .text 000002EE 00001000 00000400 00000400 60000020 [CER]
02 .rdata 0000035A 00002000 00000400 00000800 40000040 [IR]
03 .data 00000034 00003000 00000200 00000C00 C0000040 [IRW]

Key to section flags:
C - contains code
E - executable
I - contains initialized data
R - readable
W - writeable

******************************************************************************
Section: Import
ImportLookUpTblRVA:000021D8
Time Stamp: 00000000
Forwarder Chain: 00000000 (index of first forwarder reference)

Imports from MSVCR71.dll
(hint = 00FA) _exit
(hint = 004B) _XcptFilter
(hint = 00CD) _cexit
(hint = 0297) exit
(hint = 007C) __p___initenv
(hint = 00C2) _amsg_exit
(hint = 006E) __getmainargs
(hint = 013F) _initterm
(hint = 00CA) _c_exit
(hint = 00BB) _adjust_fdiv
(hint = 0082) __p__commode
(hint = 0087) __p__fmode
(hint = 009C) __set_app_type
(hint = 00F1) _except_handler3
(hint = 006B) __dllonexit
(hint = 01B8) _onexit
(hint = 00DB) _controlfp
(hint = 009F) __setusermatherr
(hint = 02EC) printf

Imports from KERNEL32.dll
(hint = 0177) GetModuleHandleA
Antoine Leca
2005-09-30 09:02:30 UTC
Permalink
Post by McLeod / IdeaFix
Post by Oscar Garcia
Creo recordar que los compiladores de Microsoft bajo entornos
visuales sí que tienen la fea costumbre de crear unos
ejecutables bastante gorditos.
Si te equivocas y seleccionas como meta una aplicación MFC (que es lo que MS
desea que haces).
Si seleciones como meta una aplicación normal y corriente, pués no.
Post by McLeod / IdeaFix
Post by Oscar Garcia
Quizá sea debido a que los infla a base de referencias a
DLLs o similares.
No. El mecanisme de enlace dinámico de Windows (PE-COFF) es un poquitín más
eficiente que él de ELF a nivel de tiempo, posee algunas posibilidades menos
(a nivel de variables globales o de interposición), pero no hay diferencias
significativas en tamaño de ejecutable.

Otra cosa es si añades entorno como MFC o AFX en lugar del estándar. O Gnome
o Qt/KDE.
Post by McLeod / IdeaFix
( mismo holamundo.c que el ejemplo anterior, compilado con Visual .NET
2003 )
Por favor, hagas comparaciones fieles: Óscar jamás compiló el .c, solo el
.cpp:

: ***@deathstar:~/prueba$ g++ -o cplusplus hola.cpp
: ***@deathstar:~/prueba$ gcc -o cnormal hola.cpp

(La diferencia está debida a las bibliotecas per defecte, entiendo que g++
incluye más bibliotecas. No sé por qué sale una diferencia en este caso.)
Post by McLeod / IdeaFix
C:\proy\holamundo\Release>dir
Notar que "Release" no es el modo per defecte.
Post by McLeod / IdeaFix
30/09/2005 00:13 3.584 holamundo.exe
30/09/2005 00:13 60.416 holamundo.pdb
30/09/2005 00:13 19.456 vc70.idb
30/09/2005 00:13 45.056 vc70.pdb
Además, creo recordar que por defecte GCC genera los informaciones de debug.
Si realmente son tamaños de los ejecutables más los informaciones de debug,
habrá que compararlo con holamundo.exe más el holamundo.pdb. No sé si los
vc70.?db también...



Las últimas versions de VisualC++ utilizan por defecte alineamento de
secciones a 4Kb (por eficiencia) mientras que antes eran 0.5K, puede dar una
diferencia en programas muy pequeños como aquí (de hecho, la última vez que
probó con un VC2003, me salío eso de los alineamientos a 4K, y no me gustó.
¿Has cambiado alguna opción?)


Antoine
Oscar Garcia
2005-09-30 09:42:40 UTC
Permalink
El Fri, 30 Sep 2005 11:02:30 +0200, "Antoine Leca"
Post by Antoine Leca
Por favor, hagas comparaciones fieles: Óscar jamás compiló el .c, solo el
Sí que lo compilé, al copiar pegar no me percaté del error. Al hacer
el ls me dí cuenta del error (ambos ejecutables tenían el mismo tamaño
porque gcc llama a g++ automáticamente cuando se trata de un archivo
cpp) así que lo modifiqué en la terminal pero se me olvidó modificarlo
en el mensaje que envié al grupo de news.
Post by Antoine Leca
(La diferencia está debida a las bibliotecas per defecte, entiendo que g++
incluye más bibliotecas. No sé por qué sale una diferencia en este caso.)
Las últimas versions de VisualC++ utilizan por defecte alineamento de
secciones a 4Kb (por eficiencia) mientras que antes eran 0.5K, puede dar una
diferencia en programas muy pequeños como aquí (de hecho, la última vez que
probó con un VC2003, me salío eso de los alineamientos a 4K, y no me gustó.
¿Has cambiado alguna opción?)
Uso Visual C++ que viene con el Visual Studio 97. Supongo que desde
aquel VC++ a uno más actual han cambiado mucho las cosas (sobre todo
en optimización de código). No he compilado ese ejemplo en VC++ porque
actualmente sólo uso VB, pero recuerdo que una prueba que hice con un
programa muy sencillo hace unos años me ocupaba unos 100k.

Quizá me aventuré demasiado rápido a opinar acerca del compilador de C
de Microsoft, pero el objetivo del mensaje era reincidir que compilar
algo en C++ no implica necesariamente una sobrecarga de espacio ni un
aumento considerable en el tamaño del ejecutable ni esas "chorradas"
que se insinuan en el mensaje original.

Obviamente es un artículo para darle menos prestigio a C++.

Es verdad que en mis comienzos empecé con C++ y que tras ver lo
complejo que resultaba hacer cualquier programa que antes hacía
decentemente en C me quede en C. Después migué a Java por ser
multiplataforma y por tener una sintaxis más clara.

Mi tropiezo con C++ se basó principalmente a mi inexperiencia en OOP
(como la gran mayoría de los programadores). Actualmente ojeo código
C++ para buscar algo que necesito y entiendo el código perfectamente.

Un saludo.
--
Óscar Javier García Baudet
LinaresDigital
http://redstar.linaresdigital.com/
Antoine Leca
2005-10-04 11:01:56 UTC
Permalink
Post by Oscar Garcia
No he compilado ese ejemplo en VC++
Pués me parece un poco frivolo hacer afirmaciones desagradables si no lo
comprobes antes.
Post by Oscar Garcia
recuerdo que una prueba que hice con un programa muy sencillo hace
unos años me ocupaba unos 100k.
¿Con o sin las informaciones de debug? ¿Seleccionando MFC?
Hay muchas maneras de no hacerlo bién, pero si vas al fundo, te das cuenta
que no hay tanta diferencias.


Antoine
Fenix
2005-10-01 21:04:02 UTC
Permalink
Post by Antoine Leca
Además, creo recordar que por defecte GCC genera los informaciones de
debug. Si realmente son tamaños de los ejecutables más los
informaciones de debug, habrá que compararlo con holamundo.exe más el
holamundo.pdb. No sé si los vc70.?db también...
Si compilas con la opción -s, eliminas esa información para posterior
debug. Que hace ejecutables más pequeñitos. :)
David Asorey Álvarez
2005-10-19 11:55:45 UTC
Permalink
Post by Olaf "El Blanco"
Los que dominen la programación en C/C++ si tienen un poco de tiempo
expliquen esto!
Parece una broma, muy divertida, por cierto.

No soy experto en C++ (ni en C ;-), pero por lo visto, C++ es un
lenguaje con bastantes "escondites" y cosas extrañas. Supongo que
será por aquello de tener que seguir siendo compatible con C y, por
otro lado, soportar programación orientada a objetos.

Corre por ahí un chiste muy bueno:

¿Qué ventaja tiene un programador de C++ frente a otros
programadores?

Respuesta:
La gran satisfacción que logra sólo con que su código compile.


Saludos.

Daivd.

Loading...