Le topic de la programmation: Et envoyez des sioux!

[sosoran]

Après je tiens également à dire que quand tu as facilement une bonne centaine d'autres candidats qui postulent en même temps que toi (pour reprendre ton exemple), faut vraiment bien être sûr de son coup pour faire une postulation aussi personnalisée. D'un point de vue effort investi / chances d'un entretien, ça monte vraiment pas bien haut et ça devient très compliqué comme stratégie à suivre pour peu que t'ai pas une énergie débordante te permettant de passer des heures et des heures sur chaque postulation chaque jour pendant des semaines ou des mois (parce qu'il faut de base statistiquement beaucoup de postulation avant de décrocher un entretien).
J'ai eu plusieurs entretien également en envoyant mon CV seul, généralement avec des boites de recrutement par contre, et ça me semble beaucoup plus pratique : Si le cv semble convenir, mini appel de 5 min pour confirmer l'intérêt réciproque et on organise un appel plus long dans les jours qui suivent pour vraiment faire le point.
Ça prends moins de temps pour le postulant, moins de temps pour le recruteur, et on peut les deux consacrer notre temps à des choses plus intéressantes.

Mais bon, ça reste un avis personnel, et je conçois (même si difficilement) qu'on puisse préférer écrire des lettres de motivations.

[William Vaurien]

Alors c'est pas forcément optimum comme manière de faire, je suis bien d'accord, et ça ressemble plus à une pratique du XXeme siècle...

Mais j'ai l'impression que de nombreux groupes fonctionnent encore comme ça, surtout ceux qui doivent ouvrir des postes et faire un recrutement suivant un processus encadré légalement.
Alors pour l'investissement je te laisse juger: tu es au chômage, tu cherches du travail. Tu devrais donc consacrer au moins 8h par jour à te trouver un poste.

Donc passer 2h ou 3h à préparer un CV sur mesure, à préparer un paragraphe qui explique pourquoi toi et pas les autres, ça ne me parait pas être du gâchis.
Sinon ton CV risque de finir dans la pile des mecs qui ont envoyé le CV moche, avec une lettre lambda, ou qui sont cuisinier et qui ont cliqué sur le mauvais bouton...

Après si tu es une star mondialement connue, comme deathdigger, tu n'as pas besoin de ça, ou si tu as un bon réseau, ce n'est en effet pas utile.
Après il y a aussi l'effet géographique qui compte:
postuler pour une SSII à Paris n'est pas pareil que postuler dans une grosse entreprise familiale à Lausanne, qui est encore différent que postuler dans l'administration Genevoise, qui sera encore différent que postuler pour un groupe financier à Londres...

[Anonyme20240202]

La lettre de motivation est toujours là, sous une forme ou une autre. Généralement c'est simplement le mail dans lequel tu joins ton CV, plutôt que de répondre "Ok, voilà mon CV", tu expliques pourquoi ce poste correspond et tu peux rentrer dans le détail d'une expérience passée qui montre que ça colle, etc.

J'ai vu effectivement des cas où absolument tous les documents, mis à part le CV, sont ignorés, mais c'est généralement des mecs que je considère "pas bon" (je parle des recruteurs qui ne regardent que le CV).

Quelques lignes pour expliquer que tu as commencé à te documenter sur le domaine en question, etc. montrer un intérêt sincère ça prend peu de temps et ça peut faire la différence.

Bon, je me rends compte qu'on est sur le topic de la prog' donc complètement hors sujet, mais tu peux préparer ça à l'avance. Tu fais une liste d'atomes crochus (biologie, dev, etc.) et si un truc colle dans l'annonce, paf, tu sors le morceau de texte "atomes crochus, biologie". C'est pas un effort si énorme honnêtement et y'a que de l'upside

[Dross]

Le portefolio pour les devs backend c'est bien à double tranchant: j'ai fais un peu de recrutement récemment et les projets persos ne rentraient pas en critère premier de la sélection.
Nous avons été voir les sites/github des candidats qui en donnait un dans leur CV mais pas un seul n'a fait pencher la balance dans le bon sens, car en fait assez souvent le portfolio sonne 'creux' (un github très peu utilisé), ou ne donne pas envie (avec un fatras de code farfelu ou avec un front vraiment horrible), ou envoie le message: en fait ma passion c'est mon projet perso, du coup votre projet d'entreprise c'est du pur alimentaire.

Le portfolio c'est comme tout, il faut savoir le présenter/l'utiliser correctement.
De mon coté ça m'a permis de choper des stages, des formations et des postes où il y avait beaucoup de compétition, avoir des trucs (vidéos/sites/code/etc) en ligne ça permet aussi de montrer rapidement du concret en fin d'entretien pour "prouver" tes dires.

Quand tu dis que tu a fait une application pour déformer une surface NURBS au travers d'un volume BSpline, les gens t'écoutent poliment mais c'est tout, quand tu montre la vidéo là t'a un effet "wahou" et tu marque plein de points (j'ai choppé mon premier job avec cette vidéo). Et ce n'était ni la première ni la dernière fois que j'ai fais ça avec mes différentes réalisations.

Après ça n'enlève en effet pas le besoin d'un CV et surtout une lettre de motiv (+ relance/résumé après rencontre, etc, bref l'usage quoi).

D'ailleurs ça me fait remarquer un truc : je ne met pas mon portfolio sur le CV, je le garde comme ressource pendant les entretiens si j'en trouve le besoin, c'est peut-être aussi là la différence avec ton expérience. Si tu avais eu un candidat qui aurai fait comme moi, soit sortir des projets lié à la tournure de l'entretien, t'aurai apprécié ou pas ?

(c'est finalement un peu le cas de tout le monde, mais quand tu recrutes t'as pas envie t'entendre ça).

Je ne comprendrais jamais ce blocage qu'on a en France, voir même obstination à vouloir faire semblant qu'on fait ça pour autre chose que l'argent. Moi j'adore programmer, même si j'étais rentier je programmerai, mais ça serai uniquement sur mes projets, pas celui d'un autre. Si je programme pour un autre c'est pour l'argent, rien de plus. Je ne comprends pas que ça pose encore problème d'être honnête par rapport à ça et je trouve ça même limite hypocrite (je ne te vise pas en particulier, juste la tendance générale).

J'ai des compétences et je les vends au plus offrant qui aura un projet sympa et une équipe compétente (donc je reste intéressé par ton entreprise, sinon je serai pas en train de te parler ; mais je fais bien ça uniquement pour l'argent).
Le plus drôle c'est que je suis ultra exigeant sur la qualité du projet et de l'équipe en plus, marrant de penser que ça puisse être exclusif.

Bon pour les débutants fraîchement sorti d'école c'est bien de pas trop la ramener là dessus, mais après franchement... je comprends vraiment pas pourquoi c'est un problème.

[gros_bidule]

Ha mais clairement, le mythe du dev qui s'investit corps et âme dans le projet, c'est souvent de l'hypocrisie. Ca l'est encore plus quand l'employeur, lui, ne fait pas l'effort d'investir dans l'employé

Mais il y a des boites qui attendent vraiment ça, sincèrement. A tord ou à raison, y'a les deux cas.
Je prendrais l'exemple d'une boite qui a aujourd'hui un gros site web dans le e-commerce : ça a commencé avec deux fondateurs (un commercial et un dev) + une bande de devs embauchés. Ils ont monté le projet ensemble, conquis des parts de marché, se sont donnés à fond (il paraît). Un des types me raconte même qu'ils partaient en vacances ensemble, la boite organisait des soirées de folie (j'en ai vécu une : digne des clips de rappeurs US avec piscine, DJ, jacuzzi dans une villa de luxe dans un coin très huppé à la montagne), ce genre de trucs. Qques années plus tard, il ne reste que 2 devs de l'équipe initiale, et le patron veut recruter. Lors de l'entretien d'embauche, il veut "des killers, comme avant". Je comprends qu'il souhaite monter une équipe de rêve v2, mais soyons honnête :
- sa boite n'est plus une startup (qqes années + 40 employés) et elle a un business stable
- il propose un salaire mi-na-ble aux devs (les commerciaux parcontre ça va, y'a du pognon)
Il n'a jamais eu ses killers. Des déceptions, des CDI qui restent 2 ans, des prestas qui ne passent même pas la période d'essai, ça oui . Le seul qui semble faire l'affaire, c'est un type un peu malsain qui joue au fils spirituel du patron, et d'après les retours que j'ai d'anciens collègues, c'est gerbant. Mais ce type, là, il pourrait bien faire son trou.
En tous cas le patron semble sincère quand il veut de l'engagement : il a beau être un sale type, sa sincérité est le seul truc qui me semble vrai. C'est juste qu'il y a goûté, dans un contexte très particulier. Sa société a évolué mais pas lui.

Une grosse ESN ou même une PME, ouaip, lol, tu vends un service puis c'est tout hein ^^. Tu es professionnel, comme l'artisan qui va monter ta salle de bain. Ne pas le dire c'est de la politesse, mais il faut être réaliste. Sinon investir dans l'employé, pour de vrai. Investir avec des moyens (vrai bon PC, licences logiciels, vrai bureau, etc), du pognon, de la disponibilité, de la flexibilité, du confort, pas juste "on pense à toi mais heu pas trop quand même". Pour autant ça n'empêche pas de se poser pour faire son trou.
Ca me fait toujours rire quand un RH d'ESN me dit (ou à un proche) après une démission "mais on a investi sur toi !". Mes fesses tiens. C'est juste le délire d'un commercial 2.0 qui pense que mettre sa photo de profil sur Linkedin avec un pistolet Nerf c'est cool.

[William Vaurien]

Je vois de quoi vous parlez, mais je ne parle pas tout à fait de ça. Si lors d'un recrutement un gus se pointe avec son github avec des commits journaliers, qu'il me parle de son projet comme son fils, sa merveille, je vais peut être pas l'engager... Premièrement parcequ'il risque de travailler 1 an en mettant de côté et ensuite se mettre au chômage pour continuer son précieux. Ou deuxièmement, plus pernicieux, il va grignoter sur son temps de travail pour faire son projet... et se casser aussi dans 1 an...
Alors pour ceux qui bossent avec des prestas qui restent 6 mois sur un projet ça semble peut être naturel, mais quand tu investi (formation, temps des seniors de l'équipe) pour faire monter un dev en compétences techniques et métier, c'est pas vraiment l'idée de le voir se barrer au bout de 12 mois...

Autre cas, un gars nous a montré une espèce d'usine à gaz pour faire de la "méta-programmation sur les connections au base de données en Java" (ou un truc du genre). 1) on a absolument pas compris ce qu'il voulait faire avec son "oeuvre" ni même à quoi ça pouvait servir, 2) le gars avait l'air dément quand il en parlait, 3) il bossait dessus depuis des années sans avoir regarder à côté si des librairies tierces auraient pu au moins l'aider.
Au final on lui a dit "merci, bonne continuation": on avait eu peur qu'il nous foute son truc dans notre projet et qu'il soit ingérable (le côté savant fou).

Alors pour un truc ponctuel c'est peut être une bonne idée. Tu fais une démo d'un truc en 3D, c'est cool. Tu veux faire de l'imagerie ou du jeu vidéo, c'est génial.
Maintenant si tu postules sur un poste de dev backend pour des services administratifs, ben, bof: je (en tant que recruteur) vais me dire que tu es très doué, et que faire des services pour des CRUD avec 3 règles métiers en Java, ba en fait ça va pas le faire pour toi. Tu vas te faire chier comme un rat mort et te barrer à la première occasion...
Si en face j'ai un dev un peu plus lambda mais fort sympathique, qui connait bien le jdk et qui suit un peu les évolution des frameworks les plus courant, je vais peut être choisir le dev lambda, même si au fond j'ai été super épaté par ta présentation et que je suis jaloux parque j'ai toujours été une brèle en 3D...

Donc double tranchant: ça ne rend pas toujours service.
Par contre je réitère: pour un JD qui n'a pas beaucoup d'XP ça peut être utile, mais encore une fois c'est pas toujours adapté: c'est très contextuel !

[Dross]

Je comprends mieux ton point, mais pour moi c'est vrai pour tout les documents/informations que tu donne en entretien.

Par exemple j'ai un diplôme d'ingénieur en conception mécanique, c'est certain qu'en fonction de la boite où je postule (pour du dev) je vais le cacher ou le mettre en avant, si la boite fait du soft pour le bureau d'étude, ils vont adorer, si ce qu'ils font n'a rien à voir je ne vais certainement pas le mettre en avant (et il faut que je me prépare à répondre aux questions à la con qui seront posées sur le sujet).

En un sens, là les portfolios t'on donné l'heure juste sur l'incompatibilité de certains de tes candidats, mais si tu était tombé sur un type qui t'avais montré les illustrations idéales pour le poste ton avis serai probablement très différent.

[vv221]

Alors que des portefolio sur du dev de logiciel, de backend ou de trucs scientifiques, humpf, déjà ça ne court pas les rues, et je doute de l'intérêt. Perso, et ça vaut ce que ça vaut, j'ai beau avoir un github pour le plaisir qui se trouve être devenu un portefolio (projets qui ont leur petite popularité), et une seule personne l'a remarqué en plus de 10 ans, et encore, c'est juste qu'elle a vu que je faisais parti du top 100 des devs Java sur github. Les projets en eux-même on n'en a même pas parlé. Vraiment, d'autres canards auront peut être une expérience différente sur le sujet, mais j'ai l'impression qu'un portefolio en dev (et je dis bien en dev), c'est au mieux has-been, sinon inutile.

Jʼai lʼexpérience inverse ici : jʼai toujours été recruté suite au partage de mon "pet project". Mais il faut dire que cʼest un cas un poil extrême : il sʼagit dʼun projet logiciel que je dirige activement depuis 2013, sur une forge logicielle dédiée que je maintiens, intégré dans plusieurs distributions Linux…

Alors clairement en entretien dʼembauche ça claque, les profils un peu tech en face sont toujours impressionnés (le fait que ça tourne autour du jeu vidéo est aussi un atout). Mais il y a une contrepartie majeure : lʼimplication que ça me demande mʼempêche dʼavoir un emploi à temps plein en parallèle, ce qui limite fortement les possibilités de postes que je peux prendre.

Et surtout ce genre de chose ne se planifie pas vraiment. Il sʼagit à lʼorigine dʼun tout bête exercice que je mʼétais improvisé pour apprendre les bases du développement logiciel. Et qui mʼa un peu () dépassé au bout dʼun moment…

---

envoie le message: en fait ma passion c'est mon projet perso, du coup votre projet d'entreprise c'est du pur alimentaire. (c'est finalement un peu le cas de tout le monde, mais quand tu recrutes t'as pas envie t'entendre ça).

Ça je le dis cash en entretien dʼembauche. Bon, sans aller qualifier lʼentreprise de pur choix alimentaire, mais je dis bien dès le début que la priorité reste mon projet personnel et quʼen cas de conflit entre les deux cʼest lʼentreprise que je lâcherai, pas le projet auquel jʼai déjà donné des années de ma vie.

Jusquʼici cette honnêteté ne mʼa jamais fait manquer une embauche.

[sosoran]

[Nattefrost]

Tant que c'est honnête, si les deux parties sont au clair sur leurs attentes et leur investissement mutuel y a pas de raison que ça foire.
La difficulté c'est d'arriver à ce "point de clarté" entre les deux parties.

[vv221]

Tant que c'est honnête, si les deux parties sont au clair sur leurs attentes et leur investissement mutuel y a pas de raison que ça foire.
La difficulté c'est d'arriver à ce "point de clarté" entre les deux parties.

Pour moi ça fait même partie des critères au moment de choisir une entreprise.
Quand je signe un contrat cʼest généralement dans lʼidée de passer au moins quelques années dans une même boîte, alors si on nʼest pas capable de se causer franchement sur ce genre de sujet dès le début, je préfère passer mon chemin.

[gros_bidule]

C'est pas évident. Parfois, les personnes (même des devs ou managers) que tu vois en entretien, tu ne les verras jamais une fois en poste. Leur discours peut ne pas correspondre à ce que tu vivras là-bas, en bien ou en mal.
Je ne dis pas qu'il faut mentir et jouer le jeu du bon employé, mais je n'accorde pas grande importance aux "valeurs" discutées lors d'un entretien. C'est juste du blabla

[Kamasa]

Je sors d'un projet TypeScript-React-Recoil et je passe sur un projet javascript-React-Redux.

'tain c'est dur.
La gestion des états dans React par Recoil est tellement simplifiée, j'ai passé la journée à essayer de comprendre comment les états sont mis à jour par Redux. En l'occurrence dans le projet sur lequel j'ai atterrit.

Un conseil si vous avez l'occasion de partir sur un nouveau projet React et qu'on vous parle de Redux : proposez Recoil ! C'est encore parmi les "experimental features" de Facebook, mais c'est très avancé et très stable.

[Sangoon]

Je sors d'un projet TypeScript-React-Recoil et je passe sur un projet javascript-React-Redux.

'tain c'est dur.
La gestion des états dans React par Recoil est tellement simplifiée, j'ai passé la journée à essayer de comprendre comment les états sont mis à jour par Redux. En l'occurrence dans le projet sur lequel j'ai atterrit.

Un conseil si vous avez l'occasion de partir sur un nouveau projet React et qu'on vous parle de Redux : proposez Recoil ! C'est encore parmi les "experimental features" de Facebook, mais c'est très avancé et très stable.

Je n'ai pas assez d'xp en recoil pour te contredire , mais je ne trouve pas complexe le système de mise à jour du state dans redux, c'est simplement des résolutions d'actions assurées par les reducers.

Par contre, dans ta nouvelle stack, c'est plutôt le retour à du js qui me parait la plus grosse perte, une fois qu'on a gouter au typescript, c'est dur de revenir en js dans des projets un peu gros je trouve.

Edit : Ceci dit, recoil à l'air bien cool à utiliser aussi

[Orhin]

Assez d'accord.
Ceci-dit, Redux ça fait quand même pas mal de boiler-blate si tu l'utilises sans aucun autre outils/librairies.
Alors qu'avec du https://redux-toolkit.js.org/ ou autre, c'est quand même nettement plus plaisant à utiliser.

[Kamasa]

Diantre, en voyant ce que propose Redux Toolkit, je retrouve des trucs qu'il me semble avoir vu.
Peut être était-ce là la subtilité J'ai suivi rigoureusement la doc Redux mais s'il y a cet outil en place sur le code, ca expliquerai pourquoi j'ai eu l'impression de rater une marche.
Je vais jeter un oeil

[Anonyme20240202]

Y'a des canards qui font du networking en c++ avec support ssl/tls?

Jusqu'à maintenant j'utilisais openssl directement, mais cette librairie me dégoute, la documentation est très mauvaise et la librairie est extrêmement maladroite dans sa présentation, ça a pas l'air de s'améliorer pour la 3.0. Bref je me suis fait un petit wrapper maison comme tout le monde j'imagine mais j'aimerais bien passer vers quelque chose de plus standard/éviter de réinventer la roue.

Je vois que Boost.Asio propose son propre wrapper pour openSSL, ça a l'air correct, j'ai pas l'impression que y'ait la moindre alternative de toute façon.

Qu'est ce que vous faites de votre côté? D'ailleurs même si c'est pas c++ curieux de savoir comment vous gérez cet aspect.

Sinon un peu la même remarque pour ffmpeg, certes la librairie est surpuissante, mais niveau documentation y'a de petits couacs, pour certains détails c'est vraiment la surprise au runtime, faut tester et voir. Ou alors aller vérifier le code source directement pour savoir ce qui se passe vraiment.

[rOut]

ffmpeg et openssl sont bien connus pour être dégueulasses ouais. Wine utilise gnutls pour faire ça, je n'y ai pas trop touché mais je crois que c'est plutôt propre et la doc m'a paru bonne.

[Tramb]

Sinon un peu la même remarque pour ffmpeg, certes la librairie est surpuissante, mais niveau documentation y'a de petits couacs, pour certains détails c'est vraiment la surprise au runtime, faut tester et voir.

Oh oui. Oh que oui.

[Cwningen]

Bientôt* : D1861R0 Secure Connections in Networking TS

*Au moins 3 ans, mais pas garanti

[Garrluk]

Je n'ai jamais testé boost.asio directement mais mes collègues qui ont testé en parle souvent en mal.
A priori ça marche assez bien pour faire des trucs simples mais dès qu'on sort un peu de ce qui a été prévu on se retrouve à faire des bidouilles de métaprog dans tous les sens pour que ça marche comme on veut, avec l'explosion de la complexité du code et les temps de compile qui vont avec.
Mais ils sont assez "anti-boost" en général avec l'argument que ce qui est dans boost aujourd'hui c'est ce qui n'a pas été inclue en C++11 et que si ça n'a pas été inclue dans le standard c'est qu'il y a une raison. Et d'ailleurs leurs 2 exemples favori pour dire qu'il n'y a plus rien de bien dans boost aujourd'hui, c'est boost.Hana et boost.Asio.
Donc c'est pas forcément un avis super objectif.

[Anonyme20240202]

Wében jamais entendu parler de GNU TLS je vais jeter un oeil du coup, peut être un peu trop bas niveau concernant les abstractions mais la doc a l'air déjà bien plus réussie.

Ok je vais tester Boost.Asio et GNU TLS ou alors faire un truc un peu définitif pour mon wrapper openSSL et je reviendrai sur le topac si j'arrive à un truc qui me plait.

Concernant boost j'utilise un peu boost filesystem (iostreams) en attendant son intégration finale dans la lib standard (on y est presque selon les compilos) et de temps en temps quelques algos tout fait par soucis de confort. Genre récemment boost range parce que j'étais limité sur une certaine version de C++. Mais pas grand chose d'autre. Toujours été plutôt satisfait de ce qu'ils proposent (ah ouais sauf boost command line arguments, assez laid pour un problème aussi simple).

[Cwningen]

Mais ils sont assez "anti-boost" en général avec l'argument que ce qui est dans boost aujourd'hui c'est ce qui n'a pas été inclue en C++11 et que si ça n'a pas été inclue dans le standard c'est qu'il y a une raison. Et d'ailleurs leurs 2 exemples favori pour dire qu'il n'y a plus rien de bien dans boost aujourd'hui, c'est boost.Hana et boost.Asio.

Non, boost c'est ce qui n'a pas été inclus dans le C++20. Mais bientôt*, ce ne sera plus que ce qui n'a pas été inclus dans le C++23**. Je n'ai jamais utilisé ASIO mais il semble que ce soit compatible avec le futur standard.

*voir post précédent
**ou C++26 ou C++29...

[Nilsou]

Sinon un peu la même remarque pour ffmpeg, certes la librairie est surpuissante, mais niveau documentation y'a de petits couacs, pour certains détails c'est vraiment la surprise au runtime, faut tester et voir. Ou alors aller vérifier le code source directement pour savoir ce qui se passe vraiment.

fffmpeg de notre coté on faisait souvent ctrl-c ctrl-v du code source de mémoire, et après on allait voir dans le code. Ça prends pas tant de temps que ça tant que tu reste sur des applications classiques et que tu n'en change pas tout les 15 du mois.

[ducon]

Pourtant, ffmpeg est utilisé sur Mars.

[rOut]

Ben après y'a une différence entre utiliser un programme et une librairie, je pense que pour ffmpeg comme pour openssl, ça a d'abord été pensé comme des programmes opaques, dont l'interface en ligne de commande est à peu près claire et documentée. Le fait de vouloir tout embarquer comme des librairies c'est assez récent finalement, et changer un code avec autant d'historique pour en faire une librairie, c'est juste pas évident du tout.

[vectra]

Je n'ai jamais testé boost.asio directement mais mes collègues qui ont testé en parle souvent en mal.
A priori ça marche assez bien pour faire des trucs simples mais dès qu'on sort un peu de ce qui a été prévu on se retrouve à faire des bidouilles de métaprog dans tous les sens pour que ça marche comme on veut, avec l'explosion de la complexité du code et les temps de compile qui vont avec.
Mais ils sont assez "anti-boost" en général avec l'argument que ce qui est dans boost aujourd'hui c'est ce qui n'a pas été inclue en C++11 et que si ça n'a pas été inclue dans le standard c'est qu'il y a une raison. Et d'ailleurs leurs 2 exemples favori pour dire qu'il n'y a plus rien de bien dans boost aujourd'hui, c'est boost.Hana et boost.Asio.
Donc c'est pas forcément un avis super objectif.

Je comprends pas ce boost-bashing.
En 2014, tu faisais comment sans filesystem, thread, mutex? Tu passais sous Qt?

(Et program-options, c'est quand que ça rentre dans std?)

Si leur politique consiste à basher ce qui est sur boost mais à la fermer quand ça passe dans std...

[Le poussin]

Je n'ai jamais utilisé ASIO mais il semble que ce soit compatible avec le futur standard.

C'est Boost.Asio qui a servi de base au networking TS, ce qui assurait déjà une bonne base. Il y a eu quelques ajustements après revue par le standard, et Boost.Asio a en quelque sorte "backporté" ces ajustements.

[Anonyme20240202]

Ben après y'a une différence entre utiliser un programme et une librairie, je pense que pour ffmpeg comme pour openssl, ça a d'abord été pensé comme des programmes opaques, dont l'interface en ligne de commande est à peu près claire et documentée. Le fait de vouloir tout embarquer comme des librairies c'est assez récent finalement, et changer un code avec autant d'historique pour en faire une librairie, c'est juste pas évident du tout.

Yep exact, la ligne de commande est géniale. La librairie demeure cool mais quelques faux pas dans la doc'

[Garrluk]

Je comprends pas ce boost-bashing.
En 2014, tu faisais comment sans filesystem, thread, mutex? Tu passais sous Qt?

(Et program-options, c'est quand que ça rentre dans std?)

Si leur politique consiste à basher ce qui est sur boost mais à la fermer quand ça passe dans std...

Alors perso j'en sais rien, je fais surtout du très bas niveau, de l'embarqué et du GPU, donc boost j'y touche pas trop et quand je fais du C++ ça se limite souvent à du C avec des méthodes de classes et des namespaces.
Après ils sont du genre à réinventer la roue si un truc leur plait pas dans l'API, donc c'est pas forcément un exemple à suivre, je me contente de répéter ce que j'ai entendu.
Mais pour le coup, ils sont vraiment véhément envers boost.Asio.

Et non, ils bashent bien la stl aussi. Genre tout l'ancien filesystem (fstream et compagnie), l'absence de fonctions "utils" pour les strings (toUpper(), trim(), ...), les size_t pour les containers qui font des warnings dans tous les sens...

Le truc c'est pas de dire que ce qui est dans la stl c'est bien et dans boost c'est de la merde, c'est plutôt que avant c++11, boost servait de test pour ce qu'il était possible de mettre dans la stl (en gros quand quelqu'un proposait à un comité de rajouter quelque chose à la stl, la réponse était "met ça dans boost et après on verra"). Les trucs qui étaient prêt ont été rajoutés en 11, ceux pour lesquels il y avait 2/3 modifs à faire ont été rajoutés en 14, mais maintenant il ne reste que les trucs pas super utiles ou inutilement compliqués (encore une fois j'en sais rien, je ne fais que répéter).