[débutant]Utilisation d'une librairie (GENIAL)

Bonjour,
j'ai un problème dés l'inclusion d'une librairie (Genial): j'écris:

Code:

---

1 2 3 4

#include<iostream> using namespace std;   #include "GENIAL\array/matrix.h";

---

et j'ai:

Citation:

---

------ Début de la génération : Projet : Test_GENIAL, Configuration : Debug Win32 ------
Compilation en cours...
Genialtest.cpp
.\Genialtest.cpp(4) : warning C4067: jetons inattendus après la directive du préprocesseur - saut de ligne attendu
.\Genialtest.cpp(4) : fatal error C1083: Impossible d'ouvrir le fichier include : 'GENIAL\array/matrix.h' : No such file or directory
Le journal de génération a été enregistré à l'emplacement "file://d:\Dossiers & prog\programation\C\C++\init\Test_GENIAL\Test_GENIAL\Debug\BuildLog.htm"
Test_GENIAL - 1 erreur(s), 1 avertissement(s)
========== Génération : 0 a réussi, 1 a échoué, 0 mis à jour, 0 a été ignoré ==========

---

J'ai pourtant mis les fichies lib de Genial dans /lib/GENIAL/, mais ça à pas l'air de marcher

si vous pouvierz m'aider.

merci.

"using namespace std" avant une inclusion c'est mal.
Le point-virgule après une directive #include est inutile.

Ensuite apparemment l'en-tête que tu tentes d'inclure ne se trouve pas là où le compilo le cherche.

bon, je vais faire dans l'ordre alors: Genial utilise des fichiers .lib. (pas de dll)

je les met où ?

Pour l'instant tu as un problème de chemin d'en-tête, les fichiers bibliothèques ça viendra après ;)

Globalement tu as deux solutions pour les fichiers, que ce soit les en-têtes ou les bibliothèques.
- Soit tu les mets dans l'arborescence de ton projet et tu y accèdes avec un chemin relatif entouré par des ""
- Soit tu les mets dans un répertoire quelconque, tu ajoutes ce répertoire aux chemins de recherche du compilo, et tu y accèdes avec un chemin entouré par des <>.

Par exemple ce que je fais habituellement c'est créer un répertoire par bibliothèque, puis un sous-répertoire "include" pour les en-têtes et un "lib" pour les bibliothèques. Ensuite j'ajoute "bibliothèque/include" aux chemins de recherche d'en-têtes, et "bibliothèque/lib" aux chemins de recherche de bibliothèques.

je l'ai mis dans le include du répertoire de VC++, mais je ne comprend pas trés bien comment on se sert de cette librairie, puisqu'elle ne comprend pas de dll et que l'aide dit qu'il est inutile de compiler celle-ci

Je doit mettre tous les .h du projet ?
je doit inclure la source ?


merci...

