MYLIB.H EST UNE LIBRAIRIE CONTENANT LES FICHIERS INCLUDES NÉCÉSSAIRES
mickbad
Messages postés71Date d'inscriptionmercredi 17 juillet 2002StatutMembreDernière intervention20 avril 2008
-
26 mai 2006 à 09:57
cs_Kirua
Messages postés3006Date d'inscriptiondimanche 14 avril 2002StatutMembreDernière intervention31 décembre 2008
-
27 mai 2006 à 14:07
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
cs_Kirua
Messages postés3006Date d'inscriptiondimanche 14 avril 2002StatutMembreDernière intervention31 décembre 2008 27 mai 2006 à 14:07
ben, c'est syntaxiquement correct ... les extensions, c'est une histoire de convention. d'ailleurs les en-têtes standards std du C++ ne portent pas d'extension du tout ...
mickbad
Messages postés71Date d'inscriptionmercredi 17 juillet 2002StatutMembreDernière intervention20 avril 2008 27 mai 2006 à 13:44
> En quoi le fonctionnement d'un EDI est-il différent
Je disais ça dans le sens (clair comme la bouse de vache :) qu'il est toujours possible de tromper l'éditeur en incluant un .cpp plutôt qu'un .h
Absurde mais possible; TurboC++, C++Builder le permettent bien (les autres très certainement mais je ne me disperse plus trop dans ce domaine ;D juste cygwin, dev-cpp, borland, lccwin32, hihi)
m'enfin :)
cs_Kirua
Messages postés3006Date d'inscriptiondimanche 14 avril 2002StatutMembreDernière intervention31 décembre 2008 27 mai 2006 à 13:05
Soit dit en passant, c'est pas grave hmm ^^. Les premiers codes postés, c'est souvent un peu par erreur, on débute et donc on ne sait pas trop ce qui a de l'intérêt ou pas (j'aurais honte que t'ailles voir mes premiers codes ^^). Simplement ici, c'est pas du code intéressant, voilà tout, c'est pas un drame.
cs_Kirua
Messages postés3006Date d'inscriptiondimanche 14 avril 2002StatutMembreDernière intervention31 décembre 2008 27 mai 2006 à 13:01
"Je crois savoir comment tu programmes : tu compiles tout en même temps via ton éditeur. Maintenant pense à un programme compilé avec gcc ou mingw avec plein de fichiers .cpp ou .c (ça revient au même). Chaque fichier source fait appel à ton Mylib.h. Le principe du Makefile est de compiler chaque source indépendamment puis de les assembler en un fichier binaire."
En quoi le fonctionnement d'un EDI est-il différent? Ton EDI, il se contente de générer un makefile et d'en appeler l'exécution par un programme tiers (GCC make dans le cas de dev-cpp, ou le make de microsoft dans le cas de VC++, ou, ou, ou ...).
Ceci dit, ce code ne sert vraiment à rien (de un), il est incorrect (de deux), et c'est une mauvaise pratique (de trois).
Incorrect, parce que le me fait penser que tu codes en C++, or en C++ correct tu aurais dû écrire ceci:
1) les inclusions multiples ne sont pas gérés
2) tes fonctions devraient être soit « static » ou encore « inline »
3) fait ce que MICKBAD a dit, une librairie!
//----------------------------------------
//- le fichier .h(fichier d'entête)
//----------------------------------------
#ifndef ___NOM_DU_FICHIER__H___ // éviter les inclusions multiples
#define ___NOM_DU_FICHIER__H___ // ...
//
// les fichiers d'entêtes globaux
// dont les autres fichiers(excepté ceux de ta librairie)
// ont besoin pour utiliser _ta_ librairie, n'inclus pas
// de fichiers inutiles ici ...
//
#include
// ...
//
// tes définitions « public » ici(macros, enum, ...)
//
#define NDF_VALEUR_CONSTANTE 1234 // NDF >> NomDuFichier(voir début fichier)
//
// tes fonctions(les prorotypes)/...
//
void ndf_clrscr(void); // par exemple
// ...
#endif // #ifndef ___NOM_DU_FICHIER__H___
//----------------------------------------
//- dans le(s) fichier(s) .cpp
//----------------------------------------
#include <cstdio> // si besoin
#include <cstdlib> // si besoin
#include <cstring> // si besoin
#include // si besoin
// ...
#include "nom_du_fichier.h"
mickbad
Messages postés71Date d'inscriptionmercredi 17 juillet 2002StatutMembreDernière intervention20 avril 2008 26 mai 2006 à 09:57
oui mais personnellement je ne trouve pas que ça soit une super idée de mettre des définitions de fonctions dans un .h !
A moins de les transformer en fonction inline (C++) ou en macro #define (pour le C), je pense que c'est une erreur.
Je crois savoir comment tu programmes : tu compiles tout en même temps via ton éditeur. Maintenant pense à un programme compilé avec gcc ou mingw avec plein de fichiers .cpp ou .c (ça revient au même). Chaque fichier source fait appel à ton Mylib.h. Le principe du Makefile est de compiler chaque source indépendamment puis de les assembler en un fichier binaire.
Selon ton principe, les étapes 1 et 2 peuvent se dérouler sans problème (au warning près suivant les options de compilation). Mais l'assemblage (étape 3) ne marchera pas car les fonctions
randomize, gotoxy, Text_Color, Get_Color_Text, colorie_nombre, colorie_texte, cls, cls2, lower_texte, upper_texte, clrscr sont définies 2 fois !!! Le compilateur ne sait pas qui choisir pour l'adressage des appels à fonction, donc il y a une erreur !
Suis-je clair ?
Ca marche peut être avec toi et ta façon de compiler mais pas pour tout le monde. Fait du développement professionnel (ou même amateur averti :)) et tu verras qu'on programme plutôt de cette manière (.cpp => .o; .o => .exe)
Dernière chose, essaye de mettre des noms de fonction adapté à ta lib car par exemple clrscr() existe déjà si tu inclus sous windows conio.h
Mieux vaut alors faire un ensemble de fonction avec un prefixe type : Mylib_clrscr(); ...
27 mai 2006 à 14:07
27 mai 2006 à 13:44
Je disais ça dans le sens (clair comme la bouse de vache :) qu'il est toujours possible de tromper l'éditeur en incluant un .cpp plutôt qu'un .h
Absurde mais possible; TurboC++, C++Builder le permettent bien (les autres très certainement mais je ne me disperse plus trop dans ce domaine ;D juste cygwin, dev-cpp, borland, lccwin32, hihi)
m'enfin :)
27 mai 2006 à 13:05
27 mai 2006 à 13:01
En quoi le fonctionnement d'un EDI est-il différent? Ton EDI, il se contente de générer un makefile et d'en appeler l'exécution par un programme tiers (GCC make dans le cas de dev-cpp, ou le make de microsoft dans le cas de VC++, ou, ou, ou ...).
Ceci dit, ce code ne sert vraiment à rien (de un), il est incorrect (de deux), et c'est une mauvaise pratique (de trois).
Incorrect, parce que le me fait penser que tu codes en C++, or en C++ correct tu aurais dû écrire ceci:
#include <cstdio>
#include <cstdlib>
#include <conio.h>
#include <ctime>
#include <cstring>
#include <dos.h>
#include <windows.h>
#include
tout simplement.
Et un librairie c'est pas un fichier .h avec des includes :).
26 mai 2006 à 17:40
//----------------------------------------
#include <stdio.h>
#include <stdlib.h>
#include <conio.h>
#include <ctype.h>
#include <errno.h>
//#include <graphics.h>
#include <time.h>
#include <string.h>
#include <dos.h>
//#include "stdafx.h"
#include <windows.h>
#include <winbase.h>
#include // <<<<<<<<< C'EST DU C++
//----------------------------------------
//- DONC:
//----------------------------------------
#include <cstdio> // C<stdio.h> - C++<cstdio>
#include <cstdlib> // C<stdlib.h> - C++<cstdlib>
#include <conio.h> // C/C++
#include <cctype> // C<ctype.h> - C++<cctype>
#include <errno.h> // C<errno.h> - C++<cerrno>
//#include <graphics.h> // C/C++ >>> BORLAND-SPECIFIC
#include <ctime> // C<time.h> - C++<ctime>
#include <cstring> // C<string.h> - C++<cstring>
#include <dos.h> // C/C++
//#include "stdafx.h" // C/C++ >>> MICROSOFT-SPECIFIC
#include <windows.h> // C/C++
//#include <winbase.h> // INUTILE - déjà inclus via <windows.h>
#include // PAS DE « .h », y'a plus de « .h » pour la stl depuis longtemps
//----------------------------------------
TRUE et FALSE sont déjà définie via <windows.h>
pour le reste, j'appuis fortement « MICKBAD »
1) les inclusions multiples ne sont pas gérés
2) tes fonctions devraient être soit « static » ou encore « inline »
3) fait ce que MICKBAD a dit, une librairie!
//----------------------------------------
//- le fichier .h(fichier d'entête)
//----------------------------------------
#ifndef ___NOM_DU_FICHIER__H___ // éviter les inclusions multiples
#define ___NOM_DU_FICHIER__H___ // ...
//
// les fichiers d'entêtes globaux
// dont les autres fichiers(excepté ceux de ta librairie)
// ont besoin pour utiliser _ta_ librairie, n'inclus pas
// de fichiers inutiles ici ...
//
#include
// ...
//
// tes définitions « public » ici(macros, enum, ...)
//
#define NDF_VALEUR_CONSTANTE 1234 // NDF >> NomDuFichier(voir début fichier)
//
// tes fonctions(les prorotypes)/...
//
void ndf_clrscr(void); // par exemple
// ...
#endif // #ifndef ___NOM_DU_FICHIER__H___
//----------------------------------------
//- dans le(s) fichier(s) .cpp
//----------------------------------------
#include <cstdio> // si besoin
#include <cstdlib> // si besoin
#include <cstring> // si besoin
#include // si besoin
// ...
#include "nom_du_fichier.h"
//
// ton code ...
//
void ndf_clrscr(void)
{
// code ...
}
// ...
// ...
// ...
26 mai 2006 à 09:57
A moins de les transformer en fonction inline (C++) ou en macro #define (pour le C), je pense que c'est une erreur.
Je crois savoir comment tu programmes : tu compiles tout en même temps via ton éditeur. Maintenant pense à un programme compilé avec gcc ou mingw avec plein de fichiers .cpp ou .c (ça revient au même). Chaque fichier source fait appel à ton Mylib.h. Le principe du Makefile est de compiler chaque source indépendamment puis de les assembler en un fichier binaire.
1) MaSource1.cpp (#include Mylib.h) => MaSource1.o (ou .obj)
2) MaSource2.cpp (#include Mylib.h) => MaSource2.o (ou .obj)
3) MaSource1.o et MaSource2.o => MonProgramme.exe
Selon ton principe, les étapes 1 et 2 peuvent se dérouler sans problème (au warning près suivant les options de compilation). Mais l'assemblage (étape 3) ne marchera pas car les fonctions
randomize, gotoxy, Text_Color, Get_Color_Text, colorie_nombre, colorie_texte, cls, cls2, lower_texte, upper_texte, clrscr sont définies 2 fois !!! Le compilateur ne sait pas qui choisir pour l'adressage des appels à fonction, donc il y a une erreur !
Suis-je clair ?
Ca marche peut être avec toi et ta façon de compiler mais pas pour tout le monde. Fait du développement professionnel (ou même amateur averti :)) et tu verras qu'on programme plutôt de cette manière (.cpp => .o; .o => .exe)
Dernière chose, essaye de mettre des noms de fonction adapté à ta lib car par exemple clrscr() existe déjà si tu inclus sous windows conio.h
Mieux vaut alors faire un ensemble de fonction avec un prefixe type : Mylib_clrscr(); ...
tu as essayé de faire une .DLL ou un .LIB ?
Bon courage
.Mick.