Dans une application VB6.0, j'utilise à de multiples reprises les mêmes
chaînes de caractères (par exemple: "#0.00" pour formatter un résultat de
calcul).
Y a t-il un intérêt à remplacer ces chaînes par des constantes publiques sur
le plan du volume et de la performance de l'application compilée ?
Est-ce que VB fait ce travail tout seul lors de la compilation ce qui réduit
l'intérêt de l'usage des constantes à la seule souplesse de programmation ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Jacques93
Bonjour jean saint jalmes, jean saint jalmes a écrit :
Bonjour,
Dans une application VB6.0, j'utilise à de multiples reprises les mêmes chaînes de caractères (par exemple: "#0.00" pour formatter un résultat de calcul).
Y a t-il un intérêt à remplacer ces chaînes par des constantes publiques sur le plan du volume et de la performance de l'application compilée ?
Non.
Est-ce que VB fait ce travail tout seul lors de la compilation ce qui réduit l'intérêt de l'usage des constantes à la seule souplesse de programmation ?
Oui, mais pas seulement souplesse :
- volume des sources - partage de constantes entre plusieurs projets - lisibilité (Constantes utilisées par les API par exemple... ) - risque d'erreur ou de faute de frappe limité - je dois en oublier ...
Ceci est valable pour pratiquement tous les langages compilés.
-- Cordialement,
Jacques.
Bonjour jean saint jalmes,
jean saint jalmes a écrit :
Bonjour,
Dans une application VB6.0, j'utilise à de multiples reprises les mêmes
chaînes de caractères (par exemple: "#0.00" pour formatter un résultat de
calcul).
Y a t-il un intérêt à remplacer ces chaînes par des constantes publiques sur
le plan du volume et de la performance de l'application compilée ?
Non.
Est-ce que VB fait ce travail tout seul lors de la compilation ce qui réduit
l'intérêt de l'usage des constantes à la seule souplesse de programmation ?
Oui, mais pas seulement souplesse :
- volume des sources
- partage de constantes entre plusieurs projets
- lisibilité (Constantes utilisées par les API par exemple... )
- risque d'erreur ou de faute de frappe limité
- je dois en oublier ...
Ceci est valable pour pratiquement tous les langages compilés.
Bonjour jean saint jalmes, jean saint jalmes a écrit :
Bonjour,
Dans une application VB6.0, j'utilise à de multiples reprises les mêmes chaînes de caractères (par exemple: "#0.00" pour formatter un résultat de calcul).
Y a t-il un intérêt à remplacer ces chaînes par des constantes publiques sur le plan du volume et de la performance de l'application compilée ?
Non.
Est-ce que VB fait ce travail tout seul lors de la compilation ce qui réduit l'intérêt de l'usage des constantes à la seule souplesse de programmation ?
Oui, mais pas seulement souplesse :
- volume des sources - partage de constantes entre plusieurs projets - lisibilité (Constantes utilisées par les API par exemple... ) - risque d'erreur ou de faute de frappe limité - je dois en oublier ...
Ceci est valable pour pratiquement tous les langages compilés.
-- Cordialement,
Jacques.
Driss HANIB
et peut être aussi la possibilité de modifier, dans la cas présent le format en mmodifiant uniquement la constante , sans avoir à rechercher dans toutes tes sources les endroits où tu l'avais utilisée.. Pour ma part je l'utilise pour le format de date qui est tratié partout de la même façon
Driss
"Jacques93" a écrit dans le message de news:%
Bonjour jean saint jalmes, jean saint jalmes a écrit : > Bonjour, > > Dans une application VB6.0, j'utilise à de multiples reprises les mêmes > chaînes de caractères (par exemple: "#0.00" pour formatter un résultat
de
> calcul). > > Y a t-il un intérêt à remplacer ces chaînes par des constantes publiques
sur
> le plan du volume et de la performance de l'application compilée ?
Non.
> Est-ce que VB fait ce travail tout seul lors de la compilation ce qui
réduit
> l'intérêt de l'usage des constantes à la seule souplesse de
programmation ?
Oui, mais pas seulement souplesse :
- volume des sources - partage de constantes entre plusieurs projets - lisibilité (Constantes utilisées par les API par exemple... ) - risque d'erreur ou de faute de frappe limité - je dois en oublier ...
Ceci est valable pour pratiquement tous les langages compilés.
-- Cordialement,
Jacques.
et peut être aussi la possibilité de modifier, dans la cas présent le format
en mmodifiant uniquement la constante , sans avoir à rechercher dans toutes
tes sources les endroits où tu l'avais utilisée..
Pour ma part je l'utilise pour le format de date qui est tratié partout de
la même façon
Driss
"Jacques93" <jacques@Nospam> a écrit dans le message de
news:%23S4M7kvEHHA.4036@TK2MSFTNGP02.phx.gbl...
Bonjour jean saint jalmes,
jean saint jalmes a écrit :
> Bonjour,
>
> Dans une application VB6.0, j'utilise à de multiples reprises les mêmes
> chaînes de caractères (par exemple: "#0.00" pour formatter un résultat
de
> calcul).
>
> Y a t-il un intérêt à remplacer ces chaînes par des constantes publiques
sur
> le plan du volume et de la performance de l'application compilée ?
Non.
> Est-ce que VB fait ce travail tout seul lors de la compilation ce qui
réduit
> l'intérêt de l'usage des constantes à la seule souplesse de
programmation ?
Oui, mais pas seulement souplesse :
- volume des sources
- partage de constantes entre plusieurs projets
- lisibilité (Constantes utilisées par les API par exemple... )
- risque d'erreur ou de faute de frappe limité
- je dois en oublier ...
Ceci est valable pour pratiquement tous les langages compilés.
et peut être aussi la possibilité de modifier, dans la cas présent le format en mmodifiant uniquement la constante , sans avoir à rechercher dans toutes tes sources les endroits où tu l'avais utilisée.. Pour ma part je l'utilise pour le format de date qui est tratié partout de la même façon
Driss
"Jacques93" a écrit dans le message de news:%
Bonjour jean saint jalmes, jean saint jalmes a écrit : > Bonjour, > > Dans une application VB6.0, j'utilise à de multiples reprises les mêmes > chaînes de caractères (par exemple: "#0.00" pour formatter un résultat
de
> calcul). > > Y a t-il un intérêt à remplacer ces chaînes par des constantes publiques
sur
> le plan du volume et de la performance de l'application compilée ?
Non.
> Est-ce que VB fait ce travail tout seul lors de la compilation ce qui
réduit
> l'intérêt de l'usage des constantes à la seule souplesse de
programmation ?
Oui, mais pas seulement souplesse :
- volume des sources - partage de constantes entre plusieurs projets - lisibilité (Constantes utilisées par les API par exemple... ) - risque d'erreur ou de faute de frappe limité - je dois en oublier ...
Ceci est valable pour pratiquement tous les langages compilés.
-- Cordialement,
Jacques.
Jacques93
Bonjour Driss HANIB, Driss HANIB a écrit :
et peut être aussi la possibilité de modifier, dans la cas présent le format en mmodifiant uniquement la constante , sans avoir à rechercher dans toutes tes sources les endroits où tu l'avais utilisée.. Pour ma part je l'utilise pour le format de date qui est tratié partout de la même façon
Oui, tout à fait. Je l'avais inclus dans ce que Jean appelle souplesse ;-)
-- Cordialement,
Jacques.
Bonjour Driss HANIB,
Driss HANIB a écrit :
et peut être aussi la possibilité de modifier, dans la cas présent le format
en mmodifiant uniquement la constante , sans avoir à rechercher dans toutes
tes sources les endroits où tu l'avais utilisée..
Pour ma part je l'utilise pour le format de date qui est tratié partout de
la même façon
Oui, tout à fait.
Je l'avais inclus dans ce que Jean appelle souplesse ;-)
et peut être aussi la possibilité de modifier, dans la cas présent le format en mmodifiant uniquement la constante , sans avoir à rechercher dans toutes tes sources les endroits où tu l'avais utilisée.. Pour ma part je l'utilise pour le format de date qui est tratié partout de la même façon
Oui, tout à fait. Je l'avais inclus dans ce que Jean appelle souplesse ;-)
-- Cordialement,
Jacques.
Driss HANIB
oui je me le suis dit après avoir appuyé sur envoyer.. comme quoi il faut bien lire avant de se précipiter.. déjà je n'ai pas dit de betise.. mais je répète.. ;o))
Driss
"Jacques93" a écrit dans le message de news:%
Bonjour Driss HANIB, Driss HANIB a écrit : > et peut être aussi la possibilité de modifier, dans la cas présent le
format
> en mmodifiant uniquement la constante , sans avoir à rechercher dans
toutes
> tes sources les endroits où tu l'avais utilisée.. > Pour ma part je l'utilise pour le format de date qui est tratié partout
de
> la même façon >
Oui, tout à fait. Je l'avais inclus dans ce que Jean appelle souplesse ;-)
-- Cordialement,
Jacques.
oui je me le suis dit après avoir appuyé sur envoyer..
comme quoi il faut bien lire avant de se précipiter..
déjà je n'ai pas dit de betise..
mais je répète.. ;o))
Driss
"Jacques93" <jacques@Nospam> a écrit dans le message de
news:%23ZSyNIwEHHA.3436@TK2MSFTNGP03.phx.gbl...
Bonjour Driss HANIB,
Driss HANIB a écrit :
> et peut être aussi la possibilité de modifier, dans la cas présent le
format
> en mmodifiant uniquement la constante , sans avoir à rechercher dans
toutes
> tes sources les endroits où tu l'avais utilisée..
> Pour ma part je l'utilise pour le format de date qui est tratié partout
de
> la même façon
>
Oui, tout à fait.
Je l'avais inclus dans ce que Jean appelle souplesse ;-)
oui je me le suis dit après avoir appuyé sur envoyer.. comme quoi il faut bien lire avant de se précipiter.. déjà je n'ai pas dit de betise.. mais je répète.. ;o))
Driss
"Jacques93" a écrit dans le message de news:%
Bonjour Driss HANIB, Driss HANIB a écrit : > et peut être aussi la possibilité de modifier, dans la cas présent le
format
> en mmodifiant uniquement la constante , sans avoir à rechercher dans
toutes
> tes sources les endroits où tu l'avais utilisée.. > Pour ma part je l'utilise pour le format de date qui est tratié partout
de
> la même façon >
Oui, tout à fait. Je l'avais inclus dans ce que Jean appelle souplesse ;-)