Ps: (ce serait peut être plus simple avec le Chat...Je suis dessus jusqu'à une heure moins-le quart)

Dans la doc il y a pourtant une page qui explique très bien l'installation, et qui dis que tu peux utiliser uniquement les en-têtes (pas de compilation ou de fichier bibliothèque nécessaire) -- j'imagine que ce sont majoritairement des templates qui composent cette bibliothèque.

Et si tu as des .lib précompilés, et bien utilise les : ajoute les aux options d'édition de liens.

Citation:

---

Envoyé par Laurent Gomila

Dans la doc il y a pourtant une page qui explique très bien l'installation, et qui dis que tu peux utiliser uniquement les en-têtes (pas de compilation ou de fichier bibliothèque nécessaire)

---

Oui, j'ai compris ça, mais le problème est que je ne sait pas les utiliser (je suis vraiment un débutant:aie: )

Citation:

---

Envoyé par Laurent Gomila

-- j'imagine que ce sont majoritairement des templates qui composent cette bibliothèque.

---

y'a que ça en fait.

Citation:

---

Envoyé par Laurent Gomila

Et si tu as des .lib précompilés, et bien utilise les : ajoute les aux options d'édition de liens.

---

Ben c'est là que le bas blesse: coment on fait ?

Citation:

---

Oui, j'ai compris ça, mais le problème est que je ne sait pas les utiliser

---

Ben tu inclues un en-tête lorsque tu en as besoin. C'est tout.

Citation:

---

Ben c'est là que le bas blesse: coment on fait ?

---

Tu devrais peut-être commencer par lire un tutoriel sur ton environnement de développement. Ce sont des manips de base que tu auras sans cesse à faire, autant bien comprendre à quoi elles correspondent et comment les réaliser.

heu oui... désolé.

j'ai suivi ça pour l'édition des liens :http://arb.developpez.com/vc++/express/
mais je n'ai pas compris commen on incluais les en tête: avec un #include ? par rapport à quel réprertoire ? ou bien peut-être en les important directement dans la solution...

Salut

Je suis l'auteur de cette bibliothèque.
Je te remercie de l'utiliser!

Puisque tu sembles utiliser VC Express, je te propose de télécharger à partir de mon site (ou de sourceforge) l'une des 2 versions disponibles avec la librairie précompilée pour Windows.

Tu trouveras plusieurs exemples n'utilisant que les fichiers headers (sample1), et des exemples utilisant exclusivement la librairie précompilée (sample2).
Quand on ne maitrise pas encore Visual Studio pour créer un nouveau projet, le plus simple consiste probablement à copier l'un de ces projets, et de modifier éventuellement quelque peu le paramétrage.

Sinon je reste à ta disposition pour tout problème...

Librairie précompilée:
-avantage: très rapide car compilée avec Intel C++ Compiler avec les meilleures options, probablement bien plus rapide qu'avec tout autre compilo
-inconvénient: seul l'interface C est utilisable. (faudrait peut-être que j'implémente des wrappers)
Si tu n'as pas besoin des fonctions contenues dans l'interface C, alors pas la peine de compiler la librairie.

PS:
Un peu de pub: Dans quelques semaines des algorithmes multi-processus seront disponibles pour tirer profit des processeurs à plusieurs noyaux:FFT...

Heu... la seule chose que j'ai remarqué est que les deux projets (sample 1 et 2) avaient intégré le projet génial, mais je n'ai pas compris la différence entre les deux (honte à moi) ni vu l'utilisation des librairies dans le deuxième...:(

