Le pub des programmeurs
- 1 927 réponses
- 117 participants
- 131 717 vues
- 130 followers
y a des programeurs sur AF si oui vous bossez sous quoi ?
jujupauty
Hors sujet : Comme disait Coluche: con promis chose due 
Jul
Pov Gabou
Citation :
Quand tu fais de la programmation réseau bas niveau.
Tu sais, quand t'écris tes paquets IP à la main...pour des algos de routage par exemple...
Y'a eu un client Kademlia qui a été tenté en Java, c'est une merde innomable qui te bouffe toute ta RAM (bon c'est aussi en grande partie dûe à la VM).
Ou quand je fais du développement pour téléphone portable et en technos embarqués. Même si la plupart du code est maintenant en NesC (dialecte de C), y'en a quand même en C++.
Du calcul 3D...
Des algos de recherche opérationnelle..
En gros, à chaque fois que les ressources machines peuvent être limitées.
Non mais ce sont des niches, tout ca: programmation reseau bas niveau, moteur graphique, etc... c'est quand meme pas la majorite du code ecrit aujourd'hui. Le code bas niveau est ecrit avec des langages de bas niveau, on est d'accord. Evidemment, la pile IP de linux, elle va pas etre faite en java
Et les OS courants sont toujours developpes en C a la tres grosse majorite. Mais meme dans certaines applis que tu cites, on voit des langages haut niveau apparaitre Le premier, evident, qui vient en tete, c'est erlang, pour certaines applis backend de telephonie.
Citation :
Pour la rapidité de prototypage, ben dans les gros softs ce n'est pas recherché, au contraire
Y a pas que le prototypage, il y a aussi la refactorisation.
Citation :
Que signifie "duck typing" ?
If it is behaving like a duck, it is a duck
En fait, python est un langage type fort, mais c'est jamais verifie dans un appel de fonction. Par exemple:def foo(a):
return a.bar()
La fonction foo marchera tout le temps tant que a a une fonction bar. Et c'est super utile pour changer en cours de route une api, car si jamais avant a etait derive quelque part d'une classe A, et que maintenant c'est derive de classe B, en C++, tu vois le bordel.
Alors le pendant, c'est que parfois, si tu passes un mauvais object, tu peux avoir un bug (genre une liste au lieu d'une chaine de characteres). Au moins pour les problemes pour lesquels j'utilise python, ca ne ma jamais pose de pb fondamental.
Je suis d'accord que tu vas pas utiliser ca pour du code militaire sensible
Mais je pense pas etre totalement deconnecte de la realite industrielle niveau informatique, ne serait-ce que parce que je frequente des gens en plein dedans; et les gros projets industriels statiques, c'est pas a la hausse. Alors peut etre que je connais que des gens dans des secteurs particuliers ? Mais en finance, dev web (cote client et cote backend), data mining, calcul distribue/calcul numerique, traitement signal, les langages a la C/C++ sont relegues a des petites parties, avec d'autres langages plus haut niveau pour le reste. Je serais curieux de voir le nombre de developpeurs par type de projet informatique, ca doit etre super interessant. Le college qui m'a fait decouvrir python, il a bosse 10 ans dans l'industrie du jeu video avant de fonder sa boite de service informatiques pour petites entreprises
(ex fan de C++ aussi, d'ailleurs). Je pense que l'approche un langage bas niveau pour le gros d'un projet, c'est plus valable aujourd'hui en grosse majorite. La gestion de la memoire a la main, ce sera bientot marginal comme l'est l'assembleur aujourd'hui: indispendable dans certains cas, mais la plupart du temps, la machine (compilateur, VM) le fait mieux.
batman14
zieQ
cptn.io
Par rapport à l'assembleur, je nuancerais tout de meme, je suis en DUT GEII ( Electronique Informatique Indus), vous savez là où on programme des microcontroleurs, et microproc, ba ils ont enlevé l'assembleur car apparement les boites recherchent les mecs assez polyvalents pour entrer avec un DUT GEII mais faire un boulot de DUT GEII+DUT Info (+concierge
;)).Donc l'assembleur, c'est encore pratique si tu veux t'amuser à faire vraiment du hard, si t'es sur du tiny tiny et que tu veux avoir une fusée avec une deudeuch de uC ...
Par rapport au système VM, ba je vais pas t'apporter d'arguments contre, mais je pense que ptet que java va aller plus vers le python mnan ...
cptn.io
batman14
cptn.io
cptn.io
Dr Pouet
Citation : En tout cas les débats sur les langages c'est comme le débat des différentes qualité des séquenceurs...
Mais bon, je m'y fais prendre à chaque fois. (vive la polémique héhé.)
Pov Gabou
cptn.io
Pov Gabou
Dr Pouet
zieQ
Dr Pouet
Hors sujet : Appelle nous Pouet et Gabou, restons simples, cher zieQ
Pov Gabou
zieQ
Pov Gabou
Citation :
Ne pas oublier la protection des données encapsulées : public, protected, private... Tu vas me dire que c'est une contrainte de protéger les données, moi je vais te répondre que ça évite de faire des conneries
Je dis pas que c'est pas important, je dis que c'est trivial, et que tout langage a cette possibilite, y compris le C finalement.
La encore, cette difference private/public/protected n'existe qu'en C++ et en java, parce que c'est une limitation du typage statique. En plus, en C++, t'as un gros probleme a ce niveau la a cause de headers, qui revient a faire pareil qu'en C finalement. Si tu veux cacher l'implementation dans des projets d'un peu gros calibre (et par la, j'entends a peu pres n'importe quoi qui ne soit pas un exemple de bouquin)
header:
/* forward declaration */
class A_imp;
class A {
private:
A_imp *m_imp;
};
implementation
class A_imp {
// bla bla
};
Du coup, c'est comme en C ou tu declares les structures, mais ou tu les definis pas (tu peux declarer FILE* a, mais pas FILE a avec stdio). Tu peux aussi utiliser une classe virtuelle, et heriter d'elle, mais c'est pas super joli non plus.
En C++, t'as pas de mecanisme pour decoupler fonctions membres et "variables" membres (pas sur du terme technique).
Citation :
Là va falloir m'expliquer cette remarque parce que je ne comprends pas ce que tu veux dire.
C'est fondamental: deja, tu ne peux deriver aucun type du langage C++. Tu peux pas faire "class MyInt : public int". Ensuite, une fonction n'est pas un objet en C++, donc tu peux pas passer facilement des fonctions en arguments (les pointeurs de fonctions membres en C++, je suis pret a parier que la majorite des programmeurs C++ savent pas comment ca marche). Une classe non plus.
En python (je prends python parce que je connais plus que superficiellement, mais ca reste valable pour pleins d'autres langages), le fait qu'une classe EST un objet est super utile; rien que pour avoir des attributs de classe par exemple.
Le fait que ce soit dynamique est aussi super utile: par exemple, j'ai une classe qui modele un modele numerique en python, GMM. Normalement, ca marche en multi dimension, mais en 1 dimension, on peut faire plus rapidement, surtout si j'implemente la dite fonction en C. Et bien en python, je peux faire (self est l'equivalent de this en C++; en python, il est explicite):
from foo import super_fast_func
class GMM:
def __init__(self, dim):
if dim == 1:
self.foo = super_fast_foo
Si je suis en dimension 1, l'implementation est changee a la volee. Le truc super important, c'est que ca se change n'importe quand, y compris quand l'objet instancie de GMM est deja cree (en fait, avant l'appel d'__init__, l'objet est deja construit en python, mais je veux pas rentrer dans les details). Donc par exemple, tu peux rajouter des fonctions a la volee selon l'etat de l'objet.
Citation : Ce problème est inhérent à *tous* les langages objets, et pas spécifiquement le C++.
Non, c'est inherent aux langages a typage statique (C++ et Java, en gros). Dans un langage a typage dynamique, si tu as fait une erreur de conception, c'est pas un probleme, car tu n'utilises pour ainsi dire *jamais* le fait qu'une instance de B est aussi de type A. On s'en fout, ce qui compte, c'est que l'interface (ie les membres, fonctions, attributs, etc..) soit la meme.
Un des inventeurs du concept objet, Kay, qui a aussi invente le smalltalk, il l'a fait avec un langage a typage dynamique. C'est pas par hasard, je pense.
Citation : Ben euh tu passes ton objet en référence ?
Je parle de la valeur de *retour*. C'est la le probleme, pas l'entree. Tu peux pas passer une valeur de retour par reference en C++ (puisque ca n'a pas de sens sans gestion automatique de la memoire).
La gestion de memoire automatique: le temps reel, Ok, les GC courants sont pas adaptes, car ils privilegient le debit par rapport a la latence, alors que temps reel est le contraire. Mais quand tu fais du temps reel, je crois que tu geres de toute facon pas de memoire dans les threads temps reels; malloc est souvent plus couteux qu'un declenchement de GC (a moins que le malloc soit gere a l'aide de mmap/pools, mais a ce niveau la, c'est plus facile de toute allouer a l'avance). Bon, je m'avance beaucoup sur ce point, j'ai tres peu d'experience; pour la MAO, en tout cas, tout ce qui est DSP, le malloc est fortement deconseille (tout appel systeme est prohibe en fait). Tu lockes une partie de la memoire pour eviter le cout eventuel de la pagination, et tu fais avec ce que tu as allouer a l'initialisation ou au reste de l'algo dsp, point barre.
Ensuite, pour a peu pres tout le reste, ca sert pas a grand chose, la grestion memoire a la main. Par exemple, la memoire allouee par un GC respecte beaucoup le principe de localite qu'un malloc classique (au moins sous linux; mais je suis pres a parier que le malloc sous linux est bien plus performant que sous windows de toute facon); y a moins de pbs de fragmentation. Quand tu sais comment fonctionne un malloc et un GC basique, tu vois vite que c'est pas si different dans le principe.
En particulier, pour les containers STL, java est aujourd'hui tout aussi performant si tu utilises les JVM IBM sous linux sur tous les benchmarks que j'ai pu voir (j'ai pas pousse trop loin non plus; il y a surement des cas ou ca foire; en fait, le pire cas doit etre bien pire en java qu'en C++, je pense). C'est aussi lie au pb que je soulevais avant vis a vis de l'absence de retour sans copie en C++ (la STL etant base sur la copie; t'es sur de te planter a un moment si tu as list<blop> ou blop est un pointeur; tu peux eviter ca en utiliser noncopyable de boost, cependant, mais c'est pas tres elegant).
Citation :
C'est moins souple à l'utilisation mais ça fait des programmes avec moins d'erreurs.
Encore une fois, ton raisonnement sous entend que toute autre chose etant egal, le typage statique est plus safe. Mais justement, tout autre chose n'est pas du tout egale. Je suis d'accord qu'il y a des projets ou declarer le type de certains fonctions est tres utile, et c'est un manque dans python.
Pour finir sur une note positive, je trouve que le meilleur argumentaire *pour* le C++, c'est celui de L. Soras que je copie de la:
http://lalists.stanford.edu/lad/2003/02/0068.html
(contexte: reponse a une interview de E. Castro de Lopo, un des developpeurs les plus celebres de la scene programmation audio sous linux, auteur de libsndfile, et SRC, qui a bosse pour fairlight pendant qqs annees, et haissant profondement le C++, plus que moi; je suis entre autre pas d'accord sur le fait que le C est plus adapte, ou plutot moins pire que le C++ pour de la conception objet; je suis d'accord pour les template par contre
)Citation :
Erik de Castro Lopo wrote:
>
> 1) C++ is not the only solution.
> 2) OO can be done in Standard C.
> 3) Some people (me included) might prefer doing OO programing in C
> rather than C++.
I agree, but partially. My opinion about OO in C vs C++ :
I think C++ adds (very useful) functionalities to C. You
can still emulate them, but it's often a pain and less
"encapsulated" than equivalent C++ concept. More, goals
of language constructions are more obvious if written
in native C++, making easier communication between
developers. C++ is just more suitable for OO developement.
Who does seriously want to write a book with a typewriter
when one can use a word processor ?
C++ is not safer or faster than C or whatever. If you want
to make something stupid, nothing prevents you to do it.
I agree C++ is still far from perfect, but for me it's today
the best solution for audio development. It needs strong
coding rules, deep comprehension of the language, software
engineering knowledge and experience to be used efficiently.
It won't make miracles just because it's C++. Learning and
applying all these concepts won't happen "in 21 days", for
sure.
Finally I'd say it makes gain time when mastered, a lot of
time, one of the most valuable ressource in today's world
IMHO.
-- Laurent
Pov Gabou
emx
Dr Pouet
zieQ
zieQ
zieQ
Pov Gabou
Pov Gabou
- < Liste des sujets
- Charte