je suis plutôt fan de Python d'habitude, mais récemment, j'ai eu besoin d'écrire une DLL pour un logiciel propriétaire existant (pour y intégrer une description des produits commercialisés par l'entreprise dans laquelle je bosse) il a donc fallu renoncer à Python...
J'ai d'abord commencé à coder en C++ puisque c'est ce qui est utilisé couramment pour ce genre de choses. Evidemment, n'étant pas développeur, j'ai galéré comme un malade... Entre les problèmes de librairies, les problèmes de compilateur, et le langage lui-même qui est quand même bien compliqué, je ne m'en suis pas sorti.
Alors je me suis mis à la recherche d'un langage système (avec lequel je puisse écrire une DLL) qui soit simple à apprendre. Je voulais également avoir des outils libres. (j'ai demandé un peu d'aide ici http://linuxfr.org/forums/41/22303.html mais ça n'a pas donné grand chose)
J'ai envisagé les langages suivants:
1/ Ocaml
Ocaml a été rapidement éliminé car je me suis vite rendu compte qu'il serait beaucoup trop long à apprendre pour quelqu'un comme moi dont la programmation n'est pas le métier. J'ai tout de même été déçu de ne pas pouvoir consacrer plus de temps à l'étude de ce langage.
2/ Pascal
Pascal est souvent présenté comme un bon langage pour les débutants. Pourtant, je n'ai pas aimé la syntaxe (après un end, il faut un point-virgule ou un point?). Ce langage semble être d'un autre age et le fait qu'il ne soit pas standardisé a également contribué à me faire abandonner: le portage d'un compilateur à un autre est une tâche ardue en Pascal (dixit Wikipedia).
2/ Le language D
C'est le grand gagnant de mes recherches: il s'agit d'une sorte de C++ dont la syntaxe est cohérente. Pour un débutant, les principales différences par rapport à C++ sont les suivantes:
- possibilité d'utiliser un ramasse-miette pour la mémoire (activé par défaut)
- pas de préprocesseur
- fonctionnement en module, comme python
- pas de séparation en-tête/implémentation
- programmation par contrat intégrée dans le langage: (pré/post)-condition pour les fonctions, tests unitaires directement dans la définition des classes, "vrai" assert.
- minimisation de l'utilisation des pointeurs: tableaux dynamiques intégrés, passage par référence par défaut
- tableaux associatifs intégrés
- utilisation du mot clé "auto" pour définir une nouvelle variable sans avoir besoin de répéter le type (Par exemple MonObjet* obj=new MonObjet() est équivalent à auto obj=new MonObjet() )
- les opérateurs "->" et "::" n'existe pas. On utilise le point à la place
Toutes ces propriétés rapprochent beaucoup le langage D du langage Python: ce qui est simple à comprendre est simple à écrire. Il n'y a pas de bizarrerie dans le langage. On se retrouve beaucoup moins souvent avec des problèmes obscurs de syntaxe comme on peut en avoir avec C++.
Pour les développeurs plus expérimentés, il y a tout ce qu'il faut également. Je vous invite à aller voir directement sur le site de digitalmars: http://www.digitalmars.com/d/
Plusieurs implémentations de compilateurs existent pour le langage D. Les plus importantes sont dmd (Digital Mars D compiler) et gdc (Gnu D Compiler), un front-end D pour gcc.
Voilà. J'ai voulu faire ce journal parce qu'on a très peu parlé de ce langage sur linuxfr...
Et vous, avez-vous déjà essayé le langage D? Qu'en pensez-vous?
# Le C++ peut être simple
Posté par Tristram . Évalué à 3.
Pour un petit code, tu peux tout définir dans un seul fichier, pas forcément besoin de headers.
Pour la mémoire, MonObjet a; crée l'objet, il sera automatiquement détruit à la fin de la fonction et tu accèdes aux méthodes avec le . a.foo();
Bref, le C++ n'oblige pas d'utiliser des pointeurs et de faire des bizareries avec le préprocesseur.
Son défaut c'est de permettre tellement de trucs (je découvre actuellement les possibilités fonctionnelles) qu'on en apprend tous les jours, et que les exemples ne sont pas cohérent.
Après, je ne vois pas trop l'interêt du D, à part être un C++ allégé (mais j'y jetterai coup d'oeil quand j'aurais du temps libre, c'est peut-être interessant).
[^] # Re: Le C++ peut être simple
Posté par pasBill pasGates . Évalué à 5.
Ca je crois qu'il le sait, le probleme ici c'est que ton objet il est sur la pile est il _sera_ detruit a la sortie de la fonction.
Si t'as pas envie qu'il soit detruit, faut commencer a jouer avec les smart pointers, et il faut alors _comprendre_ ce que sont ces smart pointers.
[^] # Re: Le C++ peut être simple
Posté par beleys (site web personnel) . Évalué à 1.
Si tu fait void toto(objet & monObjet);
Quand tu sors de ta fonction ton objet existe toujours, et pas besoin de connaissance dans les pointeurs pour l'utiliser car ils sont masqués, enfin après tout depend si l'on veut défendre le langage ou faire peur :D
++ Beleys
[^] # Re: Le C++ peut être simple
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
Tu as évité une recopie d'objet pour un appel de fonction, mais ton exemple ne change absoluement pas la notion de portée de variable. L'objet sera détruit à la fin du bloc dans lequel il est déclaré (c'est souvent ce qu'on veut, mais pas toujours le cas).
[^] # Re: Le C++ peut être simple
Posté par pasBill pasGates . Évalué à 3.
B) Ton code qui fait ca, c'est un fromage, tu vas passer un pointeur sur un objet local a l'exterieur, mais ton objet sera detruit quand meme a la sortie de la fonction, resultat, le reste de ton code va jouer avec un objet detruit, et planter.
La regle est hyper-simple: si ton objet doit etre utilise hors de la fonction, il ne PEUT PAS etre sur la pile.
[^] # Re: Le C++ peut être simple
Posté par beleys (site web personnel) . Évalué à 3.
Sinon, oui j'étais à coté de la plaque , je n'avais pas saisi que l'on souhaitait conserver un objet après son bloc de déclaration .
[^] # Re: Le C++ peut être simple
Posté par Gilles G. . Évalué à 6.
import std.math : sqrt;
float vectorLength(float[] v)
in
{
assert(v.length==3);
}
out(result)
{
assert(result>=0);
}
body
{
return sqrt(x[0]*x[0]+x[1]*x[1]+x[2]*x[2]);
}
En C/C++, il n'y a pas de moyen simple de mettre des conditions à l'entrée et à la sortie des fonctions.
Par ailleurs, en C/C++, tu aurais été obligé d'utiliser les pointeurs (ou éventuellement les références). Mais en pratique, on alloue les vecteurs de manière dynamique, donc on se retrouve à utiliser tout le temps les pointeurs.
Pour un débutant, le concept (qui vient du C) selon lequel une variable qui décrit un tableau est en fait un pointeur vers son premier élément est complètement foireux (c'est mon avis et je le partage!!). Je trouve que cela rend le code C assez difficile à comprendre.
Exemples en D:
+ un int est un entier
+ un int* est un pointeur d'entier
+ un int[] est un tableau d'entier
+ un int*[] est un tableau de pointeurs d'entiers...
+ un int[][] est un tableau d'entiers à deux dimensions
En C cela donne:
+ un int est un entier
+ un int* est un pointeur d'entier
+ un int* est un tableau d'entier
+ un int** est un tableau de pointeurs d'entiers...
+ un int** est un tableau d'entiers à deux dimensions
On voit bien qu'il y a un problème en C pour distinguer certains cas. Ce n'est pas idéal, en particulier pour les débutants!
[^] # Re: Le C++ peut être simple
Posté par Cyrille Pontvieux (site web personnel, Mastodon) . Évalué à 5.
Non ?
[^] # Re: Le C++ peut être simple
Posté par Gilles G. . Évalué à 1.
Tiens, c'est marrant je ne semble pas être le seul à me planter vu comme tu as été plussé...
int[] v; // Erreur. N'est pas autorisé en C++
int v[]={1,2}; // valide!!
Mais attention, il y a une subtilité. Ici le type de v est ..... int* !!!! Tandis que le type de v[0] est int...
Super, non?
[^] # Re: Le C++ peut être simple
Posté par Nicolas Schoonbroodt . Évalué à 3.
Je ne vois pas le problème que tu sous-entends avec ton "Super, non ?" (à moins que j'interprete mal ce que tu dis)
[^] # Re: Le C++ peut être simple
Posté par Gilles G. . Évalué à 2.
Et pour celui qui va relire la fonction MaFonction c'est chiant parce qu'il ne peut pas savoir ce qu'est v sans lire le corps de la fonction.
[^] # Re: Le C++ peut être simple
Posté par Nicolas Schoonbroodt . Évalué à 6.
...
[^] # Re: Le C++ peut être simple
Posté par Matthieu Moy (site web personnel) . Évalué à 4.
est refusé, il faut faire soit
soit
(les deux étant bien sûr incompatibles, on ne peut pas passer un « int t[42][42] à la place d'un « int ** v », et vice-versa).
Simple comme bonjour, les tableaux, en C :-\.
[^] # Re: Le C++ peut être simple
Posté par Bozo_le_clown . Évalué à 2.
Dans un cas, le compilo considère que tu voudrais passer par valeur des tableaux à 2 dimensions.
Pour allouer ca sur la pile il a besoin de connaitre la taille de ce que tu veux lui passer et dans un autre cas tu passe par des pointeurs qui peuvent pointer dans le tas.
Si tu es sûr de ce que tu fais tu peux toujours caster. Le danger étant bien entendu de pointer en dehors d'un espace alloué.
En C++ tu peux facilement t'en tirer avec des références
http://www.dgp.toronto.edu/~patrick/csc418/wi2004/notes/Poin(...)
ou mieux en définissant des templates.
Ainsi tu bénéficies toujours du contrôle de type à la compil.
[^] # Re: Le C++ peut être simple
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
Oui, bien sûr que c'est normal. Le C cache peu de choses par rapport à l'assembleur qui est en dessous, ce n'est pas son but. Ceci dit, pour le programmeur qui voulait pas se prendre la tête, c'est râté !
> Dans un cas, le compilo considère que tu voudrais passer par valeur des tableaux à 2 dimensions.
Même pas. Aucun des deux n'est un passage par valeur.
Dans un cas, le compilateur voit un tableau de pointeurs sur tableaux, et il accède à t[i][j] par *(*(t + i) +j), et dans l'autre, c'est un vrai tableau de tableau (contigüs), et on y accède avec *((int *)t + i + j*42) (aux confusions entre i et j près, j'me mélange toujours).
> Si tu es sûr de ce que tu fais tu peux toujours caster.
Je serais curieux d'avoir un exemple où le cast marche !
Encore un volontaire pour dire que le C, c'est simple ?
(je parlerai pas trop du C++, j'ai beaucoup pratiqué ce language, mais sans l'avoir appris vraiment correctement)
[^] # Re: Le C++ peut être simple
Posté par Jux (site web personnel) . Évalué à 3.
[^] # Re: Le C++ peut être simple
Posté par Gilles G. . Évalué à -1.
[^] # Re: Le C++ peut être simple
Posté par Matthieu Moy (site web personnel) . Évalué à 3.
int mafonction(int v[]);
c'est juste équivalent à
int mafonction(int * v);
Regardes l'assembleur généré pour t'en convaincre (même si tu ne connais pas l'assembleur, diff est ton ami ;-) ).
[^] # Re: Le C++ peut être simple
Posté par lasher . Évalué à 1.
[^] # Re: Le C++ peut être simple
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
Je ne connais pas la norme par coeur, mais en expérimentant un peu, l'assembleur généré est le même, le comportement du compilateur aussi, ...
[^] # Re: Le C++ peut être simple
Posté par lasher . Évalué à 2.
Si j'ai :
void f(void) {
____char tab[42];
____printf("sizeof(tab) == %lu\n", sizeof(tab));
}
J'ai bien 42 en retour. Par contre, de cette manière :
void f(char tab[42]) {
____printf("sizeof(tab) == %lu\n", sizeof(tab));
}
La fonction m'affiche bien <taille d'une adresse char *>.
Et effectivement, d'après la FAQ de fclc, même si pour déclarer officiellement un tableau multi-dimensionnel en passage de paramètre à une fonction, il faut faire quelque chose du genre
void f(char tab[42][S1][S2]....[Sn]) { ... }
Au final, le compilateur voit bien le tableau comme étant
void f(char (*tab)[S1][S2]...[Sn]) { ... }
Mais par contre déclarer les autres dimensions est nécessaire pour ne pas avoir à simuler toutes les dimensions à la main.
Enfin, c'est ce que je comprends de ce qui est écrit là :
http://docs.mandragor.org/files/Programming_languages/C/fclc(...)
[^] # Re: Le C++ peut être simple
Posté par Vivi (site web personnel) . Évalué à 2.
[^] # Re: Le C++ peut être simple
Posté par Tristram . Évalué à 6.
Quand je veux utiliser un tableau de données, j'utilise des vector, comme vector pour des entiers, vector<vector > pour un tableau d'entiers.
Le problème est que tu compare le D au C, et non pas au C++
Par contre, je me répète, le plus dur c'est de faire le tri entre ce qui est simple et pas. En plus apprendre le C++ en apprenant le C n'est finalement pas une bonne chose.
[^] # Re: Le C++ peut être simple
Posté par Gilles G. . Évalué à 3.
vector<vector<double>> mat;
C'est du vécu. Et le compilateur borland plante avec un message d'erreur qui ne t'aide pas du tout, et comme je suis débutant j'ai au départ cru qu'on ne pouvait pas mettre un vector à l'intérieur d'un autre vector!
Il a fallu que j'utilise g++ pour comprendre...
Et puis c'est un peu facile de dire que j'utilise mal le C++. Moi, j'ai plutôt l'impression que c'est le C++ qui est difficile à utiliser!
Comment se fait-il que j'arrive à programmer en D alors qu'en C++ j'étais toujours obliger de chercher de l'aide sur internet?
Attention: je ne prétends pas que le C++ est un langage pourri. C'est juste que c'est un langage pour spécialiste, pour les gens qui font que ça toute la journée.
Pour les autres il y a Python ;-) ...ou D.
[^] # Re: Le C++ peut être simple
Posté par Moonz . Évalué à 3.
Tu es en train de dire qu'il y a plus illisible, tarabiscotté, incompréhensible, cryptique que les message d'erreur de g++ ?
La fin du monde est proche
[^] # Re: Le C++ peut être simple
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
Parce que pire que les messages d'erreur de g++ >= 3.4, c'est facile, c'est g++ < 3.4 ;-). Le front-end C++ a été prèsque entièrement réécrit avec cette version, et c'était déjà le jour et la nuit côté messages d'erreur.
Après, c'est clair que le language lui-même n'a pas été conçu pour permettre des messages d'erreur clairs (contrairement à Ada, par exemple, dont la grammaire est LL(1), donc le compilo sait ce qu'il attends à chaque token, d'où des messages du genre « toto.adb:42:12: missing ";" » ou « expected "end foobar;" » au lieu de « parse error before ";" »).
[^] # Re: Le C++ peut être simple
Posté par Nicolas Boulay (site web personnel) . Évalué à 8.
float vectorLength(vector & v){
assert(v.length==3); // c'est possible que cela soit différent, pas envis de chercher
float result = sqrt(x[0]*x[0]+x[1]*x[1]+x[2]*x[2]);
assert(result>=0);
return result;
}
"La première sécurité est la liberté"
# peut etre que...
Posté par zerbro . Évalué à 0.
Pour de la programmation système non graphique (si l'on considère qu'il y a une intersection, et si j'ai compris ce que tu voulais faire), je n'ai jamais vu l'interêt d'un langage objet.
Le langage C me parait le meilleur langage pour ça : une documentation en veux tu en voila (je conseille d'ailleur le livre "programmation systeme en C sous linux de Christophe Blaess, un must).
La question sous jacente est : as tu besoin d'un langage orienté objet ?
Et vu que tu n'es pas developpeur, connais tu bien les différences fondamentales entre langage procédural (type C), et langage orienté objet (C++) ?
Je ne connais pas python, donc je ne sais pas dans quelle catégorie il entre.
Mais je suis persuadé que cette question est fondamentale dans le choix d'un langage. C'est d'ailleur pour ça que je ne comprends pas les cours d'info qui veulent faire apprendre la programmation avec JAVA a des débutants.
[^] # Re: peut etre que...
Posté par Anonyme . Évalué à 4.
Sans compter que le C propose moins de mécanismes sympas que le C++ qui fait qu'il faut lire attentivement les docs, alors que, comme on l'oublie souvent, apprendre a lire les docs est long apprentissage, inaccessible au débutant. Il faut lire pour comprendre, mais au début on ne comprend rien, alors "a quoi bon ?" se dit on. Mais bon gré mal gré au bout d'un moyen ça vient et au fur et a mesure ca devient limpide. On l'oublie quasiment tous, mais on est tous passé par là (hum pour ma part, mon exemple type est le man de find, je l'ai lu rageusement pendant 3 ans, vu en cours entre temps, et ce n'est qu'un an plus tard ou je l'ai totalement maîtrisé, ce bordel génialissime de find).
[^] # Re: peut etre que...
Posté par polytan . Évalué à 1.
Mais la meilleure solution reste quand même de tester et de voir ce que ça fait :D
[^] # Re: peut etre que...
Posté par Anonyme . Évalué à 2.
Mon dieu, tu es sincère ?
La meilleure solution c'est de se casser le cul a essayer de comprendre les docs pour accélérer au maximum l'apprentissage de leur lecture. Pour perdre le moins de temps possible dans la période "je comprend paaaaaas"
[^] # Re: peut etre que...
Posté par Guillaume Knispel . Évalué à 6.
Quand aux différences entre langage procédural (type C), et langage orienté objet (C++), elles sont bien minces face aux différences entre un langage impératif et un langage fonctionnel ou bien déclaratif.
Si tu n'as _jamais_ vu d'interet à la POO en dehors de la création de GUI, c'est que tu n'as pas encore assez programmé (ou alors dans des domaines pas assez variés). Amuse toi à faire par exemple de la modélisation géométrique et tu comprendra tout de suite.
Le python est un langage très attrayant. Il permet de faire allègrement du procédural, de l'objet, un peu de fonctionnel (voir beaucoup selon l'humeur, mais quelque fois peut efficace si on force trop la dose, il faut de temps en temps garder le comportement lié à l'impératif qui reste plus utilisé par les développeur python en tête pour ne pas coder un truc qui va ramer), utilise intensément le duck typing, permet de faire de l'introspection extrêmement dynamique.
Qu'en aux cours de programmation pour débutant, n'importe quel langage permettant d'illustrer le concept d'algorithme peut faire l'affaire (d'ailleurs Python en est un excellent pour le coup). Puis tant qu'à faire autant illustrer le plus vite possible les autres concepts de programmation et faire de l'OCaml / Prolog / etc... le plus tot possible histoire de pas être biaisé par le tout impératif.
Quand au langage D, c'est sans doute un bon langage quand on vient du Python. Perso ya quelques point qui me chagrinent un peu et aussi le support dans le monde du LL est assez léger (c'est ptet dommage, ça).
Ce que j'aime bien : tout ce que tu as cité.
+ le support des closures et quelques autres constructions autorisant du code évolutif et très modulaire.
Ce que j'aime moins :
Features To Drop (<- donc pas dans le D) :
# Support for 16 bit computers. No consideration is given in D for mixed near/far pointers and all the machinations necessary to generate good 16 bit code. The D language design assumes at least a 32 bit flat memory space. D will fit smoothly into 64 bit architectures. <-- limitation un peu arbitraire à mon gout, peut etre que le choix a été fait avec lhorrible mode 16 bits des X86 en tete, mais il est dommage de se couper de tout un domaine de l'embarqué.
+ writefln est un nom ridicule (mais printf aussi, sauf que printf était la avant ;)))
Les exceptions que peuvent lever les fonctions n'ont pas l'air d'être spécifiable dans une white list. C'est dangereux dans certain cas, et ca peut aussi parfois etre moins pratique que des codes d'erreurs du coup.
La syntaxe des contrats est inutile à mon gout, (le concept de contrat un peu moins, sauf que ca existait déjà avant que le terme soit "inventé") d'autant que tester ne serait ce que des invariants de boucle est essentiel si on veut un vague semblant de sureté et que la syntaxe est super lourde pour faire ça.
Certaines limitations sont bizarres, on dirait que les concepteur du compilo ont buté sur un pb qu'ils ont pas su régler :
ex. Pas de récurrence croisé entre des constructeurs de signature différente d'une même classe. (je crois pas que ca soit interdit en C++, mais faut être pervers pour en avoir besoin de toute façon)
Le concept de Nested Class n'est pas vraiment utile sans closure sur les classes en question et sans dynamicité des types et de types first class citizen, ce qui n'est pas à l'ordre du jour du fait même de ce que D cible comme implémentation. Ils auraient donc mieux fait de ne pas faire de Nested Class du tout.
Le type de 128 bits (reservé pour usage futur) est bizarre : sans faire de SIMD, le besoin en taille de mot vient plus de l'adressage mémoire que des capa de calcul, et on verrait mal un processeur généraliste implémenter des mots de 128 bits juste pour optimiser les calculs sur les entiers long vu le cout que ca aurait.
Certaines constructions sont curieuses :
struct S
{ int x;
invariant int y;
}
(avec l'allocation de y qui est en fait de plus potentiellement déportée)
Enfin certains points du site oueb énoncent des affirmations catégorique sur des sujets soumis à caution et j'ai typiquement horreur de ce genre de chose. Manque d'esprit critique ! bouh c'est mal :P
En conclusion je pense que D est un langage respectable mais on a la sensation d'un langage plutôt conséquent mais concu par trop peu de monde, contrairement à Python par exemple ou les nouveautés sont toujours incluse de manière à ne rien déstabiliser et à garder une grande cohérence, voir à augmenter la cohérence.
Bref j'ai un arrière gout de petit manque de cohérence pour le D, qui peut être aurait gagné a être encore un peu plus épuré tout en incluant quelques constructions "acédémiques" évoluées supplémentaires (une petite touche fonctionnelle ? ;), sans toutefois que ce petit manque soit rédhibitoire.
[^] # Re: peut etre que...
Posté par Gilles G. . Évalué à 2.
Je peux répondre à ça:
le langage D est conçu par des gens qui écrivent des compilateurs. Une des caractéristiques du langage est qu'il _doit_ être facile d'écrire un compilateur pour D. En effet, il semblerai qu'écrire un compilateur C++ soit quelque chose de _très_ difficile et les concepteurs ne veulent pas d'un langage qui soit implémenté seulement à moitié. Cette caractéristique vient donc de l'expérience qu'à digital mars dans l'écriture de compilateurs C++...
Tout à fait d'accord, l'ensemble du site est assez désagréable sur ce point, et le coté D saymieu que C++ répété partout, c'est un peu pénible. Ils feraitent mieux de présenter D et de laisser les gens juger par eux même...
[^] # Re: peut etre que...
Posté par ribwund . Évalué à 2.
pffff, la vraie partie interessante du compilo c'est le back-end :p
Signé, un mec qui n'a jamais écrit de parser et qui ne touche à rien au dessus de SSA :)
[^] # Re: peut etre que...
Posté par zerbro . Évalué à 2.
Après, le choix de l'orienté objet ou non, est, je pense, avant tout une affaire de goûts. Même si je vois beaucoup d'interêts à la programmation orientée objet, j'ai une net préférence pour le C, seulement parce que c'est le langage que je connais(sais) le mieux.
Pour débuter, je suis d'accord que le concept d'algorithmie est le plus important. Mais si l'on fait utiliser un langage orienté objet (type java), je pense qu'il faut expliquer le concept d'objet. Et ce n'est pas forcément évident quand on ne sait même pas ce qu'est un algorithme. Pour ma part, je trouve pascal génial pour débuter quand on part de zéro.
[^] # Re: peut etre que...
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
L'utilisation ou non de l'objet n'a strictement rien à voir avec le fait de faire de la prog système ou pas. C'est plutôt une histoire de modélisation, d'algorithmie. Il y a eu des OS fait quasiment entièrement en objet (BeOs par ex), cela n'en a pas fait des OS moins bien que ceux programmés en pure C (au contraire même).
[^] # Re: peut etre que...
Posté par zerbro . Évalué à 2.
Ce que je voulais dire, c'est que pour la prog système, le C dispose de vraiment tout un panel de bibliothèque spécialisées, qui permet de vraiment tout faire assez facilement. Et dans le (relativement peu) de codes système que j'ai vu en C++, c'était en fait du C encapsulé. Et je trouve ça vraiment dégueulasse : pourquoi choisir le C++ si c'est pour encapsuler du C ?
Bref, je ne dénigre aucun type de langage (malgré, peut être, les apparences). Je trouve juste que, aujourd'hui, le C me semble vraiment le mieux adapté pour faire de la programmation système, du point de vu 'pragmatique". Ceci étant donné l'histoire du langage, mais surtout par la disponibilité et la richesse de la documentation et des bibliothèques à disposition.
Après, rien n'empêche de faire du système en lisp. Mais ça sera vachement plus galère a priori :)
[^] # Re: peut etre que...
Posté par Sylvain Sauvage . Évalué à 3.
Post hoc ergo propter hoc.
Le C a été conçu comme un assembleur de haut niveau pour Unix. Le C est donc la lingua franca (oui, je fais trop de latin) des langages de programmation pour l’accès au système. Le système fourni des fonctions et il les fourni en C (section 2 des pages de manuel), il est donc normal qu’elles soient directement accessibles en C. Les autres langages peuvent les fournir aussi (bien qu’ils préfèrent souvent les cacher et fournir des services de plus haut niveau : fonctions de la libc ou carrément tout un système de services particuliers au langage) mais il leur faudra les encapsuler.
Le C++ étant compatible avec le C (c’est l’un des objectifs premiers), l’effort de concevoir un ensemble objet au dessus des fonctions système n’est pas nécessaire et n’avait pas encore été fait (il est en cours : ça fait un moment que chacun faisait ses petites classes système dans son coin, elles sortent du bois).
Alors oui, effectivement, utiliser les fonctions C en C++ est direct mais le C++ n’est pas du C et ça peut faire « dégueulasse » (surtout quand on doit jongler avec des std::string/char*) mais c’est aussi plus simple que dans un autre langage pour lequel il faudra encapsuler, faire correspondre les types (les modèles mémoire du C et du langage cible étant souvent différents), intégrer dans la philosophie du langage, etc.
(Bon, ok, c’est de moins en moins « plus simple », avec les nouveaux langages, swig…)
[^] # Re: peut etre que...
Posté par lasher . Évalué à 4.
Une réponse toute bête : parce qu'en C++, tu as les templates et les espaces de nommage, et que ça change la vie de plein de gens (et ça permet de faire exploser les temps de compilation aussi).
Maintenant en pratique je suis d'accord avec toi, souvent, ça ne sert à rien. Mais namespace et templates ne sont pas spécifiquement des constructions liées à la POO, et un langage procédural dérivé de C qui aurait ce genre de mécanisme en plus aurait beaucoup à y gagner je pense ... Sauf qu'au final, il suffit de faire du C en C++ avec ces deux trucs. :-)
Par contre, ce qui m'énerve bien plus, ce sont les gens qui font du C++, avec plein de construction C là où il existe un idiôme purement C++ (genre les casts façon C qui sont très très moches, et suppriment la vérification de type) aurait plus d'intérêt.
[^] # Re: peut etre que...
Posté par moo4 . Évalué à 3.
C'est de la provocation ça. parce que entre (int)truc et static_cast(truc) je préfère de loin le premier surtout quand le int ou truc se voit prefixé avec Mon::Namespace::De::Vingt::Metres::De::Long (ok c'est un peu exagéré).
Le C++ est le language que je trouve le plus moche après perl (qui lui est le plus moche). Ils sont pas pour autant mauvais mais l'abus de symbols combiné peut vous rendre impuissant, antipathique et tuer des chatons. Et les templates qui sont très puissant je l'admet sont aussi la <première <cause < d'illisibilité <de ce langage > > > (et ce problème entre >> et > > est vraiment ridicule)
Sinon je suis assez d'accord avec toi sur les gens qui mélange C et C++ dans un sens comme dans l'autre. C'est deux langages différents et pourtant il y a pas besoin de chercher bien loin pour trouver des cours de "C\C++" qui sont pas loin de l'hérésie à faire un gros mélange entre les deux.
Pour en revenir au D personnelement je trouve qu'il comble le manque qu'il existe entre C++ et Java/C#. C'est un langage objet avec de bonnes possibilités et une syntaxe propre mais qui sort des binaires "natifs". Il mérite vraiment à se faire connaitre, parce que à mon avis son principal défaut c'est le manque de gens (et donc libs disponiblent) qui l'utilise.
[^] # Re: peut etre que...
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
À la limite, ça, c'est pas tellement une propriété du language, c'est une propriété de l'environnement de compilation. On peut compiler du Java en natif, GCJ est une preuve d'existance. Par contre, on perds une partie des bénéfices de Java en échange.
J'ai jamais essayé D, mais je ne suis pas sûr que ça apporte grand chose par rapport à Java en fait (je ne demande qu'à être convaincu ceci-dit).
[^] # Re: peut etre que...
Posté par Gilles G. . Évalué à 2.
En fait, j'avais envisagé java, mais on peut pas écrire une librairie partagée appellable depuis du C en Java...
Et au niveau perf, Java et D ça n'a rien à voir. D est très proche de C++ au niveau performances [1].
[1] http://shootout.alioth.debian.org/gp4/benchmark.php?test=all(...)
[^] # Re: peut etre que...`
Posté par Mildred (site web personnel) . Évalué à 2.
Et pour faire un binaire natif, c'est facile. Pas de question à se poser, c'est directement dans le compilateur par défaut.
[^] # Re: peut etre que...`
Posté par ndesmoul . Évalué à 2.
[^] # Re: peut etre que...`
Posté par Moonz . Évalué à 3.
Le seul problème (et de taille !), c'est qu'il n'y a aucune lib sympa pour faire des interfaces graphiques utilisables (non, gnustep-gui n'est pas utilisable quotidiennement dans un environnement "standard" (composé d'apps en XUL/GTK/Qt/Fox/FLTK/Tk/...)) et intégrées. Je ne parle pas seulement du thème par défaut - ça se change - , ni des menus - on doit pouvoir s'y faire au bout d'un moment - mais de vraiment TOUT. Le moindre élément d'une interface GNUstep est horripilant dans autre chose que du WindowMaker. L'image pour le dock qui se fout sur la barre des taches, les menus déroulants qui parfois rajoutent un élément dans la barre des tâches, les éléments qui emmêlent les pinceaux du WM pour le focus...
Juste pour m'amuser (et si ça marche il y a des chances que je finisse par l'utiliser, mais comme il y a peu de chances que ça finisse par marcher...), je suis en train d'essayer de coder des bindings GTK qui suivent l'API graphique d'OpenStep. Mais si j'échoue, je suis bien décidé à reprendre GTKKit [http://ftp.gnome.org/pub/gimp/gtk/objc-gtkkit/] :)
[^] # Re: peut etre que...
Posté par lasher . Évalué à 4.
Sauf que le cast en C est moche parce que le C est faiblement typé, et que donc (type)truc passe toujours. Et ça, c'est tout à fait inacceptable dans un langage orienté objet, je trouve.
[^] # Re: peut etre que...
Posté par Ontologia (site web personnel) . Évalué à 0.
Imagine, l'initialisation du système :
section PUBLIC
- main <-
(
SYSTEM.make;
MEMORY.print_capacity;
FILE_SYSTEM.make;
VIDEO.auto_make;
INTERFACE.make VIDEO;
INTERFACE.connect_to MOUSE;
INTERFACE.connect_to KEYBOARD;
INTERFACE.connect_to TIMER;
put_logo;
CLOCK.make;
PANEL.make;
INTERFACE.run;
VIDEO.close;
die_with_code exit_success_code;
);
Un objet "drive" :
section INHERIT
+ parent_controler:CONTROLER := CONTROLER;
section DRIVER
//
// Creation.
//
- create ctrl:CONTROLER drive drv:USMALLINT :SELF <-
( + result:SELF;
result := SELF.clone;
result.make ctrl drive drv;
result
);
- make ctrl:CONTROLER drive drv:USMALLINT <-
(
parent_controler := ctrl;
n_drive := drv;
read_status;
// Init cache 256Ko.
1.to 64 do { j:INTEGER;
first := SECTOR.create first;
};
);
Et le controleur disque lui même, que l'on peut spécialiser par héritage :
section PUBLIC
+ port_base:USHORTINT;
//
// Creation.
//
- create port_b:USHORTINT :SELF <-
( + result:SELF;
result := SELF.clone;
result.make port_b;
result
);
- make port_b:USHORTINT <-
(
port_base := port_b;
);
//
// Deferred.
//
- n_drive:USMALLINT <- deferred;
- nbr_sector:UINTEGER <- deferred;
- nbr_cylinder:UINTEGER <- deferred;
- nbr_head:UINTEGER <- deferred;
- step:UINTEGER <- deferred;
- cursor:UINTEGER <- deferred;
- is_removable:BOOLEAN <- deferred;
- is_read_only:BOOLEAN <- deferred;
//
// Services
//
- size:UINTEGER <-
// Size drive (sector)
(
Tu le spécialises ensuite en créant un ide_controler.
Dans le bas de ton arbre d'héritage, tu met les différents type de FS que tu veux.
Avantage ?
Pas de couche de virtualisation...
C'est quand même mieux que du c avec des pointeurs, non ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: peut etre que...
Posté par Gilles G. . Évalué à 1.
Merci pour cet exemple de code.
Par contre, peut-on avoir une (courte) explication sur la signification des symboles "+", "-", "<-"(ou un lien qui explique tout ça)?
[^] # Re: peut etre que...
Posté par Gilles G. . Évalué à 1.
J'ai compris sur des projets de simulation un peu gros que l'approche Matlab peut vite devenir handicapante. L'impression que j'en ai eu, c'est que plus le programme devient gros (en nombre de lignes) et plus c'est difficile de le modifier ou de rajouter des choses. Le pire, c'est quand on veut reprendre le code de quelqu'un d'autre...
[^] # Re: peut etre que...
Posté par Camille_B . Évalué à 1.
En pur autodidacte en programmation, j'avoue avoir vraiment prit mon pied avec LISP (Scheme & Emacs Lisp) et avoir trouvé le C sympathique (du moins pas repoussant). En revanche j'avoue avoir des difficultés avec l'orienté objet, que ce soit avec Java, C# ou Objective-C (celui-là il m'a fait m'arracher ma chevelure), que je trouve bien souvent trop verbeux (Java et C#) ou obscur quoique élégant (Objective-C).
Étant donné que je fais de la progra pour le plaisir et que je n'ai pas rencontré de problèmes dans lequel l'orienté objet me fasse gagner un temps précieux, je dois avouer ne penser l'OO que comme une pratique à n'utiliser que quand cela est vraiment nécessaire. L'OO me semble apporter beaucoup de complexité pas toujours nécessaire.
Mais je pense que c'est un problème strictement personnel. Tout dépend de la manière dont nous résolvons les problèmes.
Par exemple dans mon cas le fonctionnel est plus naturel que l'impératif, pour d'autres etc.
# OCaml
Posté par Guillaume Knispel . Évalué à 3.
Ça dépend... Si tu es mathématicien tu aura peut-être plus de facilité à apprendre un langage fonctionnel qu'un langage impératif. Peut-être aussi que la tendance s'inverse si tu es responsable qualité (faudrait faire des stats :p)
[^] # Re: OCaml
Posté par MiniMoi . Évalué à 2.
En ce qui me concerne, j'utilise OCaml quand il s'agit de prototyper un algorithme complexe (et si il est récursif c'est encore mieux), ça permet de faire des choses incroyables en quelques heures ce langage, du fait de sa conception, et d'être relativement sûr de la correction de son code.
Et j'utilise Python pour prototyper le reste, très bon langage, qui s'écrit très simplement, et qui reste lisible.
Ensuite quand il faut traduire le tout en C++, bien souvent la traduction depuis Python n'est pas si douloureuse, depuis OCaml c'est différent, mais avec le bénéfice de savoir où je vais, et d'avoir l'algo qui marche pour tester.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.