Erreur compilation conflit déclaration

Version imprimable

Bonjour à tous,

J'ai un petit problème de compilation sur une re définition de structure. Je suis actuellement entrain de faire un petit programme qui utilise tesseract, jusque là pas de problème, j'ai maintenant besoin d’utiliser l'API MySQL, et là lorsque j'inclus mysql.h ainsi que baseapi.h pour tesseract au moment de la compilation j’obtiens cette erreur :
Code:

1 2 3 4 5 In file included from /usr/include/mysql/mysql.h:75:0, from ocr.cpp:4: /usr/include/mysql/my_list.h:26:3: error: conflicting declaration ‘typedef struct st_list LIST’ In file included from ocr.cpp:2:0: /usr/include/tesseract/baseapi.h:58:19: error: ‘LIST’ has a previous declaration as ‘typedef struct list_rec* LIST’
Le problème est donc que dans mes 2 fichier h dispose d'une structure semblable, alors ma question est, comment résoudre ce problème est-il possible de faire une namespace dans mon main pour une des 2 structure ?

15/12/2015, 15h01
Bousk
Salut,

pas de chance pour toi :aie:
En général un workaround est de mettre ton include dans un namespace
Code:

1 2 3 namespace MYSQL { #include <mysql.h> }
Si par contre tu lies les lib en dynamique, je pense pas que ça fonctionne.
15/12/2015, 15h03
simon884
Citation:
Envoyé par Bousk

Salut,

pas de chance pour toi :aie:
En général un workaround est de mettre ton include dans un namespace

Code:

1 2 3 namespace MYSQL { #include <mysql.h> }

Si par contre tu lies les lib en dynamique, je pense pas que ça fonctionne.
Ah parfait un grand merci à toi, je n'avais jamais rencontré ce problème et je n'ai aps non plus des années de ++ derrière moi ::D:D

Salut,
Citation:
Envoyé par simon884
Bonjour à tous,

J'ai un petit problème de compilation sur une re définition de structure. Je suis actuellement entrain de faire un petit programme qui utilise tesseract, jusque là pas de problème, j'ai maintenant besoin d’utiliser l'API MySQL, et là lorsque j'inclus mysql.h ainsi que baseapi.h pour tesseract au moment de la compilation j’obtiens cette erreur :
Code:

1 2 3 4 5 In file included from /usr/include/mysql/mysql.h:75:0, from ocr.cpp:4: /usr/include/mysql/my_list.h:26:3: error: conflicting declaration ‘typedef struct st_list LIST’ In file included from ocr.cpp:2:0: /usr/include/tesseract/baseapi.h:58:19: error: ‘LIST’ has a previous declaration as ‘typedef struct list_rec* LIST’
Le problème est donc que dans mes 2 fichier h dispose d'une structure semblable, alors ma question est, comment résoudre ce problème est-il possible de faire une namespace dans mon main pour une des 2 structure ?
Pourquoi t'obstine tu à coder "comme en C" alors que tu viens poser tes question dans la section C++ :question:

De deux choses l'une : ou bien, tu code en C++, et, dans ce cas, il serait plus qu'intéressant de perdre tes habitudes issues du C pour prendre les (bonnes) habitude propres au C++, soit tu t'es trompé de section, mais, dans ce cas, sans voir ton code, il nous est impossible de savoir si tu n'essayes pas d'inclure des notions de C++ qui seront refusées en C.

En l'état, il est impossible de faire "la part des choses", mais il me semble plus qu'important que tu fasses un choix rapide du langage que tu compte utiliser ;)

16/12/2015, 01h34
dragonjoker59

Citation:

Envoyé par koala01

Salut,

Pourquoi t'obstine tu à coder "comme en C" alors que tu viens poser tes question dans la section C++ :question:

De deux choses l'une : ou bien, tu code en C++, et, dans ce cas, il serait plus qu'intéressant de perdre tes habitudes issues du C pour prendre les (bonnes) habitude propres au C++, soit tu t'es trompé de section, mais, dans ce cas, sans voir ton code, il nous est impossible de savoir si tu n'essayes pas d'inclure des notions de C++ qui seront refusées en C.

En l'état, il est impossible de faire "la part des choses", mais il me semble plus qu'important que tu fasses un choix rapide du langage que tu compte utiliser ;)

