C et C++ mythe et realité

**Jean-Marc.Bourguet** · 08/08/2007, 14h39

Le C et le C++ sont deux langages distincts qui partagent un large sous-ensemble. Celui-ci est fort proche du C, mais il n'empêche que quelqu'un connaissant les deux langages remarquera rapidement si quelque chose a été écrit en C++, en C ou dans le sous-ensemble commun.

En pratique, il est commun d'utiliser des bibliothèques écrites en C en C++. Mais c'est le cas dans d'autres langages aussi. Et les solutions sont alors les mêmes: soit on écrit une couche mince faisant la conversion, et le style de la bibliothèque initiale est toujours sensible quand on l'utilise, soit on écrit une couche plus épaisse, gardant le coeur de la fonctionalité mais fournissant une interface plus adaptée au langage utilisé. En C++, la première solution est particulièrement aisée, il suffit de faire un include a l'intérieur d'un bloc extern "C" (et parfois ce bloc n'est pas nécessaire car les auteurs de la bibliothèque C l'ont prévu). Mais ce n'est pas pour autant qu'elle est fondamentalement différente des langages ou la couche mince doit être écrite a la main ou générée par un programme auxiliaire.

**koala01** · 08/08/2007, 15h12

Envoyé par Laurent Gomila

L'utilisation de boost devient de plus en plus inévitable

d'ailleurs c'est bien simple, sauf erreur, il y a des pans entiers de boost qui vont entrer dans la nouvelle norme...

Envoyé par Mongaulois

Ben dans visual 2005 si

(c'etait un autre post). j'ai reussi a les viré avec les option de compilation, mais je trouve pas sa propre.

Mais d'un autre côté, on ne peut pas vraiment dire non plus que le respect des normes, quelles qu'elles soient, ait jamais été l'une des préoccupations majeures de microsoft... bon

Y as bien sur une limite a tout cela. C++ n'est qu'en patie du C. Mais dire qu'ils sont totalement différent et un peu trop rapide.

Ils sont totalement différents...

Ne serait-ce que parce que C++ "automatise" une série de choses qui sont de véritable PAC (Pièges à C

) en C...

Et pour ce qui est "nouveau" en C++ l'utilisation est bien plus simple que les solutions à mettre en oeuvre pour arriver à un résultat similaire en C... et bien mieux sécurisé...

Je suis d'accord avec le fait que Strutroup (désolé si j'ai écorché son nom

) justifie le nom C++ par le fait que

Envoyé par strutroup(très apporximativement)

C++ est un C évolué ainsi que le montre le "++" (qui correspond à C=C+1) mais n'est pas un "nouveau" langage (qui aurait donné un D)

Mais le fait que ce soit une évolution (et je n'hésite pas à rajouter le mot "majeure"

) du C fait... que ce n'est plus du C... C'est autre chose

Je suis d'accord qu'il faut au maximum les séparer. Ce qui n'est pas toujours facile.

Si, c'est facile, accepte l'idée d'abandonner la CLib au profit des possibilités offertes par le C++ quand tu travaille en C++...

Par exemple les struct peuvent être aligné en C++ et non en C(du moins il me semble) ce qui peut poser de grave problème d'interfacage entre du C et du C++...

Comme tout, cela peut poser problème si tu l'utilise à mauvais escient ou si tu pars sur de fausses hypothèses.

Mais si le programme en C ne part pas sur des hypothèses non vérifiées, finalement, que la structure soit alignée ou non ne posera aucun problème d'interfacage

**r0d** · 08/08/2007, 15h18

Envoyé par koala01

Envoyé par mongaulois

Je suis d'accord qu'il faut au maximum les séparer. Ce qui n'est pas toujours facile.

Si, c'est facile, accepte l'idée d'abandonner la CLib au profit des possibilités offertes par le C++ quand tu travaille en C++...

Ha oui? Je te met au défi de me faire un pilote TWAIN en c++ (le premier qui me vient à l'esprit, mais il y a des centaines d'autres exemples) sans faire une ligne de C "pur"

**JolyLoic** · 08/08/2007, 15h20

Envoyé par Mongaulois

Par exemple les struct peuvent être aligné en C++ et non en C(du moins il me semble) ce qui peut poser de grave problème d'interfacage entre du C et du C++...

Moi, il me semble fortement qu'en C aussi, il y a possibilités de contraintes d'alignement sur des structures. Mais comme je ne connais pas le C, je ne peux rien affirmer.

**Jean-Marc.Bourguet** · 08/08/2007, 15h32

Envoyé par JolyLoic

Moi, il me semble fortement qu'en C aussi, il y a possibilités de contraintes d'alignement sur des structures.

Exact.

**koala01** · 08/08/2007, 15h36

Envoyé par r0d

Ha oui? Je te met au défi de me faire un pilote TWAIN en c++ (le premier qui me vient à l'esprit, mais il y a des centaines d'autres exemples) sans faire une ligne de C "pur"

Comme je n'ai pas le prémisse du début de la moindre idée des besoins d'un pilote TWAIN, je crains fort de n'être vraiment pas en mesure de le relever

Ce qui ne veut absolument pas dire non plus que, quand bien même j'aurais des connaissances suffisantes sur le protocole, que j'y arriverais, il faut bien l'avouer

**yan** · 08/08/2007, 15h37

pour un peu d'histoire(passé et futur) resumé du C et C++ vous pouvez regarder
http://www.research.att.com/~bs/C++0x_keynote.pdf

**yan** · 08/08/2007, 15h41

Envoyé par r0d

Ha oui? Je te met au défi de me faire un pilote TWAIN en c++ (le premier qui me vient à l'esprit, mais il y a des centaines d'autres exemples) sans faire une ligne de C "pur"

Puf, finger in the noze

euh non enfaite...
Du coup c'est un peu de C et un peu de c++

. Ou alors on peut dire que C++ peut émuler du C?

**Jean-Marc.Bourguet** · 08/08/2007, 15h43

Envoyé par r0d

Ha oui? Je te met au défi de me faire un pilote TWAIN en c++ (le premier qui me vient à l'esprit, mais il y a des centaines d'autres exemples) sans faire une ligne de C "pur"

J'aimerais bien savoir ce que tu entends par du "C pur".

**yan** · 08/08/2007, 16h03

Envoyé par Jean-Marc.Bourguet

Le C et le C++ sont deux langages distincts qui partagent un large sous-ensemble. Celui-ci est fort proche du C, mais il n'empêche que quelqu'un connaissant les deux langages remarquera rapidement si quelque chose a été écrit en C++, en C ou dans le sous-ensemble commun.

En pratique, il est commun d'utiliser des bibliothèques écrites en C en C++. Mais c'est le cas dans d'autres langages aussi. Et les solutions sont alors les mêmes: soit on écrit une couche mince faisant la conversion, et le style de la bibliothèque initiale est toujours sensible quand on l'utilise, soit on écrit une couche plus épaisse, gardant le coeur de la fonctionalité mais fournissant une interface plus adaptée au langage utilisé. En C++, la première solution est particulièrement aisée, il suffit de faire un include a l'intérieur d'un bloc extern "C" (et parfois ce bloc n'est pas nécessaire car les auteurs de la bibliothèque C l'ont prévu). Mais ce n'est pas pour autant qu'elle est fondamentalement différente des langages ou la couche mince doit être écrite a la main ou générée par un programme auxiliaire.

Je croit voir mon problème. C'est que je ne doit pas comprendre (et ne suis pas le seul) ce qu'es réellement le C... et je pense que je mélange ce sous ensemble est le C. Et c'est la ou est le problème...

**r0d** · 08/08/2007, 16h05

Envoyé par Jean-Marc.Bourguet

J'aimerais bien savoir ce que tu entends par du "C pur".

Par exemple, une fonction "libre" (par opposition à fonction membre) qui prend un char* en paramètre.
Peut-être que "C pur" n'est pas adéquat, j'ai toujours du mal avec la terminologie.

**Jean-Marc.Bourguet** · 08/08/2007, 16h21

Envoyé par r0d

Par exemple, une fonction "libre" (par opposition à fonction membre) qui prend un char* en paramètre.

Et pourquoi tu t'en priverais si c'est ce qu'il faut?

Peut-être que "C pur" n'est pas adéquat, j'ai toujours du mal avec la terminologie.

En fait, je crois que je vois l'idee mais j'ai beaucoup de mal avec les limites. Et comme avec un exemple de "driver", tu es en train de jouer avec les limites, j'aimerais savoir ou tu les places.

Le C++ a ete concu comme langage pouvant manipuler des concepts de bas niveau. Les fonctionnalites necessaires, il les a principalement heritees du C. Si c'est ce que tu fais, tu vas naturellement programmer avec quelque chose qui est proche du sous-ensemble commun du C et du C++, mais si tu es en C++, tu vas peut-etre utiliser des choses comme les templates ou les references parce que ca conviendra mieux que des macros ou des pointeurs.

**r0d** · 08/08/2007, 16h40

Envoyé par Jean-Marc.Bourguet

Et pourquoi tu t'en priverais si c'est ce qu'il faut?

C'est justement ce que j'étais en train de dire. Parfois, non seulement on ne peut pas s'en passer, mais en plus ça n'en vaut pas la peine (d'essayer de s'en passer).

Envoyé par Jean-Marc.Bourguet

En fait, je crois que je vois l'idee mais j'ai beaucoup de mal avec les limites. Et comme avec un exemple de "driver", tu es en train de jouer avec les limites, j'aimerais savoir ou tu les places.

En fait, ce n'est pas le fait de développer un driver que je voulais mettre en exergue, mais le fait d'interfacer une lib écrite en C.

**Jean-Marc.Bourguet** · 08/08/2007, 16h45

Envoyé par r0d

En fait, ce n'est pas le fait de développer un driver que je voulais mettre en exergue, mais le fait d'interfacer une lib écrite en C.

Envoyé par Jean-Marc Bourguet

En pratique, il est commun d'utiliser des bibliothèques écrites en C en C++. Mais c'est le cas dans d'autres langages aussi. Et les solutions sont alors les mêmes: soit on écrit une couche mince faisant la conversion, et le style de la bibliothèque initiale est toujours sensible quand on l'utilise, soit on écrit une couche plus épaisse, gardant le coeur de la fonctionalité mais fournissant une interface plus adaptée au langage utilisé. En C++, la première solution est particulièrement aisée, il suffit de faire un include a l'intérieur d'un bloc extern "C" (et parfois ce bloc n'est pas nécessaire car les auteurs de la bibliothèque C l'ont prévu). Mais ce n'est pas pour autant qu'elle est fondamentalement différente des langages ou la couche mince doit être écrite a la main ou générée par un programme auxiliaire.

**koala01** · 08/08/2007, 16h49

Envoyé par r0d

En fait, ce n'est pas le fait de développer un driver que je voulais mettre en exergue, mais le fait d'interfacer une lib écrite en C.

J'ai jeté un rapide coup d'oeil à twain.h (j'avoue avoir été ... découragé par le seul fait de me rendre compte que les spécifications prenaient plus de 500 pages...en anglais

)

Mais, l'un dans l'autre, qu'est ce qui pourrait t'empêcher de créer des classes pour encapsuler les différentes structures déclarées, et d'en profiter, par exemple, pour redéfinir les opérateurs de flux

A partir de là, en fournissant les fonctions "qui vont bien" pour respecter le protocole, tu pars sur un interfacage des plus facile, non

**koala01** · 08/08/2007, 16h56

Par contre, l'exemple d'une fonction prenant un char* (qu'elle soit libre ou non) est, malheureusement un contre exemple...

Finalement, si la signature attend une référence sur std::string constante, elle acceptera sans aucun problème qu'on lui fournisse un char* lors de l'appel

:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
#include <string>
#include <iostream>
using namespace std;
void Mafonct(const string& s)
{
    cout<<s;
}
int main()
{
    char str[15];
    strcpy(str,"salut");
    Mafonct(str);// c'est clairement un char* que je lui passe
    return 0;
}

**MatRem** · 08/08/2007, 19h27

Mais char * fait bien partie du c++ (ce fameux sous ensemble qui se trouve aussi dans le c

) .... non?

**koala01** · 08/08/2007, 19h37

Envoyé par MatRem

Mais char * fait bien partie du c++ (ce fameux sous ensemble qui se trouve aussi dans le c

) .... non?

Voyons voir...

le primitif char fait partie du sous ensemble
La notion de pointeurs aussi

Donc, en toute logique, un pointeur sur char fait partie du sous-ensemble

Ceci dit, la gestion au jour le jour est largement plus simple sous la forme d'une std::string que sous la forme d'un pointeur de char

**MatRem** · 08/08/2007, 21h40

Oui tout à fait...

En fait c'est un contre exemple de quoi alors la fameuse fonction qui prend un char *?
... j'ai pas du saisir

**koala01** · 08/08/2007, 22h30

Ben, c'est surtout qu'il te sera beaucoup plus facile, bien qu'un pointeur sur char fasse partie intégrante du C++, de préférer une fonction prenant une référence sur un std::string

Affichage des résultats du sondage: Au finale, pour vous, faut-il

C et C++ mythe et realité

C++

Discussions similaires

Partager

Partager