1

J'ai un assez grand et complexe ensemble de programmes à mettre en communication de VC8 à VC9. Un des modules a un certain nombre de typedefs en couches, ce qui oblige le compilateur à générer un avertissement C4503 (nom décoré tronqué). Le fichier LIB généré ne sera pas correctement lié aux autres modules du projet. VC8 n'a eu aucun problème avec cela, ce qui m'a amené à conclure que le processus de décoration a changé pour générer des noms encore plus longs, ou que la limite interne pour la longueur d'un nom décoré a diminué. Quel est le meilleur moyen de surmonter cela?Comment augmenter la longueur autorisée du nom décoré dans VC9 (MSVC 2008)?

Pour des raisons de code héritées, la suggestion MSDN de remplacer typedefs par des structures n'est pas pratique.

Les typedefs en question sont (code aseptisé):

enum Type{ 
    TYPE_COUNT, 
    TYPE_VALUE 
}; 

typedef MyVector< Container*, CriticalSectionLock > Containers; 
typedef MyVector< MyClassType*, CriticalSectionLock >::const_iterator const_iterator_type; 
typedef MyVector< stl::pair< string, Type > >::const_iterator const_iterator_def; 
typedef MyVector< Container** >::const_iterator const_iterator_container; 
typedef MyVector< stl::pair < MyBase*, MyVector< stl::pair< Container**, Containers* > > > >::const_iterator const_iterator; 
+0

Content que je ne travaille pas sur ce code. – Kibbee

+0

Si le nom décoré tronqué est tronqué de la même manière lors de la construction de la bibliothèque que lors de la construction du module lié à la bibliothèque, ne continuerait-il pas à lier correctement même en présence de cet avertissement? Ou avez-vous plusieurs symboles qui ne diffèrent qu'après le point de troncature? – GBegen

Répondre

2

Comme il ne semble pas être un moyen d'augmenter la limitation interne du compilateur sur la longueur du nom décoré, je peu la balle et fait le changement suggéré dans le MSDN. voir: http://msdn.microsoft.com/en-us/library/074af4b6.aspx

J'ai seulement dû changer le premier typedef en struct. Cela a nécessité environ 200 autres changements dans le code existant, ce qui était fastidieux, mais pas difficile. Cependant, je passerai la semaine prochaine à faire des tests de régression pour m'assurer que cela ne dérange pas quelque chose.

Voici le changement de base: (note que j'ai été forcé d'ajouter quelques cteurs à la struct)

enum Type{ 
    TYPE_COUNT, 
    TYPE_VALUE 
}; 

struct Containers 
{ 
    MyVector<Container*, CriticalSectionLock > Element; 
    Containers(int num, Container* elem):Element(num, elem){} 
    Containers(){} 
}; 
typedef MyVector< MyClassType*, CriticalSectionLock >::const_iterator const_iterator_type; 
typedef MyVector< stl::pair< string, Type > >::const_iterator const_iterator_def; 
typedef MyVector< Container** >::const_iterator const_iterator_container; 
typedef MyVector< stl::pair < MyBase*, MyVector< stl::pair< Container**, Containers* > > > >::const_iterator const_iterator; 
+0

Si vous placez un opérateur() ou quelque chose sur votre structure, cela aurait-il fonctionné plus en l'état avec moins de changements de code? –

0
#pragma warning(disable:xxx). 

homme trop courte vie.

+0

Malheureusement, il a également échoué à lier en raison de cet avertissement. Autre que cela: d'accord. –

0

@Roel: Comme je l'ai mentionné dans la publication originale: "Le fichier LIB généré ne sera pas correctement lié à d'autres modules dans le projet."

IOW, c'est plus qu'un simple «avertissement». Cela provoque le projet de ne pas fonctionner.

Mon correctif affiché est quelque peu difficile et fastidieux à implémenter complètement, mais cela fonctionne.

Questions connexes