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
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
void DecalageChaine (char* szOut, char* szIn) { int i=0; do { //*(szOut+i) =*(szIn+i); *(szOut+i) = (char)(*(szIn+i)+1); } while (szIn[i++] != ' '); }
Outre ce qui a été proposé avant, une version plus c++ pourrait être par exemple: std::string decal(const std::string& a_string) { std::string result; std::transform(a_string.begin(), a_string.end(), std::back_inserter(result), std::bind1st(std::plus<char>(), 1)); return result; }
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
void DecalageChaine (char* szOut, char* szIn)
{
int i=0;
do
{
//*(szOut+i) =*(szIn+i);
*(szOut+i) = (char)(*(szIn+i)+1);
}
while (szIn[i++] != ' ');
}
Outre ce qui a été proposé avant, une version plus c++ pourrait être par
exemple:
std::string decal(const std::string& a_string)
{
std::string result;
std::transform(a_string.begin(), a_string.end(),
std::back_inserter(result), std::bind1st(std::plus<char>(), 1));
return result;
}
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
void DecalageChaine (char* szOut, char* szIn) { int i=0; do { //*(szOut+i) =*(szIn+i); *(szOut+i) = (char)(*(szIn+i)+1); } while (szIn[i++] != ' '); }
Outre ce qui a été proposé avant, une version plus c++ pourrait être par exemple: std::string decal(const std::string& a_string) { std::string result; std::transform(a_string.begin(), a_string.end(), std::back_inserter(result), std::bind1st(std::plus<char>(), 1)); return result; }
Outre ce qui a été proposé avant, une version plus c++ pourrait être par exemple: std::string decal(const std::string& a_string) { std::string result; std::transform(a_string.begin(), a_string.end(), std::back_inserter(result), std::bind1st(std::plus<char>(), 1)); return result; }
c'est sûr que là, personne ne pourra dire que c'est du C :)
personnellement je trouve les boucles courtes un poil plus lisibles que les fonctions de <algorithm> utilisée avec des binders, à cause de la syntaxe lourde qui masque le coeur de l'action, mais c'est une question d'habitude.
Expliciter la boucle donne 3 lignes au lieu d'une, mais les 2 premières sont rapidement interpretées comme "boucle sur a_string", et l'action est proprement isolée sur sa ligne à elle :
et si on veut faire la modification en-place (si la copie doit être évitée) :
void decal(std::string& a_string, int n) { std::string::iterator it, itend = a_string.end(); for(it=a_string.begin(); it != itend; ++it) *it += n; }
-- Sam
Outre ce qui a été proposé avant, une version plus c++ pourrait être par
exemple:
std::string decal(const std::string& a_string)
{
std::string result;
std::transform(a_string.begin(), a_string.end(),
std::back_inserter(result), std::bind1st(std::plus<char>(), 1));
return result;
}
c'est sûr que là, personne ne pourra dire que c'est du C :)
personnellement je trouve les boucles courtes un poil plus lisibles que les
fonctions de <algorithm> utilisée avec des binders, à cause de la syntaxe
lourde qui masque le coeur de l'action, mais c'est une question d'habitude.
Expliciter la boucle donne 3 lignes au lieu d'une, mais les 2 premières sont
rapidement interpretées comme "boucle sur a_string", et l'action est
proprement isolée sur sa ligne à elle :
Outre ce qui a été proposé avant, une version plus c++ pourrait être par exemple: std::string decal(const std::string& a_string) { std::string result; std::transform(a_string.begin(), a_string.end(), std::back_inserter(result), std::bind1st(std::plus<char>(), 1)); return result; }
c'est sûr que là, personne ne pourra dire que c'est du C :)
personnellement je trouve les boucles courtes un poil plus lisibles que les fonctions de <algorithm> utilisée avec des binders, à cause de la syntaxe lourde qui masque le coeur de l'action, mais c'est une question d'habitude.
Expliciter la boucle donne 3 lignes au lieu d'une, mais les 2 premières sont rapidement interpretées comme "boucle sur a_string", et l'action est proprement isolée sur sa ligne à elle :
On Mon, 2 May 2005 13:09:56 +0200, "Vincent Lascaux" :
2) on pourrait mettre les incrémentations sur une autre ligne. Dans ce cas, j'ai du mal à imaginer une utilisation interessante de l'opérateur ++ (int).
J'avoue que je ne me sers jamais de cet opérateur -- j'ai tendance à penser que si je dois m'en servir, c'est un signe que le code est trop compact et pas assez clair.
-- Le grand site de la philosophie animale : <http://perso.edulang.com/philo/>
On Mon, 2 May 2005 13:09:56 +0200, "Vincent Lascaux"
<nospam@nospam.org>:
2) on pourrait mettre les incrémentations sur une autre ligne. Dans ce cas,
j'ai du mal à imaginer une utilisation interessante de l'opérateur ++ (int).
J'avoue que je ne me sers jamais de cet opérateur -- j'ai tendance à
penser que si je dois m'en servir, c'est un signe que le code est trop
compact et pas assez clair.
--
Le grand site de la philosophie animale : <http://perso.edulang.com/philo/>
On Mon, 2 May 2005 13:09:56 +0200, "Vincent Lascaux" :
2) on pourrait mettre les incrémentations sur une autre ligne. Dans ce cas, j'ai du mal à imaginer une utilisation interessante de l'opérateur ++ (int).
J'avoue que je ne me sers jamais de cet opérateur -- j'ai tendance à penser que si je dois m'en servir, c'est un signe que le code est trop compact et pas assez clair.
-- Le grand site de la philosophie animale : <http://perso.edulang.com/philo/>
Matthieu Moy
Fabien LE LEZ writes:
J'avoue que je ne me sers jamais de cet opérateur -- j'ai tendance à penser que si je dois m'en servir, c'est un signe que le code est trop compact et pas assez clair.
Perso, je l'utilise pour les boucles for, mais je n'aime pas le principe d'un opérateur avec à la fois une valeur de retour et un effet de bord. Si je veux la valeur de i, j'écris
... = ... i ...; i++;
Et il n'y a pas de risque de confusion (Que celui qui trouve que le risque de confusion introduit par un ++ dans une expression non-triviale relise le début du thread ;-).
-- Matthieu
Fabien LE LEZ <gramster@gramster.com> writes:
J'avoue que je ne me sers jamais de cet opérateur -- j'ai tendance à
penser que si je dois m'en servir, c'est un signe que le code est trop
compact et pas assez clair.
Perso, je l'utilise pour les boucles for, mais je n'aime pas le
principe d'un opérateur avec à la fois une valeur de retour et un
effet de bord. Si je veux la valeur de i, j'écris
... = ... i ...;
i++;
Et il n'y a pas de risque de confusion (Que celui qui trouve que le
risque de confusion introduit par un ++ dans une expression
non-triviale relise le début du thread ;-).
J'avoue que je ne me sers jamais de cet opérateur -- j'ai tendance à penser que si je dois m'en servir, c'est un signe que le code est trop compact et pas assez clair.
Perso, je l'utilise pour les boucles for, mais je n'aime pas le principe d'un opérateur avec à la fois une valeur de retour et un effet de bord. Si je veux la valeur de i, j'écris
... = ... i ...; i++;
Et il n'y a pas de risque de confusion (Que celui qui trouve que le risque de confusion introduit par un ++ dans une expression non-triviale relise le début du thread ;-).
-- Matthieu
Fabien LE LEZ
On Mon, 02 May 2005 22:55:33 +0200, Matthieu Moy :
Si je veux la valeur de i, j'écris
... = ... i ...; i++;
"++i;", du coup, non ?
-- Le grand site de la philosophie animale : <http://perso.edulang.com/philo/>
On Mon, 02 May 2005 22:55:33 +0200, Matthieu Moy
<MatthieuNOSPAM.Moy@imag.fr.invalid>:
Si je veux la valeur de i, j'écris
... = ... i ...;
i++;
"++i;", du coup, non ?
--
Le grand site de la philosophie animale : <http://perso.edulang.com/philo/>
i++ par habitude ;-) (sinon, je coderais en ++C). Vu qu'on ne garde pas la valeur de retour, les deux sont vraiment équivalent, donc ...
-- Matthieu
Fabien LE LEZ
On Tue, 03 May 2005 00:41:33 +0200, Matthieu Moy :
"++i;", du coup, non ?
i++ par habitude ;-) (sinon, je coderais en ++C). Vu qu'on ne garde pas la valeur de retour,
les deux sont vraiment équivalent,
Si i est un type de base, oui.
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.
Mais tout de même, si, pour un projet, j'ai le choix entre deux méthodes syntactiquement équivalentes, pas plus longue/complexe l'une que l'autre, mais dont une peut être plus lente que l'autre, j'ai tendance à choisir la plus rapide. Et une fois qu'une méthode est choisie, on ne peut plus en changer sans raison importante.
(sinon, je coderais en ++C)
Hé hé... la vieille blague... Note que "Je code en C++" signifie "Je code dans la vieille version de C, alors même qu'il en existe une nouvelle, plus riche."
-- Le grand site de la philosophie animale : <http://perso.edulang.com/philo/>
On Tue, 03 May 2005 00:41:33 +0200, Matthieu Moy
<MatthieuNOSPAM.Moy@imag.fr.invalid>:
"++i;", du coup, non ?
i++ par habitude ;-) (sinon, je coderais en ++C). Vu qu'on ne garde
pas la valeur de retour,
les deux sont vraiment équivalent,
Si i est un type de base, oui.
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.
Mais tout de même, si, pour un projet, j'ai le choix entre deux
méthodes syntactiquement équivalentes, pas plus longue/complexe l'une
que l'autre, mais dont une peut être plus lente que l'autre, j'ai
tendance à choisir la plus rapide.
Et une fois qu'une méthode est choisie, on ne peut plus en changer
sans raison importante.
(sinon, je coderais en ++C)
Hé hé... la vieille blague...
Note que "Je code en C++" signifie "Je code dans la vieille version de
C, alors même qu'il en existe une nouvelle, plus riche."
--
Le grand site de la philosophie animale : <http://perso.edulang.com/philo/>
On Tue, 03 May 2005 00:41:33 +0200, Matthieu Moy :
"++i;", du coup, non ?
i++ par habitude ;-) (sinon, je coderais en ++C). Vu qu'on ne garde pas la valeur de retour,
les deux sont vraiment équivalent,
Si i est un type de base, oui.
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.
Mais tout de même, si, pour un projet, j'ai le choix entre deux méthodes syntactiquement équivalentes, pas plus longue/complexe l'une que l'autre, mais dont une peut être plus lente que l'autre, j'ai tendance à choisir la plus rapide. Et une fois qu'une méthode est choisie, on ne peut plus en changer sans raison importante.
(sinon, je coderais en ++C)
Hé hé... la vieille blague... Note que "Je code en C++" signifie "Je code dans la vieille version de C, alors même qu'il en existe une nouvelle, plus riche."
-- Le grand site de la philosophie animale : <http://perso.edulang.com/philo/>
usenet5
Fabien LE LEZ :
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 puisque comme tu le dis ensuite, c'est aussi simple à écrire et aussi lisible. Dans "C++ Coding Standards" de Sutter et Alexandrescu, la version suffixée est donnée comme exemple de "pessimisation prématurée" à éviter.
Fabien LE LEZ <gramster@gramster.com>:
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 puisque comme tu
le dis ensuite, c'est aussi simple à écrire et aussi lisible. Dans
"C++ Coding Standards" de Sutter et Alexandrescu, la version suffixée
est donnée comme exemple de "pessimisation prématurée" à éviter.
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 puisque comme tu le dis ensuite, c'est aussi simple à écrire et aussi lisible. Dans "C++ Coding Standards" de Sutter et Alexandrescu, la version suffixée est donnée comme exemple de "pessimisation prématurée" à éviter.
Fabien LE LEZ
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. -- Le grand site de la philosophie animale : <http://perso.edulang.com/philo/>
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.
--
Le grand site de la philosophie animale : <http://perso.edulang.com/philo/>
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. -- Le grand site de la philosophie animale : <http://perso.edulang.com/philo/>