(j'utilise genial-1.2.1-vc8-sse2.zip).

merci

Si ton processeur supporte le jeu d'instructions SSE3 (certains pentium 4, et nouveaux processeurs) tu peux aussi utiliser genial-1.2.1-vc8-sse3.zip.

Les projets sample1 et sample2 intègrent le projet principal uniquement par commodité: c'est plus pratique pour naviguer d'un fichier à l'autre. C'est pas vraiment utile pour les exemples.

Quand tu crées un projet, il faut dire au compilo où trouver les fichiers headers: Projet -> Properties -> Configuration Properties -> C/C++ -> general -> Additional Include Directories

Le projet sample2 est paramétré un peu différemment, puisqu'en plus il lie la librairie (en mode debug et release):
- fichier: Projet -> Properties -> Configuration Properties -> Linker -> Input: genial_icl_sse2.lib
-chemin d'accès: Projet -> Properties -> Configuration Properties -> Linker -> General -> Additional Library Dependencies: ../../lib

Merci beaucoup, ça marche!.

par contre, mes questions vont, je sent maintenant porter sur le librairie elle même (je viens de voir un journal d'erreur énorme pour seulement 9 erreurs....)

Rassure moi, ces erreurs ne viennent pas des projets d'exemples j'espère!

Les textes d'erreurs immenses sont dûs aux templates de templates de templates...
Il ne vaut mieux pas chercher à les comprendre dans le détail.

Généralement c'est signe que les paramètres templates passés en arguments sont incompatibles entre eux ou avec la bibliothèque.

Commence par un programme minimaliste.
Regarde le (petit) tutorial dans la doc, et les divers exemples présents un peu partout.

ben en fait, je sait pas trop d'où viennent les erreurs: les journaux sont ici:http://www.developpez.net/forums/sho...44#post2145644

J'avais pas remarqué que t'avais ouvert une nouvelle discussion.

Au sujet de l'erreur de compilation, Laurent Gomila a fait le bon diagnostic: pour initialiser un tableau directement dans le constructeur, le dernier paramètre doit être une chaine de caractère. C'est pas le constructeur le plus rapide qui soit, mais c'est très pratique pour initialiser des tableaux de petite dimension.
Par contre je ne suis pas sûr du tout que cela puisse lire des booléens (le constructeur est conçu pour initialiser avec des valeurs numériques). Ca dépend de la STL qui fournit un opérateur >> de conversion. Je ne sais pas si une telle conversion est disponible pour les booléens. A voir. Sinon rien n'empêche de surcharger l'opérateur.

Pour ce qui est des erreurs à l'édition de lien, je ne sais pas trop.
Est-ce que ça compile bien avec les projets sample1/sample2 ? (Sur mon ordi, ça compile bien.)
Un programme simple "Hello World", qui n'utilise pas la bibliothèque, fonctionne-t-il?

PS: Je viens de voir que le problème à l'édition de liens est corrigé. Bien.
Je suis content de voir que c'est pas un problème de ma bibliothèque ;-)

Citation:

---

Par contre je ne suis pas sûr du tout que cela puisse lire des booléens (le constructeur est conçu pour initialiser avec des valeurs numériques). Ca dépend de la STL qui fournit un opérateur >> de conversion. Je ne sais pas si une telle conversion est disponible pour les booléens. A voir. Sinon rien n'empêche de surcharger l'opérateur.

---

Il faut utiliser le manipulateur std::boolalpha sur le flux qui sert à extraire les données. Dans ce cas "true" et "false" peuvent être lus (ou écrits) en tant que booléen.

Citation:

---

Envoyé par Laurent Gomila

Il faut utiliser le manipulateur std::boolalpha sur le flux qui sert à extraire les données. Dans ce cas "true" et "false" peuvent être lus (ou écrits) en tant que booléen.

---

Je connaissais pas! c'était pas évident à connaître!


Au sujet des avertissements postés dans l'autre poste et pour lesquels Laurent écrit:

Code:

---

Ne t'en préoccupe pas : ils signifient simplement que la bibliothèque standard n'est pas "sûre" et qu'il vaudrait mieux utiliser les fonctions spécifiques de Microsoft. Pour désactiver ces avertissements il y a un symbole à définir dans les options du préprocesseur.

---

J'utilise les pragmas suivants (dans l'en-tête "genial_config.h") pour les désactiver. Je ne sais plus trop à quel avertissement correspondent chacun des nombres.

Code:

---

1 2 3 4 5 6

#if (defined(_MSC_VER) && !defined(__ICL)) #pragma warning(disable : 4200 4244 4521 4996 ) #ifndef NDEBUG #pragma warning(disable : 4799 ) #endif #endif

---

VC8 ose prétendre que certaines fonctions STL sont désuètes (deprecated)
Si quelqu'un sait comment satisfaire le compilo, je suis preneur...

En fait il suffit de définir un symbole du genre _CRT_SECURE_NO_DEPRECATE.

Sinon j'ai regardé un peu les avertissement que tu désactives, et j'ai quelques questions pour ma culture personnelle :
- Pour le 4244, il y a des cas où un static_cast ne suffit pas ?
- Pourquoi plusieurs constructeurs par copie ??
- Pourquoi ne pas utiliser l'instruction EMMS en debug ?

Merci pour le truc _CRT_SECURE_NO_DEPRECATE .J’ai pas regardé comment ça s’utilise. Le problème c’est que ça m’étonnerait que les autres compilos comprennent cette macro. Donc a priori je vais garder le pragma. En fait je crois que c’est dû un mécanisme de vérification de validité des itérateurs. Microsoft aurait quand même pu faire quelque chose de transparent.


J’utilise assez rarement VC2005 Express. Principalement pour des raisons historiques, les versions précédentes étaient bien trop incomplètes (principalement vis-à-vis des spécialisations de templates) et étaient bien incapables de compiler ma bibliothèque.

-C4244 ('argument' : conversion from 'type1' to 'type2', possible loss of data) : je me rappelle plus trop dans quelles circonstances j’ai vu ce warnings. Le fait est que ni GCC ni ICL n’en font état. Soit j’étais un peu paresseux ce jour là pour corriger à fond, soit j’ai considéré que VC2005 abusait. Je suis pas sûr non plus qu’un cast peu faire l’affaire car les types provenaient de templates, qui peut-être sous certaines circonstances ne s’accommoderaient pas d’un cast. Faudrait que je recompile pour vérifier.

-C4521 ('class' : multiple copy constructors specified): J’ai 2 ou trois classes avec des constructeurs templates un peu compliqués. Pour une raison que j’ignore (probablement manque de standard de la part de Microsoft, parce que ni GCC ni ICL n’y trouvaient à redire), VC2005 confondait les constructeurs de copie avec un constructeur template à un seul argument. A cause de VC2005 j’ai dû faire un mélange compliqué de divers constructeurs pour obtenir quelque chose qui compile avec les 3 compilos et éviter des « ifdefs ». Mais VC2005 donne encore un warning.

-C4799 (No EMMS at end of function 'function')
Je trouve cet avertissement pertinent, d’ailleurs ICL en a un équivalent. Le compilo signale qu’il n’a pas trouvé de reset à la fin d’une fonction utilisant des instructions MMX, ce qui peut potentiellement causer des problèmes avec les calculs flottants susceptible d’être fait à la suite. Le hic, c’est que j’utilise une fonction inlinée pour chaque instruction MMX (« intrasic » pour ne pas programmer en assembleur) et que je ne veux pas faire de reset (nécessite quelques cycles d’horloge) à chaque fois dans chacune de ces fonctions. Comme la compilation en mode débug n’inline pas les fonctions je me retrouvais avec trop d’avertissements inutiles.
Ceci dit, je n'utilise quasiment plus MMX, mais plutôt SSE2 à la place.

Citation:

---

Merci pour le truc _CRT_SECURE_NO_DEPRECATE .J’ai pas regardé comment ça s’utilise. Le problème c’est que ça m’étonnerait que les autres compilos comprennent cette macro. Donc a priori je vais garder le pragma. En fait je crois que c’est dû un mécanisme de vérification de validité des itérateurs. Microsoft aurait quand même pu faire quelque chose de transparent.

---

Ca ne coûte rien de la définir. En gros dans la STL de Visual C++ tu as ce genre de choses :

Code:

---

1 2 3

#ifndef _CRT_SECURE_NO_DEPRECATE // déclare la fonction deprecated #endif

---

Mais bon désactiver l'avertissement marche tout aussi bien.

Sinon merci pour les réponses ;)

