" Bah la version 5.5 de Borland C++ est gratos en tout cas" le compilateur oui mais si tu veux l´éditeur de codes avec faut casquer.

" ps: window$ ? linux ? pff bande de pas-beau, vive le KeliOS ! ! !"
Exact! K3L10S RULEZ!

" je me demandais quels était les opérations qui faisait qu´un simple code sous VC++ pèse déjà plusieurs centaines de Ko ! "
Si tu parles d´exécutable(genre, le . exe père 750 Ko alors que y´a que un int main() {return 0;}), il y a d´autres facteurs en jeu, en plus de ceux énnoncés bravement, et au péril de sa vie par Aitonfrère.

En plus des modifications qui peuvent être fait sur ton code, il se trouve que la forme elle-même du PE executable file prend une place, quoique la majorité du temps minime. Le header au début, puis les diverses informations d´importation, d´exportation et autres prennent environ - de 1 Ko. Pas trop trop de quoi s´allarmer là.

Par contre, il se trouve que du code exécutable danns le fichier, une partie n´est pas de toi. Sous VC++, c´est un ensemble de fichiers sources qui fournissent une pitite couverture douillette à ton prog ( débuggage, construction et destruction globale en c++, entrypoint, passage des paramètres de ta fonction principale main ou winmain, préparation de l´environment pour des exécutables spéciaux comme des MFC, ect...). Crt0.c, en particuler, appèle ta joyeuse fonction main ou WinMain, par exemple. Là, ça compte plus. C´est ce qui principalement fait que ton exe est très gros de centaines de milliers d´octets alors que tu en as que pour une dizaine d´octets de code...

Kelios
---------

Un débat je ne sais pas, même si on apprend toujours en programmation, je pense avoir acquis une certaine expérience en la matière. J´ai commencé il y a 20 ans exactement ( en amateur évidemment), et depuis j´ai quand même eu l´occasion de toucher un peu à tout et faire mes choix pour me spécialiser au niveau professionnel.

Alors bien sur je n´aurai pas la prétention de savoir comment fonctionnent TOUTES les boites, ce qu´elles attendent des ses programmeurs, mais dans les domaines pour lesquels j´ai pu postuler jusqu´à maintenant VC++ a toujours été l´outils principal de développement ( pour du développement Windows). Aucune n´utilisait Borland ou un autre ( j´ai quand même vu trainer un C++ Builder, mais ce n´était que pour faire des outils en interne et parceque le chef de projet ne connaissait pas la prog MFC).

D´accord Altonfrere et les autres vous êtes pas obligés d´être d´accord avec moi.

meuuh non, c´est pas drole d´etre tous d´accord là allez tapez vous dessus, j´ai pris des pop corn, je suis pret !

wow, c´est dur de s´imaginer que sa vie ne tient a un logiciel produit par la boite que je detestait au début
bof sauf si je deviens pas developpeur, où bien que je developpe sur une autre plate forme...
et dire qu´un jour peut etre j´aurais un compilo mikro$oft dans la légalité !

erf, c´est vrai que vu le prix c´est pas pour tout de suite, à moins que le papa noël qui m´a oublié cette année ce rattrape l´année prochaine ! t´as entendu sale enflure ? radeon 9200 et vc++, et que ça saute le barbu !

C´est une ruse ! Elle n´attends que le moment où nous émettrons un avis contraire au sien pour nous sauter dessus et nous déchiqueter de ses longues griffes en hurlant " Gloire à l´Open Source et mort aux viles traîtres qui servent le démon Kro$oft ! "

Mais moi je suis toujours d´accord avec elle, hein !

• se prosterne*

--------------------------------------------------
----------------------------
Poum Pidoum Poum Poum, c´était un autre post inutil de Mouuh la vache lâche ( ´tain le rime quand même).

>Mouuh

erf heureusement qu´elle a de l´humour, on finira peut etre par la vexer malencontreusement, mais elle prend tout bien c´est génial le forum change beaucoup depuis qu´on sait que c´est une fille je trouve, c´est moins ch*ant de poster, enfin c´est plus drole...euh...

" science sans conscience n´est que ruine de l´âme"
erf c´est assez représentatif de l´état de non-esprit de certaines entreprises d´informatique, mais...je ne citerais pas de nom, sinon je suis bon pour un commando de SWAT hélitroyé au dessus de ma maison demain

merci de ta réponse Kelios ! oui effectivement tu m´avais parlé d´entrypoint et tou les truc que faisait le compilo avant la déclaration main()

alors une petite kestion, qu´elle est la différence entre eprom et EEPROM, d´après ce que j´ai compris du cours de Bigonoff l´EEPROM serais resetable par ultraviolet en raison de la petite vitre sur le composant
( je rappelle au passage que le cours que je lis est la programmation de PIC 16F84, et oui je sais ce n´est pas la science infuse que de savoir ce que je lis ; -)

ah tiens non, finalement c´est l´inverse, c´est l´eprom qui peut etre reseté par UV...
je vais plutot faire un topic vu que c pas du C\C++...

vous savez c´est peut-être bien l´open source mais là linux me gave plus qu´autres choses. Comme on dit il n´y a que les cons qui ne changent pas d´avis et moi je crois que je change d´avis. J´ai des pbs avec ce sytème et la plupart des trucs ( comme lire un DVD) je dois le faire sous Windows. je sens que Linux va disparaître définitivement de mon PC.

for Chris_le_ouf

[0bscur4ntysm]

Un Hello world en C++ tout simple :

1. include<iostream>

using namespace std;

int main()
{
cout<<"Hello World\n";
}

Où est la faute ?

´manque le return 0;, mais y´a certains compilos ( GCC par exemple) qui s´en foutent et mettront par défaut un retrun 0;

Sinon, y´a iostream et iostream.h, qui font des choses différentes selon les compilos. VC++, je crois, met son iostream de façon à ce qu´il nitialise par défaut déjà using namespace std;, tandis que iostream.h demande à ce que mette le using namespace std dans son code. Ou est-ce l´inverses des fichiers?

Donc, deux erreurs théoriques, qui dépendent du compilo.

Kelios
---------

Cette fois-vi je voudrais VRAIMENT comprendre pourquoi vous utilisez la ligne " using namespace std;" ? Je ne me suis jamais servie de cette ligne moi. J´en connais même pas sa signification. A part la correction de Kelios, j´ajouterais que je met l´extension du fichier d´en tête c´est à dire " #include < iostream.h>". Evidemment il y a un espace entre include et < .

iostream et iostream.h sont 2 choses totalement différente ( enfin presque)

Ce ne sont pas du tout les mêmes headers ( ya qu´à regarder leur contenu d´ailleurs . ..)

L´un est reservé aux STL ( ceux sans le . h) . .. voilà tout quand au using namespace std ca évite de répéter sans arrêt le namespace std justement

cf les string qui sont je pense plus utilisées du côté des STL :

1. include < string>

std::string blabla = " blabla";

en faisant : using namespace std;
ca permet d´écrire :

string blabla;

Et je tiens à rappeler que la directive de compil #include inclut le fichier dont le nom se trouve entre les " " en cherchant dans le répertoire courant, ou sinon dans les répertoires définis dans les options de compil ou les variables d´environnement en utilisant les < > . Le nom du fichier est gardé tel qu´il est écrit et le compilo ne rajoutera ni le . h ni rien d´autre. Je précise également que l´on peut inclure tout est n´importequoi, on peut très bien écrire ca :

1. include " image.jpg"
2. include " c:\pagefile.sys"
3. include " mon roman.txt"

mais je n´ose même pas imaginer les erreurs que ca peut donner

J´imagine que le compilateur te dit qu´il comprend rien d´abord dans les faux en-têtes, puis dans les vrais.

