Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 103 sur 182 PremièrePremière ... 353939596979899100101102103104105106107108109110111113153 ... DernièreDernière
Affichage des résultats 3 061 à 3 090 sur 5434
  1. #3061
    Citation Envoyé par Thamior Voir le message
    Je ne suis pas sur de bien comprendre ton propos. Certes le scoping fonctionne comme tu le décris, mais on gère bien la mémoire à la main lorsqu'on fait de l'allocation dynamique ou lorsqu'on utilise des itérateurs/références/pointeurs, non? C'est pas parce que ça se déclare comme du C++ moderne qu'au final ça n'est pas un pointeur légèrement glorifié (std::unique_ptr je te regarde).
    Plus vraiment en C++ moderne. Tu utilise des déclarations classiques, dépendantes de variables, qui sont limitées au contexte quand tu en a besoin (là ou avec le C il aurait fallut du malloc ou de la taille fixe donc de potentielles erreurs), ce qui limite tes mallocs et cie aux objets principaux des fonctions. Sauf que la plupart de ces objets sont sous la forme de tableaux et autres et tu utilise donc des objets standard comme les vector que tu vient redimensionner si nécessaire, mais qui sont automatiquement détruit à la destruction de l'objet dans tout les cas.

    Donc à la fin, tu n'a quasiment plus besoin de malloc nul part.

    Quant aux pointeurs, hormis quand tu appelle des fonctions C, tu ne les utilise plus et tu n'utilise que les références. Dire qu'on manipule la mémoire avec des références c'est un peu fort quand même, dans le sens ou c'est encapsulé, autant qu'en Java ou autre finalement. Je vois mal comment tu obtient une erreur avec un passage par référence ...
    Enfin, j'imagine que c'est possible, mais j'ai juste jamais vu ça

  2. #3062
    Citation Envoyé par Nilsou Voir le message
    Quant aux pointeurs, hormis quand tu appelle des fonctions C, tu ne les utilise plus et tu n'utilise que les références. Dire qu'on manipule la mémoire avec des références c'est un peu fort quand même, dans le sens ou c'est encapsulé, autant qu'en Java ou autre finalement. Je vois mal comment tu obtient une erreur avec un passage par référence ...
    Enfin, j'imagine que c'est possible, mais j'ai juste jamais vu ça
    int &foo(){
    int i = 1;
    return i;
    }
    Citation Envoyé par Sidus Preclarum Voir le message
    Ben du caramel pas sucré alors...
    "Avant, j'étais dyslexique, masi aujorudh'ui je vasi meiux."

  3. #3063
    J'ai autant fait d'erreurs type segfault avec des pointeurs que des références...Après je reconnais qu'il faut du talent :D (lambda capture par référence sur un temporaire, c'est le top).
    Citation Envoyé par François
    L'ordinateur cantique, c'est l'avenir.

  4. #3064
    Citation Envoyé par Nilsou Voir le message
    Plus vraiment en C++ moderne. Tu utilise des déclarations classiques, dépendantes de variables, qui sont limitées au contexte quand tu en a besoin (là ou avec le C il aurait fallut du malloc ou de la taille fixe donc de potentielles erreurs), ce qui limite tes mallocs et cie aux objets principaux des fonctions. Sauf que la plupart de ces objets sont sous la forme de tableaux et autres et tu utilise donc des objets standard comme les vector que tu vient redimensionner si nécessaire, mais qui sont automatiquement détruit à la destruction de l'objet dans tout les cas.

    Donc à la fin, tu n'a quasiment plus besoin de malloc nul part.

    Quant aux pointeurs, hormis quand tu appelle des fonctions C, tu ne les utilise plus et tu n'utilise que les références. Dire qu'on manipule la mémoire avec des références c'est un peu fort quand même, dans le sens ou c'est encapsulé, autant qu'en Java ou autre finalement. Je vois mal comment tu obtient une erreur avec un passage par référence ...
    Enfin, j'imagine que c'est possible, mais j'ai juste jamais vu ça
    Malheureusement les pratiques du C++ modernes n'empêchent pas les erreurs de mémoire comme l'on indiqué les autres canards. Les erreurs sont souvent plus subtiles (invalidation de références, etc.) mais existent quand même.

  5. #3065
    Citation Envoyé par Lazyjoe Voir le message
    N'importe quel compilateur te met un bon gros Warning bien rouge en voyant ça. Même l'environnement de développement (par exemple Eclipse) gueule en voyant ça, c'est dire

    Citation Envoyé par TarteAuxFleurs Voir le message
    Malheureusement les pratiques du C++ modernes n'empêchent pas les erreurs de mémoire comme l'on indiqué les autres canards. Les erreurs sont souvent plus subtiles (invalidation de références, etc.) mais existent quand même.
    Mouais ... avec les bons warnings appliqué, perso j'y ai rarement été confronté. En tout cas j'ai pas souvenir d'une erreur qui m'ait demandé de chercher pendant des plombes d’où venait la bourde et qui impliquait des références

    La plupart des erreurs mémoire je les ait eu ... en appelant des fonctions en C

  6. #3066
    Citation Envoyé par Nilsou Voir le message
    N'importe quel compilateur te met un bon gros Warning bien rouge en voyant ça. Même l'environnement de développement (par exemple Eclipse) gueule en voyant ça, c'est dire
    C'est un exemple, c'est tellement évident que même un humain le voit. Mais si tu rajoutes quelques couches, c'est plus dur à voir.

    Code:
    struct mon_type {
        int &ref;
    };
    
    mon_type foo() {
        int i = 1;
        return mon_type{i};
    }
    Il te dit quoi ton compilateur ? J'ai résolu le problème ?

  7. #3067
    J'ai testé android studio ajd du coup, pour faire une app android.


    et bah c'est ultra simple et intuitif. j'aimerais faire plus de projets là-dessus

  8. #3068
    Normal, c'est basé sur les IDE JetBrains, actuellement y'a pas vraiment mieux.
    C'est la faute à Arteis

  9. #3069
    Citation Envoyé par Cwningen Voir le message
    C'est un exemple, c'est tellement évident que même un humain le voit. Mais si tu rajoutes quelques couches, c'est plus dur à voir.

    Code:
    struct mon_type {
        int &ref;
    };
    
    mon_type foo() {
        int i = 1;
        return mon_type{i};
    }
    Il te dit quoi ton compilateur ? J'ai résolu le problème ?
    Dans le C++ moderne ton code il passe même pas, c'est considéré comme une erreur :

    Même pas besoin de mettre foo pour le voir d'ailleurs, juste la structure, tu tente de la compiler et de l'appeler en en déclarant une instance dans le main et pouf :

    Code:
    ../src/coeur/Projet_Vulk.cpp: In function 'int main()':
    ../src/coeur/Projet_Vulk.cpp:18:11: error: use of deleted function 'mon_type::mon_type()'
       18 |  mon_type ret;
          |           ^~~
    ../src/coeur/Projet_Vulk.cpp:6:16: note: 'mon_type::mon_type()' is implicitly deleted because the default definition would be ill-formed:
        6 | typedef struct mon_type {
          |                ^~~~~~~~
    ../src/coeur/Projet_Vulk.cpp:6:16: error: uninitialized reference member in 'struct mon_type'
    ../src/coeur/Projet_Vulk.cpp:7:10: note: 'int& mon_type::ref' should be initialized
        7 |     int &ref;
          |          ^~~
    ../src/coeur/Projet_Vulk.cpp:18:11: warning: unused variable 'ret' [-Wunused-variable]
       18 |  mon_type ret;
          |           ^~~
    make: *** [src/coeur/subdir.mk:20: src/coeur/Projet_Vulk.o] Error 1
    "make all" terminated with exit code 2. Build might be incomplete.
    De rien

    Vous aussi venez jouer au jeu de proposer la ligne de code la plus simple pour déclencher une erreur avec une référence en C++ qui ne serait pas détecté par le compilo. On verra qui est le premier gagnant
    Interdiction de compiler au préalable bande de tricheur

  10. #3070
    Citation Envoyé par Nilsou Voir le message
    Code:
    ../src/coeur/Projet_Vulk.cpp: In function 'int main()':
    ../src/coeur/Projet_Vulk.cpp:18:11: error: use of deleted function 'mon_type::mon_type()'
       18 |  mon_type ret;
          |           ^~~
    ../src/coeur/Projet_Vulk.cpp:6:16: note: 'mon_type::mon_type()' is implicitly deleted because the default definition would be ill-formed:
        6 | typedef struct mon_type {
          |                ^~~~~~~~
    ../src/coeur/Projet_Vulk.cpp:6:16: error: uninitialized reference member in 'struct mon_type'
    ../src/coeur/Projet_Vulk.cpp:7:10: note: 'int& mon_type::ref' should be initialized
        7 |     int &ref;
          |          ^~~
    ../src/coeur/Projet_Vulk.cpp:18:11: warning: unused variable 'ret' [-Wunused-variable]
       18 |  mon_type ret;
          |           ^~~
    make: *** [src/coeur/subdir.mk:20: src/coeur/Projet_Vulk.o] Error 1
    "make all" terminated with exit code 2. Build might be incomplete.
    Cette ligne n'existe pas dans mon exemple, je n'utilise pas le constructeur par défaut qui est effectivement implicitement supprimé.

    https://gcc.godbolt.org/z/MfzGx1 avec un main écrit correctement si tu veux vérifier que l'avertissement n'arrive pas plus tard.

  11. #3071
    Effectivement, comme ça ça marche

    Bon ça ne crash pas, mais on modifie effectivement une partie de la mémoire qui n'est théoriquement plus à nous

    Pourtant ça ne semble pas super dur à détecter.

    Ceci dit ça doit se détecter si on lance valgrind ou peut être même à la compil avec les options du sanitizer. Je testerais ^^

  12. #3072
    Citation Envoyé par Nilsou Voir le message
    Effectivement, comme ça ça marche

    Bon ça ne crash pas, mais on modifie effectivement une partie de la mémoire qui n'est théoriquement plus à nous

    Pourtant ça ne semble pas super dur à détecter.

    Ceci dit ça doit se détecter si on lance valgrind ou peut être même à la compil avec les options du sanitizer. Je testerais ^^
    Il y avait des exemples avec des itérateurs sur les pages précédentes
    On peut en faire avec des lambda aussi si tu veux.

    Et valgrind n'a rien à voir avec ton claim initial. Valgrind c'est au runtime. Ca gaule aussi les erreurs en C à ce tarif là.
    Sleeping all day, sitting up all night
    Poncing fags that's all right
    We're on the dole and we're proud of it
    We're ready for 5 More Years

  13. #3073
    C'est pas tout à fait vrai, on parle des sanitizer depuis le premier post. Et les sanitizer il faut lancer le programme une fois

    Mon assertion initiale c'est que dans un développement normal en C++ on a rarement des erreurs de mémoire ultra-cryptique aujourd'hui si on utilise la chaine de développement classique.

    Bon après la discussion est parties sur les outils à la compilation (notamment dans la comparaison avec rust), je pensais effectivement que les check modernes de GCC étaient suffisant. J'admets que sur ça je me trompais. J'avoue que comme j'utilise tout le temps les sanitizer en mode débug ... je ne fais plus trop la différence.

  14. #3074

  15. #3075
    Citation Envoyé par Nilsou Voir le message
    C'est pas tout à fait vrai, on parle des sanitizer depuis le premier post. Et les sanitizer il faut lancer le programme une fois
    Dans ce cas ils sont aussi en C et il n'y a aucune valeur ajoutée du C++ sur le C niveau safety :D
    Sleeping all day, sitting up all night
    Poncing fags that's all right
    We're on the dole and we're proud of it
    We're ready for 5 More Years

  16. #3076
    Citation Envoyé par acdctabs Voir le message
    J'ai trouvé ça marrant :
    holy fuck.
    Ca me fait penser à mes cours de combinatoires, où on nous expliquait qu'on pouvait génerer sans programmer n'importe quel programme correct, tant qu'on avait la patience de générer toutes les combinaisons de bits possibles pour des tailles incrémentales et de les tester.

  17. #3077
    Citation Envoyé par Tramb Voir le message
    Dans ce cas ils sont aussi en C et il n'y a aucune valeur ajoutée du C++ sur le C niveau safety :D
    Disons que tu fais quand même beaucoup moins de merde quand tu perds l'habitude de passer des pointeurs PARTOUT pour l'appel de la moindre fonction. Sans parler du nombre impressionnant de chose ou tu peut te passer de malloc/free et autres en utilisant les systèmes de classes et les outils modernes qui vont avec. Donc les merdes restantes tu a moins de chance d'en voir une passer à travers le filet des outils de debug.
    Dernière modification par Nilsou ; 11/07/2020 à 23h50.

  18. #3078
    Les développeurs s'amusent chez Amazon


  19. #3079
    Et vas-y que je réinvente la roue.
    - La version 3 est arrivée !

  20. #3080
    C'est marrant sur mon projet (Java) où je suis (depuis octobre mais il a commencé vers janvier 2019), j'ai retrouvé des réécritures aussi de trucs ... avec du deprecated qui remontait.
    J'ai effacé des méthodes et remis des trucs + propres déjà utilisés ailleurs, mais on voit bien que les bouts ont été fait par des personnes différentes à des moments + ancien.

    On est passé de Primefaces 4.3 à Primefaces 7 aussi pendant le projet, ça joue sur certains trucs mais c'est assez bizarre qu'on fait la même chose à plusieurs endroits de façon complètement différentes.

  21. #3081
    Citation Envoyé par TwinBis Voir le message
    Et vas-y que je réinvente la roue.
    C'est quoi la bonne roue pour ça en C et C++, d'ailleurs ?
    Sleeping all day, sitting up all night
    Poncing fags that's all right
    We're on the dole and we're proud of it
    We're ready for 5 More Years

  22. #3082
    Le supplice, évidemment.
    une balle, un imp (Newstuff #491, Edge, Duke it out in Doom, John Romero, DoomeD again)
    Canard zizique : q 4, c, d, c, g, n , t-s, l, d, s, r, t, d, s, c, jv, c, g, b, p, b, m, c, 8 b, a, a-g, b, BOF, BOJV, c, c, c, c, e, e 80, e b, é, e, f, f, f, h r, i, J, j, m-u, m, m s, n, o, p, p-r, p, r, r r, r, r p, s, s d, t, t
    Canard lecture

  23. #3083
    #include "chevalet.h"
    Sleeping all day, sitting up all night
    Poncing fags that's all right
    We're on the dole and we're proud of it
    We're ready for 5 More Years

  24. #3084

  25. #3085
    C'était dans boost avant ça, non?

  26. #3086
    Yes, yes, y'a plein de trucs boost qui sont incorporés petit à petit dans les libs standard

  27. #3087
    Pour la petite histoire, pour compléter mon précédent post sur JNI :
    finalement 2 dev senior ont pris le relais, ca leur a pris 1.5-2 semaines pour pondre la chose, et ils ont pu réutiliser quelque chose comme 10 % de mon code. Ca fait un peu mal d'avoir fait autant qui part à la poubelle, mais bon.
    Le projet étant fini, j'ai appris que je serai pas pris dans la boite, pas de bol ( ils ont brutalement décidé qu'il leur fallait un.e senior++ plutôt qu'un.e junior).
    Du coup il me reste 2 semaines sur un mini projet c++ avec sqlite pour créer un index à partir d'un fichier .vcf. Ensuite, retour à la case recherche de boulot.
    Mais en bilan positif j'ai quand même touché à 4 languages de prog + sql et des outils genre git, confluence, etc en 6 mois. J'espère que ca m'aidera à trouver un peu plus facilement

  28. #3088
    Les 90% de codes jetés, surtout ne vois pas cela comme qqchose de négatif.
    Il est souvent bcp plus simple de repartir de zéro, avec ses propres habitudes et outils, plutôt que rependre le code d'un autre, et devoir comprendre ce qu'il a fait. Sur un gros projet on peut tenter l'effort (enfin... le chef va l'imposer, les devs pleurer), mais sinon hop, on jette.
    Alors si en plus c'est une transition junior -> vieux chats, pardon, seniors : ton code n'avait aucune chance de survie .

    Un truc qui peut être super intéressant, c'est de regarder leur code et poser des questions. Tu vas apprendre plein de trucs (et faire la part des choses, car ils ont sûrement aussi leurs mauvaises habitudes), en plus de ce que tu as déjà acquis récemment.

    T'inquiète pas, en dev informatique on a de la chance, tu trouveras rapidement un autre poste . On est les vraies stars de l’apocalypse covid.
    Dernière modification par gros_bidule ; 01/08/2020 à 14h21.

  29. #3089
    Merci c'est sympa de me rassurer sur ces points ^^. non mais déjà c'était de base un truc un peu trop high level à faire pour un junior, alors ça m'étonne pas tant, ça me fait juste un peu chier quoi, mais bon.

    Et ouais, c'était un peu la stratégie de partir sur le dev pour des questions de survie, flexibilité, facilité à trouver un emploi, possibilité de bouger, etc etc.

    Mais bonne idée de poser des questions, il faudrait que je leur demande rapidement ce qu'il s'est passé dans le changement du code

  30. #3090
    Putain je suis en train de lire du code de u-boot et de drivers, qu'est ce que c'est dégueulasse. Les mecs lâchent du goto à foison même quand une boucle suffirait, y'a aucune logique, pire code que j'ai jamais vu. Marrant qu'on entende pas trop parler des devs bas niveau dans les médias ou autres, mais je m'imaginais que c'était des trucs hyper solides et clean, c'est bien laid

    Parfois t'as des commentaires à rallonge pour un truc évident et parfois ça écrit à 47 emplacements au pif dans la mémoire, addresses et contenus binaires hardcodés sans référence à la doc ou au pourquoi du comment

Page 103 sur 182 PremièrePremière ... 353939596979899100101102103104105106107108109110111113153 ... DernièreDernière

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •