_CRT_SECURE_NO_DEPRECATE ou changer le nom des fonctions(deprecated)?

Bonjour à tous,

Je suis en train de porter des projets de Visual 6.0 a 2005 et je me demandai quel etait la meilleure solution?
D'apres le tuto de Farscape sur le portage et la msdn quand on a des fonctions "deprecated", on peut:
- soit renommer les fonctions dans le code(en general rajouter un '_'),
- ou bien ajouter _CRT_SECURE_NO_DEPRECATE dans les variables de precompilaition.

J'ai tester les deux et ca marche mais je sais pas quel est le mieux?
Apparement le fait de rajouter _CRT_SECURE_NO_DEPRECATE supprime juste les warning de l'output, pas de modification(pas grand chose quoi).
Alors vaut-il mieux modifier ou pas mes projets(remplacer directement les fonctions).

A la longue, qu'est-ce qu'il vaut mieux faire?

Merci

salut, Le choix est à mettre en balance avec le coté technique et financier de l’opération :
Le choix se résume donc à effectuer :

• Le changement de fonctions ce qui implique : une charge de travail supplémentaire lié aux changements plus les tests à refaire derrière, pour un gain de sécurité du code accrut. ou une grosse boulette derriere ... car cette opération n'est pas sans risque.:roll:
• Et simplement assurer le portage.( les eventuels bugs sont aussi portés :aie:)

Le tout est donc à mettre en rapport avec le temps et le coût de l’opération….
Si tu as du temps et que ce n’est pas pressé, donc pas de contrainte budgétaire : Adopte les nouvelles fonctions.
Si le budget est serré, le temps est mesuré, alors assure la comptabilité : Portage simple.

De mon expérience si le coté commercial/financier rentre en jeux le portage simple est souvent gagnant, et ce en dépit des arguments techniques..
:D

Argent,argent:lol:

Mais sinon oui tu as raison ca me prendrait trop de temps de tout changer.
Finalement je vais ecouter ton experience et appliquer la methode simple quitte a devoir modifier plus tard.
De toute facon c'est pas la methode simple qui va me prendre le plus de temps ou alors:aie:

Merci Farscape
A+

J'ajoute un facteur à prendre en compte: La portabillité: Les fonctions "secure" de la CRT 8 ne sont disponibles que pour Windows et remplacent des fonctions standard, ton programme sera donc Windows-only.

Et même en se cantonant à Windows, je ne sais pas si MinGW sait utilsier la CRT 8.0 (qui contient ces fonctions "secure").

De plus, certaines des fonctions "secure" relèvent soit d'une débilité profonde, soit d'un acte délibéré de non-conformance au standard: Je pense notamment à fopen_s() et tmpfile_s() (sans compter qu'ils auraient pu donner à strtok_s() le nom standard strtok_r...).

Et d'un autre coté, ils ne nous donnent pas les fonctions dont on a vraiment besoin, comme le vrai snprintf() standard du C99 qui accepte un buffer NULL et retourne la bonne taille...:roll:

D'accord, merci pour les details mais moi il y a un truc que je comprend pas!

Pourquoi toutes les fonctions deprecated n'ont-elles pas besoin de la meme variable de preprocessor? je suppose que les fonctions touche a des niveau different mais je trouve que c'est encore plus c***** (fastidieux) car pour chaque fonction "deprecated", ou bien faut modifier ou bien trouver le bon define (et c'est pas facile).

Je m'explique:
pour fopen_s il fallait mettre _CRT_SECURE_NO_DEPRECATE
pour sprintf il faut _CRT_NON_CONFORMING_SWPRINTFS
et pour wcsicmp ben la je sais toujours pas en fait :lol:

Donc pourquoi Windows met en place des outils qui ne supporte pas les programmes d'avant? c'est nul!
encore si il faut passer de dos 1.0 à XPpro je comprend qu'il faille faire des grosse modifs, mais passer de Visual 6.0 a 2005 ca devrait pas.
Pour moi les projets V6 devrait etre compatible avec V2005.

Enfin pas grave ca nous fait du travail:aie:

A+