Bonjour,
Je fais de la programmation ocasionnellement en C++ (je ne suis pas
programmeur a la base) et j'ai besoin de petits conseils sur la construction
de fonctions.
1. Imaginons une fonction créant un vector de nChiffres contenant la même
Valeur.
Ai je intéret a l'implémenter sous la forme (1) ou (2)
(1) std::vector CreateVector(Valeur, nChiffre);
(2) (bool ou) void CreateVector(std::vector& vecteur, Valeur, nChiffre);
Naturellement vu que je code plutot en VBA a l'origine et que ma fonction ne
doit pas me renvoyer d'indicateur d'erreur je partirais plutot sur le 1.
J'imagine que les programmeurs venant du C auront sans doute tendance à la
développer selon la forme 2. Mais y'a t'il un (dés)avantage a la creer sous
une des formes plutot qu'une autre?
2. Concernant l'élaboration de fonctions contenant des parametres d'entrées
et de sorties et renvoyant une valeur booléenne (vrai/faux) selon que la
fonction réussit ou pas. Je viens de lire un article d'un programeur plutot
connu conseillant de commencer par les paramètres d'entrée et de terminer
par les parametres de sorties
(1) bool MaFonction (inParam1, inParam2, inParam3, & outParam1, &
outParam2);
(inParam designe un parametre d'entrée et outParam designe un parametre de
sortie)
Mais comme ma fonction contient des parametres d'entrée ayant des valeurs
par défaut j'aurais eu tendance a faire:
(2) bool MaFonction ( & outParam1, & outParam2, inParam1, inParam2,
inParam3=0);
Dans la pratique, pour une question de rigueur et afin ne pas se tromper en
utilisant ces fonctions j'imagine qu'il faut choisir entre 1 et 2 et
l'appliquer ensuite a l'ensemble des fonctions qu'on rédige. Alors que
choisir? Quels sont vos pratiques sur ce sujet?
Voila ces questions sont sans soute assez basiques. Surtout si vous
programmez depuis pas mal de temps..
Merci d'avance
Xavier
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
Marc Boyer
Le 24-11-2006, Xavier a écrit :
Je fais de la programmation ocasionnellement en C++ (je ne suis pas programmeur a la base) et j'ai besoin de petits conseils sur la construction de fonctions.
1. Imaginons une fonction créant un vector de nChiffres contenant la même Valeur.
Attention à la terminologie: est-ce qu'elle crée un vecteur ou est-ce qu'elle remplis un vecteur déjà créé ? La (1) renvoit un vecteur, la (2) en modifie un, crée par ailleurs.
Ai je intéret a l'implémenter sous la forme (1) ou (2) (1) std::vector CreateVector(Valeur, nChiffre); (2) (bool ou) void CreateVector(std::vector& vecteur, Valeur, nChiffre); Naturellement vu que je code plutot en VBA a l'origine et que ma fonction ne doit pas me renvoyer d'indicateur d'erreur je partirais plutot sur le 1. J'imagine que les programmeurs venant du C auront sans doute tendance à la développer selon la forme 2. Mais y'a t'il un (dés)avantage a la creer sous une des formes plutot qu'une autre?
Pour ma part, ce serait plutôt l'appel du constructeur de std::vector qui fait déjà ça tout seul.
2. Concernant l'élaboration de fonctions contenant des parametres d'entrées et de sorties et renvoyant une valeur booléenne (vrai/faux) selon que la fonction réussit ou pas.
Que signifie 'réussir ou pas' ? En C++, on gère plutôt les échecs par exceptions.
Je viens de lire un article d'un programeur plutot connu conseillant de commencer par les paramètres d'entrée et de terminer par les parametres de sorties
Ah ? Qui ça ? Les conventions C sont plutôt l'inverse: strncpy(dest,scr,capa); Ce qui correspond au 'sens' classique de l'affectation x= 2+4;
(1) bool MaFonction (inParam1, inParam2, inParam3, & outParam1, & outParam2); (inParam designe un parametre d'entrée et outParam designe un parametre de sortie) Mais comme ma fonction contient des parametres d'entrée ayant des valeurs par défaut j'aurais eu tendance a faire: (2) bool MaFonction ( & outParam1, & outParam2, inParam1, inParam2, inParam3=0); Dans la pratique, pour une question de rigueur et afin ne pas se tromper en utilisant ces fonctions j'imagine qu'il faut choisir entre 1 et 2 et l'appliquer ensuite a l'ensemble des fonctions qu'on rédige. Alors que choisir? Quels sont vos pratiques sur ce sujet?
Moi, c'est (2).
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exciter des sots IF -- Rudyard Kipling (Trad. André Maurois)
Le 24-11-2006, Xavier <xni@free.fr> a écrit :
Je fais de la programmation ocasionnellement en C++ (je ne suis pas
programmeur a la base) et j'ai besoin de petits conseils sur la construction
de fonctions.
1. Imaginons une fonction créant un vector de nChiffres contenant la même
Valeur.
Attention à la terminologie: est-ce qu'elle crée un vecteur ou est-ce
qu'elle remplis un vecteur déjà créé ? La (1) renvoit un vecteur,
la (2) en modifie un, crée par ailleurs.
Ai je intéret a l'implémenter sous la forme (1) ou (2)
(1) std::vector CreateVector(Valeur, nChiffre);
(2) (bool ou) void CreateVector(std::vector& vecteur, Valeur, nChiffre);
Naturellement vu que je code plutot en VBA a l'origine et que ma fonction ne
doit pas me renvoyer d'indicateur d'erreur je partirais plutot sur le 1.
J'imagine que les programmeurs venant du C auront sans doute tendance à la
développer selon la forme 2. Mais y'a t'il un (dés)avantage a la creer sous
une des formes plutot qu'une autre?
Pour ma part, ce serait plutôt l'appel du constructeur de std::vector
qui fait déjà ça tout seul.
2. Concernant l'élaboration de fonctions contenant des parametres d'entrées
et de sorties et renvoyant une valeur booléenne (vrai/faux) selon que la
fonction réussit ou pas.
Que signifie 'réussir ou pas' ?
En C++, on gère plutôt les échecs par exceptions.
Je viens de lire un article d'un programeur plutot
connu conseillant de commencer par les paramètres d'entrée et de terminer
par les parametres de sorties
Ah ? Qui ça ?
Les conventions C sont plutôt l'inverse:
strncpy(dest,scr,capa);
Ce qui correspond au 'sens' classique de l'affectation
x= 2+4;
(1) bool MaFonction (inParam1, inParam2, inParam3, & outParam1, &
outParam2);
(inParam designe un parametre d'entrée et outParam designe un parametre de
sortie)
Mais comme ma fonction contient des parametres d'entrée ayant des valeurs
par défaut j'aurais eu tendance a faire:
(2) bool MaFonction ( & outParam1, & outParam2, inParam1, inParam2,
inParam3=0);
Dans la pratique, pour une question de rigueur et afin ne pas se tromper en
utilisant ces fonctions j'imagine qu'il faut choisir entre 1 et 2 et
l'appliquer ensuite a l'ensemble des fonctions qu'on rédige. Alors que
choisir? Quels sont vos pratiques sur ce sujet?
Moi, c'est (2).
Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. André Maurois)
Je fais de la programmation ocasionnellement en C++ (je ne suis pas programmeur a la base) et j'ai besoin de petits conseils sur la construction de fonctions.
1. Imaginons une fonction créant un vector de nChiffres contenant la même Valeur.
Attention à la terminologie: est-ce qu'elle crée un vecteur ou est-ce qu'elle remplis un vecteur déjà créé ? La (1) renvoit un vecteur, la (2) en modifie un, crée par ailleurs.
Ai je intéret a l'implémenter sous la forme (1) ou (2) (1) std::vector CreateVector(Valeur, nChiffre); (2) (bool ou) void CreateVector(std::vector& vecteur, Valeur, nChiffre); Naturellement vu que je code plutot en VBA a l'origine et que ma fonction ne doit pas me renvoyer d'indicateur d'erreur je partirais plutot sur le 1. J'imagine que les programmeurs venant du C auront sans doute tendance à la développer selon la forme 2. Mais y'a t'il un (dés)avantage a la creer sous une des formes plutot qu'une autre?
Pour ma part, ce serait plutôt l'appel du constructeur de std::vector qui fait déjà ça tout seul.
2. Concernant l'élaboration de fonctions contenant des parametres d'entrées et de sorties et renvoyant une valeur booléenne (vrai/faux) selon que la fonction réussit ou pas.
Que signifie 'réussir ou pas' ? En C++, on gère plutôt les échecs par exceptions.
Je viens de lire un article d'un programeur plutot connu conseillant de commencer par les paramètres d'entrée et de terminer par les parametres de sorties
Ah ? Qui ça ? Les conventions C sont plutôt l'inverse: strncpy(dest,scr,capa); Ce qui correspond au 'sens' classique de l'affectation x= 2+4;
(1) bool MaFonction (inParam1, inParam2, inParam3, & outParam1, & outParam2); (inParam designe un parametre d'entrée et outParam designe un parametre de sortie) Mais comme ma fonction contient des parametres d'entrée ayant des valeurs par défaut j'aurais eu tendance a faire: (2) bool MaFonction ( & outParam1, & outParam2, inParam1, inParam2, inParam3=0); Dans la pratique, pour une question de rigueur et afin ne pas se tromper en utilisant ces fonctions j'imagine qu'il faut choisir entre 1 et 2 et l'appliquer ensuite a l'ensemble des fonctions qu'on rédige. Alors que choisir? Quels sont vos pratiques sur ce sujet?
Moi, c'est (2).
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exciter des sots IF -- Rudyard Kipling (Trad. André Maurois)
Xavier
Merci pour les remarques,
"Marc Boyer" a écrit dans le message de news:
Je fais de la programmation ocasionnellement en C++ (je ne suis pas programmeur a la base) et j'ai besoin de petits conseils sur la construction de fonctions.
1. Imaginons une fonction créant un vector de nChiffres contenant la même Valeur.
Attention à la terminologie: est-ce qu'elle crée un vecteur ou est-ce qu'elle remplis un vecteur déjà créé ? La (1) renvoit un vecteur, la (2) en modifie un, crée par ailleurs. D'accord, ma question est mal posé alors. Dois je créer le vecteur, et agir
sur celui via la fonction (par référence). Ou utiliser une fonction qui créer et renvoie le vecteur?
Ai je intéret a l'implémenter sous la forme (1) ou (2) (1) std::vector CreateVector(Valeur, nChiffre); (2) (bool ou) void CreateVector(std::vector& vecteur, Valeur, nChiffre); Naturellement vu que je code plutot en VBA a l'origine et que ma fonction ne doit pas me renvoyer d'indicateur d'erreur je partirais plutot sur le 1. J'imagine que les programmeurs venant du C auront sans doute tendance à la développer selon la forme 2. Mais y'a t'il un (dés)avantage a la creer sous une des formes plutot qu'une autre?
Pour ma part, ce serait plutôt l'appel du constructeur de std::vector qui fait déjà ça tout seul.
2. Concernant l'élaboration de fonctions contenant des parametres d'entrées et de sorties et renvoyant une valeur booléenne (vrai/faux) selon que la fonction réussit ou pas.
Que signifie 'réussir ou pas' ? En C++, on gère plutôt les échecs par exceptions. Je voulais dire que si une valeur d'entrée n'est pas correct, la fonction
renvoie false et je ne m'intérresse pas a ces parametres de sorties
Je viens de lire un article d'un programeur plutot connu conseillant de commencer par les paramètres d'entrée et de terminer par les parametres de sorties
Ah ? Qui ça ? Steve McConnell, Tout sur le code, Chap 7.5 (P190)
Les conventions C sont plutôt l'inverse: strncpy(dest,scr,capa); Ce qui correspond au 'sens' classique de l'affectation x= 2+4;
(1) bool MaFonction (inParam1, inParam2, inParam3, & outParam1, & outParam2); (inParam designe un parametre d'entrée et outParam designe un parametre de sortie) Mais comme ma fonction contient des parametres d'entrée ayant des valeurs par défaut j'aurais eu tendance a faire: (2) bool MaFonction ( & outParam1, & outParam2, inParam1, inParam2, inParam3=0); Dans la pratique, pour une question de rigueur et afin ne pas se tromper en utilisant ces fonctions j'imagine qu'il faut choisir entre 1 et 2 et l'appliquer ensuite a l'ensemble des fonctions qu'on rédige. Alors que choisir? Quels sont vos pratiques sur ce sujet?
Moi, c'est (2). D'accord ca me rassure dans ce cas..
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exciter des sots IF -- Rudyard Kipling (Trad. André Maurois)
Encore merci Xavier
Merci pour les remarques,
"Marc Boyer" <Marc.Boyer@enseeiht.yahoo.fr.invalid> a écrit dans le message
de news: slrneme90b.lj.Marc.Boyer@localhost.localdomain...
Je fais de la programmation ocasionnellement en C++ (je ne suis pas
programmeur a la base) et j'ai besoin de petits conseils sur la
construction
de fonctions.
1. Imaginons une fonction créant un vector de nChiffres contenant la même
Valeur.
Attention à la terminologie: est-ce qu'elle crée un vecteur ou est-ce
qu'elle remplis un vecteur déjà créé ? La (1) renvoit un vecteur,
la (2) en modifie un, crée par ailleurs.
D'accord, ma question est mal posé alors. Dois je créer le vecteur, et agir
sur celui via la fonction (par référence). Ou utiliser une fonction qui
créer et renvoie le vecteur?
Ai je intéret a l'implémenter sous la forme (1) ou (2)
(1) std::vector CreateVector(Valeur, nChiffre);
(2) (bool ou) void CreateVector(std::vector& vecteur, Valeur, nChiffre);
Naturellement vu que je code plutot en VBA a l'origine et que ma fonction
ne
doit pas me renvoyer d'indicateur d'erreur je partirais plutot sur le 1.
J'imagine que les programmeurs venant du C auront sans doute tendance à
la
développer selon la forme 2. Mais y'a t'il un (dés)avantage a la creer
sous
une des formes plutot qu'une autre?
Pour ma part, ce serait plutôt l'appel du constructeur de std::vector
qui fait déjà ça tout seul.
2. Concernant l'élaboration de fonctions contenant des parametres
d'entrées
et de sorties et renvoyant une valeur booléenne (vrai/faux) selon que la
fonction réussit ou pas.
Que signifie 'réussir ou pas' ?
En C++, on gère plutôt les échecs par exceptions.
Je voulais dire que si une valeur d'entrée n'est pas correct, la fonction
renvoie false et je ne m'intérresse pas a ces parametres de sorties
Je viens de lire un article d'un programeur plutot
connu conseillant de commencer par les paramètres d'entrée et de terminer
par les parametres de sorties
Ah ? Qui ça ?
Steve McConnell, Tout sur le code, Chap 7.5 (P190)
Les conventions C sont plutôt l'inverse:
strncpy(dest,scr,capa);
Ce qui correspond au 'sens' classique de l'affectation
x= 2+4;
(1) bool MaFonction (inParam1, inParam2, inParam3, & outParam1, &
outParam2);
(inParam designe un parametre d'entrée et outParam designe un parametre
de
sortie)
Mais comme ma fonction contient des parametres d'entrée ayant des valeurs
par défaut j'aurais eu tendance a faire:
(2) bool MaFonction ( & outParam1, & outParam2, inParam1, inParam2,
inParam3=0);
Dans la pratique, pour une question de rigueur et afin ne pas se tromper
en
utilisant ces fonctions j'imagine qu'il faut choisir entre 1 et 2 et
l'appliquer ensuite a l'ensemble des fonctions qu'on rédige. Alors que
choisir? Quels sont vos pratiques sur ce sujet?
Moi, c'est (2).
D'accord ca me rassure dans ce cas..
Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. André Maurois)
Je fais de la programmation ocasionnellement en C++ (je ne suis pas programmeur a la base) et j'ai besoin de petits conseils sur la construction de fonctions.
1. Imaginons une fonction créant un vector de nChiffres contenant la même Valeur.
Attention à la terminologie: est-ce qu'elle crée un vecteur ou est-ce qu'elle remplis un vecteur déjà créé ? La (1) renvoit un vecteur, la (2) en modifie un, crée par ailleurs. D'accord, ma question est mal posé alors. Dois je créer le vecteur, et agir
sur celui via la fonction (par référence). Ou utiliser une fonction qui créer et renvoie le vecteur?
Ai je intéret a l'implémenter sous la forme (1) ou (2) (1) std::vector CreateVector(Valeur, nChiffre); (2) (bool ou) void CreateVector(std::vector& vecteur, Valeur, nChiffre); Naturellement vu que je code plutot en VBA a l'origine et que ma fonction ne doit pas me renvoyer d'indicateur d'erreur je partirais plutot sur le 1. J'imagine que les programmeurs venant du C auront sans doute tendance à la développer selon la forme 2. Mais y'a t'il un (dés)avantage a la creer sous une des formes plutot qu'une autre?
Pour ma part, ce serait plutôt l'appel du constructeur de std::vector qui fait déjà ça tout seul.
2. Concernant l'élaboration de fonctions contenant des parametres d'entrées et de sorties et renvoyant une valeur booléenne (vrai/faux) selon que la fonction réussit ou pas.
Que signifie 'réussir ou pas' ? En C++, on gère plutôt les échecs par exceptions. Je voulais dire que si une valeur d'entrée n'est pas correct, la fonction
renvoie false et je ne m'intérresse pas a ces parametres de sorties
Je viens de lire un article d'un programeur plutot connu conseillant de commencer par les paramètres d'entrée et de terminer par les parametres de sorties
Ah ? Qui ça ? Steve McConnell, Tout sur le code, Chap 7.5 (P190)
Les conventions C sont plutôt l'inverse: strncpy(dest,scr,capa); Ce qui correspond au 'sens' classique de l'affectation x= 2+4;
(1) bool MaFonction (inParam1, inParam2, inParam3, & outParam1, & outParam2); (inParam designe un parametre d'entrée et outParam designe un parametre de sortie) Mais comme ma fonction contient des parametres d'entrée ayant des valeurs par défaut j'aurais eu tendance a faire: (2) bool MaFonction ( & outParam1, & outParam2, inParam1, inParam2, inParam3=0); Dans la pratique, pour une question de rigueur et afin ne pas se tromper en utilisant ces fonctions j'imagine qu'il faut choisir entre 1 et 2 et l'appliquer ensuite a l'ensemble des fonctions qu'on rédige. Alors que choisir? Quels sont vos pratiques sur ce sujet?
Moi, c'est (2). D'accord ca me rassure dans ce cas..
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exciter des sots IF -- Rudyard Kipling (Trad. André Maurois)
Encore merci Xavier
Serge Paccalin
Le 24.11.2006 18:18, :
D'accord, ma question est mal posé alors. Dois je créer le vecteur, et agir sur celui via la fonction (par référence). Ou utiliser une fonction qui créer et renvoie le vecteur?
Il n'y a pas de réponse toute faite à cette question, cela dépend d es scénarios d'utilisation. D'ailleurs, en C++, rien ne t'empêche de fournir les deux ; tu écris d'abord la version (2) :
Avec le temps, tu verras laquelle tu appelles le plus souvent.
-- ___________ _/ _ _`_`_`_) Serge PACCALIN -- sp ad mailclub.net _L_) Pour bien répondre avec Google, ne pas cliquer -'(__) « Répondre », mais « Afficher les options », _/___(_) puis cliquer « Répondre » (parmi les options).
Le 24.11.2006 18:18, :
D'accord, ma question est mal posé alors. Dois je créer le vecteur, et agir
sur celui via la fonction (par référence). Ou utiliser une fonction qui
créer et renvoie le vecteur?
Il n'y a pas de réponse toute faite à cette question, cela dépend d es
scénarios d'utilisation. D'ailleurs, en C++, rien ne t'empêche de
fournir les deux ; tu écris d'abord la version (2) :
Avec le temps, tu verras laquelle tu appelles le plus souvent.
--
___________
_/ _ _`_`_`_) Serge PACCALIN -- sp ad mailclub.net
_L_) Pour bien répondre avec Google, ne pas cliquer
-'(__) « Répondre », mais « Afficher les options »,
_/___(_) puis cliquer « Répondre » (parmi les options).
D'accord, ma question est mal posé alors. Dois je créer le vecteur, et agir sur celui via la fonction (par référence). Ou utiliser une fonction qui créer et renvoie le vecteur?
Il n'y a pas de réponse toute faite à cette question, cela dépend d es scénarios d'utilisation. D'ailleurs, en C++, rien ne t'empêche de fournir les deux ; tu écris d'abord la version (2) :
Avec le temps, tu verras laquelle tu appelles le plus souvent.
-- ___________ _/ _ _`_`_`_) Serge PACCALIN -- sp ad mailclub.net _L_) Pour bien répondre avec Google, ne pas cliquer -'(__) « Répondre », mais « Afficher les options », _/___(_) puis cliquer « Répondre » (parmi les options).
Marc Boyer
Le 24-11-2006, Xavier a écrit :
"Marc Boyer" a écrit dans le message de news:
Attention à la terminologie: est-ce qu'elle crée un vecteur ou est-ce qu'elle remplis un vecteur déjà créé ? La (1) renvoit un vecteur, la (2) en modifie un, crée par ailleurs. D'accord, ma question est mal posé alors. Dois je créer le vecteur, et agir
sur celui via la fonction (par référence). Ou utiliser une fonction qui créer et renvoie le vecteur?
Ben, ça dépend de l'usage.
2. Concernant l'élaboration de fonctions contenant des parametres d'entrées et de sorties et renvoyant une valeur booléenne (vrai/faux) selon que la fonction réussit ou pas.
Que signifie 'réussir ou pas' ? En C++, on gère plutôt les échecs par exceptions.
Je voulais dire que si une valeur d'entrée n'est pas correct, la fonction renvoie false et je ne m'intérresse pas a ces parametres de sorties
Ben oui, mais j'aurais plutôt tendance à gérer ça par des exceptions moi.
Je viens de lire un article d'un programeur plutot connu conseillant de commencer par les paramètres d'entrée et de terminer par les parametres de sorties
Ah ? Qui ça ? Steve McConnell, Tout sur le code, Chap 7.5 (P190)
Faudrait voir quels arguments il donne pour cela. Mais les conventions C et de la STL C++ sont plutôt dans l'autre sens, et la syntaxe pour les arguments par défauts idem.
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exciter des sots IF -- Rudyard Kipling (Trad. André Maurois)
Le 24-11-2006, Xavier <xni@free.fr> a écrit :
"Marc Boyer" <Marc.Boyer@enseeiht.yahoo.fr.invalid> a écrit dans le message
de news: slrneme90b.lj.Marc.Boyer@localhost.localdomain...
Attention à la terminologie: est-ce qu'elle crée un vecteur ou est-ce
qu'elle remplis un vecteur déjà créé ? La (1) renvoit un vecteur,
la (2) en modifie un, crée par ailleurs.
D'accord, ma question est mal posé alors. Dois je créer le vecteur, et agir
sur celui via la fonction (par référence). Ou utiliser une fonction qui
créer et renvoie le vecteur?
Ben, ça dépend de l'usage.
2. Concernant l'élaboration de fonctions contenant des parametres
d'entrées
et de sorties et renvoyant une valeur booléenne (vrai/faux) selon que la
fonction réussit ou pas.
Que signifie 'réussir ou pas' ?
En C++, on gère plutôt les échecs par exceptions.
Je voulais dire que si une valeur d'entrée n'est pas correct, la fonction
renvoie false et je ne m'intérresse pas a ces parametres de sorties
Ben oui, mais j'aurais plutôt tendance à gérer ça par
des exceptions moi.
Je viens de lire un article d'un programeur plutot
connu conseillant de commencer par les paramètres d'entrée et de terminer
par les parametres de sorties
Ah ? Qui ça ?
Steve McConnell, Tout sur le code, Chap 7.5 (P190)
Faudrait voir quels arguments il donne pour cela.
Mais les conventions C et de la STL C++ sont plutôt dans
l'autre sens, et la syntaxe pour les arguments par défauts
idem.
Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. André Maurois)
Attention à la terminologie: est-ce qu'elle crée un vecteur ou est-ce qu'elle remplis un vecteur déjà créé ? La (1) renvoit un vecteur, la (2) en modifie un, crée par ailleurs. D'accord, ma question est mal posé alors. Dois je créer le vecteur, et agir
sur celui via la fonction (par référence). Ou utiliser une fonction qui créer et renvoie le vecteur?
Ben, ça dépend de l'usage.
2. Concernant l'élaboration de fonctions contenant des parametres d'entrées et de sorties et renvoyant une valeur booléenne (vrai/faux) selon que la fonction réussit ou pas.
Que signifie 'réussir ou pas' ? En C++, on gère plutôt les échecs par exceptions.
Je voulais dire que si une valeur d'entrée n'est pas correct, la fonction renvoie false et je ne m'intérresse pas a ces parametres de sorties
Ben oui, mais j'aurais plutôt tendance à gérer ça par des exceptions moi.
Je viens de lire un article d'un programeur plutot connu conseillant de commencer par les paramètres d'entrée et de terminer par les parametres de sorties
Ah ? Qui ça ? Steve McConnell, Tout sur le code, Chap 7.5 (P190)
Faudrait voir quels arguments il donne pour cela. Mais les conventions C et de la STL C++ sont plutôt dans l'autre sens, et la syntaxe pour les arguments par défauts idem.
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exciter des sots IF -- Rudyard Kipling (Trad. André Maurois)
James Kanze
Marc Boyer wrote:
"Marc Boyer" a écrit dans le m essage de news:
[...]
Je viens de lire un article d'un programeur plutot connu conseillant de commencer par les paramètres d'entrée et de terminer par les parametres de sorties
Ah ? Qui ça ? Steve McConnell, Tout sur le code, Chap 7.5 (P190)
Faudrait voir quels arguments il donne pour cela. Mais les conventions C et de la STL C++ sont plutôt dans l'autre sens, et la syntaxe pour les arguments par défauts idem.
C'est une question de style. En C, effectivement, on a toute la famille des str... et des mem... avec les paramètres en sortie d'abord -- l'argument, il me semble, c'est que ça correspond aux opérateurs d'affectation, qui eux aussi modifie ce qui est à gauche. En C++, en revanche, la STL fait l'inverse, avec std::copy et al.
Personnellement, je préfère les paramètres de sortie d'abord, mais c'est sans doute surtout parce que j'en suis habitué, plutôt que pour une raison technique réele. (J'argue en général que les paramètres de sortie sont plus importants, et qu'on les remarque mieux s'ils précède, mais je crois que c'est un argument « après les faits », conçu surtout pour justifier un choix déjà fait.)
Mais c'est vrai qu'on aurait pour ainsi dire jamais des valeurs par défaut pour les paramètres de sortie. C'est la première fois que j'entends cet argument, mais c'est effectivement une raison technique pour préférer cet ordre. Si on ajoute le fait que dans les operator<op>=, le paramètre de sortie (ou plutôt d'entrée/sortie) doit obligatoirement être le premier, je crois qu'on a effectivement des raisons techniques pour justifier le choix. Mais pas des raisons assez fortes pour être impératives.
Et évidemment, il y a un style de programmation qui évite les paramètres de sortie ou d'entrée/sortie complètement. Dans les faits, je m'en sers très peu.
-- James Kanze (GABI Software) email: 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
Marc Boyer wrote:
"Marc Boyer" <Marc.Boyer@enseeiht.yahoo.fr.invalid> a écrit dans le m essage
de news: slrneme90b.lj.Marc.Boyer@localhost.localdomain...
[...]
Je viens de lire un article d'un programeur plutot
connu conseillant de commencer par les paramètres d'entrée et de terminer
par les parametres de sorties
Ah ? Qui ça ?
Steve McConnell, Tout sur le code, Chap 7.5 (P190)
Faudrait voir quels arguments il donne pour cela.
Mais les conventions C et de la STL C++ sont plutôt dans
l'autre sens, et la syntaxe pour les arguments par défauts
idem.
C'est une question de style. En C, effectivement, on a toute la
famille des str... et des mem... avec les paramètres en sortie
d'abord -- l'argument, il me semble, c'est que ça correspond
aux opérateurs d'affectation, qui eux aussi modifie ce qui est à
gauche. En C++, en revanche, la STL fait l'inverse, avec
std::copy et al.
Personnellement, je préfère les paramètres de sortie d'abord,
mais c'est sans doute surtout parce que j'en suis habitué,
plutôt que pour une raison technique réele. (J'argue en général
que les paramètres de sortie sont plus importants, et qu'on les
remarque mieux s'ils précède, mais je crois que c'est un
argument « après les faits », conçu surtout pour justifier un
choix déjà fait.)
Mais c'est vrai qu'on aurait pour ainsi dire jamais des valeurs
par défaut pour les paramètres de sortie. C'est la première fois
que j'entends cet argument, mais c'est effectivement une raison
technique pour préférer cet ordre. Si on ajoute le fait que dans
les operator<op>=, le paramètre de sortie (ou plutôt
d'entrée/sortie) doit obligatoirement être le premier, je crois
qu'on a effectivement des raisons techniques pour justifier le
choix. Mais pas des raisons assez fortes pour être impératives.
Et évidemment, il y a un style de programmation qui évite les
paramètres de sortie ou d'entrée/sortie complètement. Dans les
faits, je m'en sers très peu.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
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
Je viens de lire un article d'un programeur plutot connu conseillant de commencer par les paramètres d'entrée et de terminer par les parametres de sorties
Ah ? Qui ça ? Steve McConnell, Tout sur le code, Chap 7.5 (P190)
Faudrait voir quels arguments il donne pour cela. Mais les conventions C et de la STL C++ sont plutôt dans l'autre sens, et la syntaxe pour les arguments par défauts idem.
C'est une question de style. En C, effectivement, on a toute la famille des str... et des mem... avec les paramètres en sortie d'abord -- l'argument, il me semble, c'est que ça correspond aux opérateurs d'affectation, qui eux aussi modifie ce qui est à gauche. En C++, en revanche, la STL fait l'inverse, avec std::copy et al.
Personnellement, je préfère les paramètres de sortie d'abord, mais c'est sans doute surtout parce que j'en suis habitué, plutôt que pour une raison technique réele. (J'argue en général que les paramètres de sortie sont plus importants, et qu'on les remarque mieux s'ils précède, mais je crois que c'est un argument « après les faits », conçu surtout pour justifier un choix déjà fait.)
Mais c'est vrai qu'on aurait pour ainsi dire jamais des valeurs par défaut pour les paramètres de sortie. C'est la première fois que j'entends cet argument, mais c'est effectivement une raison technique pour préférer cet ordre. Si on ajoute le fait que dans les operator<op>=, le paramètre de sortie (ou plutôt d'entrée/sortie) doit obligatoirement être le premier, je crois qu'on a effectivement des raisons techniques pour justifier le choix. Mais pas des raisons assez fortes pour être impératives.
Et évidemment, il y a un style de programmation qui évite les paramètres de sortie ou d'entrée/sortie complètement. Dans les faits, je m'en sers très peu.
-- James Kanze (GABI Software) email: 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
Marc Boyer
Le 28-11-2006, James Kanze a écrit :
Mais les conventions C et de la STL C++ sont plutôt dans l'autre sens, et la syntaxe pour les arguments par défauts idem.
C'est une question de style. En C, effectivement, on a toute la famille des str... et des mem... avec les paramètres en sortie d'abord -- l'argument, il me semble, c'est que ça correspond aux opérateurs d'affectation, qui eux aussi modifie ce qui est à gauche. En C++, en revanche, la STL fait l'inverse, avec std::copy et al.
C'est marrant, moi je pensais à sort, remove...
Personnellement, je préfère les paramètres de sortie d'abord, mais c'est sans doute surtout parce que j'en suis habitué, plutôt que pour une raison technique réele. (J'argue en général que les paramètres de sortie sont plus importants, et qu'on les remarque mieux s'ils précède, mais je crois que c'est un argument « après les faits », conçu surtout pour justifier un choix déjà fait.)
Mais c'est vrai qu'on aurait pour ainsi dire jamais des valeurs par défaut pour les paramètres de sortie. C'est la première fois que j'entends cet argument, mais c'est effectivement une raison technique pour préférer cet ordre. Si on ajoute le fait que dans les operator<op>=, le paramètre de sortie (ou plutôt d'entrée/sortie) doit obligatoirement être le premier, je crois qu'on a effectivement des raisons techniques pour justifier le choix. Mais pas des raisons assez fortes pour être impératives.
Oui, on est pas dans la règle stricte, plutot dans la convention.
Et évidemment, il y a un style de programmation qui évite les paramètres de sortie ou d'entrée/sortie complètement. Dans les faits, je m'en sers très peu.
Idem.
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exciter des sots IF -- Rudyard Kipling (Trad. André Maurois)
Le 28-11-2006, James Kanze <james.kanze@gmail.com> a écrit :
Mais les conventions C et de la STL C++ sont plutôt dans
l'autre sens, et la syntaxe pour les arguments par défauts
idem.
C'est une question de style. En C, effectivement, on a toute la
famille des str... et des mem... avec les paramètres en sortie
d'abord -- l'argument, il me semble, c'est que ça correspond
aux opérateurs d'affectation, qui eux aussi modifie ce qui est à
gauche. En C++, en revanche, la STL fait l'inverse, avec
std::copy et al.
C'est marrant, moi je pensais à sort, remove...
Personnellement, je préfère les paramètres de sortie d'abord,
mais c'est sans doute surtout parce que j'en suis habitué,
plutôt que pour une raison technique réele. (J'argue en général
que les paramètres de sortie sont plus importants, et qu'on les
remarque mieux s'ils précède, mais je crois que c'est un
argument « après les faits », conçu surtout pour justifier un
choix déjà fait.)
Mais c'est vrai qu'on aurait pour ainsi dire jamais des valeurs
par défaut pour les paramètres de sortie. C'est la première fois
que j'entends cet argument, mais c'est effectivement une raison
technique pour préférer cet ordre. Si on ajoute le fait que dans
les operator<op>=, le paramètre de sortie (ou plutôt
d'entrée/sortie) doit obligatoirement être le premier, je crois
qu'on a effectivement des raisons techniques pour justifier le
choix. Mais pas des raisons assez fortes pour être impératives.
Oui, on est pas dans la règle stricte, plutot dans la convention.
Et évidemment, il y a un style de programmation qui évite les
paramètres de sortie ou d'entrée/sortie complètement. Dans les
faits, je m'en sers très peu.
Idem.
Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. André Maurois)
Mais les conventions C et de la STL C++ sont plutôt dans l'autre sens, et la syntaxe pour les arguments par défauts idem.
C'est une question de style. En C, effectivement, on a toute la famille des str... et des mem... avec les paramètres en sortie d'abord -- l'argument, il me semble, c'est que ça correspond aux opérateurs d'affectation, qui eux aussi modifie ce qui est à gauche. En C++, en revanche, la STL fait l'inverse, avec std::copy et al.
C'est marrant, moi je pensais à sort, remove...
Personnellement, je préfère les paramètres de sortie d'abord, mais c'est sans doute surtout parce que j'en suis habitué, plutôt que pour une raison technique réele. (J'argue en général que les paramètres de sortie sont plus importants, et qu'on les remarque mieux s'ils précède, mais je crois que c'est un argument « après les faits », conçu surtout pour justifier un choix déjà fait.)
Mais c'est vrai qu'on aurait pour ainsi dire jamais des valeurs par défaut pour les paramètres de sortie. C'est la première fois que j'entends cet argument, mais c'est effectivement une raison technique pour préférer cet ordre. Si on ajoute le fait que dans les operator<op>=, le paramètre de sortie (ou plutôt d'entrée/sortie) doit obligatoirement être le premier, je crois qu'on a effectivement des raisons techniques pour justifier le choix. Mais pas des raisons assez fortes pour être impératives.
Oui, on est pas dans la règle stricte, plutot dans la convention.
Et évidemment, il y a un style de programmation qui évite les paramètres de sortie ou d'entrée/sortie complètement. Dans les faits, je m'en sers très peu.
Idem.
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exciter des sots IF -- Rudyard Kipling (Trad. André Maurois)
Fabien LE LEZ
On 27 Nov 2006 23:45:54 -0800, "James Kanze" :
Personnellement, je préfère les paramètres de sortie d'abord,
Moi aussi. Puisque le type de retour est à gauche, je mets les autres sorties à gauche.
On 27 Nov 2006 23:45:54 -0800, "James Kanze" <james.kanze@gmail.com>:
Personnellement, je préfère les paramètres de sortie d'abord,
Moi aussi. Puisque le type de retour est à gauche, je mets les autres
sorties à gauche.
Personnellement, je préfère les paramètres de sortie d'abord,
Moi aussi. Puisque le type de retour est à gauche, je mets les autres sorties à gauche.
James Kanze
Fabien LE LEZ wrote:
On 27 Nov 2006 23:45:54 -0800, "James Kanze" :
Personnellement, je préfère les paramètres de sortie d'abord,
Moi aussi. Puisque le type de retour est à gauche, je mets les autres sorties à gauche.
Encore une motivation. Aucune des motivations n'est réelement concluante, mais prises dans l'ensemble, et dans l'absence des motivations contraires, je crois qu'on peut conclure que c'est un bon conseil.
-- James Kanze (Gabi Software) email: 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 27 Nov 2006 23:45:54 -0800, "James Kanze" <james.kanze@gmail.com>:
Personnellement, je préfère les paramètres de sortie d'abord,
Moi aussi. Puisque le type de retour est à gauche, je mets les autres
sorties à gauche.
Encore une motivation. Aucune des motivations n'est réelement
concluante, mais prises dans l'ensemble, et dans l'absence des
motivations contraires, je crois qu'on peut conclure que c'est
un bon conseil.
--
James Kanze (Gabi Software) email: james.kanze@gmail.com
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
Personnellement, je préfère les paramètres de sortie d'abord,
Moi aussi. Puisque le type de retour est à gauche, je mets les autres sorties à gauche.
Encore une motivation. Aucune des motivations n'est réelement concluante, mais prises dans l'ensemble, et dans l'absence des motivations contraires, je crois qu'on peut conclure que c'est un bon conseil.
-- James Kanze (Gabi Software) email: 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
