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