Discussion :

[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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 ?

[Bousk]

Salut,

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

Si par contre tu lies les lib en dynamique, je pense pas que ça fonctionne.

[simon884]

Salut,

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

[koala01]

Salut,

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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++

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

[dragonjoker59]

Salut,

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

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

???

[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++

[simon884]

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

[Bousk]

Salut,

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

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

[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.

[simon884]

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.

[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.

[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

[simon884]

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.

[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.

[simon884]

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?

[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.

[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.

[koala01]

@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