#include"*.h"ou#include<*.h> en C+
Résolu
mira24
Messages postés
136
Date d'inscription
Statut
Membre
Dernière intervention
-
mira24 Messages postés 136 Date d'inscription Statut Membre Dernière intervention -
mira24 Messages postés 136 Date d'inscription Statut Membre Dernière intervention -
Bonjour,
je sais que peut être ma question parait stupide pour quelqu'uns !
mais je vais la poser parceque j'ai pas pu la comprendre!
bon je suis entrain de compiler un code C++ , mais il y a des erreurs que j'ai pas pu les corriger!
en fait, lorsque je remplace #include "packet.h" par #include <packet.h> ça cause plus d'erreur!!
est ce que quelqu'un SVP peut me dire ce quoi la difference entre les deux et quant est ce qu'on utilise chaqu'une d'eux?
merci d'avance
Cdt
je sais que peut être ma question parait stupide pour quelqu'uns !
mais je vais la poser parceque j'ai pas pu la comprendre!
bon je suis entrain de compiler un code C++ , mais il y a des erreurs que j'ai pas pu les corriger!
en fait, lorsque je remplace #include "packet.h" par #include <packet.h> ça cause plus d'erreur!!
est ce que quelqu'un SVP peut me dire ce quoi la difference entre les deux et quant est ce qu'on utilise chaqu'une d'eux?
merci d'avance
Cdt
A voir également:
- Include .h
- Télécharger logiciel dvr h 264 gratuit - Télécharger - Sécurité
- Fichier h - Forum Programmation
- Convertisseur watt en km/h - Forum Matériel & Système
- Télécharger codec h 264 gratuit - Télécharger - Conversion & Codecs
- Train 1000 km/h - Guide
9 réponses
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.
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).
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'
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?
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
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
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
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
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.
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!!
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+