Chaque langage existe (théoriquement) parce que son créateur trouvait qu'un besoin devait être rempli, dans le cas de C c'est une évolution logique par rapport au B (il me semble), le C++ est une sorte de "C amélioré" (d'après les programmeurs C++ en tout cas), quant au C#, ce n'est pas la même chose.
C et C++ sont des langages bas-niveau, utilisés aujourd'hui parce qu'ils fournissent un gros contrôle sur les performances et la mémoire d'un programme, certains te diront qu'il n'y a plus de raison valable d'utiliser C aujourd'hui (mais d'autres te diront le contraire très certainement aussi du côté du forum C).
Quant au C#, c'est un langage moderne, dont l'objectif est de faciliter la vie du développeur en occultant certains aspects compliqués (grâce notamment à un garbage collector, un système de références, une bibliothèque standard assez fournie), mais en perdant du coup une partie du contrôle performance/mémoire offerts par C et C++ (notamment).
Ça ne veut pas nécessairement dire qu'un programme C# sera moins performant qu'un programme C++, un bon programme C# vaudra toujours mieux qu'un mauvais programme C++, mais si l'objectif est d'obtenir un programme extrêmement performant (ce qui n'est pas le cas le plus courant), alors C# ne fait pas partie des meilleurs choix.
Au final, personne n'est vraiment d'accord et les conseils qu'on va te donner vont beaucoup varier d'une personne à l'autre (j'ai essayé d'être assez neutre dans mon introduction, en vrai je suis un très gros fanboy C++).
Du coup, ça dépend de ce que tu veux faire comme programmes, les langages ne sont au final que des outils, et personne ne dit quelque chose comme "je veux apprendre à me servir d'un marteau" mais plutôt "je veux fabriquer un meuble", c'est la même chose ici.
Edit: Oh j'oubliais, je ne sais pas pour le cours de C#, mais le cours de C++ de ce site est obsolète et n'enseigne que des mauvaises pratiques (le langage ayant beaucoup évolué depuis l'écriture du cours), donc si ton choix se porte sur le C++, ne commence surtout pas par là (j'ai moi-même commencé le C++ avec ce cours et trimballé pas mal de lacunes/mauvaises habitudes pendant quelques années).
Il y a notamment le cours de gbdivers qui serait un bon remplaçant, et quelques livres que d'autres vont te conseiller
Ma vision, pas tout à fait impartiale : * Le C. C'est un langage qui intéresse quand les ressources mémoire et CPU sont limitées. Il ne présente plus aucun intérêt pour faire du développement sur PC par rapport à de nombreux autres langages. Il s'apprend vite mais est complexe à maîtriser. Il peut tout faire, peut tourner sur tout processeur, mais ne nous facilite pas la tâche. * Le C++. C'est le langage qui veut le beurre et l'argent du beurre. Il peut faire du très bas niveau comme le C en ayant sa compacité, et peut être utilisé dans ses capacités objet ou de métaprogramming qui en font un langage puissant. Ceci en fait un des langages les plus long à maîtriser. Il est très adaptatif, mais attention si on parle par exemple d'IHM, il y aura des impacts si on veut l'utiliser sur un autre système d'exploitation; on limite cela en utilisant des environnement 'adaptatifs' tels que Qt. * Le C#. C'est nouveau, ça prend moins la tête, ça inclut plein de choses telle que l'IHM. Ça s'apprend relativement vite. Ça utilise le Framework DotNet donc donne accès à une librairie fournie. Inconvénients, c'est Microsoft ou Microsoft, c'est moins optimal que C++, ça n'est pas vraiment portable hors Windows.
Pour ma part, je travaille actuellement dans ces trois langages et j'évite le C# auquel je préfère Java qui lui est très portable quand on a du CPU. Si tu souhaites apprendre la programmation, je te propose aussi le Python qui donnera des résultats concrets très rapidement en étant facile d'accès
Petite note, distinction du paradigme de prog. de base des 3 langages:
C: Langage impératif ;
C++: Langage orienté objet ;
C#: Langage orienté objet.
Note: Je ne vois pas en quoi le c++ est un "C amélioré" ou un "C with classes". C'est une vieille idée qui date et n'est ressortie que par de mauvais cours et des professeurs qui ne sont pas à jour. Aujourd'hui, le C et le C++ sont bien 2 langages distincts, bien qu'ayant des aspects similaires. Et si vous avez besoin de mix les deux, vous faites erreur quelque part !
Note: Je ne vois pas en quoi le c++ est un "C amélioré" ou un "C with classes". C'est une vieille idée qui date et n'est ressortie que par de mauvais cours et des professeurs qui ne sont pas à jour. Aujourd'hui, le C et le C++ sont bien 2 langages distincts, bien qu'ayant des aspects similaires. Et si vous avez besoin de mix les deux, vous faites erreur quelque part !
J'ai dis "une sorte de C amélioré", ce qui est vrai quand on regarde les origines, C++ dérive du C, et a évolué ensuite dans son coin. Mais le simple fait que 90% du code C soit valable en C++ fait qu'on peut le voir de la sorte. Le voir hein, pas l'utiliser, brûlons vifs les gens qui font du C en C++.
Dalfab a écrit:
* Le C#. C'est nouveau, ça prend moins la tête, ça inclut plein de choses telle que l'IHM. Ça s'apprend relativement vite. Ça utilise le Framework DotNet donc donne accès à une librairie fournie. Inconvénients, c'est Microsoft ou Microsoft, c'est moins optimal que C++, ça n'est pas vraiment portable hors Windows.
Pour ma part, je travaille actuellement dans ces trois langages et j'évite le C# auquel je préfère Java qui lui est très portable quand on a du CPU.
Je ne suis pas le meilleur pour parler du C#, mais il me semble que depuis la version 2.0 c'est un comité de normalisation qui s'en occupe, et que Microsoft ne fait plus que fournir l'une des implémentations du C#, celui-ci fonctionnant également sur d'autres plateformes (à l'aide de Mono).
Je peux me tromper mais je ne pense pas que la portabilité du C# soit encore remise en cause aujourd'hui.
Les 3 langages sont des langages impératifs, dans le sens où l'on va modifier l'environnement en suivant pas à pas les instructions. Le langage HTML a contrario est un langage déclaratif.
Il est possible d'instaurer des "classes" dans le C (de manière assez détournée). Cependant, C++ et C# offrent un sucre syntaxique suffisamment riche pour que le développeur n'ait pas à savoir ce qui se cache derrière.
Les langages C et C++ sont développés par des consortiums, ce qui signifie qu'ils sont ouverts à tous. Le C# est propriétaire. Si Micro$oft fait faillite, il est probable que le C#n'évolue plus (et même ne soit plus utilisable).
Le langage C# est spécifique à une plate-forme donc il y a moins de risques de bugs spécifiques.
Le C est un langage avec relativement peu de mots-clé pour aider le compilateur à te taper sur les doigts. Le C++ en a davantage pour organiser son code (class, private, public, protected, override, final,...). On retrouve probablement ces concepts en C#.
Pour moi, le langage C est à réserver à du code système car il est très proche d'un système linux. Le C++ est une boîte à outils fournie mais il faudra que tu saches créer tes outils si tu veux les utiliser. Tu ne pourras pas utiliser directement le marteau pour planter ton clou mais tu pourras le fabriquer. Le C# t'offre le marteau et tout un tas de garanties qui vont avec ce qui, je pense, réduit le temps de développement pour obtenir un résultat aussi robuste qu'un code C++ ou autant de temps de développement pour un code plus robuste.
Heureusement que nous n'y sommes pas bornées, on peut faire du fonctionnel ou du procédural ou de la méta-prog ou construire des DSEL ou ...
Lynix a écrit:
Edit: Oh j'oubliais, je ne sais pas pour le cours de C#, mais le cours de C++ de ce site est obsolète et n'enseigne que des mauvaises pratiques (le langage ayant beaucoup évolué depuis l'écriture du cours), donc si ton choix se porte sur le C++, ne commence surtout pas par là.
Il y a notamment le cours de gbdivers qui serait un bon remplaçant, et quelques livres que d'autres vont te conseiller
Pour le livre de débutant par excellence en C++ : C++ Primer 5th Edition (de Lippmann, en anglais). Actuellement pas de livre de C++ en français pour débutant, ça n'existe pas dans la littérature récente.
Il y a bien des années, la société AT&T demanda au plus prestigieux de ses centres de recherche, le très fameux laboratoires Bell, de réfléchir à un système d'exploitation. Le laboratoire Bell piétina pendant quelque années avant de donner le jour à un OS et au langage qui avait servi à l'écrire. L'OS c'était juste UNIX (l'ancêtre de Linux, Mac OS, Free BSD...) et langage c'était le langage C. Une quinzaine d'année plus tard, un jeune ingénieur voulu apporter le paradigme objet à C, ce fut à la fois un échec (C n'est pas devenu un langage objet) et une réussite. Ce jeune ingénieur s'appelle Bjarne Stroustrup et son échec de C orienté objet est devenu C++.
C et C++ ont un lourd passé commun, passé qui ne s'éteindra jamais vraiment. De nos jours la plupart des experts du C++ sont aussi d'excellents programmeurs C, et connaître les deux est indiscutablement un atout, ne serait ce que pour bien mesurer à quel point ils sont différents. Attention, cependant, la connaissance de C n'est pas un prérequis à l'apprentissage de C++, c'est même un handicap, car les deux langages sont si proches dans leur syntaxe qu'on a tendance à oublier le reste. Bjarne Stroustrup ,disait en gros aux programmeurs C dans l'introduction de l'un de ses bouquins "Vous pouvez programmer en C++, comme vous avez l'habitude de le faire en C, mais ce faisant, vous perdrez presque tout ce que C++ peut vous apporter". S'il existe un lien presque charnel entre C et C++, il n'y en a aucun avec C#. C# est la contre attaque commerciale de Microsoft à l'ascension de Java. C# a bien plus de points communs avec Java qu'avec C ou C++. Après ça ne veut pas dire que C# est un langage au rabais, même si je n'ai eu que rarement l'occasion de l'utiliser, j'ai trouvé ça plutôt sympa.
En posant cette question sur un forum C++, ne t'attendais-tu pas à un plaidoyer pour C++? Je serais curieux de voir les réponses 'objectives' à la même question sur un forum C#.
> troll off.
Sincèrement, c'est une vraie question. Je travaille en C# depuis une dizaine d'années et suis entouré de personnes pour lesquelles le développement en C++ n'a que des inconvénients par rapport au 'génial' C#. Je ne peux pas retranscrire leurs arguments que je ne comprends toujours pas.
@Dalfab: c'est très simple, C++ et C encore plus, sont des langages très exigeants. Il est facile de se tirer une balle dans le pied avec C. Avec C++, c'est plus difficile, mais quand ça arrive, on perd la jambe
Sincèrement, c'est une vraie question. Je travaille en C# depuis une dizaine d'années et suis entouré de personnes pour lesquelles le développement en C++ n'a que des inconvénients par rapport au 'génial' C#.
Chaque langage a sa propre philosophie et quand tu développes dans un langage, tu adoptes avec le temps cette philosophie. Et quand on juges des qualités et défauts d'un autre langage, on le fait par rapport à la philosophie de son propre langage, pas par rapport à la philosophie du langage que l'on critique. D'où cette impression que son propre langage est mieux.
Un exemple classique, c'est la place de la bibliothèque "standard". Certains langages vont privilégier la quantité de fonctionnalités, quitte à avoir une API moins stable (pensez aux différentes libs graphiques). Le C++ va au contraire privilégier la stabilité, ce qui fait que la STL est moins riche et cela prend du temps pour qu'une fonctionnalité y soit intégrée (mais où sont les modules ?!?!). L'utilisation de libs externes est la "norme" en C et C++, pas dans les autres langages.
Il est très difficiles de se détacher de la philosophie de son langage, ce qui rend les discussions "langage X vs Y" très trollesque.
(Cela étant dit, il faut avouer que les arguments de tes collègues sont complètement bidons et que le C++ est objectivement mieux )
il est interdit de dire du bien du Java. Ou même de suggérer que le Java n'a peut être pas que des défauts. Le Java est et restera le pire langage de tous les temps.
Merci de respecter cette regle, sous peine de banissement.
(Sinon, plus sérieusement, il n'est pas possible de considérer le message de anolya autrement que comme une blague récurrente. Faut pas tout prendre au premier degré)
Prenons alors Lua, bien qu'étant un langage de scripting très rapide (je ne ferais pas la faute de le comparer au Python), le meilleur programmeur du monde en Lua ne pourra jamais rivaliser avec du C++ pour une application extrêmement performante.
Le langage est un moyen, un outil, parfaitement d'accord, mais ces moyens ont des limites.
C'est pour ça que j'ai parlé de contrôle sur les performances et non pas directement de performances.
Si vous n'utilisez pas de fonctionnalité type "typage dynamique", rien ne vous empêche de faire un compilateur (et pas un interpréteur) qui prend en entré du LUA.
Exactement comme il est possible d'utiliser un convertisseur Python->C puis compiler le C en natif.
Exactement comme il est possible d'utiliser un convertisseur C#->C++ puis compiler le C++ en natif (cf. Unity3D pour iOS).
etc...
Un langage, c'est qu'un langage, c'est tout.
Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
Sauf qu'un langage impose des contraintes, le typage dynamique du Lua en est un bon exemple, les références partout en C#/Java aussi.
Tout ceci revient à la notion de contrôle dont je parlais, tous les langages ne traitent pas des mêmes sujets de la même façon, et de faire certaines optimisations passent à la trappe venant d'un langage donné.
Donc tous les langages ne sont pas équivalents face aux optimisations/compilateurs, simplement.
>Donc tous les langages ne sont pas équivalents face aux optimisations/compilateurs, simplement.
Ce n'est pas lié au langage et rien n'interdit de faire des avancés qui changent complètement les positions actuelles.
Il est assez commun que certains traitements sur chaines de caractère faits en C# soient bien plus rapide, après JIT que du code C++ fait de manière "standard".
Oui, si tu compiles du C# en natifs, tu peux te faire botter les fesses par le même code NGENé voir JITé.
Un langage, c'est qu'un langage, c'est tout.
Tout le reste est extrinsèque au langage et est sujet à évolution/ mise en contexte/ etc...
En résumé, utiliser le bon outil pour faire la tâche demandé.
Le bon outil étant très dépendant du développeur, de l'équipe, de la société, des outils, de l'époque, etc...
Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
Ce n'est pas lié au langage et rien n'interdit de faire des avancés qui changent complètement les positions actuelles.
C'est beaucoup trop théorique, la pratique telle qu'elle nous dit clairement qu'un langage au typage statique s'optimisera beaucoup mieux qu'un langage au typage dynamique, peut-être qu'une découverte révolutionnaire nous permettra de remettre ceci en question, mais en attendant c'est un fait.
bacelar a écrit:
Il est assez commun que certains traitements sur chaines de caractère faits en C# soient bien plus rapide, après JIT que du code C++ fait de manière "standard".
Et il est beaucoup plus commun que tout le reste du code compilé par un compilateur pouvant optimiser pendant des heures sera bien plus performant qu'une compilation JIT (avec le même code source si on veut), je ne vois pas ce que ça change.
bacelar a écrit:
Un langage, c'est qu'un langage, c'est tout.
Et tous les langages ne sont pas équivalents dans tous les domaines, le fait de proposer un typage dynamique (ce n'est qu'un exemple mais il y a d'autres situations) par exemple est une facilité pour le programmeur au détriment des possibilités d'optimisation, c'est un choix réfléchi fait par les concepteurs du langage, qui indique notamment que le langage n'est pas destiné aux applications nécessitant un contrôle extrême sur les performances.
Je change d'exemple, plutôt que de la facilité de programmation je vais parler maintenant de sûreté, lorsqu'un pointeur nul est déréférencé en C++, tout est possible, car la norme indique que c'est un UB dans le but que le compilateur fasse la chose la plus optimisée qui soit: rien du tout, le comportement possible dépendra entièrement de la plateforme.
Dans le cas du Java (ou autre langage un peu plus sûr ayant un concept proche des pointeurs), déréférencer un pointeur nul lance une exception, rendant la récupération d'erreur possible, et cela au détriment d'une optimisation: le compilateur ne peut plus ne rien faire: il doit s'assurer que ce comportement sera respecté.
Un tel comportement est possible en C++ mais il doit être rendu explicite, le programmeur peut choisir ou non de le faire (s'il le juge nécessaire/utile), c'est très exactement ce que j'appelle le contrôle sur les performances.
Ou pour reprendre mon analogie de l'outil, j'ai d'un côté un tournevis et de l'autre une visseuse électrique, la visseuse électrique sera toujours plus efficace pour remplir ce travail (ce que je compare avec la facilité de développement pour la programmation) mais seul le tournevis pourra m'assurer de ne pas visser de quelques millimètres de trop si cela est important, parce qu'une visseuse est une amélioration de l'efficacité au détriment de la précision.
Je suis même sûr que s'il n'était pas 23h, je trouverais encore un meilleur exemple, mais bon, je ne suis pas charpentier.
Rien de théorique dans ma remarque, confère le passage Assembleur - Compilateur C.
Les premiers compilateurs, fait en assembleur, générait du code bien moins performant que de l'assembleur fait main.
Maintenant, qui irait faire de l'assembleur à la main pour faire plus vite que l'optimiseur d'un compilateur C ou C++ ?
> la pratique telle qu'elle nous dit clairement
A un instant T, rien n'est généralisable via la pratique.
> langage au typage statique s'optimisera beaucoup mieux qu'un langage au typage dynamique
Pourquoi un langage est soit en typage dynamique soit en dynamique statique ?
Je peux infirmer qu'un typage statique est toujours plus rapide qu'un typage dynamique, il suffit que je programme comme un cochon en C. Et je pense que tu peux en faire autant.
>mais en attendant c'est un fait.
Le fait qu'on peut faire un programme qui rame en C est un fait, le fait que tout programme C++ est plus rapide que tout autre programme ayant des fonctionnalités des de typage dynamique est un mythe (cf. conversion Python -> C ).
>un compilateur pouvant optimiser pendant des heures sera bien plus performant qu'une compilation JIT
Comment un compilateur non-JIT pourrait prendre en compte, sans coup au runtime, des architectures NUMA qui peuvent varier au cours du temps ?
Moi, j'ai juste besoin de trouver un cas : un compilateur NGEN n'a pas de contrainte forte en terme de temps de compilation, il peut faire les même optimisations que le compilateur classique, mais il peut prendre plus de paramètre en compte que le compilateur classique (architecture matérielle constantes, type de charge du hardware par la machine spécifique, etc...). Donc, c'est quoi le "truc" qui fait toujours gagner un compilateur "standard" à un NGEN ? Moi, j'ai un "truc" qui permet à un NGEN de pouvoir aller plus loin que le compilateur à papa.
>par exemple est une facilité pour le programmeur au détriment des possibilités d'optimisation
Lors de la conception du C++, il y a avait les mêmes choix mais les outils ont évolués pour que ce "compromis" ne soit plus pertinent.
> le but que le compilateur fasse la chose la plus optimisée qui soit
Ne rien faire n'est pas forcement la chose la plus optimisée, loin s'en faut, cf. les "stolen" dans les pipes.
Et ton exemple de tournevis/visseuse, c'est complètement en contradiction avec au moins un fait de la vraie vie véritable : la visseuse de l'ISS est utilisée à la place d'un simple tournevis pour avoir un contrôle le plus fin possible sur le vissage/dévissage.
....
Pensez un peu "Out Of The Box" et rien n'est immuable.
Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
Ok, un exemple tout con dans ce cas, prouvant que la norme d'un langage empêche certaines optimisations.
int main()
{
int a, b;
std::cin >> a;
std::cin >> b;
std::cout << (a + b);
}
Et son équivalent Lua:
local a,b
a = io.read("*n");
b = io.read("*n");
print(a + b);
Ces programmes sont les plus rapides qui soient pour effectuer cette tâche dans leurs langages respectifs (si on oublie la lecture depuis l'input, seul l'addition compte).
Et pourtant, rien qu'ici, même en le compilant, Lua ne sera pas aussi performant que C++.
Pourquoi ? Parce que la façon dont l'integer overflow en C++ n'est pas défini, c'est la plateforme qui va nativement agir sur ce comportement.
En revanche en Lua, ce n'est pas vrai, je cite:
In case of overflows in integer arithmetic, all operations wrap around, according to the usual rules of two-complement arithmetic. (In other words, they return the unique representable integer that is equal modulo 264 to the mathematical result.)
Nous avons un comportement différent d'un langage à l'autre, et la norme impose au compilateur Lua => ASM (qui peut être aussi performant que celui qui fera C++ => ASM) de le prendre en compte.
Comment ce comportement sera implémenté ? Si la plateforme n'est pas une plateforme où l'overflow des entiers est garanti, le compilateur va devoir ajouter des instructions pour s'en assurer.
Autre exemple: la division, diviser un entier par 0 en C++ est un UB, en Lua c'est une erreur de script, bien sûr qu'il y a des plateformes où le compilateur pourra se démerder pour rattraper un signal et n'avoir un coût qu'en cas de division par zéro, mais les autres ?
Les concepteurs de Lua ont fait le choix de simplifier le langage en le rendant safe, une divison par zéro ne plantera pas nécessairement le programme (les erreurs Lua étant rattrapables comme des exceptions), une addition fera un overflow, déréférencer un pointeur nul lancera une exception dans certains langages, etc...
Toutes ces contraintes imposent des checks dans le code machine, qui peuvent être virés dans certain cas mais pas tous, de fait le langage empêche certaines optimisations de part sa norme et ses contraintes.
Ce n'est pas un hasard si la norme C++ donne autant d'UB, c'est parce que c'est l'option autorisant le plus de performances.
Il existe encore des cas où le compilateur n'optimise pas autant que l'assembleur manuel. De plus, une instruction C est traduite au maximum par 3 instructions en assembleur.
C'est surtout par gain de temps que très peu de code est fait en assembleur. C'est la main d'oeuvre qui manque de nos jours, pas le matériel.
>prouvant que la norme d'un langage empêche certaines optimisations.
Cela abonde dans mon sens.
Oui, le caractère "optimisation" n'est pas une loi intrinsèque, intangible et immuable du C++.
-> Pas de déclaration péremptoire à l'emporte-pièce.
>Ces programmes sont les plus rapides
MDR, non mais, qu'est-ce qui m'empêche de faire un traducteur Lua vers un programmateur de porte logique et l'implémenter dans un circuit électronique ? Rien. Ne pas respecter une "norme" ne m'interdit pas de faire MA tambouille.
> Lua ne sera pas aussi performant que C++.
Avec un interpréteur Lua X et un compilateur C++ Y. Tu compares X et Y, pas les langages.
Avec un circuit intégré à un CPU Z, ton compilateur Y a perdu.
Comparez les langages, pas le reste.
L'outillage, on peut l'utiliser pour tout plein de langage avec un peu de bricolage.
@anolya, t'as déjà fait de l'assembleur sur RISK ???
> 3 instructions en assembleur.
LOL, c'est vrai qu'un simple appel de fonction avec plusieurs paramètres, c'est 3 instructions maximum, sur tous les processeurs de tous les temps passé présent et futur, Intel du présent compris. Mais bien sûr.
On s'enlève les œillères les gars.
Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
MDR, non mais, qu'est-ce qui m'empêche de faire un traducteur Lua vers un programmateur de porte logique et l'implémenter dans un circuit électronique ? Rien. Ne pas respecter une "norme" ne m'interdit pas de faire MA tambouille.
Un langage vient avec sa norme, évidemment que si tu ne respectes pas la norme du langage tu peux tout exploser, sauf qu'un langage n'existe pas sans sa norme. Faut arrêter les "et si" à un moment donné.
Du coup, en portes logiques tu n'auras pas la même complexité d'un langage à l'autre, à cause de la norme, c'est exactement ce qui est dit depuis le début.
Et puis arrêtons la mauvaise foi deux secondes, je comprends ton point de vue théorique, mais en pratique c'est des conneries.
bacelar a écrit:
Avec un interpréteur Lua X et un compilateur C++ Y. Tu compares X et Y, pas les langages.
bacelar a écrit:
On s'enlève les œillères les gars.
Relis, j'ai bien parlé d'un compilateur Lua équivalent au compilateur C++, celui qui ne lit pas les messages des autres ici c'est toi...
bacelar a écrit:
Comparez les langages, pas le reste.
Un langage vient avec sa norme, sa norme impose des contraintes sur l'optimisation et un contrôle à différent degré de ce qu'il est possible ou non d'optimiser, on ne fait que parler des langages ici...
Un langage vient avec sa norme, évidemment que si tu ne respectes pas la norme du langage tu peux tout exploser, sauf qu'un langage n'existe pas sans sa norme. Faut arrêter les "et si" à un moment donné.
Non, pas forcément...
Un langage comme python, par exemple, n'est défini par aucune norme, qu'elle soit issue d'une société tierce ou d'un organisme de standardisation international.
C'est un langage qui n'existe que... au travers de l'implémentation de son interpréteur, et c'est ce qui pose souvent problème (deux interpréteurs pouvant parfaitement présenter des comportements différents dans certaines circonstances)
Il y a bel et bien un "accord tacite" qui vise à considérer le comportement d'un des interpréteur comme étant le "comportement normal", mais c'est à peu près tout ce que tu as
Et puis, on peut aussi discuter de ce qui est admis comme "norme". En n'étant finalement qu'à peine plus catholique que le pape, on pourrait considérer que n'est admis comme norme qu'un document issu d'un organisme de normalisation international reconnu. Cela ferait de C et de C++ des langage normés, alors que C# et java n'en seraient pas (vu que la définition de ces langages dépendent exclusivement de la société qui les développe).
Maintenant, on peut aussi admettre comme notion de norme n'importe quel document décrivant précisément les différents besoins et comportements observables dans une série de circonstances bien particulières. A ce titre, C# et java pourraient rentrer dans la course... Mais ce ne serait toujours pas le cas de python
Ce qui se conçoit bien s'énonce clairement. Et les mots pour le dire viennent aisément.Mon nouveau livre : Coder efficacement - Bonnes pratiques et erreurs à éviter (en C++)Avant de faire ce que tu ne pourras défaire, penses à tout ce que tu ne pourras plus faire une fois que tu l'auras fait
Reste quand même la documentation officielle de Python décrivant son comportement, pareil pour Lua, que les implémentations alternatives s'efforcent de suivre dans la mesure du possible (et où un comportement différent de l'implémentation de référence est considéré comme un bug).
Au final, et peut-être un peu par abus de langage aussi, il y a toujours une norme, un ensemble de règles liées au langage.
Ça me fait penser d'ailleurs au Lua qui a été modifié pas mal de fois, et où chaque implémentation différente est encouragée à se différencier au niveau du nom (l'implémentation de Lua ayant été modifiée pour Garry's Mod par exemple, le langage est appelé GLua).
De toute façon le débat portait avant tout sur C, C++ et C#, trois langages possédant assez explicitement ce que j'appelle une norme.
Mes articles | Nazara Engine | Discord NaN | Ma chaîne Twitch (programmation)
En recherche d'emploi.
Mes articles | Nazara Engine | Discord NaN | Ma chaîne Twitch (programmation)
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C
En recherche d'emploi.
Discord NaN. Mon site.
Discord NaN. Mon site.
Mes articles | Nazara Engine | Discord NaN | Ma chaîne Twitch (programmation)
Mes articles | Nazara Engine | Discord NaN | Ma chaîne Twitch (programmation)
Mes articles | Nazara Engine | Discord NaN | Ma chaîne Twitch (programmation)
Mes articles | Nazara Engine | Discord NaN | Ma chaîne Twitch (programmation)
Mes articles | Nazara Engine | Discord NaN | Ma chaîne Twitch (programmation)
« Je n’ai pas besoin de preuve. Les lois de la nature, contrairement aux lois de la grammaire, ne permettent aucune exception. »
D. Mendeleïev
Mes articles | Nazara Engine | Discord NaN | Ma chaîne Twitch (programmation)