JadeSalina a écrit:

Je veux bien arrêter de parler de Casey jusqu'à ce qu'il sorte une nouvelle révolution mondiale mais je sais pas si je pourrais me retenir de poster des trucs en restant "sage", on s'amuse bien par moments, vous ne trouvez pas ?

Je pense que pour le moment tu as du saouler tout le monde sur Casey , que beaucoup de personne te voit comme une personne imbu de sois même /donneuse de leçon et complètement fanatisé...
Que la discussion n'a apporté absolument rien (ça doit etre dans 3eme topic sur la question ), tu dis toujours les mêmes choses ,et les personnes sur ce forum aussi.
Et pourtant beaucoup disait (moi le premier) que la réflexion initiale aurait pu être intéressante , mais de la façon de comment tu l'as amené (avec beaucoup de mauvaise fois ) , n'a fait que empirer les choses.
Parce que oui utilisait le bazooka trop tôt , c'est une réflexion intéressante.
Mais à part ça , oui on s'amuse bien...

C'est peut être la meilleure chose à faire en terme de temps passé, mais les connaissances nécessaires derrière ne sont pas les mêmes... Alors que lui il va jusqu'à voir si tel ou tel port du CPU ne serait pas surchargé et fait en sorte d'appeler des opérations qui utilisent les ports d'une manière optimale.

Quand on t'as prouvé que par A + B qu'il fait n'importe quoi , qu'il comprend à peine ce qu'il fait et que ces notions d'optimisation sont mauvaise. ce n'est pas de la mauvaise foi ?
Et pourtant en terme d'architecture des ordinateurs , c'est mon domaine ,et non on ne peut pas savoir précisément quel ports seront utilisé précisément , et je pense qu'il ne le sait pas non plus.

Bien sur , comme c'est Casey qui le dit et qu'il sait trop optimiser...
Mais enfaite t'as aucun contrôle sur les ports de sortie (sinon ça s'appellerait pas un processeur out of order)

Surtout que se baser sur quel port sera utilisé est beaucoup trop "spécifique" (même si on y arrive) , vu que AMD et Intel sont différent sur ce point là , et même sur Intel cela diffère entre les gen.

Je sais que 90% ne sait pas de quoi je parle (et toi aussi) , mais pour moi , ça me semble flagrant qu'il y pige pas une sur ce qu'il fait ,et qu'il fait vraiment de la magie vaudou en asm.

C'est tout le soucis, aucun argument qu'on dise est bon , tant que ce n'est pas Casey qui le dit, c'est une discussion de sourd...

-
Edité par HelbaSama 31 mai 2022 à 18:37:51

