Voila j'essaye de creer une petit fonction "basique" de cryptage qui renvoie
le decalage d'une chaine de caractére de 1 caractere dans une autre chaine
('A' remplacer par 'B'). Si je n'effectue pas de décalage c'est ok
"//*(szOut+i) =*(szIn+i)";
Si le décalage est effectué "*(szOut+i) = (char)(*(szIn+i)+1)" cela me
renvoie la chaine décalé+ symboles qui n'ont pas lieu d'étre apres..
Voila c'est sans doute trivial mais je suis débutant et si quelqu'un avait
la réponse (et une explication sur l'échec)...
Question bis: Comment faire pour ne pas avoir à déclarer la taille de la
chaine Result (// char Result[strlen(Chaine)] ne marche pas..)
Merci d'avance
Xavier
Et ce n'est pas vraiment de l'optimisation prématurée
Voire... Décider de mettre ++i partout dans un projet, je ne sais pas trop si c'en est.
ah bon ? pour moi c'est clair, ce n'est pas de l'optimisation prématurée. Choisir ++i comme "coding standard", c'est choisir la meilleure de 2 formes souvent équivalentes, voilà tout.
comme a cité benoit, la forme "i++" est une "pessimisation prématurée", et une obfuscation (la description de cet opérateur est plus compliquée), il n'y a aucune raison de l'utiliser par défaut si ce n'est le poids d'une (mauvaise, mais par le passé bénigne) habitude.
Dans les 2 autres cas que tu cites, tu laisses entendre qu'une fois une forme utilisée dans un projet, ça devrait tenir lieu de règle. Dans ce cas, c'est bien au début d'un projet qu'il faut choisir ++i, sans notion d'optimisation, tout simplement parceque l'autre est une moins bonne règle dans l'absolu (elle a des exceptions - des itérateurs compliqués, utilisés dans une boucle cruciale. Et pour un nouveau venu, qqun qui n'a pas assimilé 'i++' comme incrémentation standard, la forme suffixe est un peu une obfuscation).
-- Sam
gramster@gramster.com (03 May 2005 13:56,
Et ce n'est pas vraiment de l'optimisation prématurée
Voire...
Décider de mettre ++i partout dans un projet, je ne sais pas trop si
c'en est.
ah bon ? pour moi c'est clair, ce n'est pas de l'optimisation prématurée.
Choisir ++i comme "coding standard", c'est choisir la meilleure de 2 formes
souvent équivalentes, voilà tout.
comme a cité benoit, la forme "i++" est une "pessimisation prématurée", et
une obfuscation (la description de cet opérateur est plus compliquée), il
n'y a aucune raison de l'utiliser par défaut si ce n'est le poids d'une
(mauvaise, mais par le passé bénigne) habitude.
Dans les 2 autres cas que tu cites, tu laisses entendre qu'une fois une
forme utilisée dans un projet, ça devrait tenir lieu de règle.
Dans ce cas, c'est bien au début d'un projet qu'il faut choisir ++i, sans
notion d'optimisation, tout simplement parceque l'autre est une moins bonne
règle dans l'absolu (elle a des exceptions - des itérateurs compliqués,
utilisés dans une boucle cruciale. Et pour un nouveau venu, qqun qui n'a
pas assimilé 'i++' comme incrémentation standard, la forme suffixe est un
peu une obfuscation).
Et ce n'est pas vraiment de l'optimisation prématurée
Voire... Décider de mettre ++i partout dans un projet, je ne sais pas trop si c'en est.
ah bon ? pour moi c'est clair, ce n'est pas de l'optimisation prématurée. Choisir ++i comme "coding standard", c'est choisir la meilleure de 2 formes souvent équivalentes, voilà tout.
comme a cité benoit, la forme "i++" est une "pessimisation prématurée", et une obfuscation (la description de cet opérateur est plus compliquée), il n'y a aucune raison de l'utiliser par défaut si ce n'est le poids d'une (mauvaise, mais par le passé bénigne) habitude.
Dans les 2 autres cas que tu cites, tu laisses entendre qu'une fois une forme utilisée dans un projet, ça devrait tenir lieu de règle. Dans ce cas, c'est bien au début d'un projet qu'il faut choisir ++i, sans notion d'optimisation, tout simplement parceque l'autre est une moins bonne règle dans l'absolu (elle a des exceptions - des itérateurs compliqués, utilisés dans une boucle cruciale. Et pour un nouveau venu, qqun qui n'a pas assimilé 'i++' comme incrémentation standard, la forme suffixe est un peu une obfuscation).
-- Sam
kanze
Fabien LE LEZ wrote:
On Tue, 03 May 2005 09:30:04 +0200, (Benoît Bréholée):
Bon, je veux bien admettre qu'un type pour lequel ++ est défini est forcément copiable, et généralement sa copie ne coûte pas trop cher. Je sais bien aussi qu'optimiser prématurément est Mal.
Et ce n'est pas vraiment de l'optimisation prématurée
Voire... Décider de mettre ++i partout dans un projet, je ne sais pas trop si c'en est. Décider de mettre ++i à un endroit parce qu'on l'a mis ailleurs, ce n'en est pas, c'est juste suivre les règles du projet. Décider de mettre ++i à un endroit alors qu'on a mis i++ ailleurs, c'est de l'optimisation -- et de l'optimisation prématurée si la décision de vient pas des résultats du profiler.
Excellente summarisation. Il ne manque d'un point :
-- Décider de mettre ++i à un endroit bien qu'on a mis des i++ partout ailleurs, c'est une optimisation prématurée.
(Ben, j'aurais un peu moins d'hésitations sur le premier point aussi. Ce n'en est pas, et basta. Mais ça n'a pas vraiment d'importance.)
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Fabien LE LEZ wrote:
On Tue, 03 May 2005 09:30:04 +0200, usenet5@breholee.org (Benoît
Bréholée):
Bon, je veux bien admettre qu'un type pour lequel ++ est
défini est forcément copiable, et généralement sa copie ne
coûte pas trop cher. Je sais bien aussi qu'optimiser
prématurément est Mal.
Et ce n'est pas vraiment de l'optimisation prématurée
Voire...
Décider de mettre ++i partout dans un projet, je ne sais pas trop si
c'en est.
Décider de mettre ++i à un endroit parce qu'on l'a mis ailleurs, ce
n'en est pas, c'est juste suivre les règles du projet.
Décider de mettre ++i à un endroit alors qu'on a mis i++ ailleurs,
c'est de l'optimisation -- et de l'optimisation prématurée si la
décision de vient pas des résultats du profiler.
Excellente summarisation. Il ne manque d'un point :
-- Décider de mettre ++i à un endroit bien qu'on a mis des i++
partout ailleurs, c'est une optimisation prématurée.
(Ben, j'aurais un peu moins d'hésitations sur le premier point
aussi. Ce n'en est pas, et basta. Mais ça n'a pas vraiment
d'importance.)
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On Tue, 03 May 2005 09:30:04 +0200, (Benoît Bréholée):
Bon, je veux bien admettre qu'un type pour lequel ++ est défini est forcément copiable, et généralement sa copie ne coûte pas trop cher. Je sais bien aussi qu'optimiser prématurément est Mal.
Et ce n'est pas vraiment de l'optimisation prématurée
Voire... Décider de mettre ++i partout dans un projet, je ne sais pas trop si c'en est. Décider de mettre ++i à un endroit parce qu'on l'a mis ailleurs, ce n'en est pas, c'est juste suivre les règles du projet. Décider de mettre ++i à un endroit alors qu'on a mis i++ ailleurs, c'est de l'optimisation -- et de l'optimisation prématurée si la décision de vient pas des résultats du profiler.
Excellente summarisation. Il ne manque d'un point :
-- Décider de mettre ++i à un endroit bien qu'on a mis des i++ partout ailleurs, c'est une optimisation prématurée.
(Ben, j'aurais un peu moins d'hésitations sur le premier point aussi. Ce n'en est pas, et basta. Mais ça n'a pas vraiment d'importance.)
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
kanze
Samuel Krempp wrote:
(03 May 2005 13:56,
Dans les 2 autres cas que tu cites, tu laisses entendre qu'une fois une forme utilisée dans un projet, ça devrait tenir lieu de règle.
Ce qui me semble tout à fait la politique à suivre.
Dans ce cas, c'est bien au début d'un projet qu'il faut choisir ++i,
Pourquoi pas. Sauf que je n'ai pas de machine à remonter le temps. Et le projet, ici, a commencé il y a plus de dix ans.
sans notion d'optimisation, tout simplement parce que l'autre est une moins bonne règle dans l'absolu (elle a des exceptions - des itérateurs compliqués, utilisés dans une boucle cruciale. Et pour un nouveau venu, qqun qui n'a pas assimilé 'i++' comme incrémentation standard, la forme suffixe est un peu une obfuscation).
Chez nous, on s'attend à ce que même les nouveaux venus connaissent les deux formes. Mais évidemment, on n'embauche pas de gens sans connaissance de C++ préalable.
Quant à « moins bonne règle dans l'absolu » (sans tenir compte de l'optimisation), je te laisserai débattre le point avec Kernighan et Richie (et Stroustrup, qui se servait de i++ à l'époque aussi -- je ne sais pas ce qu'il fait maintenant). En ce qui me concerne, en dehors de la question de performance, je ne vois pas de différence.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Samuel Krempp wrote:
gramster@gramster.com (03 May 2005 13:56,
Dans les 2 autres cas que tu cites, tu laisses entendre qu'une
fois une forme utilisée dans un projet, ça devrait tenir lieu
de règle.
Ce qui me semble tout à fait la politique à suivre.
Dans ce cas, c'est bien au début d'un projet qu'il faut
choisir ++i,
Pourquoi pas. Sauf que je n'ai pas de machine à remonter le
temps. Et le projet, ici, a commencé il y a plus de dix ans.
sans notion d'optimisation, tout simplement parce que l'autre
est une moins bonne règle dans l'absolu (elle a des exceptions
- des itérateurs compliqués, utilisés dans une boucle
cruciale. Et pour un nouveau venu, qqun qui n'a pas assimilé
'i++' comme incrémentation standard, la forme suffixe est un
peu une obfuscation).
Chez nous, on s'attend à ce que même les nouveaux venus
connaissent les deux formes. Mais évidemment, on n'embauche pas
de gens sans connaissance de C++ préalable.
Quant à « moins bonne règle dans l'absolu » (sans tenir compte
de l'optimisation), je te laisserai débattre le point avec
Kernighan et Richie (et Stroustrup, qui se servait de i++ à
l'époque aussi -- je ne sais pas ce qu'il fait maintenant). En
ce qui me concerne, en dehors de la question de performance, je
ne vois pas de différence.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Dans les 2 autres cas que tu cites, tu laisses entendre qu'une fois une forme utilisée dans un projet, ça devrait tenir lieu de règle.
Ce qui me semble tout à fait la politique à suivre.
Dans ce cas, c'est bien au début d'un projet qu'il faut choisir ++i,
Pourquoi pas. Sauf que je n'ai pas de machine à remonter le temps. Et le projet, ici, a commencé il y a plus de dix ans.
sans notion d'optimisation, tout simplement parce que l'autre est une moins bonne règle dans l'absolu (elle a des exceptions - des itérateurs compliqués, utilisés dans une boucle cruciale. Et pour un nouveau venu, qqun qui n'a pas assimilé 'i++' comme incrémentation standard, la forme suffixe est un peu une obfuscation).
Chez nous, on s'attend à ce que même les nouveaux venus connaissent les deux formes. Mais évidemment, on n'embauche pas de gens sans connaissance de C++ préalable.
Quant à « moins bonne règle dans l'absolu » (sans tenir compte de l'optimisation), je te laisserai débattre le point avec Kernighan et Richie (et Stroustrup, qui se servait de i++ à l'époque aussi -- je ne sais pas ce qu'il fait maintenant). En ce qui me concerne, en dehors de la question de performance, je ne vois pas de différence.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
