MYLIB.H EST UNE LIBRAIRIE CONTENANT LES FICHIERS INCLUDES NÉCÉSSAIRES

mickbad Messages postés 71 Date d'inscription mercredi 17 juillet 2002 Statut Membre Dernière intervention 20 avril 2008 - 26 mai 2006 à 09:57
cs_Kirua Messages postés 3006 Date d'inscription dimanche 14 avril 2002 Statut Membre Dernière intervention 31 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.

https://codes-sources.commentcamarche.net/source/37773-mylib-h-est-une-librairie-contenant-les-fichiers-includes-necessaires

cs_Kirua Messages postés 3006 Date d'inscription dimanche 14 avril 2002 Statut Membre Dernière intervention 31 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és 71 Date d'inscription mercredi 17 juillet 2002 Statut Membre Dernière intervention 20 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és 3006 Date d'inscription dimanche 14 avril 2002 Statut Membre Dernière intervention 31 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és 3006 Date d'inscription dimanche 14 avril 2002 Statut Membre Dernière intervention 31 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:

#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 :).
excrt Messages postés 75 Date d'inscription mercredi 5 avril 2006 Statut Membre Dernière intervention 3 juillet 2006
26 mai 2006 à 17:40
- autre chose

//----------------------------------------
#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 ...
}

// ...
// ...
// ...
mickbad Messages postés 71 Date d'inscription mercredi 17 juillet 2002 Statut Membre Dernière intervention 20 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.

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.