Les commentaires que tu as mis dans ton code prouvent que tu ne maîtrises pas le langage... (et un certain test aussi, mais je te laisse le trouver, c'est tellement ridicule)

Ton move sur trivally_copyable ne move pas, les nodiscard à profusion inutiles

-
Edité par dragonjoker 31 mai 2022 à 19:14:44

dragonjoker a écrit:

Les commentaires que tu as mis dans ton code prouvent que tu ne maîtrises pas le langage... (et un certain test aussi, mais je te laisse le trouver, c'est tellement ridicule)

Ton move sur trivally_copyable ne move pas, les nodiscard à profusion inutiles

-
Edité par dragonjoker il y a 37 minutes

Vous pouvez me dire quel est le test en question pour savoir si c'est celui auquel je pense ? Et quelles commentaires ? Ah merci de dire que les nodiscard non inutiles, mais vous savez, on ne sais pas ce qui peut passer dans la tête de l'utilisateur, il vaut mieux être safe comme vous dites. Et "Ton move sur trivally_copyable ne move pas", vous voulez dire que j'ai mis des std::move qui sont redondants selon le type instancié (par exemple types primitifs) ? Dans ce cas ça va juste le copier comme on peut s'y attendre ce n'est pas bon ?

JadeSalina a écrit:

Ah merci de dire que les nodiscard non inutiles, mais vous savez, on ne sais pas ce qui peut passer dans la tête de l'utilisateur, il vaut mieux être safe comme vous dites. 

Tu t'enfonces de plus en plus dans le ridicule, en déformant volontairement ce qui est dit. Tu passe pas pour une personne maligne, mais pour une personne de mauvaise foi.

gbdivers a écrit:

JadeSalina a écrit:

Ah merci de dire que les nodiscard non inutiles, mais vous savez, on ne sais pas ce qui peut passer dans la tête de l'utilisateur, il vaut mieux être safe comme vous dites. 

Tu t'enfonces de plus en plus dans le ridicule, en déformant volontairement ce qui est dit. Tu passe pas pour une personne maligne, mais pour une personne de mauvaise foi.

Il y a marqué "les nodiscard à profusion inutiles",

J'ai mis des nodiscard uniquement sur les getter qui ne modifient pas l'objet (sans effets de bords), et donc pour lesquels il ne fait aucun sens de ne pas chopper la valeur de retour (d'où le nodiscard).

Donc c'est quoi ce qui est dit du coup ? Je ne veux pas du tout déformer les propos

EDIT : C'est justement pas moi qui suit de mauvaise foi ici... dragonjoker qualifie mes nodiscard de "inutile" alors qu'au contraire ils sont tous justifiés, à quel moment je déforme les propos ? Je me demande presque si vous avez pas juste survolé le code et vu plein de nodiscard en vous disant "tiens elle fait exprès de complexifier inutilement" alors que pas du tout !!

-
Edité par JadeSalina 1 juin 2022 à 0:01:43

> Casey il fait vraiment des trucs complexes, vous savez ce que j'appelle des trucs complexes ? Faire du multithread sans lib, sans mutex, en full atomics, et utiliser des intrinsics.

C'est pas très dur de faire des trucs complexes et la complexité n'implique pas la qualité ou les performances. Après faut voir si ça a un intérêt.

Sinon je suis assez d'accord avec le titre et c'est d'ailleurs ce qui est fait assez souvent, la plupart des gens s'adaptent à leur besoin et n'écoutent pas aveuglément sans comprendre. Faut juste savoir si on veut des perfs, de la maintenabilité, de la généricité etc ..

Après avoir des perfs n'implique pas du code illisible, la maintenabilité du code lent, la généricité du code complexe etc ..

Tu as des projets persos ? ça pourrait être pas mal de faire un langage

JadeSalina a écrit:

C'est justement pas moi qui suit de mauvaise foi ici... dragonjoker qualifie mes nodiscard de "inutile" alors qu'au contraire ils sont tous justifiés, à quel moment je déforme les propos ? Je me demande presque si vous avez pas juste survolé le code et vu plein de nodiscard en vous disant "tiens elle fait exprès de complexifier inutilement" alors que pas du tout !!

Parce que [[nodiscard]] n'a,justement, du sens que dans le cas où la fonction renvoie une valeur que l'utilisateur (de la fonction) pourrait trop facilement oublier de récupérer, alors qu'elle lui apportera une information peut-être essentielle...

Par exemple: sais tu  que printf renvoie une entier?  Sais tu ce que représente cet entier? Mais, en toute honnêteté, as tu quoi  que ce soit à foutre de l'information que cet entier t'apporte?

Et - ce n'est pas le cas de printf, nous sommes d'accord -- cette information risquait de compromettre de façon majeure la suite du traitement, parce qu'elle t'indiquait qu'elle n'a pas été en mesure de faire son taf correctement?

Ne serait-il pas des plus intéressant pour le type qui a fait appel à cette fonction (et qui ne l'a pas forcément écrite, voire, qu'il en a oublié les détails) d'avoir un signal fort de la part du compilateur qui lui dise "hé, cette fonction te renvoie une valeur à laquelle tu ferais peut-être bien de prêter attention"?

Voilà le cas d'utilisation de [[nodiscard]].  Il n'y a aucun sens à  mettre un [[nodiscard]] sur une fonction dont c'est la nature même de renvoyer une information demandée par l'utilisateur car, s'il y fait appel, c'est qu'il s'attend à  récupérer cette information, il y a quand même un minimum de logique à  avoir

Prenons un autre exemple: la fonction membre instert de std::vector.  Elle renvoie un itérateur sur le premier élément qui a été inséré par cette fonction.

Dans la plupart des cas, tu t'en foutra royalement de cet itérateur.  Dans certaines situation, tu apprécieras de l'avoir, histoire de continuer le traitement sur cet élément. Cela ne fait aucun sens d'ajouter un [[nodiscard]]  de ce cas.

Par contre, sur une fonction proche de

int extractDatas(Source, Collection & datas);

dont la valeur de retour correspond au  nombre d'éléments extraits à partir de la source et placés dans la collection

Dans le "pire des cas", 0 t'indiquera qu'il y a clairement eu une erreur. Dans le meilleur des cas, une différence entre la valeur renvoyée et une valeur connue et attendue t'indiquera une "réussite partielle".

Vu que tout le traitement qui suit sans doute l'appel à cette fonction va se baser en grande partie sur le contenu de datas, et donc sur le travail effectué par cette fonction, il est effectivement peut-être intéressant de tagger cette fonction en [[nodiscard]] pour donner l'occasion à l'utilisateur de réagir "le plus vite possible" au problème occasionné par cette fonction.

Il ne s'agit pas de mettre tout et n'importe quoi n'importe où n'importe quand.  Il s'agit de mettre les jalons intéressants aux endroits où ils ont du sens et où ils pourront éviter les problèmes aux utilisateurs de tes fonctions.

Il n'y aurait aucun sens à placer un panneau de circulation indiquant "pendant dix kilomètres, la route sera strictement rectiligne, sans le moindre croisement".  Par contre, il est ** peut-être ** intéressant de mettre un panneau signalant que tu as un tournant en épingle à cheveux dans 250 m, c'est à dire, juste après le bosquet qui t'en cache la vue

Quand on t'as prouvé que par A + B qu'il fait n'importe quoi

Je suis pas très convaincue de la preuve... Pour moi il aurait fallu que vous recodiez le truc à votre manière que qu'on voit directement que vous avez de meilleurs performances, mais je vais absolument pas vous demander de faire ça (il y a pas juste des cubes, le système d'éclairage est quelque peu complexe, même si vous allez me dire qu'en suivant un tuto learnopengl on fait mieux, mais encore une fois je n'ai pas la preuve sous les yeux, mais bon c'est pas grave)

Il n'y a aucun sens à mettre un [[nodiscard]] sur une fonction dont c'est la nature même de renvoyer une information demandée par l'utilisateur car, s'il y fait appel, c'est qu'il s'attend à récupérer cette information, il y a quand même un minimum de logique à avoir

Aaaaaaaah merciiiiiiiiiiiiiiii !!!!! Evidemment que c'est complètement ravagé de se dire que l'utilisateur pourrait potentiellement oublier de récupérer le résultat d'un getter.

Il s'agit de mettre les jalons intéressants aux endroits où ils ont du sens et où ils pourront éviter les problèmes aux utilisateurs de tes fonctions.

 Vous allez me faire pleurer... C'est ce que j'essaye de dire depuis des mois : il faut prendre des mesures qui permettent effectivement de s'éviter des problèmes, si la personne n'a strictement aucune chance de commettre telle ou telle erreur (comme appeler un getter dans le vide) alors ça ne sert à rien de prévenir l'erreur, et d'autant plus si la mise en place de la protection entraine des coûts collatéraux (complexification de la structure du code ou autre) (ce n'est pas le cas de nodiscard bien sûr, à part un header un peu moins lisible).

Mais je me disais que peut être, quand on écrit la bibliothèque standard elle même, on fait en sorte d'avoir toutes les précautions possibles, même les plus idiotes, car ça va être utilisé à très grande échelle (on parle de std::vector quand même), sinon si c'était juste un truc vite fait pour moi, j'aurais absolument pas mis de nodiscard ici. Apparemment selon certains standards, il faudrait le mettre dans ce cas https://rules.sonarsource.com/cpp/RSPEC-6007 

Et sinon pour le reste du code c'est ça que vous qualifiez de complexe ou alors je suis complètement à côté de la plaque ? (et expliquez moi svp, pas juste "oui t'as rien compris") Je rappelle que tout ça est parti du fait que j'avais dit que std::vector est le 2ème container de la STL le plus simple en terme de logique, par rapport à des std::map par exemple, implémentées avec des arbres rouge noir. Et j'ai dit aussi que le C++ complexifiait déraisonnablement l'implémentation, du fait du fonctionnement du langage (exceptions, moves, etc), comparé à une implémentation en C qui n'utilise pas ces concepts

-
Edité par JadeSalina 21 juillet 2022 à 0:05:04

JadeSalina a écrit:

Je suis pas très convaincue de la preuve... Pour moi il aurait fallu que vous recodiez le truc à votre manière que qu'on voit directement que vous avez de meilleurs performances, mais je vais absolument pas vous demander de faire ça (il y a pas juste des cubes, le système d'éclairage est quelque peu complexe, même si vous allez me dire qu'en suivant un tuto learnopengl on fait mieux, mais encore une fois je n'ai pas la preuve sous les yeux, mais bon c'est pas grave)

C'est ce que je dis , tant que c'est Casey l'a dit , GBdivers l'a montré.
Tout ce qui font du rendu 3D ici te diront pareil que moi que sa façon de faire et mauvaise.
Tu veux voir comment on fait mieux, regarde les démo de Lynix oy DragonJoker.

Mais donc tu veux voir un code 3D en asm, qui prend le Throughput/latency ,et les ports en compte ?
Tu peux voir ici :  code VU
Ce code s'il est peu compréhensible, c'est parce que le code doit être en désordre (vu que le processeur est dans l'ordre - in order).

Mais tu confirme ce que je disais, tu prend en compte que les arguments d’autorité...

> C'est ce que j'essaye de dire depuis des mois : il faut prendre des mesures qui permettent effectivement de s'éviter des problèmes, si la personne n'a strictement aucune chance de commettre telle ou telle erreur (comme appeler un getter dans le vide) alors ça ne sert à rien de prévenir l'erreur

Ce n'est clairement pas ce que tu dis dans cette discussion tout du moins...
Dans cette discussion tu prétends que ça ne te sert à rien de mettre des vérifs à la compilation, parce que "ça te saoule" et que "tu ne feras jamais l'erreur", donc bon, ça va, tu rentres toujours dans tes chaussures ?

De plus, dans ton implémentation, tu as rajouté des [[nodiscard]] juste pour faire style, mais on t'a jamais demandé d'en mettre partout, c'est toi qui l'as fait pour faire bonne figure, alors que c'est contre productif ici.

L'exagération dans un sens ou dans l'autre ne t'apporte pas de crédibilité, au contraire.

Je retire ce que j'ai dit, sur la dissonance cognitive. Je pense bien qu'il y en a une, mais elle n'est rien comparé à l'effet Dunning-Kruger qu'on observe ici.

Ne t'inquiète pas, on est nombreux à être passés par là. Bonne descente.

Lynix a écrit:

Je retire ce que j'ai dit, sur la dissonance cognitive. Je pense bien qu'il y en a une, mais elle n'est rien comparé à l'effet Dunning-Kruger qu'on observe ici.

Ne t'inquiète pas, on est nombreux à être passés par là. Bonne descente.

Haha, je n'ai pas totalement lu le reste des messages beaucoup trop, mais il semblerait que chacun arrive à la même conclusion.

> si la personne n'a strictement aucune chance de commettre telle ou telle erreur (comme appeler un getter dans le vide) alors ça ne sert à rien de prévenir l'erreur

Ca peut toujours arriver, même si ça peut paraitre évident la plupart du temps il suffit d'ajouter un peu de metaprog à base de macros pour que l'erreu r devienne moins facile à identifier vu que le code est moins clair.

Donc la question c'est plutôt, est-ce qu'il faut passer du temps à mettre des sécurités pour des cas rares et spécifiques, et ça c'est une question de choix ou d'utilisation du code fourni.

JadeSalina a écrit:

Vous allez me faire pleurer... C'est ce que j'essaye de dire depuis des mois : il faut prendre des mesures qui permettent effectivement de s'éviter des problèmes, si la personne n'a strictement aucune chance de commettre telle ou telle erreur (comme appeler un getter dans le vide) alors ça ne sert à rien de prévenir l'erreur, et d'autant plus si la mise en place de la protection entraine des coûts collatéraux (complexification de la structure du code ou autre) (ce n'est pas le cas de nodiscard bien sûr, à part un header un peu moins lisible).

Si l'on est d'accord sur le principe, le gros problème est que ta vision des "problème potentiels" ne tient absolument pas la route dés que l'on parle d'un développement à peine plus complexe que deux ou trois classes triées sur le volet.

Dés que ta vision va se frotter à ne serait-ce qu'une dizaine de fichier d'implémentation et à deux développeur -- voire, à un "ras-le-bol temporaire" qui te fera abandonner ton projet pour plus de deux semaines -- tu vas te retrouver dans la m...de parce que tu as voulu "gagner un peu de temps" en ne posant pas les jalons qui auraient pu t'éviter les problèmes.

Pour faire simple: tout comme il y a (généralement) trois étapes majeures à l'introduction d'un code dans un projet, à savoir:

• la compilation
• la période de tests (si elle existe)
• la mise en production

on peut également dire qu'il y a trois sortes de problèmes:

Ceux qui sont repérés lors de la compilation: à ce stade, ce n'est qu'étourderie, distraction et fautes de frappe.  On ne parle même pas encore d'une erreur car le seul à savoir que le problème a pu exister à un moment quelconque, c'est celui qui a écrit ( et corrigé) le code.

Ceux qui sont repérés lors de la période de tests (si elle existe) : A ce stade, on peut effectivement parler d'une "erreur".  C'est sous cette forme que les bibliothèques de tests te le présenteront.  C'est sous cette forme que la personne qui "fait le test du singe" avec ton programme te le présentera également : "dis, jade, il semblerait que tu as fait une erreur à <tel endroit>, parce que, quand j'introduit "hello world" (alors qu'on me demande d'introduire un entier), j'obtiens 3587"

Et enfin, il y a ceux qui ne sont remarqué qu'après la mise en production, qu'après que ton code n'ai été diffusé et qu'on ait commencé à l'utiliser. A ce stade, nous ne parlons plus d'erreur, mais bien de "bug". Parce que ton code (qui n'est d'ailleurs plus sous cette forme à proprement parler depuis l'étape précédente) est enfermé dans une "boite noire" et ressemble "à de la magie" pour l'utilisateur lambda: le programme qui l'utilise.

Le gros problème, c'est que l'on peut -- grosso modo -- estimer que le temps nécessaire à la résolution d'un problème est proportionnel au temps qu'il te faut pour en prendre conscience depuis l'écriture du code qui l'occasionne:

Si tu te rends compte d'un problème (le fameux if( a = b) au lieu d'un if(a == b) ou un ; qui manque à la fin d'une instruction) simplement en relisant ton code, la correction est immédiate et ne prend que le temps de positionner le pointeur de ton éditeur de textes sur l'endroit fautif et d'ajouter le symbole manquant.

Si, alors que tu es occupée à développer une fonction "un peu complexe", tu te dis que "oui, mais ho, stop, à tel endroit je fais une connerie", tu peux te dire que tu as déjà le début de la solution au moment où tu t'en rends compte.

Autrement, ben, s'il n'y a pas de solution apparente, c'est sans doute qu'il n'y a pas de problème, n'est-ce pas?  Du moins, jusqu'à ce que le compilateur mette le doigt sur un problème, fut-il "potentiel".

Car tu peux faire confiance au compilateur: si tu lui donne les bonnes instructions, les bonnes règles de conduite, il va repérer ces problèmes -- fussent-ils "potentiels" -- beaucoup plus facilement et certainement que toi.  Je peux te l'assurer

Là, le temps de correction du problème risque d'être déjà ... plus long, car tu auras peut être plus de mal à le comprendre et à  en trouver la source, surtout si tu as modifié plusieurs fichiers (à l'exemple de l'oubli de déclarer une fonction constante que tu as donné plus haut).

Puis vient la période de tests.  Attention, je ne parle pas ici d'une approche de type TDD, où chaque ligne écrite occasionne une recompilation et l'exécution d'un test se solde par une erreur qu'il s'agit de corriger dans le code pour pouvoir passer à l'étape suivante.  Je parle du "test du singe":

Tu compile ton projet en entier et tu le fais fonctionner en t'arrangeant pour passer par l'ensemble des situations possibles et pour "faire une connerie" à chaque situation, voir, en t'arrangeant pour tester une succession d'actions qui aurait été repérée, à un moment donné, comme pouvant poser problème.

Car il faut bien te dire que c'est comme cela que l'utilisateur final de ton programme va l'utiliser.  Il ne le fera surement même pas exprès. Mais tu peux être sure que si une connerie peut occasionner le mauvais fonctionnement de ton programme, il y aura toujours un utilisateur final pour la commettre.

Si tu remarque un problème à  ce moment là, il te faudra sans doute "un peu plus de temps" pour le corriger que si tu l'avais remarqué à la première étape.  Et c'est normal: Tu ne feras pas le "test du singe" à chaque ligne écrite et tu attendras généralement d'avoir terminé l'implémentation d'une fonctionnalité particulière (après tout, pourquoi faire le test du singe sur une fonctionnalité dont on sait qu'elle ne fonctionne pas "en l'état", n'est ce pas? )

Cela te prendra d'autant plus de temps que tu auras écrit beaucoup de code pour implémenter cette fonctionnalité, car le gros problème du test du singe, c'est que  l'origine des problèmes qu'il permet de mettre en avant est malheureusement souvent ... très écartée de l'endroit où elle apparait à l'usage.

C'est d'ailleurs à ce moment là  que tu vas commencer à utiliser le débugueur.

Et si je te dis que ce qui n'était à la base qu'une distraction de ta part, qui est devenu (lors du passage à la période de tests) devient un bug une fois cette période passée, c'est parce que c'est -- dans l'idéal -- qu'après avoir eu le "GO" du  testeur que tu fera passer ton code de sa branche "développement" à la branche de "production".

C'est le moment précis où ton code va commencer à se confronter effectivement avec "l'extérieur", où il va "sortir du cocon de l'équipe de développement".

Seulement, s'il reste un problème avec le code que tu as écrit -- et je te répète que les "il suffit de" ne ... suffisent jamais à te garantir que ce ne sera pas le cas -- il ne sera découvert qu'à force d'usages "encore plus idiots et plus aberrants" que ceux que l'on aura tentés lors de la période de tests.

Le temps nécessaire avant que le problème ne finisse par se présenter à l'utilisateur peut donc varier entre trois jours et ... six mois, un an, ou peut-être même d'avantage.  Et ce qu'il faut bien comprendre, c'est que, à ce moment là, toi, en tant que développeuse, tu n'en as même pas encore conscience!

Car, pour que tu puisse en avoir conscience, il faudra que l'utilisateur qui aura souffert du problème ... ait pris "la peine" de le faire remonter d'une manière ou d'une autre (de faire un "rapport de bug"). Ce qui est loin d'être gagné pour une quantité incroyables de bonnes (ou de mauvaises) raisons

Le gros problème, c'est que le développement du projet ne vas généralement pas s'arrêter après la mise en production, que ton collègue va peut être introduire sa propre branche -- correspondant au développement de la fonctionnalité sur laquelle il a travaillé pendant un mois -- dans la branche "développement" générale et que toi aussi, tu auras eu plus que le temps de rajouter un tas de fonctionnalités à la branche de développement, même si elles n'ont pas encore été mises en production.

"Avec un peu de chance", il se peut que la fonctionnalité qui pose problème et pour laquelle tu auras eu un rapport de bug soit restée "particulièrement isolée", dans le sens où il n'y aurait pas (ou "très peu) d'autre fonctionnalité développées par la suite qui l'auraient utilisée.

Cependant, il ne faut pas trop y croire... Selon le temps qu'il aura fallu au bug pour être remonté (et le rythme de développement de ton projet), il y a beaucoup plus de chances pour que le résultat de la fonctionnalité qui pose problème ait été réutilisé par une autre, dont le résultat aura lui-même été réutilisé par encore une autre, dont le résultat ... je pourrais continuer longtemps comme cela, tu auras compris l'idée

Et là où l'histoire devient "particulièrement vache, c'est que, si le problème dont souffre ta fonctionnalité ne fait "qu'occasionner un résultat aberrant" (parce qu'il n'est simplement pas "suffisamment juste" ou "suffisamment précis" pour l'usage qui sera fait du résultat), même si la fonctionnalité qui utilise ce résultat a été développée en respectant la pratique du TDD, tu es très loin d'être tirée d'affaire.

Car, il va falloir trouver  l'origine du problème -- pour cela, il va falloir investiguer dans du code dont tu as oublié les détails (et peut-être même certaines "grosses lignes) -- avant d'arriver à y apporter une solution.

Et, si tu as de la chance, les tests unitaires effectuer (sur base d'un TDD) sur toutes les fonctionnalités développées à  partir de la tienne se mettront à planter misérablement.  Ton beau sapin de noel rempli de boules vertes se transformera en une monstruosité remplie de boules rouges.  Il s'agira donc de corriger tous les problèmes mis en avant suite à "ta simple correction".

Ne viens pas nous dire que cela n'arrivera jamais.  C'est déjà arrivé en 2010 avec -- si mes souvenirs sont bons -- une fonction de hachage particulièrement prisée...

JadeSalina a écrit:

Mais je me disais que peut être, quand on écrit la bibliothèque standard elle même, on fait en sorte d'avoir toutes les précautions possibles, même les plus idiotes, car ça va être utilisé à très grande échelle (on parle de std::vector quand même), sinon si c'était juste un truc vite fait pour moi, j'aurais absolument pas mis de nodiscard ici. Apparemment selon certains standards, il faudrait le mettre dans ce cas https://rules.sonarsource.com/cpp/RSPEC-6007

Décidément, j'admire l'art dont tu fais preuve pour passer d'une extrême à l'autre afin de contredire les gens...

Parce que pour passer de "ca me saoule d'écrire cinq lettres ou de passer cinq minutes à comprendre pourquoi le compilateur m'engueule quand ca arrive" à "oui, mais regardez la règle N°6007 d'un outil d'analyse syntaxique dont le but est de signaler tous les problèmes qui pourraient survenir à un moment ou un autre" (n'utilise pas une norme MIRSA ou très semblable?)... Tiens, ca m'a donné une furieuse envie de réécouter Jaques Dutronc (ce qui ne nous rajeuni pas ) ..

Rassures moi, quand tu décidera de retourner ton pantalon, tu t'assureras au moins de ne pas le faire en publique ?

-
Edité par koala01 1 juin 2022 à 16:32:28

Jade n'a pas une pensée "d'ingénieur" , parce que tout simplement faire en sorte de faire qu'un code qui se prépare pour la pire des scénario , ça à un nom : https://fr.wikipedia.org/wiki/Loi_de_Murphy

Et effectivement si on code on doit avoir aussi en tete : "Tout ce qui est susceptible d'aller mal ira mal".

Merci koala01 pour votre réponse détaillée et bienveillante comme à chaque fois (vous devriez écrire un livre ).

le gros problème est que ta vision des "problème potentiels" ne tient absolument pas la route dés que l'on parle d'un développement à peine plus complexe que deux ou trois classes triées sur le volet. [...] Dés que ta vision va se frotter à ne serait-ce qu'une dizaine de fichier d'implémentation et à deux développeur...

 Sur ce point là je ne peux rien dire, effectivement j'ai pas l'habitude de faire des projets avec beaucoup de développeurs, je peux juste m'en tenir à ce que vous-savez-qui et d'autres ont pu dire, mais je ne peux pas vérifier moi même ces informations. Tout ce que je peux dire, c'est que dans mes trucs perso je m'en sort bien sans avoir besoin de mettre des jalons de partout, mais c'est peut être pas représentatif de la réalité, je vous l'accorde.

Décidément, j'admire l'art dont tu fais preuve pour passer d'une extrême à l'autre afin de contredire les gens...

Je pensais que vous étiez dans l'extrême de mettre le plus de vérifications possibles, ce n'est pas pour contredire qui que ce soit, je pensais que vous auriez mis le plus de vérifications possibles et imaginable.

De plus, dans ton implémentation, tu as rajouté des [[nodiscard]] juste pour faire style, mais on t'a jamais demandé d'en mettre partout, c'est toi qui l'as fait pour faire bonne figure, alors que c'est contre productif ici.

Encore une fois, c'est sûr à 100% que j'aurais pas mis les nodiscard si c'était mon code perso, je les ai mis car je pensais que c'est ce que vous auriez fait, pour être dans le style le plus "théoriquement correct" possible que vous avez l'air de défendre tant, car je maintiens que ça n'a pas de sens d'appeler un getter sans effet de bords et sans récupérer sa valeur, et que même si normalement personne ne le ferait, pourquoi vous dites que ça serait contre productif de les mettre ici ? Microsoft n'est pas de cet avis apparemment https://github.com/microsoft/STL/blob/60decd0d829e68666b556780002c83605d748d80/stl/inc/vector#L1724 

@koala01, vous m'avez repris quand j'ai dit que std::vector était le 2ème plus simple container, en me disant que ça n'a rien de simple et même que "ce sont sans doute de loin les comportements les plus complexes à mettre en oeuvre", en parlant de reserve/resize en disant que "leur comportement différent en fonction des circonstances (ne font rien si la taille ou la capacité demandée est inférieure respectivement à la taille ou à la capacité actuelle)".

J'ai donc implémenté un mini vector vite fait en respectant les 10 besoins essentiels que vous avez demandé et en le faisant en "style C++" donc à l'opposé total de ce que j'avais fait pour mon ETL que vous avez trouvé si moche. Je vous dit donc ce que j'en ai pensé : je trouve que c'est extrêmement trivial et je ne comprends pas pourquoi vous dites que c'est "complexe à mettre en oeuvre". C'est pour ça que j'aimerais que vous me disiez ce qui ne va pas dans mon code puisque si je trouve que c'est si simple, c'est forcément que j'ai du foirer un truc non ? (en sachant que je n'ai pas testé le code au delà du main que vous avez écrit, il y a peut être des bugs à la con).

l'effet Dunning-Kruger qu'on observe ici.

Ecoutez ce n'est pas ma faute si vous trouvez que c'est complexe alors que moi je le fait facilement, qu'est ce que vous voulez que je vous dise

-
Edité par JadeSalina 21 juillet 2022 à 0:04:43

JadeSalina a écrit:

Ecoutez ce n'est pas ma faute si vous trouvez que c'est complexe alors que je moi je le fait facilement, qu'est ce que vous voulez que je vous dise

J'ai bien conscience que c'est du troll, mais c'est exactement ça le mode de pensée sous Dunning-Kruger. Tu n'as pas de vue d'ensemble de la situation et tu ne te concentres que sur des points spécifiques où en distordant la réalité tu peux avoir raison.

Si c'est si simple, pourquoi tu t'es plantée sur ta première implémentation de vector (qui ne pouvait même pas accueillir de type sans constructeur par défaut, par exemple) ? Serais-tu capable de commettre des erreurs toi aussi ?

Mais si quelqu'un qui prétend qu'il suffit de ne pas commettre des erreurs se trompe, alors ... tout le monde peut se tromper à un moment donné ? Les bras m'en tombent.

Bref, je l'ai déjà dit, ça ne sert à rien de discuter avec toi à ce stade de ton apprentissage et au vu de ton état d'esprit actuel, tu n'es pas la première débutante à péter plus haut que ton cul qu'on croise, et probablement pas la dernière. Tout ce que tu auras prouvé jusqu'ici c'est ta compétence à énerver tous les experts du forum.

JadeSalina a écrit:

qu'est ce que vous voulez que je vous dise

Va trouver un boulot.

>je pensais que vous auriez mis le plus de vérifications possibles et imaginable.

En debug, oui.

Donc, s'il n'y a pas d'impact sur le résultat final, oui, systématiquement. Mais un "[[nodiscard]]" a un impact sur le code client, donc à ne mettre que pour fiabiliser le code client "de prod".

>un getter sans effet de bords

Les getter à effet de bords, c'est courant (cache, etc...) et parfois ils le deviennent et il faut donc que l'interface donne la possibilité de le faire si nécessaire, sans avoir à recompiler tous les codes client "de la terre".

>, et que même si normalement personne ne le ferait,

Toi, t'es pas tombé sur des "getter" qui "chauffe" le bousin. (Et là, un "[[nodiscard]]" est plus qu'un truc qui casse les couilles, mais une erreur)

>pourquoi vous dites que ça serait contre productif de les mettre ici ?

Ca dépend de la "philosophie" du bidule qu'on développe (haut niveau d'abstraction potentiel, close to metal pour juste de la praticité, etc...).

Je pense que leurs commentaires sont un peu à l'emporte-pièce et qu'ils "veulent" te prendre à contre-pied. Pour que tu réfléchisses un peu plus loin que de pisser du code sans la moindre réflexion sur l'usage du bidule. Ce que la réflexion sur '[[nodiscard]] Or not [[nodiscard]]' devrait te pousser à faire.

Si le fait de prendre un peu de temps sur '[[nodiscard]] Or not [[nodiscard]]' est inutile pour toi, c'est que tu ne prends pas assez de temps pour concevoir correctement tes "interfaces" programmatiques. Il faut aider à leur bonne utilisation : "rendre compliqué sa mauvaise utilisation et simple sa bonne utilisation".

>Microsoft n'est pas de cet avis

Comme déjà indiqué, c'est une question de "philosophie" de l'interface. Il n'y a pas de "oui/non" manichéen, faut juste que cela soir cohérent au niveau de toute l'interface programmatique. Donc y réfléchir, donc ne pas dire que cela ne sert à rien de but en blanc.

-
Edité par bacelar 1 juin 2022 à 18:19:52

Pour le coup je ne vois aucune raison de ne pas rajouter un nodiscard à une fonction sans effets de bords: plus exactement, une non-void qui n'altère rien d'autre que ses variables locales, qui ne touche pas aux I/O, etc.

Pour exactement les memes raisons que VC6 est le dernier compilo que j'ai eu en main qui acceptait de binder des rvalues avec des références non-const.
--> C'est débile et cela n'a aucun sens. Si on veut appeler une telle fonction, alors on veut stocker son résultat

Si c'est si simple, pourquoi tu t'es plantée sur ta première implémentation de vector (qui ne pouvait même pas accueillir de type sans constructeur par défaut, par exemple) ? Serais-tu capable de commettre des erreurs toi aussi ?

Alors oui je peux faire des erreurs j'ai pas dis le contraire surtout sur un truc que je fait vite fait one shot sans même tester derrière. Quand je disais ne pas faire d'erreurs, c'est par exemple par rapport aux erreurs que "const" permettrait de détecter, mais je fait plein d'autres types d'erreurs. Vous avez complètement raison que je m'était plantée sur ça. En fait vous allez rigoler, j'avais commencé par utiliser malloc puisqu'ici on veut justement initialiser à la main, mais vous savez quoi ? Moi qui aime la simplicité du C, au moment de vouloir copier une valeur en mémoire dans le push_back, j'ai machinalement écrit "tab[i] = elem", quelle sotte que je suis, comme si ça ressemblait à ce qu'on voulait faire... (c'est ironique, bien sûr que ça ressemble). Le truc c'est que appeler operator= sur de la mémoire non initialisée ça fait de la m****, donc mon "quick fix" a été de passer par new pour qu'il initialise, mais la bonne chose à faire était d'appeler le constructeur et pas operator= bien entendu. D'où le fait que le code aurait pas compilé en lui passant un T non default-constructible puisque je faisait une initialisation par défaut.

Il n'empêche que le truc en lui même reste simple, c'est pas parce qu'on fait une erreur bete que ça rend le truc compliqué (d'ailleurs vous êtes rapidement allé voir le code, car j'ai corrigé le problème dans l'heure qui suivait le post, après avoir fait une petite pause (oui au passage je trouve que faire des pauses et revenir sur son code plus tard ça permet de trouver des bugs automatiquement )).

Si vous voulez tout savoir, je trouve à titre personnel que c'est impossible d'implémenter quoi que ce soit, même 3 lignes, sans avoir au moins un retour du compilateur. Pour le js::vector il m'a quand même fallu quelques compilations avant que ça compile, il manquait des ';' et autres typos de ci de là, ce qui ne veut pas dire pour autant que "mettre un ';' après une instruction" est un problème compliqué en soi

Si le fait de prendre un peu de temps sur '[[nodiscard]] Or not [[nodiscard]]' est inutile pour toi, c'est que tu ne prends pas assez de temps pour concevoir correctement tes "interfaces" programmatiques. Il faut aider à leur bonne utilisation : "rendre compliqué sa mauvaise utilisation et simple sa bonne utilisation".

Justement j'ai eu une réflexion, qui était celle-ci : je met nodiscard ça ne sert à rien d'appeler un getter qui ne fait rien d'autre que renvoyer une valeur si c'est pas pour utiliser cette dite valeur, et d'autant plus que là c'est plutôt du code de "lib" et pas un truc interne qu'on se fait vite fait et qui va potentiellement beaucoup évoluer (et donc le nodiscard se mettrait dans nos pattes sans arrêt)

-
Edité par JadeSalina 1 juin 2022 à 19:28:30

int main() // 1
{
    [[maybe_unused]] int a = 0;  // 2
    return 0; // 3
}

J'ai gagné quoi ?

JadeSalina a écrit:

Sur ce point là je ne peux rien dire, effectivement j'ai pas l'habitude de faire des projets avec beaucoup de développeurs, je peux juste m'en tenir à ce que vous-savez-qui et d'autres ont pu dire, mais je ne peux pas vérifier moi même ces informations. Tout ce que je peux dire, c'est que dans mes trucs perso je m'en sort bien sans avoir besoin de mettre des jalons de partout, mais c'est peut être pas représentatif de la réalité, je vous l'accorde.

Et c'est bien ce que l'on te reproche à longueur de discussion. C'est de parler sans savoir, en te basant sur des "on dit que" et sur la seule expérience que tu aies: des projets persos sans doute bouclés pour la plupart en moins d'une semaine

Si, encore, tu  te contentais de "parler sans savoir", cela irait encore.  Le fait est que, en plus, tu viens nous présenter tes certitudes (qui ne tiennent pas la route avec l'expérience) comme des vérités divines, impossibles à contredire

Et, cerise sur le chapeau, tu sembles en permanence persuadée que des gens qui ont quinze ans (et plus) d'expérience ne comprennent simplement pas les technique que tu essayes de leur expliquer, alors qu'ils les connaissent depuis qu'ils sont sortis de l'école, alors que, contrairement à toi, nous avons conscience que si la technique a un "certain intérêt", elle présentera, dans la plupart des projets que nous allons traiter, plus d'inconvénients que d'avantages.

JadeSalina a écrit:

Je pensais que vous étiez dans l'extrême de mettre le plus de vérifications possibles, ce n'est pas pour contredire qui que ce soit, je pensais que vous auriez mis le plus de vérifications possibles et imaginable.

Non, je suis dans "le juste milieu" qui consiste à prendre les précautions que je juge utiles ou nécessaires.

J'admets cependant volontiers que la notion de "précautions utiles ou nécessaires" tend chez moi à s'étendre à "toute précaution permettant de lever un doute, aussi minime soit-il", car l'expérience m'a appris que ceux qui manipuleront mon code -- qu'il s'agisse de moi, de mes collègues ou de l'utilisateur du produit final que je m'apprête à livrer -- feront forcément des erreurs.

M

JadeSalina a écrit:

Encore une fois, c'est sûr à 100% que j'aurais pas mis les nodiscard si c'était mon code perso, je les ai mis car je pensais que c'est ce que vous auriez fait, pour être dans le style le plus "théoriquement correct" possible que vous avez l'air de défendre tant,

Ce qui est c'est bien dommage, car je voulais justement t'inciter à présenter le code "tel que tu l'aurais fait pour toi", et non "tel que tu croyais que nous voudrions le voir"... J'aurais peut être  du insister d'avantage sur ce point

JadeSalina a écrit:

pourquoi vous dites que ça serait contre productif de les mettre ici ? Microsoft n'est pas de cet avis apparemment https://github.com/microsoft/STL/blob/60decd0d829e68666b556780002c83605d748d80/stl/inc/vector#L1724

Encore une fois, ne te fie pas trop au code que peut proposer Microsoft et surtout pas "soit disant" solutions qu'il tente plus souvent qu'à son tour d'imposer pour "soi disant" améliorer la qualité de notre code alors qu'il ferait largement mieux d'améliorer la qualité du leur pour commencer.

La politique générale de Microsoft semble souffrir d'un réel problème d'égo en étant visiblement persuadée que tout leur code est forcément inattaquable et que tous ceux qui utilisent les fonctionnalités qu'elle peut proposer ne sont de toutes façons que des poulets sans cervelle, si bien qu'il faut absolument sécuriser la moindre fonction.

Elle ne se rend simplement pas compte que, si elle arrivait à corriger les failles de son propre code, elle serait sans doute en bien meilleure positon pour ne pas devoir imposer des sécurités qui ne riment à rien.

Dans le cas particulier de nodiscard, à quoi est ce que cela pourrait rimer de vouloir obliger la personne qui appelle une fonction à en récupérer le retour alors qu'il est évidentque c'est justement pour profiter de la valeur renvoyée que la fonction a été appelée?

JadeSalina a écrit:

Merci koala01 pour votre réponse détaillée et bienveillante comme à chaque fois (vous devriez écrire un livre ).

le gros problème est que ta vision des "problème potentiels" ne tient absolument pas la route dés que l'on parle d'un développement à peine plus complexe que deux ou trois classes triées sur le volet. [...] Dés que ta vision va se frotter à ne serait-ce qu'une dizaine de fichier d'implémentation et à deux développeur...

 Sur ce point là je ne peux rien dire, effectivement j'ai pas l'habitude de faire des projets avec beaucoup de développeurs, je peux juste m'en tenir à ce que vous-savez-qui et d'autres ont pu dire, mais je ne peux pas vérifier moi même ces informations. Tout ce que je peux dire, c'est que dans mes trucs perso je m'en sort bien sans avoir besoin de mettre des jalons de partout, mais c'est peut être pas représentatif de la réalité, je vous l'accorde.

Décidément, j'admire l'art dont tu fais preuve pour passer d'une extrême à l'autre afin de contredire les gens...

Je pensais que vous étiez dans l'extrême de mettre le plus de vérifications possibles, ce n'est pas pour contredire qui que ce soit, je pensais que vous auriez mis le plus de vérifications possibles et imaginable.

De plus, dans ton implémentation, tu as rajouté des [[nodiscard]] juste pour faire style, mais on t'a jamais demandé d'en mettre partout, c'est toi qui l'as fait pour faire bonne figure, alors que c'est contre productif ici.

Encore une fois, c'est sûr à 100% que j'aurais pas mis les nodiscard si c'était mon code perso, je les ai mis car je pensais que c'est ce que vous auriez fait, pour être dans le style le plus "théoriquement correct" possible que vous avez l'air de défendre tant, car je maintiens que ça n'a pas de sens d'appeler un getter sans effet de bords et sans récupérer sa valeur, et que même si normalement personne ne le ferait, pourquoi vous dites que ça serait contre productif de les mettre ici ? Microsoft n'est pas de cet avis apparemment https://github.com/microsoft/STL/blob/60decd0d829e68666b556780002c83605d748d80/stl/inc/vector#L1724 

@koala01, vous m'avez repris quand j'ai dit que std::vector était le 2ème plus simple container, en me disant que ça n'a rien de simple et même que "ce sont sans doute de loin les comportements les plus complexes à mettre en oeuvre", en parlant de reserve/resize en disant que "leur comportement différent en fonction des circonstances (ne font rien si la taille ou la capacité demandée est inférieure respectivement à la taille ou à la capacité actuelle)".

Non, je t'ai reprise sur l'origine de la complexité que tu associais à tord aux "exceptions, à la sémantique de mouvement (copy and swap) et autres joyeusetés"

J'ai effectivement -- car il ne s'agit pas de revenir sur mes écrits -- "Je sous entend que l'implémentation d'un tableau dynamique est en tout état de cause bien plus complexe que ce que ton manque d'expérience ne pourrait te laisser le croire, en effet".

Pour être honnête, j'ai hésiter entre écrire "en tout état de cause" et "sans doute", ce qui aurait fortement changé le sens de la phrase.  J'aurais de toutes évidences du  choisir l'autre solution

Enfin, ce que j'ai dit en gros, c'est que la complexité vient essentiellement du nombre de comportements que l'on attend de la part de cette classe, dont les deux plus complexes sont sans doute reserve et resize. Peut-être aurais-je du préciser  que je dis cela parce qu'il s'agit de deux comportements dont la description précise prend en compte trois situations particulières et distinctes ;).

Et, surtout, j'ai conclus sous la forme de

koala01 a écrit

La mise en oeuvre est malgré tout un peu plus complexe, surtout quand il s'agit d'augmenter la quantité de mémoire disponible, car la mémoire doit ête demandée au système d'exploitation.

Attention, je serais capable de te fournir l'implémentation d'une classe proche de std::vector qui présente une sécurité correcte en moins de vingt minutes.  Ce n'est donc pas vraiment ** très compliqué **.

Ce qui montre bien que je ne considère pas vraiment cela comme quelque chose de "très complexe" (principalement parce que "même moi" suis en mesure de l'implémenter facilement et avec le niveau de sécurité requis)

 Tu as trouvé cela trival ? tant mieux pour toi, car il se fait que ca l'est malgré tout...

Cela me confirme malheureusement que tu as énormément de potentiel, et que tu le gâche uniquement parce que tu as eu la faiblesse te seras laisser embrigader par un chant de sirènes au point que le bon développeur que tu aurais pu devenir risque de rester à  jamais très mauvais.

Que de talents gâchés!

-
Edité par koala01 1 juin 2022 à 19:36:19

JadeSalina a écrit:

Il n'empêche que le truc en lui même reste simple, c'est pas parce qu'on fait une erreur bete que ça rend le truc compliqué (d'ailleurs vous êtes rapidement allé voir le code, car j'ai corrigé le problème dans l'heure qui suivait le post, après avoir fait une petite pause (oui au passage je trouve que faire des pauses et revenir sur son code plus tard ça permet de trouver des bugs automatiquement )).

Si vous voulez tout savoir, je trouve à titre personnel que c'est impossible d'implémenter quoi que ce soit, même 3 lignes, sans avoir au moins un retour du compilateur. Pour le js::vector il m'a quand même fallu quelques compilations avant que ça compile, il manquait des ';' et autres typos de ci de là, ce qui ne veut pas dire pour autant que "mettre un ';' après une instruction" est un problème compliqué en soi

Tu ne fais que confirmer ce qu'a dit Lynix : si tu fais déjà des erreurs sur un code simple, comment peux tu prétendre que tu n'en feras pas sur des vrais projets de plusieurs dizaines ou centaines de milliers de lignes de code ? Peux tu garantir que sur un vrai projet, tu ne feras pas d'autres erreurs bêtes ? Peux tu garantir que sur un vrai projet, le compilateur trouvera toutes les erreurs bêtes ? Que revenir plus tard te permettra de trouver les erreurs automatiquement ?

C'est juste de la naïveté de débutant et tant que tu ne bosseras pas sur de vrais projets, tu ne comprendras pas en quoi Casey dit de la merde.

Trouve un boulot !

-
Edité par gbdivers 1 juin 2022 à 20:03:11

je voulais justement t'inciter à présenter le code "tel que tu l'aurais fait pour toi"

Alors tel que je l'aurais fait pour moi c'est très simple :

//

Oui, pas de vector du tout mdrr !! Memory arenas ftw ! Vive AAA (Almost Always Arenas) (dsl je m'égare, reprenons)

Si j'avais voulu me faire un vector pour moi en C++, il faut distinguer 2 cas :

• si il faut respecter les règles du C++ : alors j'aurais fait pareil que j'ai fait, sans mettre [[nodiscard]] ni noexcept
• si je fait comme je veut : alors du coup ça serait pas techniquement utilisable dans du code C++ puisque je n'aurais ni copy, ni move, ni destructeurs, ni exceptions, ça serait juste une suite d'objets POD en mémoire qui s'agrandit au besoin et qui assert si y'a plus de mémoire (le mec a qu'à aller s'acheter de la RAM !!). En fait maintenant que vous le dites, j'aurait fais comme le stretchy buffer de Sean Barrett, en rajoutant des templates pour plus de confort

Ce qui montre bien que je ne considère pas vraiment cela comme quelque chose de "très complexe" (principalement parce que "même moi" suis en mesure de l'implémenter facilement et avec le niveau de sécurité requis)

Alors là je n'ai jamais supposé la moindre seconde que vous ne sauriez pas l'implémenter, c'est pour ça que je comprenait pas pourquoi vous disiez que c'était complexe, vu que je sais que vous avez un niveau exceptionnel (vous avez bien les 3 carrés de C++ sous votre pseudo que je sache)

Cela me confirme malheureusement que tu as énormément de potentiel, et que tu le gâche uniquement parce que tu as eu la faiblesse te seras laisser embrigader par un chant de sirènes au point que le bon développeur que tu aurais pu devenir risque de rester à jamais très mauvais.

 Moi je me dis plutôt que j'aurais fini vraiment nulle si j'étais pas tombée sur ce chant de sirènes, car justement c'est là que j'ai entendu pour la première fois ce genre de choses "alternatives", puisque tout ce que vous dites et répétez à longueur de journée c'est ce que j'ai toujours entendu de partout tout le temps (et oui je n'ai pas connu les "mauvais cours C++", j'ai appris avec d'un côté un cours de C++17, et des livres de Bjarne Stroupsup/Scott Meyers de l'autre, le tout saupoudré de core guidelines/cppcon/cppreference)

tu n'es pas la première débutante à péter plus haut que ton cul qu'on croise, et probablement pas la dernière

Au moins vous serez entrainés pour la prochaine !  (mais je suis quand même pas débutante moi, je dois avoir dans les 3000 heures de C++)

Tu ne fais que confirmer ce qu'a dit Lynix : si tu fais déjà des erreurs sur un code simple, comment peux tu prétendre que tu n'en feras pas sur des vrais projets de plusieurs dizaines ou centaines de milliers de lignes de code ?

 Oui bien sûr que je fais des erreurs je ne dis pas le contraire (par contre pas des = au lieu de == ça ça m'est arrivé qu'une fois). Et le truc du new[] c'était plus un "brain fart" qu'une erreur, comme j'ai dit, une petite pause et tout s'éclaircit ! D'ailleurs j'avais mis un commentaire qui disait que c'était de la daube de faire ça, mais en fait c'était plus que de la daube c'était faux.

C'est juste de la naïveté de débutant et tant que tu ne bosseras pas sur de vrais projets, tu ne comprendras pas en quoi Casey dit de la merde.

Lui il n'est pas débutant pourtant, il a 35 ans de code dans les jambes (de bouteille comme vous dites, bien que ça fasse un peu alcoolique) (vous ai je dit qu'il a commencé à 7 ans ?)

-
Edité par JadeSalina 1 juin 2022 à 23:56:29

JadeSalina a écrit:

Lui il n'est pas débutant pourtant, il a 35 ans de code dans les jambes (de bouteille comme vous dites, bien que ça fasse un peu alcoolique) (vous ai je dit qu'il a commencé à 7 ans ?)

C'est pas le premier dev expérimenté et incompétent que je vois. Peut être que c'est dû au fait qu'il a peut être travaillé que sur des petits projets seul, comme pour HH. Ou peut être que c'est dû au fait que c'est un con arrogant, qui est incapable de reconnaître ses erreurs et donc d'apprendre. Le fait est là : il dit beaucoup de conneries.

Et je précise : ce n'est pas des conneries par rapport à ses choix, mais par rapport à sa façon de penser, d'affirmer des choses sans savoir de quoi il parle, d'être dans sa bulle de connaissance (ou d'ignorance, au choix). C'est cette attitude en soi qui est le plus critiquable, parce que c'est elle qui l'empêche d'apprendre.

Je fais du vélo depuis mes 7 ans (ou avant, je sais plus) et j'en fait depuis plus de 35 ans. Ca fait pas de moi un expert en vélo. L'ancienneté est un argument pour justifier des connaissances et de l'expérience, mais si en pratique, on voit qu'il n'y a ni connaissance ni expérience, l'argument de l'ancienneté est un argument bidon. 

Et 3000 heures de C++ ? Tu as fait quoi ? Étudié quoi ? Fais quels projets ? 3000 heures, ca fait beaucoup pour quelqu'un qui a si peu de recul.

> Si vous voulez tout savoir, je trouve à titre personnel que c'est impossible d'implémenter quoi que ce soit, même 3 lignes, sans avoir au moins un retour du compilateur.
Vraiment?
int main(void)
{
    // Pas de code
}

Et théoriquement, je pourrais  écrire un programme de un millions d'énoncés sur une seule ligne en C++.

-
Edité par PierrotLeFou 2 juin 2022 à 0:30:11

Tu trolles. C'est pas bien de faire ça, dans une discussion aussi sérieuse.

pierrot dans toute sa splendeur :)) 

int main(void)
{
    return;

}

gbdrivers ça fais un moment que c'est plus très sérieux 

Oh ? Ah bon ? On me prévient jamais.

-
Edité par gbdivers 2 juin 2022 à 1:11:57