???
16/12/2015, 01h52
koala01

Citation:

Envoyé par dragonjoker59

???

Déjà rien que le fait de voir un typedef struct st_list LIST dans un code C++, moi, ca m’horripile!!

C'est -- peut-être -- un alias de type qui te viens d'un fichier d'en-tête de la biblitohèque que tu utilises, mais, si ca vient de ton code perso, il est largement temps de revoir les bases du C++ ;)
16/12/2015, 09h32
simon884

Citation:

Envoyé par koala01

Déjà rien que le fait de voir un typedef struct st_list LIST dans un code C++, moi, ca m’horripile!!

C'est -- peut-être -- un alias de type qui te viens d'un fichier d'en-tête de la biblitohèque que tu utilises, mais, si ca vient de ton code perso, il est largement temps de revoir les bases du C++ ;)

Ce n'est pas du code perso, mais un fichier d'en-tête de bibliothèque :)
16/12/2015, 10h07
Bousk

Citation:

Envoyé par koala01

Salut,

Pourquoi t'obstine tu à coder "comme en C" alors que tu viens poser tes question dans la section C++ :question:

De deux choses l'une : ou bien, tu code en C++, et, dans ce cas, il serait plus qu'intéressant de perdre tes habitudes issues du C pour prendre les (bonnes) habitude propres au C++, soit tu t'es trompé de section, mais, dans ce cas, sans voir ton code, il nous est impossible de savoir si tu n'essayes pas d'inclure des notions de C++ qui seront refusées en C.

En l'état, il est impossible de faire "la part des choses", mais il me semble plus qu'important que tu fasses un choix rapide du langage que tu compte utiliser ;)

Euh sauf que les conflits et codes C sont "juste" la lib mysql et tesseract :roll:
16/12/2015, 10h51
ternel

Teseract, c'est aussi de la base de données?
Parce que sinon, tu as tout intérêt à créer une classe intermédiaire, représentant la donnée pour ton programme.
Ainsi, tu pourrais répartir l'usage des deux bibliothèques dans deux (ou plus) unités de compilation distinctes.
17/12/2015, 09h46
simon884

Citation:

Envoyé par leternel

Teseract, c'est aussi de la base de données?
Parce que sinon, tu as tout intérêt à créer une classe intermédiaire, représentant la donnée pour ton programme.
Ainsi, tu pourrais répartir l'usage des deux bibliothèques dans deux (ou plus) unités de compilation distinctes.

Non non ce n'est pas de la base de donnée, c'est de la reconnaissance de caractères.

Par contre ta technique de classe intermèdiaire m'intéresse, je veut bien en savoir un peu plus, au cas où je suis confronter à ce problème un jour.
17/12/2015, 11h29
ternel

Si tu encapsule complètement la bibliothèque, en anglais, ca s'appelle un wrapper. Mais ca n'est pas vraiment le besoin ici.

Si la donnée de ton problème est un texte, ce n'est pas un texte-de-tesseract, ni un texte-de-sql, mais un texte.
Tu n'auras que des fonctions dédiées
Ainsi, pour extraire un texte d'une image, tu auras peut-être extraire(image const&, texte&) ou texte extraire_texte(image const&), qui sera la seule à avoir besoin de texte-de-tesseract. Du coup, en la codant dans un fichier à part, seul ce fichier utilisera tesseract.

Et de même pour l'interaction vers sql.

C'est la distinction entre code technique et code métier.
Le problème que gère ton programme doit se coder en code métier.
17/12/2015, 16h15
koala01

