Discussion :

[camboui]

Bonjour,
J'ai une appli qui m'affiche "runtime error" en debug avant même d'entrer dans main().
En release elle va à peine plus loin et se plante aussi.
Je me demande bien pourquoi ???
Je pensais à un objet/variable static, mais je ne vois pas où/lequel.

J'ai effacé les répertoires debug et release, rebooté la machine, rien n'y fait.
Merci de m'aider s'il vous plait

compilo: VS2005

[camboui]

Bon, ben j'ai trouvé.
J'ai du code hérité de VC++6 qui contient des couillonades comme celles-ci

Code :

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

1
2
3
4
5
6
7
8
9
// this seems to work: hope it always work!!!
#	pragma data_seg(".CRT$XID")
static _PVFV pXI_D=InitStuff;
#	pragma data_seg()
 
// this seems to work: hope it always work!!!
#	pragma data_seg(".CRT$XTW")
static _PVFV pXT_W=DoneStuff;
#	pragma data_seg()

Ça fonctionnait toujours très jusqu'à ma dernière compil qui date du 13 octobre. Et puis aujourd'hui, bardaf.
Il semble qu'il y ait eut un KB (critical update) pour VS2005 récemment, je suppose que c'est à cause de ça.

En tout cas ça ne m'arrange pas.
Donc question: comment exécuter du code avant l'entrée dans main() sous VS2005 ?

[bacelar]

Généralement, le plus simple est de créer des objets globaux.
Leur constructeur est appelé avant le main.
Les membres statics de classe aussi, je crois.

[camboui]

Oui, en effet.
Ce que j'ai appelé "les couillonades" c'est justement du code qui doit être exécuter avant les objets globaux/statiques. Le problème de ces derniers c'est qu'on ne sait pas dans quel ordre ils sont créés, et pour peu qu'il y ait des interdépendances...
Cette pratique n'est pas propre, bien sûr, mais c'est du vieux code qui ne demande qu'à être porté. Ce qui va prendre un peu de temps.

[Mac LAK]

L'ordre d'initialisation au sein du même fichier ne change pas (jamais testé, mais ça doit être l'ordre de déclaration à priori).

Quitte à faire goret, mets tout le code de ce genre dans le même fichier, dans le "bon" ordre de dépendance, et jette le code dans une oubliette avec un tag "A refondre proprement".

[camboui]

Ce vieux code est un genre de CString qui utilise son propre allocateur de mémoire. Il a été écrit à l'époque sous Borland 3.5 (16 et 32 bits) puis porté sous VS6 (puis resté en l'état). Cet allocateur est initialisé avant toute chose mais une option de compilation permet d'utiliser les malloc/new classiques. J'ai donc simplement désactivé l'allocateur.

Il est clair que cette classe CString n'est plus à utiliser, mais il reste des bouts de code ça et là. Le plus coriace étant un wrapper C++ autour de l'API ODBC qui utilise ce CString.

Merci.