In file included from Progr.c:1:
Noms.txt:1: parse error before " Muda"
Noms.txt:2: stray ´\351´ in program
Noms.txt:10: stray ´\347´ in program
In file included from Progr.c:1:
Noms.txt:16:7: missing terminating ´ character
Noms.txt:16:7: warning: multi-character character constant
Noms.txt:20: stray ´\351´ in program
Noms.txt:26: stray ´\351´ in program
Noms.txt:33: stray ´\351´ in program
Noms.txt:33:60: warning: multi-character character constant
Noms.txt:33:69: warning: no newline at end of file
In file included from Progr.c:2:
/ usr/include/stdlib.h:137: parse error before " __ctype_get_mb_cur_max"
In file included from / usr/include/sys/types.h:266,
from / usr/include/stdlib.h:414,
from Progr.c:2:
/ usr/include/bits/pthreadtypes.h:48: parse error before " size_t"
/ usr/include/bits/pthreadtypes.h:51: parse error before " __stacksize"
In file included from Progr.c:2:
/ usr/include/stdlib.h:431: parse error before " size_t"
/ usr/include/stdlib.h:460: parse error before " size_t"
/ usr/include/stdlib.h:554: parse error before " __size"
/ usr/include/stdlib.h:556: parse error before " __nmemb"
/ usr/include/stdlib.h:565: parse error before " size_t"
In file included from / usr/include/stdlib.h:576,
from Progr.c:2:
/ usr/include/alloca.h:33: parse error before " __size"
In file included from Progr.c:2:
/ usr/include/stdlib.h:581: parse error before " __size"
/ usr/include/stdlib.h:731: parse error before " size_t"
/ usr/include/stdlib.h:735: parse error before " size_t"
/ usr/include/stdlib.h:804: parse error before " size_t"
/ usr/include/stdlib.h:807: parse error before " size_t"
/ usr/include/stdlib.h:811: parse error before " size_t"
/ usr/include/stdlib.h:814: parse error before " size_t"
/ usr/include/stdlib.h:822: parse error before " size_t"
/ usr/include/stdlib.h:826: parse error before " size_t"
/ usr/include/stdlib.h:833: parse error before " mbstowcs"
/ usr/include/stdlib.h:834: parse error before " size_t"
/ usr/include/stdlib.h:836: parse error before " wcstombs"
/ usr/include/stdlib.h:837: parse error before " size_t"
In file included from / usr/include/_G_config.h:44,
from / usr/include/libio.h:32,
from
/usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.2.2/inc
lude/stdio.h:81,
from Progr.c:3:
/ usr/include/gconv.h:72: parse error before " size_t"
/ usr/include/gconv.h:88: parse error before " size_t"
/ usr/include/gconv.h:97: parse error before " size_t"
/ usr/include/gconv.h:174: parse error before " size_t"
/ usr/include/gconv.h:177: parse error before ´}´ token
In file included from / usr/include/libio.h:32,
from
/usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.2.2/inc
lude/stdio.h:81,
from Progr.c:3:
/ usr/include/_G_config.h:47: field `__cd´ has incomplete type
/ usr/include/_G_config.h:50: field `__cd´ has incomplete type
In file included from
/usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.2.2/inc
lude/stdio.h:81,
from Progr.c:3:
/ usr/include/libio.h:350: parse error before " size_t"
/ usr/include/libio.h:359: parse error before " size_t"
/ usr/include/libio.h:467: parse error before " _IO_sgetn"
/ usr/include/libio.h:467: parse error before " size_t"
In file included from Progr.c:3:

/usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.2.2/inc
lude/stdio.h:288: parse error before " size_t"

/usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.2.2/inc
lude/stdio.h:295: parse error before " size_t"

/usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.2.2/inc
lude/stdio.h:326: parse error before " size_t"

/usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.2.2/inc
lude/stdio.h:330: parse error before " size_t"

/usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.2.2/inc
lude/stdio.h:498: parse error before " fread"

/usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.2.2/inc
lude/stdio.h:498: parse error before " size_t"

/usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.2.2/inc
lude/stdio.h:501: parse error before " fwrite"

/usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.2.2/inc
lude/stdio.h:501: parse error before " size_t"

/usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.2.2/inc
lude/stdio.h:513: parse error before " fread_unlocked"

/usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.2.2/inc
lude/stdio.h:513: parse error before " size_t"

/usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.2.2/inc
lude/stdio.h:515: parse error before " fwrite_unlocked"

/usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.2.2/inc
lude/stdio.h:515: parse error before " size_t"
/ usr/include/gconv.h:176: warning: array `__data´ assumed to have one element

squaleon Posté le 10 février 2004 à 17:15:35
Un Hello world en C++ tout simple :

1. include<iostream> oublier . h

using namespace std; pas besoin de ça

int main() pas besoin du int
{
cout<<"Hello World\n";
} return0 oublier

Où est la faute ? les fautes

tu peux même rajouter un ; à la fin de ´return 0´
comme ça c´est encore plus classe ! ( et puis le compilo ne te sort pas un ´parse error: missing ´;´ before ´}´)