Ceci dit, si tu en arrives à un point où tu commence à mélanger le besoin d'accéder à une base de donnée et celui de profiter de la reconnaissance de caractères, je me dis qu'il y a peut être un problème de conception, et que tu devrais pouvoir t'arranger pour éviter ce mélange.

Je m'explique : la reconnaissance de caractères et l'accès (sous la forme de requêtes SELECT s'entend) peuvent tous les deux être considérés comme faisant partie de ce que l'on pourrait appeler "l'acquisition de données", mais, la manière dont tu les acquiéreras sera totalement différente : évaluation de champs d'une part contre évaluation des pixels d'une image de l'autre. Et, même si tu récupères l'image grâce à une requête SQL, tu dois, d'abord et avant tout, travailler sur une image, et non sur un champs de base de donnée.

Tu as donc "tout loisir" de créer une séparation bien claire entre ce qui a trait à ta base de données et ce qui a trait à la reconnaissance de caractères, et c'est vers cela que tu devrais tendre ;)
18/12/2015, 09h37
simon884

Citation:

Envoyé par koala01

Ceci dit, si tu en arrives à un point où tu commence à mélanger le besoin d'accéder à une base de donnée et celui de profiter de la reconnaissance de caractères, je me dis qu'il y a peut être un problème de conception, et que tu devrais pouvoir t'arranger pour éviter ce mélange.

Je m'explique : la reconnaissance de caractères et l'accès (sous la forme de requêtes SELECT s'entend) peuvent tous les deux être considérés comme faisant partie de ce que l'on pourrait appeler "l'acquisition de données", mais, la manière dont tu les acquiéreras sera totalement différente : évaluation de champs d'une part contre évaluation des pixels d'une image de l'autre. Et, même si tu récupères l'image grâce à une requête SQL, tu dois, d'abord et avant tout, travailler sur une image, et non sur un champs de base de donnée.

Tu as donc "tout loisir" de créer une séparation bien claire entre ce qui a trait à ta base de données et ce qui a trait à la reconnaissance de caractères, et c'est vers cela que tu devrais tendre ;)

Non non je ne mélange rien, en faite la reconnaissance de caractères s'effectue sur une image du type png en utilisant limagick++ et ensuite une fois la reconnaissance effectué je sauvegarde les mots trouvés en base de données tout simplement, la librairie MYSQL me sert seulement à faire un INSERT.
18/12/2015, 09h53
Bousk

C'est justement là que tu mélanges tout.
Tu as un unique truc qui fait lecture de l'image, extraction de la chaîne, enregistrement dans la DB.
Là où tu pourrais/devrais avoir un truc pour la lecture de l'image, image que tu passes ensuite à un truc pour extraire la chaîne, chaîne que tu passes ensuite à un dernier truc (tous sont différents hein) qui fait l'enregistrement dans la DB.
Et que tu lises l'image sur le disque, le web, en raw, ... du png, jpg, psd, ... n'influe en rien sur le code de lecture de la chaîne qui s'y trouve.
L'extraction de la chaîne se moque de savoir l'origine de l'image, elle n'en connait que son format dans l'application et te sort une chaîne.
Et l'enregistrement dans la DB est totalement indépendant du reste, tu pourrais enregistrer des chaînes sorties d'un fichier texte, entrées par l'utilisateur ou peu importe.

Que tu utilises tesseract pour le point 2, mysql pour le point 3 ou n'importe quoi qui le permette, ils ne peuvent/doivent absolument jamais entrer en conflit.
18/12/2015, 10h13
simon884

Citation:

Envoyé par Bousk

C'est justement là que tu mélanges tout.
Tu as un unique truc qui fait lecture de l'image, extraction de la chaîne, enregistrement dans la DB.
Là où tu pourrais/devrais avoir un truc pour la lecture de l'image, image que tu passes ensuite à un truc pour extraire la chaîne, chaîne que tu passes ensuite à un dernier truc (tous sont différents hein) qui fait l'enregistrement dans la DB.
Et que tu lises l'image sur le disque, le web, en raw, ... du png, jpg, psd, ... n'influe en rien sur le code de lecture de la chaîne qui s'y trouve.
L'extraction de la chaîne se moque de savoir l'origine de l'image, elle n'en connait que son format dans l'application et te sort une chaîne.
Et l'enregistrement dans la DB est totalement indépendant du reste, tu pourrais enregistrer des chaînes sorties d'un fichier texte, entrées par l'utilisateur ou peu importe.

Que tu utilises tesseract pour le point 2, mysql pour le point 3 ou n'importe quoi qui le permette, ils ne peuvent/doivent absolument jamais entrer en conflit.

Ok je vois, mais je vous cache pas que j'ai un peu de mal a comprendre comment éviter ce conflit, sachant que le conflit que j'ai eu venait des includes de mes 2 librairies, donc d'après vous je devrais si j'ai bien compris ré écrire la ou les les fonctions dont j'ai besoin?
18/12/2015, 10h28
ternel

Relis mon précédent message.

Il suffit que les deux fonctions extraire et sauvegarder soient définies dans deux .cpp différents. Chacun n'a besoin que d'un seul des includes.
18/12/2015, 12h14
dragonjoker59

@Bousk et @Koala, vous allez pas un peu vite? Il n'a montré qu'une erreur et vous partez bille en tête en disant qu'il mélange tout.

Ou alors vous souhaiteriez qu'il écrive une lib pour chaque fonctionnalité (une lib d'OCR, une lib d'insertion en BDD) ?
Il est possible que je ferais comme cela, mais on ne connait rien de ses contraintes, ni de son code.
18/12/2015, 14h44
koala01
Citation:

Envoyé par dragonjoker59

@Bousk et @Koala, vous allez pas un peu vite? Il n'a montré qu'une erreur et vous partez bille en tête en disant qu'il mélange tout.

Ou alors vous souhaiteriez qu'il écrive une lib pour chaque fonctionnalité (une lib d'OCR, une lib d'insertion en BDD) ?
Il est possible que je ferais comme cela, mais on ne connait rien de ses contraintes, ni de son code.

Non, nous n'allons absolument pas trop vite!

Il a été clairement défini que le problème vient du fait que, quelque part dans son code, deux fichiers inclus entrent en conflit et que ces fichiers font partie d'une bibliothèque de reconnaissance de caractères pour l'un et d'une bibliothèque d'accès à une base de données pour l'autre.

Ceci étant établi, il est facile de déterminer que le PO doit travailler selon un ordre bien précis qui est :
1. le chargement d'une image (quelle qu'en soit le format / l'origine)
2. le traitement d'image pour en récupérer les caractères qui s'y trouvent
3. la génération de chaines de caractères composés des caractères que l'on vient d'extraire
4. la sauvegarde de ces chaines de caractères dans une base de données.
le seul point commun entre le (1) et le (2), c'est que l'on travaille sur des image. Tu dois donc avoir une abstraction qui te permette de représenter cette image
le seul point commun entre le (2) et le (3), c'est que l'on travaille avec des caractères, qui n'ont absolument rien à voir avec la notion d'image et qui se foutent pas mal d'avoir été calculés au travers d'une bibliothèque prévue pour
le seul point commun entre le (3) et le (4), c'est la notion de chaine de caractères.

Dés lors, il semble évident que ces quatre point doivent pouvoir travailler de manière totalement autonome, d'autant plus que le PO nous indique qu'il est justement confronté à un problème lorsque ce n'est pas le cas et que, au final, la sauvegarde dans la base de données se fout pas mal de savoir l'origine des chaines de caractères qu'elle doit sauvegarder

Où donc vois tu que nous allions "un peu vite" en besogne :question: