OK, mais là on parle de programmation en C++ pas d'un sous-ensemble de C++. Ta proposition de ne pas utiliser les classes est une façon parmi d'autres de choisir une stratégie pour répondre aux questions que je pose.
Pas d'accord. Pour paraphraser S.Meyers (« Effective C++ »), le C++ est en réalité 4 langages en un :
Le langage C
Le langage « C avec classes » (et potentiellement en 2b. C avec classes + exceptions + RTTI)
C + STL (c'est très, TRÈS utilisé dans pas mal de machins pour simulations numériques soit dit en passant)
Le système de templates (en incluant les possibilité de méta-programmation) + C
Tu peux prendre indépendamment n'importe lequel de ces langages, ou bien en faire une combinaison. Pour donner un exemple à la con : j'utilise C++ pour l'écriture d'un runtime. Nous utilisons le système OO, les templates, et nous avons utilisé la STL principalement pendant la phase de prototypage (nous essayons de remplacer les conteneurs STL par des structures de données qui s'adaptent mieux au contexte — à l'exception de std::string, bien pratique). Nous n'utilisons pas les exceptions. Jamais. Nous ne pouvons pas nous permettre de payer pour exceptions et potentiellement la RTTI qui va avec.
Ta fonction écrit sur stdout ou dans un fichier si c'est une valeur complexe ou renvoie un code de retour. Tu récupères la valeur avec '>' ou avec les backquotes pour les valeur complexes.
Ah bah forcément, si tu limites les fonctions du shell à ce qui t'arrange … :-) Mais oui, je suis bien d'accord, le shell n'est que le « squelette » (en gros : structures de contrôle et notion de « statement »). Que le reste soit fait à base d'utilisation de bc, seq, etc. ne me choque pas du tout dans le cadre de Bash. Ce que je dis, c'est que la notion de « fonction » en Bash est en réalité une notion de « procédure » (i.e. qui ne renvoie aucun résultat). Et si tu veux pouvoir communiquer ce résultat à d'autres fonctions dans ton script Bash, ou tout bêtement à l'appelant, tu te retrouve obligé de passer par des variables globales prédéfinies et connues de l'utilisateur de la fonction. Si toutes tes fonctions Bash sont purement autonomes je suis d'accord ça suffit. Si tu cherches à aller plus loin (je ne dis pas que c'est souhaitable), la notion de fonction en Bash est très limitée.
Le shell ne sert pas à manipuler ces valeurs, il sert à coordonner le travail de plusieurs processus (en leur passant les valeurs).
Ben plein de gens ne sont pas d'accord avec toi, sinon la notation $(()) pour faire de l'arithmétique entière n'existerait pas, par exemple (et je m'en suis servi plusieurs fois pour automatiser des benchmarks dont les binaires prenaient en paramètres des valeurs numériques …). Ou les fonctions « builtin », etc.
Cela dit, c'est justement parce que programmer en C/C++/ADA/blah est trop chiant pour ce qui concerne la « coordination de processus », mais que (ba)sh est trop limité dans beaucoup de cas (le script de coordination commence à dépasser la trentaine de lignes ;-)) que des langages comme Perl émergé.
[à propos du passage de paramètre en C/C++] La différence avec ce que j'ai écrit est que tu as supprimé l'opération de recopie. Si tu passes un pointeur avec transfert de propriété et que tu veux continuer à travailler sur la valeur, il faut la recopier. Quelle que soit la façon dont tu résous le problème, tu n'as pas le droit de le passer sous silence.
Donc en gros, tu m'expliques que si je fais des choses plus compliquées que Bash, alors j'ai plus de questions à me poser quant à la façon de concevoir mes fonctions en C++. Je dis que si tu veux rester au « même niveau » de fonctionnalités que Bash pour les appels de fonction, un moyen simple est de faire faire du « tout référence constante » pour le passage de paramètre, et « tout référence » (non-const) pour écrire le résultat de la fonction (ça marche aussi en passant un std::ostream).
Pour la copie, etc., j'aimerais bien que tu me donnes un exemple simple de ce que tu veux dire en utilisant Bash et C++. Les copies profondes ou superficielles ne sont un problème que si tu manipules des objets complexes. Dans le cas des appels de fonction en C++, je ne vois pas le rapport. Ta fonction se fout de la sémantique de copie. Elle prend des paramètres en entrée, et renvoie éventuellement un résultat, point.
[^] # Re: Tableau
Posté par lasher . En réponse au journal Tu souhaites apprendre à programmer en shell. Évalué à 3.
Pas d'accord. Pour paraphraser S.Meyers (« Effective C++ »), le C++ est en réalité 4 langages en un :
Tu peux prendre indépendamment n'importe lequel de ces langages, ou bien en faire une combinaison. Pour donner un exemple à la con : j'utilise C++ pour l'écriture d'un runtime. Nous utilisons le système OO, les templates, et nous avons utilisé la STL principalement pendant la phase de prototypage (nous essayons de remplacer les conteneurs STL par des structures de données qui s'adaptent mieux au contexte — à l'exception de
std::string, bien pratique). Nous n'utilisons pas les exceptions. Jamais. Nous ne pouvons pas nous permettre de payer pour exceptions et potentiellement la RTTI qui va avec.Ah bah forcément, si tu limites les fonctions du shell à ce qui t'arrange … :-) Mais oui, je suis bien d'accord, le shell n'est que le « squelette » (en gros : structures de contrôle et notion de « statement »). Que le reste soit fait à base d'utilisation de
bc,seq, etc. ne me choque pas du tout dans le cadre de Bash. Ce que je dis, c'est que la notion de « fonction » en Bash est en réalité une notion de « procédure » (i.e. qui ne renvoie aucun résultat). Et si tu veux pouvoir communiquer ce résultat à d'autres fonctions dans ton script Bash, ou tout bêtement à l'appelant, tu te retrouve obligé de passer par des variables globales prédéfinies et connues de l'utilisateur de la fonction. Si toutes tes fonctions Bash sont purement autonomes je suis d'accord ça suffit. Si tu cherches à aller plus loin (je ne dis pas que c'est souhaitable), la notion de fonction en Bash est très limitée.Ben plein de gens ne sont pas d'accord avec toi, sinon la notation
$(())pour faire de l'arithmétique entière n'existerait pas, par exemple (et je m'en suis servi plusieurs fois pour automatiser des benchmarks dont les binaires prenaient en paramètres des valeurs numériques …). Ou les fonctions « builtin », etc.Cela dit, c'est justement parce que programmer en C/C++/ADA/blah est trop chiant pour ce qui concerne la « coordination de processus », mais que (ba)sh est trop limité dans beaucoup de cas (le script de coordination commence à dépasser la trentaine de lignes ;-)) que des langages comme Perl émergé.
Donc en gros, tu m'expliques que si je fais des choses plus compliquées que Bash, alors j'ai plus de questions à me poser quant à la façon de concevoir mes fonctions en C++. Je dis que si tu veux rester au « même niveau » de fonctionnalités que Bash pour les appels de fonction, un moyen simple est de faire faire du « tout référence constante » pour le passage de paramètre, et « tout référence » (non-const) pour écrire le résultat de la fonction (ça marche aussi en passant un std::ostream).
Pour la copie, etc., j'aimerais bien que tu me donnes un exemple simple de ce que tu veux dire en utilisant Bash et C++. Les copies profondes ou superficielles ne sont un problème que si tu manipules des objets complexes. Dans le cas des appels de fonction en C++, je ne vois pas le rapport. Ta fonction se fout de la sémantique de copie. Elle prend des paramètres en entrée, et renvoie éventuellement un résultat, point.