Salut,

D'avance désolé, mais voici quelques remarques après rapidement avoir parcouru le code :

* utilisation du français dans des noms des fonctions et macros
* aucune cohérence dans les convention de nommages
* utilisation de macro pédagogiques fantaisistes
* nombreuses allocations dynamiques superflues
* aucune vérification sur les tailles des tampons
* aucune vérification sur les pointeurs externes
* aucune vérification sur les pointeurs internes
* aucune vérification sur allocations mémoires
* utilisation de variable globales qui rends le code inutilisable en multitâche
* code totalement non thread safe
* code parfois bien compliqué pour de simple taches
* etc...

=> résultat : quelque soit l'utilité de cette librairie, elle est tout simplement inutilisable...

la seule chose que je dis c'est :
- un realloc par caractère lu d'un fichier ne sert à rien. Un seul malloc avec la taille du fichier suffit
- utiliser un buffer alloué dynamiquement ne sert à rien. La lecture directe du fichier avec mis à jour de la table des occurrences suffit.
Donc, pourquoi se compliquer la vie en utilisant un buffer, qui plus est, réalloué X fois inutilement ?

primo, la taille exacte du fichier peut être obtenue par un ftell des l'ouverture du fichier, ce qu permet de ne faire qu'un seul malloc au total. Dans ton code, si ton fichier fait 1Mo, tu fais 1 million de realloc. Ca sert a rien et il n'y a rien de plus inefficace...
Enfin, tu n'a pas besoin d'allouer un buffer pour stocker le contenu du fichier.

salut,

tu lis ton fichier caractère par caractère et à fois chaque tu réalloues ton buffer !!

Grosses perte de temps et de mémoire inutile !

Faut revoir tout ca...

nope, pas que les cin/cout....
rien d'autre te choques, c'est que tu dois pas souvent coder en C.

lol, il faut modifier tout le code pour que ca puisse compiler en C...

Ce n'est pas un code "C" mais un pur code C++..

Hum, nne dernière remarque pour la route !

tu dis "en effet il faut compiler en C. "...

Dans ce cas, fournis un svcmanager.c et non par un svcmanager.cpp

Faut rester cohérent *.c => c, *.cpp =>c++

Aller, j'vais prendre mes pillules !!

A+

suite du précédent....

"...fait que fournir un pointeur dans les choux à HeapFree() c'est pas "pas grave" mais dangeureux... Toujour être sur qu'un pointeur a été initialisé dans le code avant d'appeler une fonction de libération".

Cela dit, c'est mon VS2005 qui me l'a signalé car ayant survolé le code, je ne l'avais vu...

Donc, un conseil (surtout quant tu diffuses du code), compile un coup avant avec un niveau de warning 3 ou 4. Cela permet de détecter des choses que l'on n'a pas vu ...

Bon courage.

Je ne m'emballe pas ! je dis seulement qu'il est mieux d'avoir un code propre. C'est tout.

Par contre, c'est quoi ton éditeur ?

Car tu fournis un projet VS et j'utise les outils MS depuis VC5 (donc VC5, VC6, VC2003 et VS2005) et ils m'ont toujours mis les infos bulles sur les versions "génériques" des api Windows.

Tu as quelle version de VS ? car pour moi (VS professional complet), il était impossible de compiler ton code originel !

enfin, je t'ai pas dis qu'il faut uploader toute les 5 minutes, je fais seulement des remarques pour améliorer ton code.... T'es pas obligé de le corrgier dnas la minute ! C'est dimanche, tout de même !


Pour le tetu, c'était seulement pour le

>> Pour szPrePath, aucun soucis je n'utilise que les 4 premiers octets...

Pour toi peut être, sauf que tout le monde ne pourra pas compiler ton code sans avoir à le modifier. Ors tu postes une source pour la partager ! C'est peut être bon pour toi mais primo l'initialisation de szPrePath est fausse, et ensuite y a en certains qui quand ils recupèrent une source et que cela ne compile pas, ils jettent la source à la poubelle. Ma fois c'est toi qui voit !

>> Pour la var buff non initialisee, c'est un ptit oubli, mais y a quand meme extremement peu de chance pour que ca cause un bug, car HeapAlloc reverra une valeur de retour dans tous les cas.

Tétu le monsieur ! Si RegQueryValueExA() à la ligne 498 retourne 0 (on sen sait jamais),
HeapAlloc() n'est donc pas appelé et donc HeapFree() se retoruve avec un buff avec un valeur indéfinie. 99 % de plantage assuré dans ce cas

Sinon, je te déconseille d'explicitement utiliser les fonctions Win32 directement dans leur version xxxA() ou xxxW() mais la forme xxx() car ton code en sera plus générique.
De plus, il sera compilable en ANSI/Unicode si tu utilise des TCHAR au lieu des char par exemple...