Bonjour, quand on fait :, où est le fichier "iostream"? Dans quel répertoire?Code:#include <iostream>
Version imprimable
Bonjour, quand on fait :, où est le fichier "iostream"? Dans quel répertoire?Code:#include <iostream>
Hello,
Tout dépend de ton compilo, et d'ou tu l'a installé.
Par défaut, sur Windows, avec VS, il est dansSur Linux, ça doit être quelques chose commeCode:C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include
"iostream", et autres includes sont des fichiers normaux, fais une recherche de ce fichier, tu aura l'emplacement exact. :)Code:
2
3
Salut,
La plupart des IDE permettent d'ouvrir le fichier include. A ce moment-là, tu peux retrouver son emplacement (sur Visual, tu laisses la souris sur son onglet, click-droit ouvrir l'emplacement, ..)
Sinon une recherche dans l'explorer de fichier devrait donner un résultat.
Merci, c'est plus précisément dans /usr/include/c++/<version de gcc>, si vous voulez plus d'infos.
Maintenant je vais modifier la bibliothèque standard.
Si j'arrive à comprendre ces codes bizzares.
Ça me semble être une très mauvaise idée. Ton code sera non portable car se basera sur une version modifiée de la STL, sans compter le fait que tu risques d'y inclure des bugs.Citation:
Envoyé par sosolal
Au moins utiliser ce fameux répertoire include pour créer des bibliothèques dynamiques.
Non, c'est un répertoire de headers. Il ne contient aucune librairie.Citation:
Envoyé par sosolal
Qu'est-ce que tu veux faire au final ?
créer une bibliothèque qu'on pourrait inclure avec :
:aie:Code:#include <MaBiblioDeLaMortQuiTueOfTheDoom/MaClasseDeLaMortQuiTueOfTheDoomQuiEstDansMaBiblioDeLaMortQuiTueOfTheDoom.h>
Tu veux dire inclure le fichier avec des chevrons plutôt que des guillemets ?
Il a des options dans les compilateurs pour ça...`-Ipath pour gcc`.
non mais avec cette manière on est pas obligé de faire un manuel d'utilisation pour chaque compilateur : l'/usr/include/C++ est centralisé! Il est utilisé par tout les compilateurs!
Il y a quand même une grande différence entre ajouter des headers dans /usr/include (en les installant par exemple) et modifier les headers du compilo ou de la lib standard.
En plus rien ne garantit que tous les compilateurs utilisent le même dossier. Déjà, il y la différence d'OS qui joue.
Puis les personnes qui utilisent un compilateur connaissent les options pour mettre les chemins des libs, ne serait-ce que pour mettre le noms des libs utilisés.
Et c'est pas comme si il y avait 36 milles compilateurs.
je ne connais qu'un argument de gcc. Et pourtant, c'est celui que j'utilise...
Bonjour,
ce que tu veux faire n'a strictement rien à voir.
Pour créer une lib, on fournit un dossier qui contient .h etc
C'est l'utilisateur qui les installe où il veut et configure son build via les include_path
Un développeur qui s'y connait un peu ne voudra pas d'une telle solution. Il préfèrera choisir ou installer les headers et les librairies. Sous Linux, il utilisera probablement un répertoire /usr/include/NOMLIB/, pour les headers et les .so ou .a seront dans /usr/lib. Sous FreeBSD, il travaillera dans /usr/local/ et pas dans /usr. Sous Windows, il installera probablement dans un répertoire spécifique.Citation:
Envoyé par sosolal
Et ensuite, libre à chaque compilateur de faire comme il veut. Si tu utilise un corss-compiler pour (par exemple) compiler du code Windows sous Linux, alors les headers ne seront pas dans /usr/include mais dans un répertoire à part.
Bref : je pense que tu penses que c'est un peu trop facile :) Il me semble à moi qu'avant de faire ces choix assez drastiques, tu devrais d'abord prendre un peu plus d'expérience en développement. Très honnêtement, entrer un répertoire d'include et un répertoire de lib dans un process de build, ça prends 15 secondes. Essayer d'imaginer une solution pour éviter ça, c'est un peu inutile selon moi.
Euh... C'est quoi les .so et les .a ???
Pour nunux tu trouveras des explications par là
http://lea-linux.org/documentations/Dev-libc
Ce qui est génial dans tous tes posts (sosolal), c'est que tu sembles connaitre environ 1/6e de ce qu'il faut avoir appris pour vraiment travailler efficacement dans l'IT. (et si tu es vraiment collégien entre la 6e et la 3e, c'est une bonne base ce que tu as accumulé jusqu'à présent)
Ce qui est moins bien : ce que tu ne connais pas/ne comprends pas la justification/n'a pas les explications te semble être de la m***e... (et si tu pètes un câble sur ça... mon pauvre ne viens pas travailler dans l'IT car tu en verras des pires)
Et quand la réponse ne te convient pas, tes réponses sont... très expéditives ? [oui, je l'avoue, une fois en 2008 ou 2009 j'étais très fatigué et j'ai répondu UNE FOIS de façon aussi expéditive que toi, et le post est trouvable sur le net.]
Mais tu le fais un peu trop souvent à mon goût.
Bref : pour tous TOUS tes posts je ne peux que t'indiquer google, ou alors de répondre plus calmement/en faisant un texte et pas juste une ligne.
-----
.so = lib dynamique
.a = lib statique
C'est ce qui permet de réduire les sources que tu te trimballeras et/ou d'obtenir des fonctionnalités supplémentaires !... et parfois de réduire le poids de l'exécutable généré.
Le .so est "dynamique" dans le sens où au chargement du binaire en mémoire, ton OS va également charger le .so en mémoire si celui-ci ne l'est pas déjà. = ton binaire/exécutable plus léger à la sortie de la compilation + moins de sources
Le .a est "statique" dans le sens où ton binaire va contenir, en plus de son propre code, le .a associé (.a comme Archive, généré avec la commande "ar", ancêtre/coéquipier de "tar" qui était plutôt fait pour les bandes magnétiques) = moins de sources avec ton code
Dans ton cas : _zzyx_ t'a donné le meilleur lien possible pour toutes les questions que tu te poses...
On parle de la libC/libC++, donc si tu veux exporter un programme :
- soit tu fournis le bout de la libC/libC++ que tu utilises avec ton programme, et il tournera indépendamment de celle installée (en pratique ça marche très rarement...)
- soit tu ne mets que des appels vers les fonctions et les .so résolvent ça à la volée (choix par défaut quand tu fais "gcc *.c"/"g++ *.cpp").
Merci. Je vais me plonger dans la lecture du lien.
EDIT : Bon, ça plante alors que j'ai juste essayé la méthode normale sans bibliothèques. Faut franchement inventer les tutos sérieux avec des codes qui fonctionnent.
Ca malheureusement.... pour les tutos... en 5 ans de bricoles sur mes machines et OVH je peux te donner ces conseils :
1) Vérifie qu'il s'agit bien du même OS
2) Vérifie que c'est la même version OS & logicielle/lib
3) ...attention aux "dates" des tutos ! (plus de 3 ans = le fichier de conf' a changé de tronche, des paramètres en plus ont été rajoutés, etc... dans la plupart des cas)
Quand j'ai voulu mettre un SMTP avec gestion des comptes et mails dans un MySQL...
En un week-end je n'ai jamais réussi à faire fonctionner quoique ce soit (et ça passait par des réinstalls de temps en temps pour avoir une conf' "propre")...
J'ai du tester 5 ou 6 tutos différents à chaque fois.
Quand tu débutes, c'est l'horreur absolue ce genre de tutos, car comme tu le dis : ça marche pas.
Mais c'est toute l'expérience passée qui "reste en ligne" et qui fonctionnait à l'époque (et dont les gars/filles ont été suffisamment sympas pour les présenter publiquement), donc en soit c'est un bien qui amène un mal à plus long terme dans la plupart des cas.
Et c'est au fur et à mesure que tu sauras quoi piquer comme infos à chaque OS/version pour ton cas précis, et à la fin "ça risque de fonctionner".
Mais comme partout : quand ça marchera sur ta machine de test (réinstallée régulièrement), et que tu l'amèneras sur ta machine de "prod"... tu auras les fameux problèmes qui suivent : la libXYZ qui va avec ton nouveau logiciel est incompatible avec la libABC et ça sera une autre paire de manche à régler (et dans l'industrie ils ont la fameuse "préprod" qui est une copie régulière de la prod sur laquelle on règle ces conflits avant de passer en "prod" pure).
faudrait créer une intelligence artificielle qui mets à jour les tutos automatiquement :aie: