Les langages objets ... ne sont pas antinomiques des langages impératifs
C'était mon propos, en fait. À ceci près que je considère l'objet comme un ajout, par-dessus l'impératif, tout en ayant toujours refusé la logique du "tout-objet", ce qui est peut-être la raison pour laquelle j'apprécie le C++: on a plusieurs paradigmes a dispo, mais le langage ne nous force jamais a les utiliser, et en utiliser un n'empêche évidemment pas d'utiliser les autres.
Je pense que c'est vraiment une des forces principales de ce langage (encore que, ça aurait été pas mal d'avoir des conteneurs standards qui n'obligent pas à utiliser les exceptions, mais d'un autre côté coder un tableau dynamique ou une liste chaînée sans exceptions n'est pas si complexe, et <algorithm> peut fonctionner même avec de simples pointeurs, donc ça me va).
au passage ces langages ont été écrit en C dans lequel on pouvait déjà faire de l'objet
Tout comme le compilateur swi-prolog, on peut donc dire qu'on peut faire du déclaratif pur en C... ou peut tout faire en C, après tout, sauf peut-être utiliser des CPU ternaires?
Le problème, c'est qu'en C il faut une attention de tous les instants pour ne pas écrire de bugs, ce qui est moins vrai (donc toujours vrai) dans les langages implémentant des couches plus hautes (et l'impact sur la performance CPU n'est pas toujours favorable au langage que l'on imagine: penser sort (C) vs std::sort (C++)).
Il faut aussi bien plus réfléchir pour faire des choses simples dans d'autres langages (au niveau architecture, j'entend. Est-ce un mal, par contre, je ne sais pas.).
Mais d'un autre côté, exposer une interface publique qui soit écrit dans une sous-partie du C, c'est la seule façon d'avoir une bibliothèque avec une ABI stable, qui soit relativement facile a embarquer dans d'autres langages (presque tous les langages ont au moins un moyen raisonnablement simple d'appeler du code d'une lib C... à condition que ça soit du C très traditionnel, j'imagine qu'utiliser les derniers apports du C peut casser pas mal de choses).
[^] # Re: L'orienté objet c'est surfait
Posté par freem . En réponse au lien eC : un C orienté objet. Évalué à 2.
C'était mon propos, en fait. À ceci près que je considère l'objet comme un ajout, par-dessus l'impératif, tout en ayant toujours refusé la logique du "tout-objet", ce qui est peut-être la raison pour laquelle j'apprécie le C++: on a plusieurs paradigmes a dispo, mais le langage ne nous force jamais a les utiliser, et en utiliser un n'empêche évidemment pas d'utiliser les autres.
Je pense que c'est vraiment une des forces principales de ce langage (encore que, ça aurait été pas mal d'avoir des conteneurs standards qui n'obligent pas à utiliser les exceptions, mais d'un autre côté coder un tableau dynamique ou une liste chaînée sans exceptions n'est pas si complexe, et
<algorithm>peut fonctionner même avec de simples pointeurs, donc ça me va).Tout comme le compilateur swi-prolog, on peut donc dire qu'on peut faire du déclaratif pur en C... ou peut tout faire en C, après tout, sauf peut-être utiliser des CPU ternaires?
Le problème, c'est qu'en C il faut une attention de tous les instants pour ne pas écrire de bugs, ce qui est moins vrai (donc toujours vrai) dans les langages implémentant des couches plus hautes (et l'impact sur la performance CPU n'est pas toujours favorable au langage que l'on imagine: penser
sort(C) vsstd::sort(C++)).Il faut aussi bien plus réfléchir pour faire des choses simples dans d'autres langages (au niveau architecture, j'entend. Est-ce un mal, par contre, je ne sais pas.).
Mais d'un autre côté, exposer une interface publique qui soit écrit dans une sous-partie du C, c'est la seule façon d'avoir une bibliothèque avec une ABI stable, qui soit relativement facile a embarquer dans d'autres langages (presque tous les langages ont au moins un moyen raisonnablement simple d'appeler du code d'une lib C... à condition que ça soit du C très traditionnel, j'imagine qu'utiliser les derniers apports du C peut casser pas mal de choses).