CONNEXION
  • RetourJeux
    • Tests
    • Soluces
    • Previews
    • Sorties
    • Hit Parade
    • Les + populaires
    • Les + attendus
    • Tous les Jeux
  • RetourActu
    • Culture Geek
    • Astuces
    • Réalité Virtuelle
    • Rétrogaming
    • Toutes les actus
  • Bons plans
  • RetourHigh-Tech
    • Actus JVTECH
    • Smartphones
    • Mobilité urbaine
    • Hardware
    • Image et son
    • Tutoriels
    • Tests produits High-Tech
    • Guides d'achat High-Tech
    • JVTECH
  • RetourVidéos
    • A la une
    • Gaming Live
    • Vidéos Tests
    • Vidéos Previews
    • Gameplay
    • Trailers
    • Chroniques
    • Replay Web TV
    • Toutes les vidéos
  • RetourForums
    • Hardware PC
    • PS5
    • Switch
    • Xbox Series
    • Overwatch 2
    • FUT 23
    • League of Legends
    • Genshin Impact
    • Tous les Forums
  • PC
  • PS5
  • Xbox Series
  • PS4
  • One
  • Switch
  • Wii U
  • iOS
  • Android
  • MMO
  • RPG
  • FPS
En ce moment Genshin Impact Valhalla Breath of the wild Animal Crossing GTA 5 Red dead 2
Etoile Abonnement RSS

Sujet : printf("blabla");

News événement
Jouez et tentez de remporter des places de cinéma ainsi que des goodies du film Kraven The Hunter
DébutPage précedente
«1  ... 146147148149150151152153154155156
Page suivanteFin
lokilok lokilok
MP
Niveau 11
04 février 2021 à 09:55:24

[08:43:48] <Bunyan>
Mais bon, j'suis plutôt partisan du "une méthode/fonction = un seul return" en règle général, et ça reste du choix personnel (en parti).

Tu connais des guidelines qui préconisent ça aussi ? Je sais que celle du C++ sont contre justement parce que ça complexifie les fonctions (le premier exemple le montre plutôt bien) : https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines.html#Rnr-single-return

boucif boucif
MP
Niveau 24
04 février 2021 à 10:43:51

Le 04 février 2021 à 00:47:46 ikigaimi a écrit :
pas nécessairement en fin de fonction, mais à certains endroits de la fonction (autant pour moi), comme dans ce code par exemple (lignes 55 et 65 de la version Java): https://www.techiedelight.com/quicksort-using-dutch-national-flag-algorithm/

Le 04 février 2021 à 00:47:46 ikigaimi a écrit :
pas nécessairement en fin de fonction, mais à certains endroits de la fonction (autant pour moi), comme dans ce code par exemple (lignes 55 et 65 de la version Java): https://www.techiedelight.com/quicksort-using-dutch-national-flag-algorithm/

Je le fais ça permet de sortir de la fonction si les paramètres en entrée sont incorrect, après suivant les cas vaut mieux lever une exception que faire un return, mais typiquement ce genre de cas est utile si tu as un traitement à faire sur un tableau, qu'au finale t'as aucun élément ou pas assez d'élément pour que ta fonction soit utile, tu as des paramètres vide ou null ... Ca t'évite que ta fonction s'exécute pour rien faire ou plante ...

ProTennix ProTennix
MP
Niveau 10
04 février 2021 à 12:12:55

Godrik qui me critiquait récemment pour mon apologie de l'assembleur, c'est justement dans ce genre de cas que générer le bytecode java ou l'assembleur C++ est utile pour bien comprendre ce genre truc.

Message édité le 04 février 2021 à 12:13:34 par ProTennix
lokilok lokilok
MP
Niveau 11
04 février 2021 à 12:15:32

Je vois difficilement en quoi montrer de l'assembleur faciliterait les explications :hap:

UnaryOperator UnaryOperator
MP
Niveau 9
04 février 2021 à 12:34:14

Le 04 février 2021 à 09:55:24 lokilok a écrit :

[08:43:48] <Bunyan>
Mais bon, j'suis plutôt partisan du "une méthode/fonction = un seul return" en règle général, et ça reste du choix personnel (en parti).

Tu connais des guidelines qui préconisent ça aussi ? Je sais que celle du C++ sont contre justement parce que ça complexifie les fonctions (le premier exemple le montre plutôt bien) : https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines.html#Rnr-single-return

Ca dépend du langage.

Typiquement en kotlin/scala, on peut réécrire le second cas à l'aide d'un pattern matching et bénéficier de syntaxe allégée, et pour le coup c'est bien plus propre:


fun main(args: Array<String>) {
    setOf(1, -2, 0)
    	.map { it.to(it.sign()) }
    	.forEach { (int, sign) -> println("$int is $sign") }
}

private fun Int.sign() = when {
  this < 0 -> "negative"
  this > 0 -> "positive"
  else -> "zero"
}
Message édité le 04 février 2021 à 12:38:45 par UnaryOperator
ProTennix ProTennix
MP
Niveau 10
04 février 2021 à 13:02:34

Le 04 février 2021 à 12:15:32 lokilok a écrit :
Je vois difficilement en quoi montrer de l'assembleur faciliterait les explications :hap:

Tu vois si le return dégage de la StackFrame

lokilok lokilok
MP
Niveau 11
04 février 2021 à 15:09:31

UnaryOperator, c'est pas tant le pattern matching qui rend ça possible, c'est plus le fait que if / else c'est uniquement un statement en C++ alors qu'en Kotlin ça peut être utilisé en tant qu'expression. Puis derrière t'as le pattern matching qui rend ça encore plus simple effectivement.

Mais oui c'est vrai certains langages facilitent le fait d'avoir un seul return, par contre je trouve le code de ton main pas très lisible, je crois que je commence à comprendre pourquoi godrik critique les API fonctionnelles style map/filter :hap:

ProTennix, mais pour que tes explications soient compréhensibles tu dois expliquer bien plus de choses que si tu décrivais simplement le fonctionnement de return du point de vue du langage de programmation. Je vois pas ce que ça simplifie.

Message édité le 04 février 2021 à 15:13:56 par lokilok
boucif boucif
MP
Niveau 24
04 février 2021 à 15:23:18

Le 04 février 2021 à 12:04:52 ikigaimi a écrit :

Le 04 février 2021 à 02:29:54 godrik a écrit :
Dans ces cas la c'est pour terminer la fonction a ce point de l'execution. Quand la ligne 44 (ou 65) est executer, la fonction termine et l'execution retourne a la fonction appellante.

Ca arrive parfois que l'on mettent return; a la fin du corps d'une fonction. Ca ne sert a rien, c'est typiquement une convention stylistique.

l'execution retourne à la fonction appelante, c'est-à-dire qu'on sort de la fonction et on passe à la suite (les lignes suivantes) ? ou bien on revient en début de fonction (comme une fonction récursive)? Désolée

En C# (en java ça doit être la même chose), on sort de la fonction courante et on continue l'exécution sur la fonction appelante.

UnaryOperator UnaryOperator
MP
Niveau 9
04 février 2021 à 16:04:06

Le 04 février 2021 à 15:09:31 lokilok a écrit :

Mais oui c'est vrai certains langages facilitent le fait d'avoir un seul return, par contre je trouve le code de ton main pas très lisible, je crois que je commence à comprendre pourquoi godrik critique les API fonctionnelles style map/filter :hap:

Je vois pas comment on peut faire plus lisible que ça. Faut vivre avec son temps. Le paradigme fonctionnel (surtout en kotlin/scala) c'est monnaie courante :noel:

godrik godrik
MP
Niveau 27
04 février 2021 à 16:57:10

Le 04 février 2021 à 09:55:24 lokilok a écrit :

[08:43:48] <Bunyan>
Mais bon, j'suis plutôt partisan du "une méthode/fonction = un seul return" en règle général, et ça reste du choix personnel (en parti).

Tu connais des guidelines qui préconisent ça aussi ? Je sais que celle du C++ sont contre justement parce que ça complexifie les fonctions (le premier exemple le montre plutôt bien) : https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines.html#Rnr-single-return

Non, en general, ce sont des conventions propres a des projets en particulier. Avoir un seul return est en effet une convention stupide a mon avis. Un seul return c'est une convention qui vient de langages comme C qui n'a pas de destructeur implicite et deterministe. Et ou du fait avoir un seul return donne un point unique de desallocations des ressources. En C++, ce n'est pas utile. MISRA demande un seul return je pense (ou le demandais a un moment)

Mais j'ai vu des projets ou toutes les fonctions void finissent par return; a la fin de la fonction. C'est completement redondant, mais par convention toute les fonctions ont un return a la fin. Avant la } final. Ca sert a rien, mais c'est la.

godrik godrik
MP
Niveau 27
04 février 2021 à 16:57:30

Le 04 février 2021 à 16:04:06 UnaryOperator a écrit :

Le 04 février 2021 à 15:09:31 lokilok a écrit :

Mais oui c'est vrai certains langages facilitent le fait d'avoir un seul return, par contre je trouve le code de ton main pas très lisible, je crois que je commence à comprendre pourquoi godrik critique les API fonctionnelles style map/filter :hap:

Je vois pas comment on peut faire plus lisible que ça. Faut vivre avec son temps. Le paradigme fonctionnel (surtout en kotlin/scala) c'est monnaie courante :noel:

eye of the beholder tout ca.

godrik godrik
MP
Niveau 27
04 février 2021 à 17:03:35

Le 04 février 2021 à 12:04:52 ikigaimi a écrit :

Le 04 février 2021 à 02:29:54 godrik a écrit :
Dans ces cas la c'est pour terminer la fonction a ce point de l'execution. Quand la ligne 44 (ou 65) est executer, la fonction termine et l'execution retourne a la fonction appellante.

Ca arrive parfois que l'on mettent return; a la fin du corps d'une fonction. Ca ne sert a rien, c'est typiquement une convention stylistique.

l'execution retourne à la fonction appelante, c'est-à-dire qu'on sort de la fonction et on passe à la suite (les lignes suivantes) ? ou bien on revient en début de fonction (comme une fonction récursive)? Désolée

Mettons les fonctoins recursives de cote pour un moment. Regardes ce bout de code. (ici c'est du C++, mais java pareil)


#include <iostream>

void f(int x) {

  std::cout<<"ici"<<std::endl;
  if (x > 0) {
    std::cout<<"la"<<std::endl;
    return ;
  }
  std::cout<<"ailleurs"<<std::endl;
}


int main () {

  std::cout<<"avant"<<std::endl;
  f (1);
  std::cout<<"milieu"<<std::endl;
  f(-1);
  std::cout<<"apres"<<std::endl;

  return 0;
}

Ca donne ca:
avant ici la milieu ici ailleurs apres

Quand on a atteint le return;, l'execution de f a terminer et l'execution est retourne a la fonction qui a appeller f, ici c'est main. Donc l'execution de main continue.

Si f etait une fonction recursive, return te ferait sortir de l'execution courrant de f. Et peut etre que la fonction appellante est f, ou peut etre que c'est autre chose.

lokilok lokilok
MP
Niveau 11
04 février 2021 à 17:24:14

[16:04:06] <UnaryOperator>

Le 04 février 2021 à 15:09:31 lokilok a écrit :

Mais oui c'est vrai certains langages facilitent le fait d'avoir un seul return, par contre je trouve le code de ton main pas très lisible, je crois que je commence à comprendre pourquoi godrik critique les API fonctionnelles style map/filter :hap:

Je vois pas comment on peut faire plus lisible que ça. Faut vivre avec son temps. Le paradigme fonctionnel (surtout en kotlin/scala) c'est monnaie courante :noel:

Supposons que dans le print tu veux aussi afficher un paramètre "foo" qui serait le résultat de "bar(sign)", tu ferais comment ?

Bunyan Bunyan
MP
Niveau 16
04 février 2021 à 19:11:05

lokilok

Tu connais des guidelines qui préconisent ça aussi ? Je sais que celle du C++ sont contre justement parce que ça complexifie les fonctions (le premier exemple le montre plutôt bien) : https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines.html#Rnr-single-return

Le second me plaît plus à l'oeil à cause de mon habitude, mais je n'irai clairement pas faire un retour là-dessus si jamais c'était un code que je relisais. Il est trop simple, et j'évite d'être dogmatique en règle général :)

Pour moi, c'est surtout dans des cas plus complexe où je n'ai pas un "return" dans chaque branche du "if", avec des méthodes qui font plus de 40 lignes que je vais avoir un souci avec ça, car le flux de code est largement complexifié ("alors, la seconde branche du if fait un return, ainsi que sa cinquième, mais les autres vont jusqu'au bout...").
Ouaip, on pourrait dire que c'est une conséquence plus qu'un problème dans mon exemple (le problème étant que ça ait été codé n'importe comment), mais de mon avis, ça amplifie facilement les problèmes quand il n'y a pas de sérieuses relectures ni un sérieux (et sensé) découpage en fonction/méthode.

Ensuite, niveau guidelines en elles-mêmes, le "single entry, single exit" viendrait des très vieux langages, ainsi que du C [1], pour éviter des fuites mémoires et faciliter la gestion du flux de code à priori.
Hormis ça, c'est une guideline que j'ai fréquemment entendue dans l'écosystème Java.

[1] : https://softwareengineering.stackexchange.com/questions/118703/where-did-the-notion-of-one-return-only-come-from

feanor_ledev feanor_ledev
MP
Niveau 7
31 mars 2021 à 10:20:13

Si vous voudriez commencer la programmation bas niveau, vous commencerez par C ou C++ ou Rust ? :(

J'ai des notions dans chacun de ces langages car j'ai bidouillé avec quelques fois, mais maintenant, à côté de mon apprentissage back end frotn end pour devenir Web dev, j'ai envie de me faire plaisir avec un langage assez bas niveau dans ce genre là. Autant pour apprendre que pour avoir dans mon bagage un langage véloce et qui me permettait de m'amuser à faire de petites librairies compatible pour Node ou deno.
Et j'avais un petit side project ou il me fallait un programme qui généré des fichiers etc, je comptais le faire en C# mais c'est l'occasion de le faire avec autre chose même si ça met plus de temps. :(

Vous prendriez quoi et pourquoi ? :(

Message édité le 31 mars 2021 à 10:24:26 par feanor_ledev
_S0uL _S0uL
MP
Niveau 9
31 mars 2021 à 11:23:34

Si c'est pour te faire plaisir, choisis celui qui te plaît le plus :)

D'un point de vu perso je choisirai Rust pour la découverte du langage ou C si je m'intéresse plus au projet qu'à l'apprentissage d'un langage.

feanor_ledev feanor_ledev
MP
Niveau 7
31 mars 2021 à 16:50:34

Le 31 mars 2021 à 11:23:34 _S0uL a écrit :
Si c'est pour te faire plaisir, choisis celui qui te plaît le plus :)

D'un point de vu perso je choisirai Rust pour la découverte du langage ou C si je m'intéresse plus au projet qu'à l'apprentissage d'un langage.

D'accord. Oui bah le truc c'est qu'aucun me plaît d'avantage, mais Rust ressortait pas mal dans les threads que j'ai de ci de la sur Reddit, etc

J'imagine que Dev avec ça doit être vraiment cool.

Pseudo supprimé
Niveau 7
31 mars 2021 à 19:14:34

Le 31 mars 2021 à 10:20:13 Feanor_ledev a écrit :
Si vous voudriez commencer la programmation bas niveau, vous commencerez par C ou C++ ou Rust ? :(

Si c'est pour faire de l'embarqué, C est le langage le plus supporté, donc le choix par excellence.

feanor_ledev feanor_ledev
MP
Niveau 7
04 avril 2021 à 20:15:32

J'ai choisis le C++. Sur ce que je veux faire je peux faire ou du C ou du C++, j'imagine que c'est mieux de faire le C++ du coup. :(

J'ai un peu poussé vers le C, avant de voir que je pouvais bien faire du C++, la partie difficile du C c'est comprendre les pointeurs en général et le fait qu'il faut tout faire a la main. C'est pas évident mais c'est cool ! :(

En tout cas c'est super sympa, et j'ai pas de difficulté a comprendre la syntaxe, les choses de bases comme ça. Comme quoi le C# et le JS/TS ça m'a pas mal aidé en fait. :(

En tout cas le C++ c'est vachement cool en fait, juste pour setup l'environnement c'est pas simple mais sinon après ca va tout seul pour commencer à bidouiller.

godrik godrik
MP
Niveau 27
05 avril 2021 à 22:22:42

plusieurs forumeurs m'ont contacte recement aux sujet de topics qui disparaissent et des topics d'aide aux devoir. En parler ici semble raisonable donc allons y.

1/ On voit pas mal de topic de "j'ai un probleme, aidez moi" qui recoivent une reponse avec plein de details. Et un jour apres, OP efface le message et l'aide apporter par le forum disparait. Autant on ne peut pas empecher les forumeurs d'effacer leur topics, autant on peut essayer d'eduquer les forumeurs. Mais comment? Que pensez vous d'un topic epingle? Qu'est ce qu'il devrait dire?

2/ On voit aussi pas mal de topic de "faites mon TP", voir meme de "passez mon exam a ma place" qui me paraissent etre completement contre productif. Les cas les plus extreme sont supprimes par la moderation. Mais comment est ce que vous pensez qu'on devrait traiter la question?

DébutPage précedente
Page suivanteFin
Répondre
Prévisu
?
Victime de harcèlement en ligne : comment réagir ?
Infos 0 connecté(s)

Gestion du forum

Modérateurs : godrik, LGV
Contacter les modérateurs - Règles du forum

Sujets à ne pas manquer

La vidéo du moment