Version imprimable
Moi je dirais que pour un petit prog vite fait qui ne sert qu'a moi par exemple je le ferai naturellement en C (premier language de haut niveau que j'ai appris). Par habitude et puis pour la souplesse du code.
Alors qu'un programme o� rentreront en compte la vitesse d'exec, la quantit� de m�moire et tout je le ferai en C++ qui m'imposera une certaine rigueur.
Qu'est-ce qui change lorsque vous decidez de programmer en C ou en C++ ?? Pour ma part si je veux faire du C, je n'ai que des restrictions par rapport au C++, mais si je veux passe du C au C++, je n'ai quasiment rien a changer...
Tout a fait d'accord !!Citation:
Envoy� par claudio.matzke
Le C++ est un langage de programmation oriente objet, quel confort !! Plus besoin de reecrire ce qui a ete ecrit il y a plus de vingt ans !! Simplement heriter du code disponible pour creer ses propres objets.
Je prefere jouer avec mes legos plutot que les atomes qui les composent ! :wink:
Enfin... Ne m�langeons pas les torchons et les serviettes! Pourquoi toujours opposer deux langage avec des utilit�s differentes... Certes, C++ est tr�s utile pour faire des programmes windows (merci les h�ritages de CFrame, ect.); mais qui ose dire qu'il est plus simple d'utiliser C++ pour faire un noyau d'OS (ni les codeur de win, ni ceux de Linux, ne l'on dit!)?
C'est pourtant vrai qu'il y a des choses qui ont objectivement �t� am�lior�e de C � C++.
Stroustrup lui m�me explique que le nom vien du faite que C++ est le C avec des truc en plus (tout le monde a reconnu l'incr�mentation: ++), mais que ce n'est pas tout a fait un "D" (C+1); parce que le C++ est plus proche du C que ne le serait un langage nouveau.
Tout cela pour dire qu'on peut oublier C++ quand on a pas besoin d'objets; et oublier C quand on veut faire de la POO. Simple question de bon sens!
Je suis d'accord sur le principe : le C et le C++ ne servent pas � la m�me chose, et il s'agit de deux versions du m�me langage. La programmation de micro-controleur par exemple se fait en C ou asm...
Mais juste une petite pr�cision: la plupart des noyaux (Unix, Linux et Windows) ont �t� �crit avant ou pendant l'invention du C++ (quand je dis pendant, c'est avant que le langage et la STL soient consid�r�s comme mature).
D'o� le C...
Personnellement je n'ai jamais cod� de noyau d'OS, je ne peux donc pas dire si l'objet est inutile ou non dans ce domaine tr�s sp�cifique, mais je comprend qu'une fois que c'est fait, et que �a tourne plutot pas trop mal, on a pas trop le courage de tout r��crire (surtout quand c'est pas de l'objet ;) ) et qu'on pr�f�re modifier simplement le code d�j� �xistant.
Quand � savoir si C plus simple de faire un noyau en C++, quelqu'un d'exp�riment� peut-il r�pondre ?
Bonne remarque... Qui me pousse un peu a revoir ce que j'ai dis.Citation:
Envoy� par F�anor13
Je comprends ais�ment que ceux qui font du C++ con�oivent mal de "retomber" vers les C. Cependent, dans le cas contraire; c'est a dire celui ou on commence par le C, il est assez concevable, celon ce qu'on fait, qu'on pense pouvoir ce passer de C++.
Bonjour � tous,
Juste pour dire, j'ai d�j� programm� du C, du C++, du Java et aussi du Pascal Objet (Delphi quoi!)
Je ne sais plus qui l'a dit dans le forum, mais effectivement, je pense que le C et le C++ n'ont pas vocation � faire la m�me chose.
Dans un premier temps, je pense qu'il serait bon de classifier un peu, le C est un langage d'assez bas niveau, en effet, on peut acc�der aux espaces m�moire, bidouiller les bits, on fait des allocations de m�moire manuellement (malloc), ce qui fait que c'est de bas niveau.
Ensuite, nous avons le C++, alors lui il est un peu plus dur � classer du fait qu'on puisse faire du C dans un environnement de C++, il est � la fois bas niveau, et haut niveau, on peut programmer sans se soucier de l'allocation de la m�moire, ou des bits, par contre, on a toujours � faire des delete pour les objets.
Ensuite, je mettrais le Pascal objet, puisqu'il permet aussi des op�rations sur la m�moire ou sur les bits.
Enfin, le Java, qui est un langage pur objet, et qui apporte une couche d'abstraction suppl�mentaire.
Alors � quoi �a sert, cette classification? Je pense que c'est une bonne base pour dire que chaque langage � ses avantages et ses inconv�nients, et donc ne sert pas dans les m�mes cas.
Perso, j'ai utilis� le C pour faire du temps r�el, et je pense que c'est pour le moment le meilleur langage pour �a. En temps r�el, la gestion de la m�moire est fondamental, il faut �tre le plus pr�s possible des composants pour �a.
Ensuite, le C++ et le Pascal Objet (aussi le Java, mais j'en dit un mot plus loin) permettent une abstraction non n�gligeable et apporte aussi bien d'autre avantages. A quoi sert l'abstraction? Elle sert autant que le passage des cartes perfor�es � l'assembleur, ou de l'assembleur au C... Pourquoi je vais me faire chier � g�rer la m�moire, c'est pas � �a que sert le programme que j'�cris! Et en plus, les avantages qu'apporte l'h�ritage et l'encapsulation, sont tr�s important!
A l'attention de ceux qui ont toujours programmer en C, vous rendez vous compte de l'avantage de pouvoir �crire :
Ou m�me l'exemple des dessins!Code:Button b = new Button("OK");
Enfin, un bref mot sur le Java, qui effectivement apporte les m�me avanc�es que le C++, mais sans confusion. Avec du Java on fait de l'objet, c'est tout. En plus, le Java apporte l'avantage de s'abstraire de la machine sur laquelle le programme s'ex�cute.
Saviez vous que les MAC et les PC ne mettent pas les bits de poids fort du m�me cot�?
Pour terminer, je dirai comme quelqu'un l'a d�j� dit, avec tout on peut faire tout! Un jour nous sommes pass� des cartes perfor�es � l'assembleur, puis au C, puis au C++, puis.... on verra!
Si vous ne fa�tes pas d'application critique au niveau gestion de la m�moire, je vous conseille de suivre votre temps, passez au C++.
Si vous avez besoin de faire tourner votre appli sur toutes les plateformes, fa�tes du Java.
Et puis si vous voulez faire votre appli, perso, vous avez le choix entre Java, C++ et Delphi!
Merci pour votre attention!
Des remarques de votre part me fera�t plaisir!
A+
premi�re remarque :
je ne vois pas temps de diff�rence entre malloc et new, surtout new[], sauf qu'on peut se planter sur la taille dans malloc (super avantage, non ;) )
deuxi�me remarque :
je code en Pascal Objet moi aussi et je n'aime pas ce langage, donc je risque de ne pas �tre objectif, mais pour ce qui est d'un langage d'assez bas niveau je m'oppose, surtout quand je vois les restriction d'utilisation des pointeurs sur objets, mais je ne m'�tendrais pas plus sur le sujet car il s'agit d'un post C-C++ en non pas C++-tous les autres.
troisi�me remarque :
l'utilisation du java est plus abstraite que le pascal, mais le langage en lui m�me pas tant que �a, surtout compar� � la CLX de Borland. la seul diff�rence, c'est que leur librairie est standard. Je ne m'�tendrais pas plus sur le sujet pour les m�me raisons que la deuxi�me remarque.
quatri�me remarque :
que le mac code en big endian ou en little endian (inversion des positions des bits de poid fort), cela n'as pas grande importance (sauf en asm) car c'est le compilateur qui g�re �a. Que l'on code en C, en C++, en Pascal, en Java ou en C#, tant que se que l'on fait est standard, on a pas � ce poser de question.
Cinqui�me remarque (qui s'adresse CCausa::pSui) :
Le probl�me auquel je pensais, ce n'est pas vraiment de passer au C++, mais plutot de r��crire tous le code du noyau.
Je rappel que le Cobol est encore l'un des langages les plus utilis�s au mode car bcp d'appli qui �taient �crites dans ce langage sont mise � jour mais pas r��crite.
Comme je l'ai d�j� �crit, je n'ai jamais cod� de noyau et j'aimerai bien que quelqu'un l'ayant d�j� fait puisse s'exprim� ici.
en effet, par exemple en C on peut transtyper implicitement un pointeur void* vers un autre pointeur, pas en C++.Citation:
Envoy� par gl
Ainsi, un compilo C peut compiler
alors que pour un compilo C++ il faudra expliciter le transtypageCode:char *str = malloc(20);
sinon il faut quand m�me faire la diff�rence entre le C et le C++, par exempleCode:char *str = (char*)malloc(20);
en C on utilise malloc/free en C++ new/delete
en C on utilise printf, en C++ std::cout
etc ...
programme complet ok en C mais pas en C++:
Code:
2
3
4
5
new appelle le constructeur d'un objet, et pas malloc.Citation:
Envoy� par F�anor13
"toutes" les plate-formes, c'est un peu exag�r�.Citation:
Si vous avez besoin de faire tourner votre appli sur toutes les plateformes, fa�tes du Java.
Sinon en codant en C ou C++ avec des biblioth�ques portables, on arrive � faire fonctionner un executable sur autant de plate-formes que Java.
salutCitation:
Envoy� par BlackGoddess
je code en C/C++ des algos de traitement d'images, donc je suis pas vraiment sp�cialiste en info / prog, et jusqu'il y a peu je m�langait all�grement C et C++ ...
alors ds mes prog j'utilisait des fois printf, d'autres fois cout, pareil avec malloc et new .. a la barbare quoi :wink:
je me suis am�lior� en C++ que j'utilise principalement maintenant (surtout pr les classes images et les fonctions qui vont bien) mais j'utilise toujours fprintf et fscanf parce que les m�thodes �quivalentes en C++ me semblent bien compliqu�es ... :roll:
donc est ce vraiment mal de m�langer C et C++ ? quelles pr�cautions prendre ?
que signifie extern "C" ?
printf et scanf moins compliqu�s ?
Hum ... ce n'est pas comme :
- S'il fallait apprendre par coeur une liste de sp�cificateurs de formats (/avoir une table � port�e de main)
- s'il fallait comprendre la diff�rence adresse-valeur, voire comment fonctionnent les pointeurs pour se servir de scanf
- si lire une chaine de caract�res �tait simple et non dangeureux � la fois
(http://www.research.att.com/~bs/new_learning.pdf)
- si le C++ nous permettait d'�tendre simplement le panel de fonctions d'affichage (textuel) pour nos donn�es
- si la syntaxe de malloc n'�tait pas lourde -- c'est vrai quoi, pourquoi extraire des informations des types qui sont connus � la compilation ?
non l� j'appr�cie cin et cout ... je parlais de fprintf et fscanf , lecture/�criture ds un fichier :wink:Citation:
Envoy� par Luc Hermitte
d'ailleurs a propos des pointeurs : j'ai pris l'habitude des pointeurs que je passe en param�tres des fonctions:
si j'ai bien compris en C++ les r�f�rences permettent de simplifier l'utilisation des pointeurs, pas besoin de se demander si c'est un pointeur ou pas:Citation:
double* fonction( int *a, char[] name)
mais je me suis toujours pas d�cid� a remplacer mes * par des & ... :?Citation:
&double fonction( int &a, char &name) ???
Oui mais non. Pas l�!
Les r�f�rences, ne s'utilisent pas pour acc�der au premier �l�ment des tableaux.Code:std::vector<double> f(std::vector<int> const &, std::string const &)
En param�tre, on va garder les pointeurs pour les gros objets optionnels.
Pour ce qui est des fichiers. Soit je pr�f�re passer par des biblioth�ques sp�cialis�es soit, par des parseurs (qui eux utilisent souvent le couple du C) qui me permettent de mieux contr�ler les ereurs de format possibles.
ok
je vais continuer gentiment avec mes pointeurs pour l'instant :D
merci :wink:
Luc Hermitte, pourquoi n�cessairement remplacer les tableaux par des vecteurs ?
Euh ... Oui, j'aurais du pr�ciser. Cet exemple c'�tait pour montrer le seul type d'utilisation de r�f�rences que je voyais dans le cadre de passage de tableaux.
Les vecteurs ont divers avantages, mais pas exactement au niveau des passages de param�tres (autre que l'on en �conomise un qui avait �t� oubli� ici).
En revanche, je pense qu'il manquait clairement des const dans le premier code, un tout du moins.
Bonjour,
Les vectors sont utiles quand on veut une don�e extensible facilement et s�re, avec les m�mes performances d'acc�s et simpliciter d'ecriture qu'un tableau.
Cependant, m�me si la taille est statique, il est int�ressant de passer par la classe vector, pour les op�rations de recherche...
Mias, on ne d�vie pas un peu du sujet l� :)