Discussion :

[L'elfe d'Azur]

Bonjour,

j'ai une erreur etrange lors que je compile un projet qui fonctionnait bien jusqu'a ce que je passe de fedora 10 a 14 (64bits).

In file included from .../DeviceCore_i.cpp:10:0:
.../Sensor_i.h:40:24: error: conflicting return type specified for ‘virtual long unsigned int odin::Sensor_i::validityPeriod()’
.../com/stubs/odin_if.h:837:26: error: overriding ‘virtual CORBA::ULong _impl_Sensor::validityPeriod()’

Pourtant lorsque je vais regarder dans ma bibliotheque Omniorb4/CORBA, je trouve quelque chose comme

Code :

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

1
2
 
typdef long unsigned int ULong

donc on a bien la meme definition mais il n'arrive plus a faire le parallele entre le typedef et son type d'orgine

Une idee de la cause?

Merci,
Melaine

[r0d]

Bonjour,

le problème n'est pas un "typedef non reconnu" mais un conflit sur le typedef. Ce qui signifie que ton type est défini plusieurs fois et de façon différente.

En revanche, je ne comprend pas bien quel est le type incrimininé. Est-ce ULONG? ULong?
Ce que je ne comprend pas non plus c'est que si ce type est défini et utilisé dans une portée nommée et définie (namespace CORBA), il devrait pas y avoir de conflit. J'en conclus donc que "la vérité est ailleurs".

[L'elfe d'Azur]

Desole, j'ai fait une erreur en ecrivant ma question.

le type incrimine est bien ULong
Avec un grep, je trouve dans la bibliotheque OmniORB4:

./include/omniORB4/CORBA_basetypes.h:typedef unsigned long _CORBA_ULong;
./include/omniORB4/CORBA_primitive_types.h:typedef _CORBA_ULong ULong;

Ce que je ne comprend pas non plus c'est que si ce type est défini et utilisé dans une portée nommée et définie (namespace CORBA), il devrait pas y avoir de conflit. J'en conclus donc que "la vérité est ailleurs".

Ben moi non plus. Surtout que sur une machine Ubuntu que j'ai aussi a ma disposition tout compile sans soucis et qu'avant je compilais tres bien en fedora 10.

[r0d]

Dans ton message d'erreur, il semble que la ligne de code qui pose problème est une fonction qui renvoie un long unsigned int, alors que que CORBA::ULong est un unsigned long. Peut-être est-ce une piste.

Le fait que ça ne compile plus sur la nouvelle version de Fedora s'explique par le fait que d'une version à l'autre les bibliothèques changent. Surtout si tu passes à du 64bit. C'est (malheureusement) assez fréquent, et pas seulement en c++ pour le coup (même si le c++ est particulièrement touché par ce mal).

[r0d]

En fait il faudrait que tu nous donnes plus de précisions.
Quel est ton environnement de dev (IDE/editeur/compilateur)?
Plus de précisions sur l'erreur: la ligne incriminée, le message d'erreur exact, si c'est une fonction polymorphe, quelles sont ses autres signatures, etc.
Vérifie que ULong ne soit pas défini de façon différente dans d'autres parties du programme et surtout dans ses dépendances (bien que je ne pense pas, à première vue, que l'erreur vienne de là).

[3DArchi]

Dans ton message d'erreur, il semble que la ligne de code qui pose problème est une fonction qui renvoie un long unsigned int, alors que que CORBA::ULong est un unsigned long. Peut-être est-ce une piste.

long unsigned int et unsigned long, c'est pareil. En revanche, unsigned long et unsigned int c'est différent et provoque l'erreur de compil de la fonction virtuelle que l'on soit en 32 bits, 64 bits, 16 bits, etc.
norme ISO/IEC 14882:2003 7.1.5.2 Simple type specifiers, table 7
draft C++0X N3126 : 7.1.6.2 Simple type specifiers, table 9

[L'elfe d'Azur]

C'est bon j'ai trouve pourquoi j'ai un probleme :

extrait du fichier .../omniORB4/CORBA_basetypes.h

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
#if SIZEOF_LONG == 4
typedef long                      _CORBA_Long;
 
typedef unsigned long             _CORBA_ULong;
 
#elif SIZEOF_INT == 4
#  ifndef OMNI_LONG_IS_INT
#    define OMNI_LONG_IS_INT
#  endif
 
typedef int                       _CORBA_Long;
 
typedef unsigned int              _CORBA_ULong;

Ainsi, avant j'avais un systeme 32bits sur une machine 64 bits et donc sizeof(long)=sizeof(int) = 4

Maintenant que je suis passe sur un system 64bits sizeof(long) = 8 et sizeof(int)=4.
Et comme corba definit ULong tel que izeof(ULong)=4 ...

Il faut que je revois l'ensemble du projet et corrige tout ca. Ho joie du programmeur

Merci de ton aide, je n'avais pas fait attention aux differentes declaration et j'avais survolle mon grep un peu trop vite.

[3DArchi]

Si tu as un compilateur assez récent, utilises <cstdint> et son cortège de uintN_t (N=8,16,32,64)

Ceci dit, si tu as mélangé des CORBA_[U]LONG et des unsigned long int, t'es plutôt mal. Car comme je l'ai dit [unsigned] long et [unsigned] int sont 2 types différents même s'ils sont sur le même nombre de bits.

[L'elfe d'Azur]

J'ai repris un projet donc je decouvre petit a petit le code et effectivement ils ont melange des CORBA::Long et des long ou des CORBA::ULong et des unsigned long.

Je pense que je vais remplacer les long par des CORBA::Long
en esperant que ce soit la derniere surprise que je decouvre.

Merci

[r0d]

Juste un conseil d'ordre général: attention lorsque tu modifies du code écrit par un autre. En général, ce qui a été écrit l'a été pour une raison. Et comme il est difficile de connaître un programme que l'on n'a pas écris, on peut passer à côté de ces raisons et générer des erreurs à d'autres endroits.

Et surtout si le programme que tu es en train de modifier fonctionnait bien avant, cela signifie que normalement, chaque bout de code qui le compose a son rôle à jouer.

Il ne faut pas tomber dans le piège du "ha, les mecs qui ont programmé ça étaient nul, moi je suis bien meilleur je vais remettre de l'ordre là-dedans". Chacun a sa façon de programmer, et souvent on est obligé de faire des trucs pas terrible pour que notre programme fonctionne en temps voulu. Ce que j'essaie de dire, c'est que parfois tu vas tomber sur du code qui va te paraître horrible, voire faux, mais fais bien attention avant de le modifier, car une ligne de code n'est jamais sans effet, et donc une ligne de code sert toujours à quelque chose.

Bon, à part bien sûr les rarissimes exemple que l'on trouve dans les bêtisiers de développeurs.