Bonjour,
 
je n'ai jamais fait de C++. Pour mon stage, je programme sous Visual C++ 2005, ce qui est tout nouveau pour moi. En fait, j'ai écrit des fonctions en C, un programme principal en C, et je possède deux fonctions de lecture et de sauvegarde d'image en C++ que je souhaite appeler dans mon programme principal en C:
[#0000ff size=2]  

[size=1] [/size]
Comment dois je m'y prendre ? J'ai tenté de les déclarer en " extern "C" " mais ceci n'a pas marché ?
Quels sont les points importants lorsque l'on veut appeler des fonctions en C++ dans un programme en C ?
 
Merci pour votre aide.

En général Il faut instancier l'objet , et ensuite en appeler ses méthodes.

 
Ha ok, c'est du chinois pour moi qui ne fait pas de programmation objet ... mais bon je vais tenter de me renseigner là dessus. Merci.

ce que dark a voulu dire cest que tu dois avoir qq part, avant d'apeller les methodes lectureImage et /ou sauvegareImage qq chose du genre
imageBMP *pIm = new imageBMP();// constructeur par def
...bla bla...
pIm->lectureImage(image, path, header, infoheader);
...
 
 
autre tite remarque, suis p't'etre un maniaque, mais les noms de classes, essaie de faire qq chose du genre CNomDeMaClasse plutot que nomdemaclasse.
 
le 'C' qui manque m'arrache toujours les yeux.
voilo
 
@pluche
 
 

 
nomdemaclasse, c'est illisible.
NomDeMaClasse, nomDeMaClasse, nom_de_ma_classe, Nom_De_Ma_Classe,  c'est lisible de mon point de vue.
Je crois que c'est surtout contre productif de vouloir imposer une convention de nommage à quelqu'un, hors projet commun.
 
Quand à préfixer par C, je pense à chaque fois que la class est un POD, une sorte de C-classe quoi. Mais apparemment non. En plus ça ne facilite pas la lisibilité du nom de la classe ...  

je pense que le prefixe C va à l'encontre du principe d'opacité des objets, l'utilisateur n'a pas besoin de savoir que tel type est un alias d'une classe
 
imaginez cvector, clist, ... qu'est-ce qu'on en a a foutre que cvector est le nom d'une classe ? ce qui compte c'est la sémantique de cvector (le fond)

+1

pour repondre a la question initiale, interfacer le C avec le C++ est loin d'etre evident, il faudra ecrire (pour utiliser les classes C++ ou des fonction dans du code C) des modules wrapper en C++ avec extern "C" pour les symboles à utiliser dans le code C.
 
il y a aussi d'autres choses à savoir qui sont detaillées dans cette faq
http://jlecomte.ifrance.com/c++/c+ [...] pp-fr.html

 
Allez, un argument pour la défense (parce qu'il faut savoir être objectif) : My::String par exemple. on ne sait pas à prori si c'est un nom de classe, ou un nom de typedef. Autrement dit, peut-on déclaré ce nom ?  
namespace My { class String; } // oui si String est un nom de class, non si c'est un nom de typedef.

t'as qu'a arréter de coder avec les MFC, ça ira beaucoup mieux

 
 
j'ai pas trop compris, que String soit un nom de classe ou un typedef c'est la meme chose, non ? je veux dire que My::String est à partir de la un nom réservé et on ne peut plus déclaré de classe My::String ou de typedef My::String
 
d'ailleur ce code ne compile pas
 
 

 
ou alors je sui à coté    

 
C'est pas exactement ce dont je parle.
 

 
L'exemple qui illustre ce que je disais :
 

 
ça me gène souvent, et je ne sais pas pourquoi il était nécessaire de contraindre cette utilisation de typedef.

ok, mais je vois rien de choquant, ca me parait logique qu'on puisse faire l'un et pas l'autre, et dans le premier c'est juste une déclaration anticipée et la déclaration complete qui suit ?
 
tu voudrais que ce soit comment ? parce que faut bien que la resolution des noms se fasse

Rien de choquant, et c'est bien une déclaration suivie d'une définition.
 

qu'un typedef-name soit un class-name (je rêve)
 

Si tu as une explication sur le pourquoi du comment, n'hésites pas

 
ouai, tu m'aivais deja fais la remarque, mais il semble que dans le standard ce sont bien ces termes (forward declaration & declaration) qui sont employés
 

 
ouai, d'apres le code qe tu as montrés tu voudrais pouvoir faire
 

 
mais class String; c'est une forward declaration, et String est incomplet jusqu'a class String {}; pour moi c'est un point de syntaxe lié aux  mots cles class, struct et union qui permet de déclaré l'existance d'un nom de classe avant sa déclaration complete (ou sa definition si tu preferes)
 
 

 
j'avais pas compris ce que tu voulais faire, mais si ce code compilais
 
 

 
ca ferait 2 types pour un nom
 
l'explication que je vois d'apres le standard (§9.1) c'est que 'class machin' (independament de ce qui suit) insert machin dans le namesapce de la portée courante, et
class machin; // forward déclaration, le nom machin existe
typedef int machin; // impossible car machin existe
class machin {}; // declaration, ou definition (en fait les 2 termes sont employés), si machin n'existe pas il est inseré (pas de conflit), machin est un type complet
 
enfin personnelement je vois pas ou est le probleme et ou est la limitation  

Dans le lexique, mais ailleurs ?
 
 

Je crois que c'est ça.
 
 

 
Mon explication, c'est que "class machin;" déclare le class-name : "machin".
"typedef int machin;" déclare le typedef-name : "machin".
Un nom du même nom est déjà déclaré, et n'est pas un typedef-name (...?), donc pas glop. Mais je ne vois pas le paragraphe qui spécifie cela.
7.1.3.3 est intéressant :
 

 
A noter que la première ligne est une définition contrairement à mon exemple.
A noter aussi que le diagnostic de la deuxième ligne est une redéfinition, alors que typedef int complex; est une déclaration
 

Il n'y a pas de problème, juste que ce serait agréable de pouvoir faire des déclarations "anticipées" sur des typedef-name (qui ne représente pas des class-name), afin de limiter les dépendances et les temps de compilation.

ce qui est sur c'est qu'on ne peut pas avoir de typedef-name et de class-name equivalent puisque la syntaxe ne permet pas de lever ce genre d'ambiguité, c'est ce qui est détaillé dans 7.1.3.3 dans un sens et dans l'autre
 

 
je pense que c'est pareil, definition ou declaration le nom est inseré
 

 
tu aurais un exemple ? parce que pour les classes ok mais c'est deja le cas

Je ne sais pas s'il est difficile pour un compilateur de lever l'ambiguité. Instinctivement, je dirais que non. Mais bon ...
 

Effectivement, c'est marqué *déclaré* dans le texte de 7.1.3.3    
 

 
$ cat file.hpp
#ifndef FILE_HPP
#define FILE_HPP
class Foo;
void func( Foo const& );
#endif
 
$ cat file.cpp
#include "file.hpp"
#include "foo.hpp"
void func( Foo const& foo ) { /* utilise foo */ }
 
$ cat foo.hpp
#ifndef FOO_HPP
#define FOO_HPP
//typedef int Foo; // défendu !
struct Foo {}; // OK
#endif

 
si on pouvais faire

 
c'est mieux comme ca, niveau abstraction vaut mieux considerer autant les class-name que les typedef-name comme des noms de type
 

 
je m'attendais a ca , dans ce cas autant faire ditectement
 

 
pour les classe ok et on peut le faire, mais pour le reste je vois toujours pas l'interet  

j'aurais pas trouvé débile que ce soit int.
 

C'est bien comme cela que je les considèrent. Je veux qu'un typedef-name soit considéré comme un class-name (même si le typedef-name ne représente pas un class-name. cf §7.1.3.4)
 

 
des fois, j'aime bien avoir un fichier qui met des typedef sur les grandeurs que j'utilise dans un projet.
typedef  double profondeur;
typedef unsigned short idCount ;  
histoire de garantir que le type est bien le même dans toute les TU, et par souci de clarté.
Malheureusement, ça a un cout au niveau dépendance, et temps de compilation.

 
ouai dans ce cas pourquoi pas mais en general quand foo designe un class-name et un typedef name, la syntaxe pour instancier un objet (ou on ne precise que le nom du type) ne permet pas au compilateur de determiner le distinguer l'un des 2 type.
 

 
je savais pas que ca avais un cout, pour quel raison ? (j'aurais pensé le contraire)
 
et sinon c'est en effet ce qu'on fait dans tout les projets et les bibliotheques, et meme de maniere indirect tu trouve ca dans tout les programme, et meme en pagaille dans boost ou la lib c++ (j'imagine)
 
en parlant de limitation, il y en a une qui est frustrante c'est le fait de ne pas pouvoir faire de typedef template car coté implementation ca semble ne posée aucun probleme (meme au niveau de la syntaxe)
 
j'avais deja eu ce probleme en cherchant a faire

 
et un site parlait effectivement de ce probleme, qui serait certainement "corrigé" dans un prochain standard

Mon idée est que foo ne désigne alors que le typedef-name.
 

Tu inclus ce fichier partout, tout simplement. Une modification dans ce fichier entraine la recompilation de tout le projet.
Et lorsque tu es sur un réseau (très) lent, et que tu passes 75% du temps de compilation en préprocessing, tu te poses la question de savoir s'il est bien nécessaire d'inclure autant de monde. ça devient problématique lorsque ce fichier de typedef inclu lui aussi pas mal de monde; et tu tires la pelote ...
Si l'environnement de compilation est bien fait (préprocessing en local notamment), ça réduit les problèmes.
 

C'est beaucoup moins simple que tu ne le crois Je me rappelle d'en avoir lu quelques détails, et c'est tellement problématique que le mot clé typedef a été abandonné au profit de "using". Je crois que ça a été discuté à Lillhammer.

a ok, si c'est pas si simple que ca  
 

 
en effet, personnelement je n'ai jamais eu de projet de cette ampleur, les plus gros c'etait 4-5min pour tout recompiler, du moment que ce genre de modif sont rares et à titre exceptionnelles (ce qui est en général le cas) ca me pose pas de probleme mais effectivement dans l'absolu ca peut en etre un.

Quelle est la sémantique que l'on veut donner à typedef template ? C'est cette question qui a fait débat notamment.  
 

En fait, je ne trouve pas qu'un recompilation du projet soit un coût, si c'est en modifiant le fichier de typedef -- c'est exceptionnel on est d'accord. Le projet sur lequel je travaille actuellement met bien 1h30 à se compiler, et la lenteur de la compilation provient du preprocessing. La, je considère comme un coût prohibitif l'inclusion d'un fichier de typedef qui me fait tirer toute une purée de bibliothèques -- dont je n'ai pas le contrôle.