Bonjour à tous,  
 
petite question que je me pose depuis longtemps et j'aimerai bien avoir un début de réponse cohérent, et justifié (et non pas de guerres).
 
Je suis un developeur C ANSI de base, avec du C++ qui est venu par la suite (comme tant d'autres ici je pense). Hors le C a évolué avec le C ISO, qui inclut les objets et tant d'autres choses. Avant je voyais le C++ comme l'évolution du C ANSI, mais avec le C ISO qui continue aussi d'évoluer ce n'est pas vrai.
 
Donc je me demande, quelles différences majeurs entre les deux? pourquoi l'un et pas l'autre ? (je n'ai jamais vu d'offres pro de projet objet en C, est-ce trop 'jeune' ?).
 
 
Merci pour toute réponse ou redirection
 
 

Le C et le C++ sont deux langages distincts et donc, par conséquent, ils évoluent chacun de leur côté, indépendamment l'un de l'autre.
http://david.tribble.com/text/cdiffs.htm

Un site qui a l'air très intéressant, merci bien.
 
Ca devrait répondre à la plupart de mes questions je pense. Sauf le fait que personne ne fait du C object j'ai l'impression.

Aussi, au risque de poser une question très stupide :
 
Le C++ par rapport au C, au niveau compilateur, qu'est-ce?
Est-ce que les ajouts du C++ sont essentiellement des headers C + des macros avec tout de même de grosses optimisations du compilateur (un peu comme LaTeX pour TeX, mais on va me traiter de fou pour cette comparaison ), ou bien tout est dans le compilateur?
 
Merci

"C object" ?!  
Euuuh... keskesséksetruc ?
 
Pour le C++, ce n'est pas un "C avec des trucs ajoutés dedans". C'est un vrai langage, à part, différent du C. Donc y a pas de macro "pour que le C soit objet", ou autre hérésie de ce genre.  
 
Pour le compilateur, y en a un par langage : gcc/g++, cc/CC, etc.

1- Rooh j'avais cru que le C ISO99 apportait l'objet, mais en fait pas trouvé donc probablement pas.
 
2- Ok
 
Merci

comme déjà dit, ce sont deux langages différents, le C++ ayant de manière standard la capacité de linker avec du C.
 
Après, si on trouve des compilateurs capable de compiler les deux, ce parce que ça ne sert à rien de faire 36x le même travail. En gros, GCC est une collection, donc tu as plusieurs parties avant qui transforment du charabia en langage intermédiaire, que la partie arrière unique peut optimiser et traduire en binaire machine.

Merci pour les précisions, c'est très intéressant. Je vais commencer à m'intéresser un peu plus au fonctionnement des compilateurs je pense, pour mieux comprendre ce que je code... (j'ai fait un OS mais je ne vais probablement pas faire de compilo, le travail serait énorme j'imagine )

(quelque part, quand j'ai vu que tu m'avais répondu et avec la qualité de ma question et tes réponses habituelles aux newbs sur OSA je m'attendais à bien pire ^_^).

 
Flex et bison (ou lex et yacc, suivant les gouts)... tu vas aimer...

déjà fait du lex et yacc
(et déjà fait mon propre parser pour mon propre langage )

Bah voila, c'est ca, ni plus ni moins. Ca traduit un langage "humain" (C, C++ et co). Suivant les langages, ca fait du bytecode ou du langage machine.

Amha, le plus chaud dans un compilateur, c'est la gestion des optimisations (machines et programmes dépendantes). Dans certains coins, ca doit pas être trivial, en plus des bugs d'archi.

oui mais je parlais d'un compilateur donc avec binaire, pas juste d'un parseur de script c'est là qu'est la partie difficile j'imagine.

Dans "binaire", ca inclut bytecode ou pas?

oui

Tiens une question qu'on m'a posé en entretien et qui m'interesse aussi.
 
En supposant qu'on utilise le même code (donc exit l'OOP) vaut-il mieux faire du C ou du C++? En gros quel compilateur pour du code C 'basic' est le plus intéressant j'imagine. AMHA ca ne change rien mais je peux me tromper.

Sauf qu'un code C s'il arrive à compiler en C++ ne fournit pas obligatoire le même résultat.
Niveau performance, aucune différence.

Ooh car les conventions ont pu changer entre les deux?
 
Ok merci bien.

puisque que ce ne sont pas les mêmes langages et que C++ permet de compiler un sous-ensemble du C, avec quelques différences sémantiques...

ok c'est bien ce que je pensais, mais j'imagine qu'en général ca doit pas trop s'éloigner.
 
 
 
(si tu peux venir sur mon topic en cat C ca m'interesse fortement )

bah besoin que ça s'éloigne pour tout défoncer.
sizeof 'a' c'est le plus simple exemple.

hmm?c'est à dire, sizeof ne renvoie pas la même chose?

takakompilai

ok je regarderai cela plus tard merci
Pour l'instant mon autre soucis a la priorité

je reviens sur le sizeof mon ami Taz.
 
Pourquoi sizeof(monarray) ne me donne pas la même taille suivant que monarray a été déclaré en statique ou en dynamique? Je ne comprend pas trop la subtilité

Déjà c'est "sizeof variable" et "sizeof(Type)".
Ensuite ça ne fait aucune différence
 

non ?

hmm je regarderai cela au travail mais quand je voulais calculer la taille d'un tableau avec sizeof(variable)/sizeof(*variable) ca ne fonctionnait qu'avec un tableau 'statique' avec un dynamique ca donnait 1 d'où ma question.
 
Merci

ça n'existe pas les tableaux dynamiques. Un tableau a une taille statique connue à la compilation (sans parler de C99).

int *i = new int[10];
 
comment tu trouves la taille de ce truc?

 
Tu ne peux pas, c'est de l'allocation dynamique. Ou alors, tourne toi vers des langages avec un runtime complet (genre java, python, C#...).
 
Ou utiliser des objets fournis par certains toolkits, qui font ca très bien. Ou utiliser d'autres objets C++, genre string, vectors.
 
Ou utiliser tes propres objets, qui auront une propriété qui retournera leur taille.
 
Amha, cette situation, c'est une aberration du C++ qui a voulu rester proche du C en laissant de tels écueils.

Mais c'est ridicule. Quand je fais un delete, il doit bien savoir la taille a désaloué non?

Oui mais le langage n'offre aucun outil pour la recuperer, car ca n'aurait pas de sens ... vu que y'a pas de tableau dans l'histoire, mais juste un pointeur.

bah y'a bien un outil pour retrouver la mémoire allouée à ce pointeur non?
Il y a longtemps j'avais un peu codé autour de malloc, et je crois bien qu'au bloc mémoire d'avant ou truc du genre tu as la taille totale allouée.
 
Bref quand je récupère un tableau, si je ne sais pas d'où il vient, aucun moyen d'avoir la taille?

Mais on recupere jamais de tableau justement! On recupere uniquement un pointeur, qui peut pointer aussi bien vers une variable, que vers le 13 element d'un tableau C,  ou le milieu d'une zone memoire allouee via malloc... t'as aucune maniere fiable de savoir d'ou ca vient.

Bah c'est naze je trouve

C'est le kernel (ou la lib qui contient malloc, qui demande au kernel de la mémoire via brk()/sbrk() sous Unix) qui sait combien d'octet il alloue quand tu fais un appel a malloc() (new n'est qu'un "wrapper" vers malloc, avec support des arguments pour les constructeurs).

Théoriquement, il n'est pas impossible de retrouver cette taille, en pratique rien de standard n'existe. Tu es censé savoir ce que tu alloues

Sinon, du C objet, y'en a plein qui en font. Par exemple, GTK est écrit en C et complètement orienté objet. Mais c'est à vomir, certes

Bienvenue dans le monde des langages de bas-niveau, petit scarabe.

 
Ok c'est bon à savoir merci.
 

Pas vraiment. Certes, le noyau sait ce qu'il a alloué, mais s'il fallait obtenir cette information ensuite, cela devrait passer par un appel système. Ce qui implique deux changements de contexte, pour une information qui est déjà disponible en userland (vu que tu as fait toi meme le malloc/mmap).

Ca serait une perte de ressources inutiles. On pourrait aussi le garder dans la libc (un buffer ou autre, comme pour le IO fully buffered), mais ca impliquerait de devoir charger le runtime en C pour quelque chose qui est somme toute assez inutile.

Ce qui est pénible en C/C++, c'est l'utilisation des pointeurs. C'est leur plus grand atout mais aussi leur plus grande faiblesse. Un manque de rigueur, et ca te fait un projet codé comme un pied qui va tourner sur du x86 mais se vautrer en bus error sur du sparc, simplement pour des casts de maÿrde et des pointeurs pas correctement alignés.

Tu peux expliquers plus en détail ta dernière phrase ca m'interesse.
Merci