#include"*.h"ou#include<*.h> en C+
Résolu/Fermé
mira24
Messages postés
136
Date d'inscription
vendredi 15 février 2008
Statut
Membre
Dernière intervention
2 juin 2011
-
12 mai 2008 à 15:02
mira24 Messages postés 136 Date d'inscription vendredi 15 février 2008 Statut Membre Dernière intervention 2 juin 2011 - 12 mai 2008 à 16:38
mira24 Messages postés 136 Date d'inscription vendredi 15 février 2008 Statut Membre Dernière intervention 2 juin 2011 - 12 mai 2008 à 16:38
A voir également:
- Include .h
- Télécharger logiciel dvr h 264 gratuit - Télécharger - Sécurité
- Gigaset al 170 h haut parleur - Forum telephonie fixe
- Convertir watt en km/h - Forum Matériel & Système
- C# include ✓ - Forum C#
- Bac h - Forum Études / Formation High-Tech
9 réponses
Mahmah
Messages postés
496
Date d'inscription
lundi 17 septembre 2007
Statut
Membre
Dernière intervention
22 juin 2010
125
12 mai 2008 à 16:22
12 mai 2008 à 16:22
Salutations,
Pour les extensions il y a une liste des extensions a interpréter comme C++ dans les options de Visual C++. Par défaut j'ai : *.cpp;*.cxx;*.cc;*.c Il n'y a qu'à mettre à jour les tiennes et cela devrait marcher. Personnellement je n'ai toujours mis que des .cpp donc Visual ne m'a jamais posé de problème.
Pour le #include "" ou <> Visual et Gcc ne fonctionnent pas pareil.
La règle pour gcc :
"" indique que le chemin donné est à prendre à partir du répertoire où se trouve le fichier en train d'être compilé.
Pour info on ne donne jamais un chemin absolu, c'est euh... logique ! Toujours relatif.
<> indique que le fichier a inclure est dans un des répertoires d'includes donnés au compilateur via l'option -I
Un utilisateur de gcc (Rocky ?) pourra te dire comment est définie la priorité si il existe plusieurs fichiers ayant le même nom dans des répertoires différents.
La règle pour MS Visual C++ :
la règle est similaire sauf que Visual se sert de la différence entre les deux pour définir une priorité entre les deux.
Ainsi pour "" il cherchera d'abord à partir du répertoire actuel puis dans les répertoires donnés au compilo et pour <> l'inverse. Donc si il ne trouve pas dans celui indiqué il vérifiera quand même l'autre possibilité. (pas gcc)
La priorité des répertoires du <> se définit dans les options (tools->options) et selon la version "project settings" ou "project and solution" -> directories : liste déroulante -> include files.
En somme:
#include "packets.h" veut dire que packets.h est dans le même répertoire que le fichier courant.
#include <packets.h> veut dire que packets.h est à la racine d'un des répertoires donnés au compilateur (via -I pour gcc et via les options pour Visual)
Voili voilou,
Comme compilo on peut aussi utiliser Gcc avec MinGW dont le but est de fournir un shell unix basique sous Windows mais qui fournit également les principales librairies win32 au format lib*.a. C'est ce qu'utilise notamment Code::Blocks.
M.
Pour les extensions il y a une liste des extensions a interpréter comme C++ dans les options de Visual C++. Par défaut j'ai : *.cpp;*.cxx;*.cc;*.c Il n'y a qu'à mettre à jour les tiennes et cela devrait marcher. Personnellement je n'ai toujours mis que des .cpp donc Visual ne m'a jamais posé de problème.
Pour le #include "" ou <> Visual et Gcc ne fonctionnent pas pareil.
La règle pour gcc :
"" indique que le chemin donné est à prendre à partir du répertoire où se trouve le fichier en train d'être compilé.
Pour info on ne donne jamais un chemin absolu, c'est euh... logique ! Toujours relatif.
<> indique que le fichier a inclure est dans un des répertoires d'includes donnés au compilateur via l'option -I
Un utilisateur de gcc (Rocky ?) pourra te dire comment est définie la priorité si il existe plusieurs fichiers ayant le même nom dans des répertoires différents.
La règle pour MS Visual C++ :
la règle est similaire sauf que Visual se sert de la différence entre les deux pour définir une priorité entre les deux.
Ainsi pour "" il cherchera d'abord à partir du répertoire actuel puis dans les répertoires donnés au compilo et pour <> l'inverse. Donc si il ne trouve pas dans celui indiqué il vérifiera quand même l'autre possibilité. (pas gcc)
La priorité des répertoires du <> se définit dans les options (tools->options) et selon la version "project settings" ou "project and solution" -> directories : liste déroulante -> include files.
En somme:
#include "packets.h" veut dire que packets.h est dans le même répertoire que le fichier courant.
#include <packets.h> veut dire que packets.h est à la racine d'un des répertoires donnés au compilateur (via -I pour gcc et via les options pour Visual)
Voili voilou,
Comme compilo on peut aussi utiliser Gcc avec MinGW dont le but est de fournir un shell unix basique sous Windows mais qui fournit également les principales librairies win32 au format lib*.a. C'est ce qu'utilise notamment Code::Blocks.
M.
Utilisateur anonyme
12 mai 2008 à 15:09
12 mai 2008 à 15:09
Salut, c'est une question de chemin d'accès à mon avis. Les <> prennent en compte le chemin d'accès défini par le compilateur (il sait où se trouve ce fichier) et les "" accèdent à partir du répertoire courant. On utilise les "" pour faire référence à un fichier avec un chemin d'accès absolu par exemple #include "c:\fichier.h" (quoique c'est déconseillé de mettre le fichier à cet endroit).
naruto-94
Messages postés
865
Date d'inscription
mercredi 17 août 2005
Statut
Membre
Dernière intervention
20 décembre 2012
188
12 mai 2008 à 15:10
12 mai 2008 à 15:10
Salut ,
Je crois que quand on appelle l'include avec < > c'est pour dire que la librairie se trouve dans le dossier lib ( ou autre ) de ton IDE alors que avec les " " c'est pour appelé une libraire qui se trouve dans ton dossier de projet .
A tt'
Je crois que quand on appelle l'include avec < > c'est pour dire que la librairie se trouve dans le dossier lib ( ou autre ) de ton IDE alors que avec les " " c'est pour appelé une libraire qui se trouve dans ton dossier de projet .
A tt'
mira24
Messages postés
136
Date d'inscription
vendredi 15 février 2008
Statut
Membre
Dernière intervention
2 juin 2011
3
12 mai 2008 à 15:22
12 mai 2008 à 15:22
merci de me repondre :)
je dois alors utiliser pour appeler des fichiers le #unclude"*.h" en indiquant le chemin de ce fichier?
je dois alors utiliser pour appeler des fichiers le #unclude"*.h" en indiquant le chemin de ce fichier?
mira24
Messages postés
136
Date d'inscription
vendredi 15 février 2008
Statut
Membre
Dernière intervention
2 juin 2011
3
12 mai 2008 à 15:24
12 mai 2008 à 15:24
pardon c'est plutôt #include"*.h"
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
mira24
Messages postés
136
Date d'inscription
vendredi 15 février 2008
Statut
Membre
Dernière intervention
2 juin 2011
3
12 mai 2008 à 15:28
12 mai 2008 à 15:28
juste pour signaler!
est ce que le fait que ces code sont en c++ et d'extension *.cc et le compilateur que j'utilise est le DEVcpp sous windows XP a une influence sur la compilation de ces codes qui sont faites pour être compiler sous Linux ???!!
merci
est ce que le fait que ces code sont en c++ et d'extension *.cc et le compilateur que j'utilise est le DEVcpp sous windows XP a une influence sur la compilation de ces codes qui sont faites pour être compiler sous Linux ???!!
merci
Utilisateur anonyme
12 mai 2008 à 15:30
12 mai 2008 à 15:30
Salut, oui certains compilateurs adaptent leurs paramètres suivant l'extension du fichier. Visual C++ râle par exemple si on cherche à compiler en C un fichier qui a l'extension .cpp
mira24
Messages postés
136
Date d'inscription
vendredi 15 février 2008
Statut
Membre
Dernière intervention
2 juin 2011
3
12 mai 2008 à 15:36
12 mai 2008 à 15:36
merci à tous
en fait j'ai essayer de compiler ces codes *.cc par Visual C++ mais ça marche pas de tt il n'arrive pas à les lire que lorsque je change leurs extension en *.cpp!!!
bon c'est résolut le probleme mnt
tt simplement je dois compiler ces code sous Linux pour eviter tt probleme!
bonne journée à tous
en fait j'ai essayer de compiler ces codes *.cc par Visual C++ mais ça marche pas de tt il n'arrive pas à les lire que lorsque je change leurs extension en *.cpp!!!
bon c'est résolut le probleme mnt
tt simplement je dois compiler ces code sous Linux pour eviter tt probleme!
bonne journée à tous
Utilisateur anonyme
12 mai 2008 à 15:53
12 mai 2008 à 15:53
Si tu cherches un compilateur pour travailler de la même façon que sous Linux (gcc), alors je te conseille Cygwin. Ca ressemble au shell typiquement Linux.
mira24
Messages postés
136
Date d'inscription
vendredi 15 février 2008
Statut
Membre
Dernière intervention
2 juin 2011
3
12 mai 2008 à 15:59
12 mai 2008 à 15:59
merci, j'ai deja travailé avec cygwin et ça marche bien surtout que j'utilise le NS-2 et la simulation ça marche bien mais lorsqu'il s'agit d'une implémentation sous NS là j'ai rencontré plein de problèmes !! c'est pour ça j'ai changé le SE sur mon laptop mais j'utilise encore le windows sur mon PC .
et lorsque je compile sous windows ça marche pas!
en tt cas ça sert à rien de perdre le temps sous windows alors que sous Linux ça marche trop bien juste que je suis débutante avec Linux et j'ai pas pu m'eloigner de Wiindows facilement!!
et lorsque je compile sous windows ça marche pas!
en tt cas ça sert à rien de perdre le temps sous windows alors que sous Linux ça marche trop bien juste que je suis débutante avec Linux et j'ai pas pu m'eloigner de Wiindows facilement!!
Utilisateur anonyme
12 mai 2008 à 16:07
12 mai 2008 à 16:07
Ben installe un Linux en machine virtuelle, pour travailler c'est pas trop mal. Une petite install vmware pour utiliser Linux en cas de besoin et hop!
12 mai 2008 à 16:38
et merci à tous en fait.
bon en tt cas j'ai installé Linux version CentOs 5 en multiboot avec Windows XP sur mon laptop.
je vais essayer tt mon mieux pour m'adapter avec Linux ;-)
et pour la compilation j'utiliserai le gcc qui est plis adequat surtout que j'utilise le NS-2.
a+