Le topic de la programmation: Et envoyez des sioux!

[Tramb]

Dites petite question de C++ :

En C++ il n'existe aucune façon « standard » de copier un tableau de classe en profitant de la surcharge du « = » des classes ainsi définie ?

Je pensais à std:copy mais la description de la fonction ne dit rien à ce propos...

std::copy est la bonne fonction.

Ton constructeur de copie (move) et tes operator= font bien la même chose, hein ?
Tout doit être raccord sinon mauvaises blagues

[Mr Slurp]

Je suis d'accord avec toi, mais que la virtualisation soit chez toi ou sur le cloud, ça revient au même
Après, si tu as la maintenance et tout le toutim avec tes serveurs virtuels chez toi, c'est aussi une option. Mais il va falloir que tu gères les queues et autres pour la compil', là où c'est à peu-près transparent dans le cloud.

Pour ma part, c'est un truc que je n'ai jamais fait (ce n'est pas mon métier de faire des grosses applis lourdes), mais quand je vois ça :
https://www.youtube.com/watch?v=7pzBwuMjpP0

Je trouve ça assez cool (avec la notion de version et de last build, de tests auto en masse, etc). Tu peux monter la même chose sur des serveurs AWS avec un peu plus de boulot.

Edit : En français
https://www.youtube.com/watch?v=fAUMEqASqgk

Edit 2 : Bon du coup, vu que c'est gratuit pour mon utilisation, je suis en train de tester

Merci, je vais regarder pour au moins savoir ce que ça offre, mais pour la gestion des pipelines je fait déjà ça avec Jenkins. Bon j'avoue que je suis loin de spawn des machines le temps d'une compile ou d'un tests, et il est certain que le cloud va faciliter ce genre de tâches par sa nature, mais il est fort probable que je puisse faire des choses similaire via Jenkins et mon serveur de Virtualisation.

[Nilsou]

std::copy est la bonne fonction.

Ton constructeur de copie (move) et tes operator= font bien la même chose, hein ?
Tout doit être raccord sinon mauvaises blagues

Sauf que rien n'oblige strictement à ce que ce soit le cas

Ce qui m’embête c'est que le simple fait que tu pose la question montre que std::copy n'est pas clair sur ce qu'il fait.
Est-tu d'ailleurs certains qu'il appelle l'un ou l'autre, je suis allé voir les spec de la fonction, sauf preuve du contraire rien n'oblige à ceci dans l'implémentation ... c'est donc complétement dépendant du compilo ...

[Tramb]

Non c'est pas la question de std::copy.
Un objet doit supporter toutes les interfaces de copie. Parfois tu auras de la RVO ou pas. Parfois ça sera mové, parfois non.
Chaque objet doit être clos en termes de ces opérations sinon c'est la porte ouverte à un bug quand tu l'utilises dans un nouveau contexte. Ce nouveau contexte pouvant être un nouveau conteneur, un nouveau compilateur, une nouvelle révision du standard...

C'est non-spécifié dans le cas de std::copy parce que ça n'a pas à l'être tout simplement.

[Nilsou]

Qu'entends tu par « un objet doit pouvoir supporter toutes les interface de copie », je suis désolé mais ça me semble sorti de nul part, un memcpy sur un objet casse la large majorité des objets complexes, quoi que tu ais défini comme constructeur de copie, opérateurs ou méthode ...
edit : ajoutons à cela que si ton point de vue se valait en C++ on pourrait l'étendre et alors un objet devrait pouvoir supporter tout les systèmes d'allocation et on aurait pas défini le new, on se serait contenté de faire des malloc puis d'appeler le constructeur manuellement via des tests au début de chaque méthode de l'objet pour vérifier si les variables ont déjà été initialisée ou pas. Ça c'est le vieux fonctionnement des structures. Non, au lieu de ça on a défini le new et le new[] ainsi que delete et delete[] qui permettent de résoudre le soucis et les objets doivent être utilisé avec et sont conçus pour.
Ma question était : existe t-il l'équivalent pour la copie, un opérateur qui appelle le = défini par l'utilisateur pour l'affectation (ou le constructeur de copie, peu importe), a coups sur. Et toi tu me réponds que c'est à l'objet d'être robuste dans tout les cas ...

Chaque objet doit être clos en termes de ces opérations sinon c'est la porte ouverte à un bug quand tu l'utilises dans un nouveau contexte. Ce nouveau contexte pouvant être un nouveau conteneur, un nouveau compilateur, une nouvelle révision du standard...
C'est non-spécifié dans le cas de std::copy parce que ça n'a pas à l'être tout simplement.

C'est de la tautologie ce que tu écris , c'est justement parce que c'est non spécifié dans std:copy que c'est vulnérable à tout changement d'implémentation. Si c'était spécifié il n'y aurait aucun soucis... (comme pour new et delete)

[Tramb]

Tu n'as pas le droit de faire des memcpy sur des objets si is_trivially_copyable renvoie faux. Ce qui sera le cas si tu as un constructeur de copie.

Ce n'est pas ce que je disais.
Si ton objet a besoin de pouvoir être copié non trivialement (ton cas vu que tu veux invoquer ton operator=), il te faut supporter le constructeur de copie *et* l'opérateur=. Les deux. Toujours.
Et une routine qui veut le copier peut faire autant de copies temporaires et de combinaison de copies, assignements et moves qu'elle le souhaite. Toute la combinatoire doit marcher.

Produis un programme qui a *besoin* de l'appel à operator= et on discutera de sa validité

[Cwningen]

appelle le = défini par l'utilisateur pour l'affectation (ou le constructeur de copie, peu importe)

On est tous d'accord : peu importe. Qu'est-ce que t'imagine que std::copy pourrait appeler d'autre ?

[Nilsou]

Bah j'en sais rien, mais rien n'interdit dans la doc que j'ai lu qu'ils te fasse un gros memcpy. Quand la spec ne te dit rien sur le sujet les implémentations sont totalement libres ....

Si ton objet a besoin de pouvoir être copié non trivialement (ton cas vu que tu veux invoquer ton operator=), il te faut supporter le constructeur de copie *et* l'opérateur=. Les deux. Toujours.
Et une routine qui veut le copier peut faire autant de copies temporaires et de combinaison de copies, assignements et moves qu'elle le souhaite. Toute la combinatoire doit marcher.

Oui mais on en revient à ce que je disais : ou dans la spec de std:copy il est marqué qu'il doit y avoir vérification de is_trivially_copyable ? Nul part dans ce que j'ai lu. C'est complétement laissé à la discrétion du compilateur.

Même si je suis d'accord que ce serait complétement con, n'avoir aucune info sur ce qui est fait est quand même surprenant.

[Cwningen]

https://en.cppreference.com/w/cpp/ty...ially_copyable

Objects of trivially-copyable types that are not potentially-overlapping subobjects are the only C++ objects that may be safely copied with std::memcpy or serialized to/from binary files with std::ofstream::write()/std::ifstream::read().

[rOut]

Bah la spec de std::copy dit bien que ça fait des copies des éléments. Une copie en C++ étant un appel à l'opérateur d'assignation par copie ou à un constructeur par copie (au choix de l'implem), éventuellement via leurs versions implicites si elles peuvent exister, qui consiste à appeler les opérateurs correspondants sur les bases / membres de la classe, avec le cas particulier ou ces opérateurs sont triviaux c'est à dire un memcpy. Tout est implicite, mais spécifié.

PS: Faites du C.

[deathdigger]

Merci, je vais regarder pour au moins savoir ce que ça offre, mais pour la gestion des pipelines je fait déjà ça avec Jenkins. Bon j'avoue que je suis loin de spawn des machines le temps d'une compile ou d'un tests, et il est certain que le cloud va faciliter ce genre de tâches par sa nature, mais il est fort probable que je puisse faire des choses similaire via Jenkins et mon serveur de Virtualisation.

C'est tout un pan de l'informatique qui est devenu populaire quand j'ai arrêté de faire du tech. Y'a notamment les notions de conteneurs que je n'ai jamais abordé.

Là, j'ai fait des tests avec un petit helloworld (qui m'a servi à tester Github également ), c'est cool mais un peu obscure. Je compile bien, mais je ne retrouve pas le résultat de ma compilation (l'exécutable en l'occurrence). Je pense que c'est la partie "Artifact" qu'il faut que je comprenne.

J'ai des thunes sur mon compte formation, je me tâte à m'en payer une sur ce genre d'outils. J'ai vraiment louper le coche de tout ce qui est versioning, cloud, etc.

[Mr Slurp]

C'est tout un pan de l'informatique qui est devenu populaire quand j'ai arrêté de faire du tech. Y'a notamment les notions de conteneurs que je n'ai jamais abordé.

Là, j'ai fait des tests avec un petit helloworld (qui m'a servi à tester Github également ), c'est cool mais un peu obscure. Je compile bien, mais je ne retrouve pas le résultat de ma compilation (l'exécutable en l'occurrence). Je pense que c'est la partie "Artifact" qu'il faut que je comprenne.

J'ai des thunes sur mon compte formation, je me tâte à m'en payer une sur ce genre d'outils. J'ai vraiment louper le coche de tout ce qui est versioning, cloud, etc.

Non de mon coté le versionning/build pipeline, l'automatisation & co, je suis rentré de plus en plus dedans avec le temps car vraiment, quand c'est bien foutu, la CI devient un membre à part entière de l'équipe et le meilleur amis des QA (vu le travail que ça leur sauve).
Les conteneur c'est encore un autre monde que je n'ai jamais attaqué, un jour sans doute, quand les journées feront 30 heures

[Nilsou]

https://en.cppreference.com/w/cpp/ty...ially_copyable

Hum, tu veut dire que finalement, c'est dans la spec générale donc pas besoin de le préciser dans std::copy ... Ok. J'aurais préféré que ce soit plus clair quand même mais Ok.

[jilbi]

Non de mon coté le versionning/build pipeline, l'automatisation & co, je suis rentré de plus en plus dedans avec le temps car vraiment, quand c'est bien foutu, la CI devient un membre à part entière de l'équipe et le meilleur amis des QA (vu le travail que ça leur sauve).

Oui vraiment, avoir un petit pipeline qui vous compile les branches importantes à chaque commit, et apres il n'y a plus qu'à appuyer sur un bouton pour deployer sur les env de test/prod (voir deployement auto si on a les machines), c'est un pur bohneur et ça simplifie grandement la vie. Surtout si on doit rollback la prod au dernier bon commit, c'est un click si l'artefact n'a pas été effacé car trop vieux ( sinon 2 clics vu qu'il faut re-build)
Allez voir tout ce qui est integration continue/ piepeline gitlab / jenkins et autre, c'est de plus en plus indispensable.

[Cwningen]

Hum, tu veut dire que finalement, c'est dans la spec générale donc pas besoin de le préciser dans std::copy ... Ok. J'aurais préféré que ce soit plus clair quand même mais Ok.

La notion de "trivialement copiable" existe pour désigner les types qu'on peut copier comme un simple paquet d'octets. memcpy/memmove copient des octets et non des objets. std::copy copie les objets, donc si copier un objet n'est pas équivalent à copier les octets qui le composent (c'est à dire n'est pas trivialement copiable), memmove n'est pas une implémentation valide de std::copy.

[Dross]

Allez voir tout ce qui est integration continue/ piepeline gitlab / jenkins et autre, c'est de plus en plus indispensable.

Je me suis mis au CI/CD il y a 4 ans (j'ai 8 ans d'XP) et j'ai adoré le support que ça m'apportait (plus de tests unitaires qui pourrissaient sur place car untel ne les lançais pas, plus de surprise lors de la mise en prod après 3 mois de dev, etc).

Pour les conteneurs je m'y suis mis sérieusement il y a un an, déployé chez un client avec cette année, c'est dingue comment ça simplifie tout. Même (et surtout ?) durant le dev. Une ligne de commande + un fichier config et voir tout le petit monde (un redis, un rabbitmq, un elasticsearch, 1 front end, 1 API et quelques workers) démarrer en même temps sur ta machine pour tester le bouzin ça fait son ptit effet. Tu coupe tout et hop, tout à disparu de ta machine sans laisser des cochonneries un peu partout.

T'a ton junior qui veux tester un truc ? Paf tu lui met dans les pattes le bon fichier config et il est opérationnel en 5 secondes montre en main.

Et ça simplifie la doc aussi, quand je vois celle de Gitea ça fait un peu baver, tu veux MySQL ? Tiens tu change le fichier avec ça et ça. Tu veux du Postgres ? Alors tu met ça et ça. C'est putain d'efficace et élégant.

[ducon]

Je me suis mis au CI/CD il y a 4 ans (j'ai 8 ans d'XP) et j'ai adoré le support que ça m'apportait

On dit CD-i.

[Teocali]

On dit CD-i.

bah non. CDI. merde, t’es prof, tu devrais le savoir, Philippe.

[ducon]

Ouais, fais péter la poire.

[MrBeaner]

Hello les code freaks Après avoir pythonné une année dans des projets de data science, je suis vraiment heureux d'avoir appris un premier langage de programmation. C'était une envie depuis longtemps et j'ai vite pris le virus et ce topic y a contribué

Avant de me former sur Django pour construire mon future site web, j'ai décidé de suivre le cours d'introduction à l'informatique donné par HarvardX sur edX. C'est assez bien fait je trouve, même si c'est très dur parfois, surtout quand on prend les exercices en difficulté hard. Pour moi, c'est idéal parce qu'on apprend quelques bases en C, ce qui a m'a fait réaliser plein de choses que j'ignorais en tapant mes fonction et en construisant mes modèles en python. Pour avoir fait plein de MOOC, je le recommande si le format vous plaît.

Par contre, j'ai beaucoup moins de plaisir à résoudre des problèmes en langage de bas niveau. J'image que la difficulté doit beaucoup y contribuer, mais je me demandais : est-ce que ça se résume qu'à la difficulté, ou bien est-ce qu'il existe des penchants naturels pour la programmation en langage de haut niveau ou de bas niveau selon votre expérience ?

Autrement, je suis encore un Bulbizare en programmation et, même si j'essaie essentiellement d'avoir les skills pour les projets auxquels je suis confronté, j'ai hâte de voir où j'en serai dans quelques années

[Dross]

ou bien est-ce qu'il existe des penchants naturels pour la programmation en langage de haut niveau ou de bas niveau selon votre expérience ?

C'est surtout une question de priorité et de cas d'utilisation.
Perso je sors des produits logiciels, pas du code ; donc le bas niveau pour moi c'est une hérésie et une perte de temps.
Mais le gars qui fait de l'embarqué lui il se bas avec les ressources disponibles, donc un framework qui te sort des binaires de 250mo pour un Hello World c'est une hérésie pour lui.

Y'a pas de mauvais outil, juste des mauvais cas d'utilisation. Et un bon outil utilisé dans le bon endroit c'est super agréable, quel que soit ton niveau.

[TarteAuxFleurs]

Je dirai que la programmation "bas niveau" (proche du système ou du matériel) demande justement une bonne connaissance de l'informatique en général (comment ça marche un CPU, c'est quoi un pointer et comment ça se traduit par la suite, comment un programme s’exécute sur une machine, etc.) ce qui fait qu'il y a un une grosse courbe d'apprentissage, là où ces détails techniques te sont plus ou moins bien cachés sur des langages interprétés.
Si tu as de la chance c'est des concepts auxquels tu es exposé petit à petit, sinon ça fait beaucoup à assimiler en une fois

[MrBeaner]

Merci pour vos réponses ! Effectivement, je comprends pourquoi pas mal de gens recommandent de commencer par Python puis de descendre une fois une certaine maîtrise acquise, parce que commencer direct dans les Bytes, c'est assez hardcore

Autrement, comme j'ai appris plutôt autour de la science des données, j'ai un peu peur de louper quelques bases répandues au niveau du code. Pour python, je me suis pas mal investi à suivre le PEP8 et à trouver une structure de notebook qui serait facile à réutiliser. La prochaine étape serait, pour Django, de maîtriser les bonnes pratiques de modifications (comme tenshu l'avait indiqué) plutôt de changer mes roues sur l'autoroute comme je l'ai toujours fait sur mes Prestashop/Wordpress

[Anonyme20240202]

En vrai personne ne fait du bas niveau... pour longtemps. Même en C tu peux très facilement construire des abstractions haut niveau et les utiliser sans aucun coût additionnel en terme de performance.

Donc la première chose que fait un bon programmeur c'est de se créer ses abstractions pour éviter de perdre du temps.

Même si tu regardes le code pour Apollo ou d'autres vieilleries, y'a tout un tas d'abstractions haut niveau. Ca commence souvent avec une simple fonction (qui expose une interface simple et masque la complexité sous jacente), rien que ça c'est haut niveau.

La véritable difficulté en programmation c'est l'algorithmique, les structures de données, etc. Connaître les interactions finales avec le hardware (cache locality, etc.) s'pas important, c'est bien d'avoir les bases mais c'est pas très important à moins d'être spécialiste.

Et la majorité du temps les abstractions tu les ré-utilise, tu ne réinventes pas la roue, donc ce qui compte c'est aussi de bien connaître l'ecosystème offert par ton langage.

Donc au final mis à part la syntaxe, les langages sont les mêmes grosso merdo. Même un "gros" truc comme le typage se comprend assez vite.

Pour simplifier quand t'as une signature de fonction genre donne moi le determinant de ma matrice du style: det(ma_matrice)

Bah l'implémentation sous jacente, quelle soit en C ou en Python, la majorité du temps tu t'en tapes allégrement, tu sais ce que fais le langage en pseudo algorithme.

----

Là où t'es véritablement confronté à la programmation "bas niveau" je pense c'est quand t'es plus proche du hardware, mais là encore ça sera souvent des abstractions, donc ça sera encore une fois pas vraiment une question de langage mais une question du domaine en lui même.

Le truc que tu apprends constamment à utiliser ce sont de nouvelles librairies, le langage pas tant que ça en comparaison.

Si tu veux savoir comme c'est fait "techniquement" le bas niveau pourrait t'intéresser, mais s'plus une question d'avoir de bonnes bases en informatique.

----

Pour finir avec un exemple:

Si tu fais de la programmation réseau en python, genre un client Torrent en python. Bah le programme fera "pareil" que l'équivalent en C ultimement, il va parler à ton interface réseau. Tu peux assez facilement faire un client torrent sans trop plonger dans les couches réseaux, les drivers, etc., tout ce que tu veux c'est l'idée haut niveau du P2P, mais tu peux aussi construire le client depuis le début en t'intéressant aux protocoles bas niveau genre NDP pour IPV6.

Tu peux conduire ta voiture/prendre le train en sachant plus ou moins comment ça fonctionne, ça t'empêche pas de t'en servir quoi

[jilbi]

Ce qui est quand même important quand on fait du "haut niveau" c'est aussi de savoir ce qui bouffe de la memoire: quels objets, structure etc ... parce qu'on est assez vite (dans l'industrie) confronté à des contraintes machine, et "rajoute e la ram et bidouille les options memoire", ça marche un temps, mais c'est pas trés pro :D .
Et donc plus on monte en abastraction, plus il faut allez de soit même creuser pour savoir comment c'est optimisé en interne (par exemple les streams introduits dans java8)
Mais ça, ça vient avec l'experience.

[gros_bidule]

Ha ça, c'est sûr, plus on monte en abstraction et plus on a affaire à une boite noire. Il est important d'être curieux et de comprendre ce qui se passe dedans, sinon on peut passer à côté de quelques soucis.

Et la curiosité, c'est très important la curiosité !
Tu cites les streams en Java -> j'ai un triste exemple d'anciens collègues débutants qui voulaient absolument utiliser les streams partout, et interdire les "simples" boucles for/while. Leur raison ? "bah c'est plus optimisé que les boucles, nan ?". Les types n'ont jamais étudié la question mais se permettent d'affirmer un truc, et puis bon, même sans avoir étudié ou fait des benchs et analyses (mémoire, etc), comment un stream pourrait être plus rapide, ou juste "mieux" qu'une boucle for ? Non mais sérieusement, comment ? Ce n'est pas parce que c'est nouveau que c'est mieux, mais ça certains ont du mal à s'y faire. Je trouve ça désolant.
Nota : je parle des simples itérations sur une liste, pas de mapping, filtering etc.


Il y a aussi certains détails pratiques à connaître. Par ex la récursivité si tu fais du Java. En théorie, la récursivité c'est très bien (enfin... souvent), mais essaie de faire une méthode récursive sur la JVM (donc en Java, etc) : il se peut que ton programme plante avec une stakoverflow. Pourquoi ? Parce que à chaque fois que tu passes un niveau de récursivité, la JVM doit sauver des données (les params d'entrée si ma mémoire est bonne) dans une pile (stack). Et cette pile a une taille limite, du genre 128Ko ou 512Ko, ça dépend de la JVM, l'OS, ou de la valeur paramétrée.
Tu peux donc te retrouver à renoncer à la récursivité même si d'un point de vue purement théorique, ton algo fonctionne.
Je l'avais vu sur un programme de scrapping de comptes Twitter : il fallait faire créer un graphe (en mémoire) en cherchant les amis de qqun, puis les amis de ces amis, etc. La fonction récursive était très belle, top, mais le programme plantait au bout de quelques jours (on utilisait l'API Twitter, qui a du rate limiting, donc on était lent). On a du reprogrammer ça, c'est bête ^^. C'était d'autant plus bête qu'on avait livré la première version (récursive) au client, et on l'avait testé pas mal, mais visiblement pas avec assez de données, ni la bonne méthodologie (des tests d'integ ou unit auraient révélé le soucis).

[jilbi]

Les types n'ont jamais étudié la question mais se permettent d'affirmer un truc, et puis bon, même sans avoir étudié ou fait des benchs et analyses (mémoire, etc), comment un stream pourrait être plus rapide, ou juste "mieux" qu'une boucle for ? Non mais sérieusement, comment ? Ce n'est pas parce que c'est nouveau que c'est mieux, mais ça certains ont du mal à s'y faire. Je trouve ça désolant.

Hahaha la stupidité du truc (surtout que les stream sont un poil plus gourmands en memoire, mais c'est négligeable) . Ce que j'ai mis en gras c'est un probléme globalement partout dans la tech, mais j'ai envie de dire que c'est un mal pour un bien: ça veut dire qu'il y a plus de demande de dev que d'offre, et que c'est l'industrie qui doit faire l'effort d'appâter les dev avec une jolie stack technique.
Aprés oui, dés fois on se dit "putain, mais on a PAS besoin de passer en micro-services en fait!" mais on le fait parce que c'est le truc à la mode, que ça fait beau sur le CV :D

Pour ton histoire de recursivité, c'est ta structure graphe qui était trop grosse ? (ps: pas bien de pas mettre de test d'intégrations, bouh ! )

[Tramb]

Par contre, j'ai beaucoup moins de plaisir à résoudre des problèmes en langage de bas niveau. J'image que la difficulté doit beaucoup y contribuer, mais je me demandais : est-ce que ça se résume qu'à la difficulté, ou bien est-ce qu'il existe des penchants naturels pour la programmation en langage de haut niveau ou de bas niveau selon votre expérience ?

Ce penchant existe carrément.
Pour être un programmeur complet tu peux viser tout le spectre, mais tu ne seras pas super expert partout comme un mec qui consacre sa vie à un de ces angles.
Perso je pense qu'il y a un un miminum de bas niveau à savoir même pour programmer dans des langages de très haut niveau.
Et qu'il y a un minimum de théorie à savoir parce que quand tu fais du bas niveau, tu fais quand même des outils autour ailleurs que sur le runtime.

[Cwningen]

Le bas niveau, c'est les autres.

Pour le programmeur Python, le bas niveau c'est le C.
Pour le programmeur C, le bas niveau c'est l'assembleur.
Pour le programmeur en assembleur, le base niveau c'est le langage machine.
Pour le programmeur en langage machine... ah non, en fait personne ne programme en langage machine.

[Tramb]

Pareil pour le haut niveau

Ca me rappelle "L'enfer, c'est le code des autres".