Le topic de la programmation: Et envoyez des sioux!

[vv221]

Le mieux après c'est de trouver un boulot surpayé pour bosser exclusivement sur du logiciel libre, sans personne qui te dise sur quoi travailler ni comment le faire .

Pfff, frimeur

…

Ça recrutera par chez toi vers janvier-février 2022 ?

[Charmide]

En tout cas merci à tous pour vos conseils/expériences.

De ce que j'en retire c'est soit je me lance dans le dév web qui est apparemment plus accessible histoire de mettre un pied dedans, soit je persiste dans le dév C/C++/Python/trucmuch mais là ça demande quand même une expérience et même des années de formation (et je sais pas si je peux vraiment me le permettre vu que j'ai déjà 35 piges).

Dans l'idée caricaturale ouais. J'en rajoute une couche: Python c'est très populaire pour faire des backends web aussi (Django/Flask sont deux piliers en la matière), c'est un langage relativement "neutre" et populaire dans beaucoup de domaine. C/C++ c'est plus spécialisé, en général si tu descends aussi bas niveau c'est que t'as des enjeux importants de performance (e.g. faire tourner cyberpunk à plus de 15fps en ville) ou un environnement contraignant. Parce que c'est spécialisé j'aurais tendance à dire que effectivement y'a une barrière à l'entrée plus élevé.

(L'échange classique que t'auras partout c'est plus ou moins d'abstraction - moins d'abstraction === plus de contrôle === plus de boulot et de réinvention de la roue, C/C++ est à l'extrême de ce côté là, plus d'abstraction === plus de libraries et de machins === moins de contrôle === moins de boulot pour créer des trucs, de ce côté là des choses comme Java et ses sous-ensembles. Les industries/domaines se retrouvant quelque part sur l'échelle là où c'est logique pour eux.)

- - - Mise à jour - - -

Yep, perso j'ai déjà bossé sur un projet de ce type.
En gros c'est un boitier qui se connecte à plein de capteurs externes pour faire de la remontée d'information ou l'envoi de commandes. Le hardware est maison, ça tourne avec une distri linux custom et ça expose une API Rest pour communiquer avec l'extérieur.
Mais y'a aussi une interface de contrôle développée en Angular avec des tableaux/graphes/formulaires, le tout servie par un nginx.

Un autre exemple que j'aime bien : pas mal de gros jeux ont une interface utilisateur basée sur des technos web, genre Battlefield c'est du React.

Heureusement qu'on a plus les launchers en flash

[rOut]

Pfff, frimeur

…

Ça recrutera par chez toi vers janvier-février 2022 ?

C'est possible vu la tendance, mais c'est loin et aussi bien ça peut partir en couille avec le procès Oracle vs Google. Après c'est pas la seule boite à faire de l'open-source et y'a une bonne dynamique ces derniers temps je trouve.

[gros_bidule]

Après, si c'est l'opensource qui te bottes, sans forcément aller jusqu'au logiciel libre, il ne faut pas avoir peur de toquer à la porte de boites un peu célèbres (mais pas que).
Par exemple si l'on parle de Pivotal (Spring Framework), Gradle, RedHat, Google, etc, ça peut faire peur, on a facilement l'impression qu'il faut être un cador (on a vite en tête une ou deux "célébrités", en oubliant la masse un peu plus anonyme) pour postuler chez eux et avoir un poste intéressant. Sauf que non en fait, ils sont plus accessibles qu'on ne l'imagine. C'est plein de gens comme nous quoi, et le taff peut être épanouissant.

[Captain_Cowkill]

Dans l'idée caricaturale ouais. J'en rajoute une couche: Python c'est très populaire pour faire des backends web aussi (Django/Flask sont deux piliers en la matière), c'est un langage relativement "neutre" et populaire dans beaucoup de domaine. C/C++ c'est plus spécialisé, en général si tu descends aussi bas niveau c'est que t'as des enjeux importants de performance (e.g. faire tourner cyberpunk à plus de 15fps en ville) ou un environnement contraignant. Parce que c'est spécialisé j'aurais tendance à dire que effectivement y'a une barrière à l'entrée plus élevé.

(L'échange classique que t'auras partout c'est plus ou moins d'abstraction - moins d'abstraction === plus de contrôle === plus de boulot et de réinvention de la roue, C/C++ est à l'extrême de ce côté là, plus d'abstraction === plus de libraries et de machins === moins de contrôle === moins de boulot pour créer des trucs, de ce côté là des choses comme Java et ses sous-ensembles. Les industries/domaines se retrouvant quelque part sur l'échelle là où c'est logique pour eux.)

Désolé, j'ai pas trop compris ton dernier paragraphe

[Charmide]

Moi non plus en relisant, ça doit pas être une grande perte

[Nilsou]

Dans l'idée caricaturale ouais. J'en rajoute une couche: Python c'est très populaire pour faire des backends web aussi (Django/Flask sont deux piliers en la matière), c'est un langage relativement "neutre" et populaire dans beaucoup de domaine. C/C++ c'est plus spécialisé, en général si tu descends aussi bas niveau c'est que t'as des enjeux importants de performance (e.g. faire tourner cyberpunk à plus de 15fps en ville) ou un environnement contraignant. Parce que c'est spécialisé j'aurais tendance à dire que effectivement y'a une barrière à l'entrée plus élevé.

Tu exagère grandement. Je ne sais pas dans quel domaine tu bosse, mais en moyenne C/C++ c'est dans le top 5 des langages les plus demandés en entreprise. Et dans ce même top 5 tu a souvent Java ou C#, qui en sont lourdement inspiré. Donc tu te retrouve avec des top 5 ou 3/5 des langages les plus demandés c'est quand même des proches parents du C. Et le reste des tech, en dehors du Python, c'est du web.

Dire que C/C++ c'est ultra spécialisé c'est nimp.

(L'échange classique que t'auras partout c'est plus ou moins d'abstraction - moins d'abstraction === plus de contrôle === plus de boulot et de réinvention de la roue, C/C++ est à l'extrême de ce côté là, plus d'abstraction === plus de libraries et de machins === moins de contrôle === moins de boulot pour créer des trucs, de ce côté là des choses comme Java et ses sous-ensembles. Les industries/domaines se retrouvant quelque part sur l'échelle là où c'est logique pour eux.)

Là aussi c'est nimp, dire que C/C++ c'est « plus d'abstraction === plus de libraries et de machins === moins de contrôle === » alors qu'il s'agit d'un des langages ou tu peut le plus tripatouiller le détail du détail de ce que fait chaque fonction, c'est un peu nimp aussi, amha.
Surtout que tout les autres langages ou presque sont plus abstrait ...

[Orhin]

Tu exagère grandement. Je ne sais pas dans quel domaine tu bosse, mais en moyenne C/C++ c'est dans le top 5 des langages les plus demandés en entreprise.

Parler de top 5 ça n'a pas de sens, il faut regarder la part relative des langages.
Si les 2 premiers de ton top récupèrent 90% des projets, ça lui fait une belle jambe au C++ d'être dans le top 5.

Donc tu te retrouve avec des top 5 ou 3/5 des langages les plus demandés c'est quand même des proches parents du C.

Nawak.
Java ou C# ne sont absolument pas des proches parents du C (d'un point de vue utilisation au quotidien hein, on s'en fout qu'historiquement il y ait des liens).

Dire que C/C++ c'est ultra spécialisé c'est nimp.

C'est pourtant la réalité du terrain.
Je suis désolé mais t'as l'air d'avoir une vision ultra biaisée de ce qui se passe vraiment dans les entreprises qui font de l'informatique.

Le C/C++ est très utilisé dans certains domaines ayant de fortes contraintes (bas niveau, traitement temps réel dans la communication, grosse simulation, etc) par contre dans les autres domaines ce sont des langages quasi absents.

Là aussi c'est nimp, dire que C/C++ c'est « plus d'abstraction === plus de libraries et de machins === moins de contrôle === » alors qu'il s'agit d'un des langages ou tu peut le plus tripatouiller le détail du détail de ce que fait chaque fonction, c'est un peu nimp aussi, amha.
Surtout que tout les autres langages ou presque sont plus abstrait ...

T'as compris exactement l'inverse de ce qu'il voulait dire hein.
Il dit justement que C/C++ c'est moins d'abstraction et plus de contrôle.

Bon ok son paragraphe était super mal rédigé par contre.

[Charmide]

Tu exagère grandement. Je ne sais pas dans quel domaine tu bosse, mais en moyenne C/C++ c'est dans le top 5 des langages les plus demandés en entreprise. Et dans ce même top 5 tu a souvent Java ou C#, qui en sont lourdement inspiré. Donc tu te retrouve avec des top 5 ou 3/5 des langages les plus demandés c'est quand même des proches parents du C. Et le reste des tech, en dehors du Python, c'est du web.

Dire que C/C++ c'est ultra spécialisé c'est nimp

J'ai bien dit "caricaturalement" et j'ai jamais dit que c'était un truc ultra confidentiel qui sert à rien ou je ne sais quoi que tu t'imagines. T'es sérieux quand t'utilises Java comme argument sinon? A ce compte là tu peux mettre tous les langages impératifs dans le même panier je pense.

Là aussi c'est nimp, dire que C/C++ c'est « plus d'abstraction === plus de libraries et de machins === moins de contrôle === » alors qu'il s'agit d'un des langages ou tu peut le plus tripatouiller le détail du détail de ce que fait chaque fonction, c'est un peu nimp aussi, amha.
Surtout que tout les autres langages ou presque sont plus abstrait ...

C'est littéralement ce que j'ai écris nilsounet, mais c'est pas grave.

Mon prochain post ça sera 1+1=2, j'attends avec impatience ta réponse pour expliquer que c'est n'imp.

EDIT: zut grillé, mais c'est bien ça me rassure :x

[Cwningen]

C++ === moins d'abstraction ?

Et 1+1=10 tout le monde le sait.

[TwinBis]

C++ === moins d'abstraction ?

Que Java et ses copains, oui.
Il faut lire son message en entier (même si la forme pique un peu).

C++ ça reste considéré comme un langage bas niveau dans l'informatique "au global" (pour ce que ça vaut).

[Cwningen]

Qu'est-ce qui manque au C++ ? C'est quoi vos critères pour ce manichéisme bas/haut niveau ? Ça fait dix ans que j'ai pas touché au Java, et j'ai cru comprendre que ça a beaucoup évolué depuis, mais à l'époque ça me semblait pas permettre tellement plus d'abstractions.

[TwinBis]

C'est pas une question de manichéisme, c'est une question de distance au hardware par ajoût de couches d'abstraction successives.
Et haut/bas niveau ce n'est pas un jugement de valeur, ce sont des outils différents pour des usages différents. Il faut arrêter de placer sa fierté dans le technos que vous utilisez.

[Cwningen]

C'est pas un problème de valeur ou de fierté, c'est un problème de classer les langages en deux catégories que je ne comprends pas.

[TwinBis]

http://icarus.cs.weber.edu/~dab/cs14.../programs.html

[Orhin]

C'est pas un problème de valeur ou de fierté, c'est un problème de classer les langages en deux catégories que je ne comprends pas.

Mais il n'y a pas 2 catégories, le classement bas/haut niveau c'est toujours relativement à un autre langage.
À la limite tu peux le représenter sauf forme d'un axe.

[rOut]

Franchement le C++ moderne c'est quand même vachement haut niveau. Ça plane même un petit peu trop haut à mon avis (pour une utilisation professionnelle on va dire).

[Cwningen]

http://icarus.cs.weber.edu/~dab/cs14.../programs.html

Ce texte classe bien le C++ dans les langages de plus haut niveau (tous les langages cités sont de haut niveau d'après lui). La notion du bas niveau est présentée comme la possibilité d'accès au matériel, rien à voir avec les abstractions possibles.

Le C++ permet d’accéder au matériel (si tu en as envie) et, en même temps, d'utiliser des abstractions (si tu en as envie). Je ne comprends pas comment on peut le mettre à l'extrémité "moins d'abstraction" de cet axe.

[Charmide]

Alors oui, on peut rajouter 28 couches de frameworks, librairies et abstraction dans n'importe quel langage, tout comme en règle générale on peut se démerder pour en avoir le minimum vital dans n'importe quel contexte. Bien pour ça que les guerres de clocher entre langages de programmation m'ont toujours fait bien marrer. Il "manque" rien au C++, c'est turing complet et y'a un écosystème, regarde juste dans quel domaine et pour faire quoi c'est utilisé.

Faut se rappeler que j'essayais de donner des repères à un mec qui se lance tout juste et qui n'en a pas. Tu peux toujours trouver des exceptions, incroyablement la vie est plus compliqué que quand tu la projettes sur un axe, c'est pas pour ça que les heuritstiques sont inutiles. Tu peux toujours avoir un référentiel différent que celui de "l'industrie", ce truc flou et vague dans lequel on mélange 29745 domaines différents, et trouver que le C++ c'est déjà trop haut niveau, tout dépend de ce que tu fais.
En attendant, si tu regardes à l'échelle de l'industrie et de ce que fait le dev moyen en 2020, ça tombe clairement dans le top 10/15% de la distribution dans ce domaine. Et ça me semble utile de se rendre compte en tant que noob que y'a des gens qui ont un accès direct au matériel parce qu'ils en ont besoin, et d'autres qui branchent 23 librairies dans une VM de VM de VM pour faire communiquer 2 ERPs sans avoir jamais appris ce que c'est qu'un pointeur.

[Nilsou]

Parler de top 5 ça n'a pas de sens, il faut regarder la part relative des langages.
Si les 2 premiers de ton top récupèrent 90% des projets, ça lui fait une belle jambe au C++ d'être dans le top 5.

Bah le C est le langage le plus utilisé dans les entreprises (en 2016 du moins) d'après l'IEEE. Ça a l'air d'être une étude globale sur le monde.
https://www.inteam.fr/blog/langages-...s-entreprises/

Même aujourd'hui le C reste l'un des premiers dans les classement IEEE Spectrum : https://spectrum.ieee.org/static/int...languages-2020

Sur les offres d'emploi en 2019 : le C++ c'est 36000 emploi, à peu prés autant que javascript et derrière Python et Java (qui sont dans les 68000). Là non plus on est loin d'être sur un petit langage spécialisé. (source) et on est loin de ton « premier qui fait 90% des projets ».

Chez developez.net leur classement sur leurs offres d'emploi sur leur propre portail en France donne le C+C++ à environ 12% des offres. Genre, légèrement devant Python, C# et PHP quoi ...
https://emploi.developpez.com/actu/3...s-mieux-payes/ et avec seul deux langages qui recrutent bien plus : le Java et le Javascript.

Et c'est sans compter le C#, qui, si si, est un proche parent du C++.

[Charmide]

"10/15%", facile

[Tramb]

Le C++ permet d’accéder au matériel (si tu en as envie)

Grâce à sa feature de "Ubiquitous Undefined Behaviour"

[Nilsou]

Bon question pratique sinon,
Je refait en ce moment, justement, un cours de C++.

Je me demande si il n'y a pas eu une évolution du langage dans C++17 ou dans la version 2020 sur l'héritage et les surcharge, mais impossible de trouver la réponse.

En gros, en C++, dans mes connaissances traditionnelle, la surcharge ne fonctionne pas entre classe mère et classe fille (comprendre : une classe mère qui contient une méthode void foo(int a) et une classe fille contenant une méthode void foo(float b) si j’appelle foo(int) sur une instance de la classe fille, ça ne m’appellera pas la variante de la classe mère, qui correspond, ça me jettera à la compilation ou ça me fera une conversion implicite.

J'ai toujours trouvé cette (absence de) mécanique débile. Je me demandais si ça avait été modifié en C++17 et postérieur ?

J'ai fouillé, sans rien trouver, mais j'ai peut-être manqué un truc ?

[Mr Slurp]

Bon question pratique sinon,
Je refait en ce moment, justement, un cours de C++.

Je me demande si il n'y a pas eu une évolution du langage dans C++17 ou dans la version 2020 sur l'héritage et les surcharge, mais impossible de trouver la réponse.

En gros, en C++, dans mes connaissances traditionnelle, la surcharge ne fonctionne pas entre classe mère et classe fille (comprendre : une classe mère qui contient une méthode void foo(int a) et une classe fille contenant une méthode void foo(float b) si j’appelle foo(int) sur une instance de la classe fille, ça ne m’appellera pas la variante de la classe mère, qui correspond, ça me jettera à la compilation ou ça me fera une conversion implicite.

Non, ça le fera pas. Une surcharge n'est pas une méthode virtuelle, et une virtuelle à forcément la même signature entre classe mère et fille. Ce que du décrit serait une sorte de mix bâtard des deux que je ne vois pas possible sans être une grosse source de problème.

[Anonyme20240202]

#include <iostream>

class Parent {
  public:
    void work(const std::string& in) {
        std::cout << data << in << std::endl;
    }
  private:
    const std::string data{"Parent: "};
};

class Child : public Parent {
  public:
    using Parent::work; // Impossible de compiler sans
    void work(float in) {
        std::cout << data << in << std::endl;
    }
  private:
    const std::string data{"Child: "};
};

int main() {
    Parent parent;
    parent.work("text 1");
    
    Child child;
    child.work(2);
    child.work("text 2");
}

Out

Parent: text 1
Child: 2
Parent: text 2

[Anonyme20240202]

Ah et pour la conversion implicite

#include <iostream>

class Parent {
  public:
    void work(int in) {
        std::cout << data << in << std::endl;
    }
  private:
    const std::string data{"Parent: "};
};

class Child : public Parent {
  public:
    using Parent::work;
    void work(float in) {
        std::cout << data << in << std::endl;
    }
  private:
    const std::string data{"Child: "};
};

int main() {
    Parent parent;
    parent.work(1);
    
    Child child;
    child.work(2.0);
    child.work(3);
}

main.cpp:27:19: error: call of overloaded ‘work(double)’ is ambiguous

Fix

child.work((float)2.0);

child.work((int)2.0);

Mais bon ouais c'tait plus pour répondre pour la blague, perso je commence toujours avec mon besoin puis je me réfère à la documentation, je fais pas émerger des possibilités bizarres pour voir ce que ça peut faire.

Donc dans ce cas j'ai pas réfléchi au sens que ça pourrait avoir et je doute que y'en ai besoin

[Cwningen]

child.work(2.0f);

Les suffixes c'est plus pratique (il y en a aussi pour les entiers).

[Anonyme20240202]

Ouais t'inquiète pas je passe ma vie avec surtout avec std::chrono_literals

[Nilsou]

Non, ça le fera pas. Une surcharge n'est pas une méthode virtuelle, et une virtuelle à forcément la même signature entre classe mère et fille. Ce que du décrit serait une sorte de mix bâtard des deux que je ne vois pas possible sans être une grosse source de problème.

J'arrive pas à voir le problème : le compilateur irait chercher la classe void foo(int) dans sa classe, il se rends compte que ça n'existe pas alors il va la chercher dans la classe mère. A partir du moment ou la méthode est protected ou public elle est censé être accessible à la classe fille et le mécanisme de surcharge standard prendre le relai comme partout ailleurs.
En fait c'est un soucis qui a une origine technique je pense à l'origine, sur le papier je ne voit pas bien pourquoi ça devrait être impossible.

- - - Mise à jour - - -

Ouais t'inquiète pas je passe ma vie avec surtout avec std::chrono_literals

Merci pour tes réponses Kamikaze, l'astuce du using je l'avais déjà vu mais jamais utilisé, c'est une bonne réponse au problème en effet

Même si je trouve que ça devrait vraiment être le comportement par défaut, je suis étonné que ça n'ait pas été intégré en C++20, j'imagine qu'il y a une bonne raison mais je ne trouve pas laquelle...

[Mr Slurp]

J'arrive pas à voir le problème : le compilateur irait chercher la classe void foo(int) dans sa classe, il se rends compte que ça n'existe pas alors il va la chercher dans la classe mère. A partir du moment ou la méthode est protected ou public elle est censé être accessible à la classe fille et le mécanisme de surcharge standard prendre le relai comme partout ailleurs.
En fait c'est un soucis qui a une origine technique je pense à l'origine, sur le papier je ne voit pas bien pourquoi ça devrait être impossible.

- - - Mise à jour - - -



Merci pour tes réponses Kamikaze, l'astuce du using je l'avais déjà vu mais jamais utilisé, c'est une bonne réponse au problème en effet

Même si je trouve que ça devrait vraiment être le comportement par défaut, je suis étonné que ça n'ait pas été intégré en C++20, j'imagine qu'il y a une bonne raison mais je ne trouve pas laquelle...

J'avoue que je ne connaissait pas non plus cet usage du "using", mais étant donné que c'est du C++ 17, je suis moins surpris de ne le rencontrer que maintenant.
Pour moi la source de problème serait pour une grosse partie des développeurs par forcément au point sur les standard (et je m'inclue partiellement dedans) de comprendre pourquoi telle ou telle version serait appelé, et si le cas présenté ici est encore assez simple avec des types natifs, il serait plus compliqué à désambiguïser si ton paramètres était une classes ou un de ses héritage.