Citation:

---

Envoyé par Charlemagne

Merci pour le truc _CRT_SECURE_NO_DEPRECATE .J’ai pas regardé comment ça s’utilise. Le problème c’est que ça m’étonnerait que les autres compilos comprennent cette macro. Donc a priori je vais garder le pragma.

---

Un compilo qui ne comprend pas un pragma donne typiquement un warning.
Ce n'est pas au compilo de comprendre la macro, mais aux headers, qui soit la comprennent, soit ne se rendent même pas compte qu'elle existe.
Préfère le define au pragma, car:

1. il est plus spécifique
2. Il stoppe le mal à sa source plutôt que de casser le thermomètre.

Citation:

---

-C4244 ('argument' : conversion from 'type1' to 'type2', possible loss of data) : je me rappelle plus trop dans quelles circonstances j’ai vu ce warnings. Le fait est que ni GCC ni ICL n’en font état. Soit j’étais un peu paresseux ce jour là pour corriger à fond, soit j’ai considéré que VC2005 abusait. Je suis pas sûr non plus qu’un cast peu faire l’affaire car les types provenaient de templates, qui peut-être sous certaines circonstances ne s’accommoderaient pas d’un cast. Faudrait que je recompile pour vérifier.

---

Warnings de portabilité 64 bits, te préviennent quand tu convertis un size_t en int, par exemple. Tu peux les désactiver en retirant l'option /Wp64 dans les propriétés du projet (beaucoup plus propre qu'un pragma).