Bonjour,
 
J'aimerais savoir à quoi correspond la variable d'environnement LD_LIBRARY_PATH qui est définie dans le fichier de configuration. J'ai cherché sur Internet mais ça ne me parait pas plus clair. Il s'agit du chemin de la bibliothèque où se trouve, par exemple, les définitions des fonctions appelées depuis le C++ comme celles contenues dans math.h ? Ou est ce plus compliqué ?
 
D'autre part, je suis en train d'essayer d'utliser Qt. Je rencontre un problème car la bibliothèque où se trouve les fichiers .h dont j'ai besoin est installée à une certaine adresse (/usr/lib/qt-2.3.0/include) que je ne peux modifier. Je me vois obligé de taper pour chaque fichier dont j'ai besoin, l'ensemble de l'adresse (par ex. #include "/usr/lib/qt-2.3.0/include/qstring.h" ). Comment éviter cela ? Est ce que ce problème peut être évité en modifiant la variable LD_LIBRARY_PATH ?
 
D'avance merci de vos réponses  
 
Nathan g
 
 

http://www.visi.com/~barr/ldpath.html

Vaut mieux que tu fasse un bon Makefile avec des options de compilations du type:
 
QTINC = /usr/lib/qt-2.3.0/include
QTLIB = /usr/lib/qt-2.3.0/lib
 
et ensuite dans la ligne de compil, tu mets
-IQTINC -LQTLIB
 
Ca te permettra de mettre des "#include<qstring.h>".

A ce propos justement, est ce que la bonne orthogrtaphe n'est pas plutot :
 
#include <qstring>
 
ou
 
#include "qstring.h"
 
plutot que  
 
#include <qstring.h>
 
Je pose cette question car dans un post récent, on m'a conseillé de remplacer l'écriture de #include "fstream.h" par #include <fstream> dans un exemple de programme (avec, en plus l'écriture d'un using namespace std).
 
Je rencontre régulièrement des warning dans la compilation de mes programmes qui me disent que l'écriture de mes #include est incorrecte. Je pense que le problème vient de ce genre d'erreur.
 
Merci de votre réponse à ma question sur la meilleure orthographe a adopter !

rien à voir. y a un fichier iostream sur ton disque et voilà. il est dans un répertoire du CPPPATH, donc < >

En fait, ce fichier iostram est simplement le fichier iostream.h caché car il ne comporte quasiment qu'un #include <iostream.h>. Finalement quel est son intérêt ? Pourquoi ne pas toujours utiliser le fichier iostream.h avec #inlcude <iostream.h> ?
 
De plus, comment savoir si une fonction dont on a besoin doit être appelée par un #include<toto> ou #include<toto.h> puisque les deux orthographes existent parfois (comme pour iostream) et parfois pas ?
Est ce qu'il y a une règle générale ou vaut-il mieux toujours faire appel à des fichiers *.h dont on est certain qu'ils existent ?

parce que le fait que tu aies un iostream.h est un détail d'implémentation, rien d'autre.
 
les header de STL sont sans .h, les autres en .h

Merci de ce début de réponse. Cependant, je m'interroge encore. iostream.h fait partie de la STL ? Je croyais qu'il ne s'agissait que des librairies du style <list>, <vector>, ...
 
D'autre part, ce que tu dis s'applique aussi à fstream, stdlib, time ? Quel sont les headers de la STL et qu'est ce qui n'en fait pas partie ?

« iostream.h est un détail d'implémentation »
 
« les header de STL sont sans .h »
 
je te le dis comment ?

<string> et <string.h> existent aussi, mais c'est pas du tout pareil.
<iostream> et <iostream.h> c'est pas pareil non plus. Certains compilos ne comportent plus <iostream.h>.
La règle est simple : fichier d'en-tête C++ standard : pas de .h, sinon y a le .h.

Quand tu dis que iostream et iostream.h c'est pas pareil, je suis un peu étonné. En effet, le seul contenu du fichier iostream que j'ai (à l'adresse /usr/include/g++-3 pour moi) est :
 
#ifndef __IOSTREAM__
#define __IOSTREAM__
#include <iostream.h>
#endif
 
C'est pourquoi j'avais tendance à considérer que iostream et iostream.h (placé au même niveau que iostream) étaient identiques. Il est vrai que c'est le seul fichier pour lequel j'ai trouvé cette concordance (ce n'est pas le cas de string).

ce que t'arrives pas à comprendre, c'est que la norme dit <iostream>, tout le reste c'est du folklore d'implémentation. t'as qu'à aller aussi pomper des trucs dans bits/ si ça t'amuse

Faudrait regarder dans <iostream.h>. <iostream> nécessite de passer par le namespace std, pas <iostream.h> (+ d'autres changements)

 
Et les headers de la C Standard Library aussi : cstdio, cstddef, ctime, etc.
 

 
Et je t'ai déjà expliqué que c'était comme ça pour la compatiblité ascendante. Avant 1999, il fallait inclure iostream.h, et les symboles n'étaient pas définis dans le namespace std. Depuis, c'est l'inverse.
 
En plus, la norme dit que si tu veux utiliser les headers C, tu peux utiliser #include <cstdio> au lieu de #include<stdio.h>, et les symboles se retrouveront peut-être dans std (quoique ce n'étais pas le cas la dernière fois que j'ai regardé dans la plupart des compilos courants).
 
Mais pour tous les autres headers (QT, Unix, etc.), les choses n'ont pas trop changé: tu utilises les headers avec .h.

avant 98

Tu m'as expliqué ça quand ? T'es qui ?
Et ton explication t'es mignon mais je crois pas avoir prétendu le contraire.
 

Ca aurait du changer ?
 
Au passage y'a pas que le namespace qui change. Par exemple, ios -> ios_base
http://msdn.microsoft.com/library/ [...] tation.asp

 
Mille excuses, j'ai pas fait gaffe et je t'ai quoté pour répondre à nathan_g. Si tu relis ce fil et le fil "Appel de C++ depuis Fortran", tu verras que tout ce que j'ai dit colle: on a déjà eu cette discussion, etc. etc. yada yada.
 
En tout cas, merci de me dire que je suis mignon, ça faisait longtemps qu'on ne me l'avait pas dit.