C/C++ Émulateur dofus 2.4x (CPP)

Inscrit
6 Octobre 2015
Messages
38
Reactions
0
#21
Bonne chance pour ton émulateur alors, mais tu me surprendrais positivement si t'arrivais à en faire quoique ce soit d'intéressant.
Merci, on verra bien ce que ça donne ^^
Moi j'ai lu, et je ne comprends pas pourquoi tu es sur la défensive. Il n'y a pas d'attaque dans son message.
Je ne le suis pas, j'ai juste pas envie de débattre pour rien dire, il a raison sur le fait que si un truc est mal fait ça va cassé plus rapidement qu'avec du C# ou autre mais dans le cas inverse si c'est propre j'aurais un gain par rapport au autre émulateur, déjà en chargeant 15k de maps, de positions de subareas, 10k de spell, 19k de spell effects ect je suis à peine à 90 MB et ça me prend pas longtemps la ou un java serait a presque 1 GB xD (j'abuse peut-être un peu)
 

neross

Membre Actif
Inscrit
20 Decembre 2014
Messages
150
Reactions
0
#22
Merci, on verra bien ce que ça donne ^^

Je ne le suis pas, j'ai juste pas envie de débattre pour rien dire, il a raison sur le fait que si un truc est mal fait ça va cassé plus rapidement qu'avec du C# ou autre mais dans le cas inverse si c'est propre j'aurais un gain par rapport au autre émulateur, déjà en chargeant 15k de maps, de positions de subareas, 10k de spell, 19k de spell effects ect je suis à peine à 90 MB et ça me prend pas longtemps la ou un java serait a presque 1 GB xD (j'abuse peut-être un peu)
Ce qui est totalement stupide en argument car byte[5] en C#, C+, Flash, Java ou autre tu auras toujours 5byte en mémoire ram. xP
 
Inscrit
29 Septembre 2011
Messages
393
Reactions
3
#23
Merci, on verra bien ce que ça donne ^^

Je ne le suis pas, j'ai juste pas envie de débattre pour rien dire, il a raison sur le fait que si un truc est mal fait ça va cassé plus rapidement qu'avec du C# ou autre mais dans le cas inverse si c'est propre j'aurais un gain par rapport au autre émulateur, déjà en chargeant 15k de maps, de positions de subareas, 10k de spell, 19k de spell effects ect je suis à peine à 90 MB et ça me prend pas longtemps la ou un java serait a presque 1 GB xD (j'abuse peut-être un peu)
Après utiliser le c++ pour la performance pas vraiment bonne idée car si tu t'amuses à faire quelque choses en c++ que tu ne maîtrises pas correctement tu peux rapidement te retrouver avec un émulateur moins stable qu'en le fessant en java . c'est comme la course automobile si tu est dernier de ta catégorie c'est pas en achetant une voiture de ouff que tu sera premier.
 
Dernière édition:
Inscrit
22 Octobre 2011
Messages
34
Reactions
0
#24
Ce que dit neross est tout à fait vrai. D'ailleurs l'empreinte mémoire supplémentaire utilisée par du code C# est vraiment négligeable par rapport au même code C++. Je ne sais pas ce qu'il en est à propos de Java par contre, mais j'imagine que ça ne doit pas être incroyablement plus élevé. Tu es sans doute habitué aux 1GB de RAM utilisés par Ancestra, c'est simplement parce que l'utilisation de la mémoire était extrêmement mal optimisée sur cet émulateur.

mais dans le cas inverse si c'est propre j'aurais un gain par rapport au autre émulateur
C'est vrai en théorie grâce aux performances réelles d'un langage relativement bas niveau comme C++. Mais en pratique, ce n'est pas du tout le cas, tu te rendras vite compte qu'il est extrêmement difficile d'écrire une grosse base de code en C++ qui soit à la fois maintenable et performante (dans le sens plus performante que la même base de code écrite dans un autre langage). La raison est que si tu veux réellement profiter des possibilités d'optimisation bas niveau offertes par le C++ qui apportent le gain de performance théorique, le code deviendra vite très difficile à maintenir, surtout que le gain en performances sera vraiment négligeable grâce à la puissance de nos machines d'aujourd'hui par rapport au temps passé à développer et maintenir. La question est très différente si on travaille sur de l'embarqué évidemment où potentiellement chaque cycle d'horloge compte, mais je rentre ça dans ce que j'ai appelé "applications critiques" dans mon post précédent.

Et je ne dis pas du tout ça parce que tu es en train d'apprendre: ce que je dis là, n'importe quel développeur C++ professionnel le constate sans arrêt (pour peu qu'il connaisse quelques autres langages quand même, histoire de pouvoir comparer). Si tu commences à écrire une très grosse base de code en C++, il y a peu de chances qu'elle outspeed violemment les implémentations dans d'autres langages. Et de façon générale, l'écriture du code est beaucoup moins productive en C++ qu'avec d'autres langages. C'est la raison pour laquelle il y a de moins en moins de nouvelles applications développées en C++ aujourd'hui. Même les gens qui développent des applications critiques sont en train d'essayer de progressivement remplacer le C++: par exemple le langage Rust développé par Mozilla (sur lequel je travaille actuellement d'ailleurs) a pour but d'écarter totalement la présence du C++ dans le moteur Web de Firefox. Le langage Go a été développé par Google dans la même optique: remplacer le C++.
 
Inscrit
6 Octobre 2015
Messages
38
Reactions
0
#25
Ce qui est totalement stupide en argument car byte[5] en C#, C+, Flash, Java ou autre tu auras toujour:s 5byte en mémoire ram. xP
http://www.abstractpath.com/2012/size-of-a-csharp-string/ si tu veux un simple example :p
Si je veux allouer une chaine de caractère j'alloue byte par byte dans un char*, toi tu prend déjà par défaut x bytes sans même mettre quoi que ce soit a l'intérieur, et j'pense que y'a plein d'autre example du style, quand ta une surcouche par dessus qui te fais un automatisme, t'en a forcément plus, après c'est vrai que maintenant c'est pas grand chose mais sur un émulateur a mon avis si
"Each .NET char takes 2 bytes." tu vois c'est pas si stupide que ça :)
Et tu prouve bien que tu sais pas trop ce que tu raconte, si on pars du principe de ton byte[]
En C++ ça pourrais donner un std::vector<char> qui lui meme de base est quelque part dans la mémoire et a une taille en plus des bytes que tu lui attribue, rien que de ça tu dois avoir beaucoup plus d'allocations du coté du .NET

Après utiliser le c++ pour la performance pas vraiment bonne idée car si tu t'amuses à faire quelque choses en c++ que tu ne maîtrises pas correctement tu peux rapidement te retrouver avec un émulateur moins stable qu'en le fessant en java . c'est comme la course automobile si tu est dernier de ta catégorie c'est pas en achetant une voiture de ouff que tu sera premier.
Effectivemment, pour ça qu'il faut maîtriser au moin un minimum et savoir comment fonctionne la mémoire derrière pour pas faire n'importe quoi
Ce que dit neross est tout à fait vrai. D'ailleurs l'empreinte mémoire supplémentaire utilisée par du code C# est vraiment négligeable par rapport au même code C++. Je ne sais pas ce qu'il en est à propos de Java par contre, mais j'imagine que ça ne doit pas être incroyablement plus élevé. Tu es sans doute habitué aux 1GB de RAM utilisés par Ancestra, c'est simplement parce que l'utilisation de la mémoire était extrêmement mal optimisée sur cet émulateur.


C'est vrai en théorie grâce aux performances réelles d'un langage relativement bas niveau comme C++. Mais en pratique, ce n'est pas du tout le cas, tu te rendras vite compte qu'il est extrêmement difficile d'écrire une grosse base de code en C++ qui soit à la fois maintenable et performante (dans le sens plus performante que la même base de code écrite dans un autre langage). La raison est que si tu veux réellement profiter des possibilités d'optimisation bas niveau offertes par le C++ qui apportent le gain de performance théorique, le code deviendra vite très difficile à maintenir, surtout que le gain en performances sera vraiment négligeable grâce à la puissance de nos machines d'aujourd'hui par rapport au temps passé à développer et maintenir. La question est très différente si on travaille sur de l'embarqué évidemment où potentiellement chaque cycle d'horloge compte, mais je rentre ça dans ce que j'ai appelé "applications critiques" dans mon post précédent.

Et je ne dis pas du tout ça parce que tu es en train d'apprendre: ce que je dis là, n'importe quel développeur C++ professionnel le constate sans arrêt (pour peu qu'il connaisse quelques autres langages quand même, histoire de pouvoir comparer). Si tu commences à écrire une très grosse base de code en C++, il y a peu de chances qu'elle outspeed violemment les implémentations dans d'autres langages. Et de façon générale, l'écriture du code est beaucoup moins productive en C++ qu'avec d'autres langages. C'est la raison pour laquelle il y a de moins en moins de nouvelles applications développées en C++ aujourd'hui. Même les gens qui développent des applications critiques sont en train d'essayer de progressivement remplacer le C++: par exemple le langage Rust développé par Mozilla (sur lequel je travaille actuellement d'ailleurs) a pour but d'écarter totalement la présence du C++ dans le moteur Web de Firefox. Le langage Go a été développé par Google dans la même optique: remplacer le C++.

Oui, ça prend plus de temps et tu fais plus facilement des conneries, je m'en suis déjà rendu compte que c'était relou t'inquiète x)
Le code difficile a tenir.. mmh non je suis pas d'accord pour ce genre d'application une fois que la base est faite tu n'y touche plus et rajoute que par dessus, mais oui ça prend plus de temps, pour avoir un bon exemple, ce que j'ai fais là en 1 mois peut-être ma pris 1/2 semaine en node.
Par contre oui c'est moin productif c'est sur
Mais une fois que tout le système est fait concrètement, ça devrait prendre le meme temps qu'avec un language lambda ^^
 
Dernière édition:
Inscrit
22 Octobre 2011
Messages
34
Reactions
0
#26
Les strings en C# sont des strings UTF-16. Si tu veux utiliser de telles strings en C++, tu auras la même occupation de deux octets par caractères. Si tu veux utiliser un type qui prend qu'un seul octet, tu utilises le type byte en C#, pas le type char. Le type std::string est en effet moins gourmand en mémoire que le type String de C# (sans prendre en compte le contenu de la string vu que l'encodage est différent). Mais il est plus courant d'avoir peu de très longues strings que beaucoup de petites strings, auquel cas la différence devient négligeable. Si l'occupation mémoire des String C# devient effectivement préoccupante dans un contexte particulier, alors il faut optimiser dans ce cas précis (changer la technique de stockage, ne pas utiliser le type String, il y a plein de possibilités, on optimise selon le langage avec lequel on travaille).
Et non, dans le contexte d'un émulateur, une différence de 200/300Mo entre l'implém C++ et l'implém C#, c'est absolument négligeable (surtout quand on sait que même les machines d'entrée de gamme ont au minimum 4Go de RAM aujourd'hui).

Et si, le code est plus difficile à maintenir, quelle que soit l'application en fait, c'est un fait avéré et reconnu. Mais ça c'est justement ce qui caractérise le C++: un bon compromis entre maintenabilité et performances, bien qu'aujourd'hui je sois de l'avis que plusieurs langages sont meilleurs que le C++ à ce jeu, mais ça c'est un avis personnel.
 
Inscrit
6 Octobre 2015
Messages
38
Reactions
0
#27
Les strings en C# sont des strings UTF-16. Si tu veux utiliser de telles strings en C++, tu auras la même occupation de deux octets par caractères. Si tu veux utiliser un type qui prend qu'un seul octet, tu utilises le type byte en C#, pas le type char. Le type std::string est en effet moins gourmand en mémoire que le type String de C# (sans prendre en compte le contenu de la string vu que l'encodage est différent). Mais il est plus courant d'avoir peu de très longues strings que beaucoup de petites strings, auquel cas la différence devient négligeable. Si l'occupation mémoire des String C# devient effectivement préoccupante dans un contexte particulier, alors il faut optimiser dans ce cas précis (changer la technique de stockage, ne pas utiliser le type String, il y a plein de possibilités, on optimise selon le langage avec lequel on travaille).
Et non, dans le contexte d'un émulateur, une différence de 200/300Mo entre l'implém C++ et l'implém C#, c'est absolument négligeable (surtout quand on sait que même les machines d'entrée de gamme ont au minimum 4Go de RAM aujourd'hui).

Et si, le code est plus difficile à maintenir, quelle que soit l'application en fait, c'est un fait avéré et reconnu. Mais ça c'est justement ce qui caractérise le C++: un bon compromis entre maintenabilité et performances, bien qu'aujourd'hui je sois de l'avis que plusieurs langages sont meilleurs que le C++ à ce jeu, mais ça c'est un avis personnel.
Quand tu veux faire tourner ton serveur sur un vps linux de 1gb si ça l'est, et tu n'es pas obligé d'utilisé std::string, j'ai parlé de char*
Et non, si je dois rajouter des effets de sort sur un système qui est déjà en place par exemple, ça n'en sera pas plus difficile, après peut-être pour certain n'ayant pas le niveau nécessaire, moin productif oui
 
Inscrit
27 Février 2016
Messages
27
Reactions
0
#28
De toute façon vous avez pas le savoir, tout est en ma possession.
 
Inscrit
2 Juin 2016
Messages
82
Reactions
3
#30
Empreinte mémoire =/= performance

N'importe quel émulateur C# un minimum bien développé sera plus performant que le tien en C++, à moins que tu ne sois Stroustrup.
Le C++ c'est rigolo, mais c'est pas productif et pas adapté à ton projet

bisous
 
Inscrit
6 Octobre 2015
Messages
38
Reactions
0
#31
Empreinte mémoire =/= performance

N'importe quel émulateur C# un minimum bien développé sera plus performant que le tien en C++, à moins que tu ne sois Stroustrup.
Le C++ c'est rigolo, mais c'est pas productif et pas adapté à ton projet

bisous
"N'importe quel émulateur C# sera plus performant que le tien en C++"
Jpp omg on est pas sur dozen of elites ici sérieux
moua je pense ke pour fair du c# performant il fau etre bill gates mini

Le nombre d'émulateur qui sont développé en C++ "rigolo" comme tu dis est pas mal (https://github.com/TrinityCore/TrinityCore) pour du WoW par exemple qui est juste l'un des émulateurs les plus stable et performant je crois
Explique moi en quoi un émulateur C# un minimum bien développé sera plus performant que le mien stp
 
Inscrit
2 Juin 2016
Messages
82
Reactions
3
#32
La simplicité et l'ingéniosité de la TPL (ainsi que de la programmation asynchrone en général), ainsi que le compilateur JIT permettront d'out-performances les bonobos qui développent en C++

Sinon, je serais ravis de t'entendre sur ta politique de programmation concurrente, et pourquoi pas sur les primitives de synchronisation, qui selon toi sont "mieux" que celles du C#

Bisous
 
Inscrit
6 Octobre 2015
Messages
38
Reactions
0
#33
La simplicité et l'ingéniosité de la TPL (ainsi que de la programmation asynchrone en général), ainsi que le compilateur JIT permettront d'out-performances les bonobos qui développent en C++

Sinon, je serais ravis de t'entendre sur ta politique de programmation concurrente, et pourquoi pas sur les primitives de synchronisation, qui selon toi sont "mieux" que celles du C#

Bisous
Où est-ce que j'ai dis que les "primitives de synchronisation" était mieux que le C# ?
sinn ba c simpl pr faire comme stroustrup tu fé dé muttexe et apré tu loque ^^
bisou
 
Inscrit
2 Juin 2016
Messages
82
Reactions
3
#34
Vu le type de projet, ca sera fortement multi-threadé et la qualité des primitives sync joueront un rôle majeur dans les perfs. Donc oui, ça compte.

Quid de ta politique de ta P. concurrente?

bisous
 
Inscrit
22 Octobre 2011
Messages
34
Reactions
0
#35
tu n'es pas obligé d'utilisé std::string, j'ai parlé de char*
J'ose espérer que tu n'as pas prévu d'écrire une seule fois le type "char*" dans le code de ton émulateur, on est en 2017 quand même.

Mais bon puisque tu as l'air de penser que bas niveau = plus performant, voici un exemple (très simple) et concret (un peu plus que celui de DrBrook en tout cas mais cependant ce qu'il dit est plutôt vrai, bien qu'il exagère un peu): donc tu as l'air d'aimer les char* car leur empreinte mémoire est minimale (chaîne de N caractères = N octets en mémoire + 4 ou 8 octets pour transporter le pointeur). Très bien, par contre pour connaître sa taille c'est une complexité en O(N). Tu dois faire une allocation mémoire pour chaque chaîne de caractères y compris pour les toutes petites chaînes (moins de 22 caractères, et ça inclut la chaîne vide qui statistiquement est une des chaînes de caractères les plus utilisées). Si tu veux rajouter un caractère à la fin d'une string, c'est une réallocation + du O(N) si cette dernière échoue (pour recopier tous les caractères au nouvel emplacement mémoire).

À côté de ça, regardons par exemple le type std::string, qui rappelons le pèse de base 12 octets sur une machine 32 bits et 24 sur une machine 64 bits. L'accès à la taille se fait en O(1), vu qu'elle est transportée avec la chaîne. Si ta chaîne fait moins de 10 chars sur du 32 bits / 22 chars sur du 64 bits, tu profites de la small string optimization (SSO) et tu n'as pas d'allocation à faire. Si tu veux ajouter un caractère à la fin, c'est une complexité en O(1) en amorti grâce à l'algorithme de préallocation. Il y a évidemment de très nombreuses autres choses mais ces trois là sont significatives. Conclusion: std::string est beaucoup plus rapide, et peut même allouer moins de mémoire si tu manipules beaucoup de petites chaînes grâce à la SSO.

L'exemple char* VS std::string est un exemple parmi les innombrables qui font que beaucoup de programmes C++ sont beaucoup plus performants que des programmes C. Tu peux maintenant imaginer que pour des raisons similaires, beaucoup de programmes écrit dans un langage plus haut niveau sont aussi ou plus performants que des programmes C++.

Et non, si je dois rajouter des effets de sort sur un système qui est déjà en place par exemple, ça n'en sera pas plus difficile, après peut-être pour certain n'ayant pas le niveau nécessaire, moin productif oui
Et quand tu devras changer légèrement ton système déjà en place car tu te seras rendu compte que pour une raison ou une autre, y a un truc qui va pas (et ça t'arriveras ne t'en fais pas, même à moi ça pourrait m'arriver c'est dire), là tu verras que c'est plus difficile à maintenir que dans d'autres langages de façon générale, quel que soit ton niveau
 
Dernière édition:
Inscrit
6 Octobre 2015
Messages
38
Reactions
0
#36
même
J'ose espérer que tu n'as pas prévu d'écrire une seul fois le type "char*" dans le code de ton émulateur, on est en 2017 quand même.

Mais bon puisque tu as l'air penser que bas niveau = plus performant, voici un exemple (très simple) et concret (un peu plus que celui de DrBrook en tout cas mais cependant ce qu'il dit est plutôt vrai, bien qu'il exagère un peu): donc tu as l'air d'aimer les char* car leur empreinte mémoire est minimale (chaîne de N caractères = N octets en mémoire + 4 ou 8 octets pour transporter le pointeur). Très bien, par contre pour connaître sa taille c'est une complexité en O(N). Tu dois faire une allocation mémoire pour chaque chaîne de caractères y compris pour les toutes petites chaînes (moins de 22 caractères, et ça inclut la chaîne vide qui statistiquement est une des chaînes de caractères les plus utilisées). Si tu veux rajouter un caractère à la fin d'une string, c'est une réallocation + du O(N) si cette dernière échoue (pour recopier tous les caractères au nouvel emplacement mémoire).

À côté de ça, regardons par exemple le type std::string, qui rappelons le pèse de base 12 octets sur une machine 32 bits et 24 sur une machine 64 bits. L'accès à la taille se fait en O(1), vu qu'elle est transportée avec la chaîne. Si ta chaîne fait moins de 10 chars sur du 32 bits / 22 chars sur du 64 bits, tu profites de la small string optimization (SSO) et tu n'as pas d'allocation à faire. Si tu veux ajouter un caractère à la fin, c'est une complexité en O(1) en amorti grâce à l'algorithme de préallocation. Il y a évidemment de très nombreuses autres choses mais ces trois là sont significatives. Conclusion: std::string est beaucoup plus rapide, et peut même allouer moins de mémoire si tu manipules beaucoup de petites chaînes grâce à la SSO.

L'exemple char* VS std::string est un exemple parmi les innombrables qui font que beaucoup de programmes C++ sont beaucoup plus performants que des programmes C. Tu peux maintenant imaginer que pour des raisons similaires, beaucoup de programmes écrit dans un langage plus haut niveau sont aussi ou plus performants que des programmes C++.


Et quand tu devras changer légèrement ton système déjà en place car tu te seras rendu compte que pour une raison ou une autre, y a un truc qui va pas (et ça t'arriveras ne t'en fais pas, même à moi ça pourrait m'arriver c'est dire), là tu verras que c'est plus difficile à maintenir que dans d'autres langages de façon générale, quel que soit ton niveau
Mdrrrr tu t'es amusé là, mais non j'ai pas envie de souffrir j'utilise pas de char* si ce n'est c_str(), sinon oui tu as raison pour std::string j'imagine, enfin tout dépend de comment tu allouerais ta mémoire, je peux très bien faire une seule grosse allocation sur un void* et me balader avec un seul pointeur et stocker toutes mes chaines ;D
Et oui comme du script shell peut-être plus performant que du C++, du php.. tout est dans l'implémentation, mais non je n'aurais pas besoin de retoucher a un système de ce genre logiquement et dans tout les cas c'est plus long qu'un language plus haut niveau de toute façon ça parait logique
C'est tout aussi vrai pour les perfs, et encore heureux que des languages qui sortent plus récemment puissent atteindre de pareil ou meilleur performance qu'un language qui commence a ce faire un peu vieux, MAIS attention il y a un mais le c++ reste le meilleur ^-^ quand ta les connaissances pour pouvoir faire des trucs qui seront plus rapide mais plus long à faire
Après le but est pas non plus de faire un truc parfait hein, j'apprends des trucs, je m'amuse et c'est assez propre quand même je pense.
 
Dernière édition:
Inscrit
22 Octobre 2011
Messages
34
Reactions
0
#37
C'est toi même qui a dit qu'on était pas obligé d'utiliser std::string.

Et si, tu auras forcément à retoucher un système de ce genre à un moment, même dans des projets où tous les contributeurs sont des gourous du langage (au hasard le compilateur Rust vu que je le connais bien) il faut régulièrement changer des pans entiers du code parce que quelque chose n'avait pas été prévu (pour la raison que ce n'était simplement pas prévisible). Ce n'est pas un hasard si aujourd'hui la plupart des gros acteurs de l'informatique essayent de s'éloigner le plus possible du C++.

Si tu veux savoir, je fais du C++ depuis 7 ans, et malgré ses défauts ça a longtemps été un de mes langages favoris, pas pour les performances non car je n'ai jamais écrit d'application dont le temps d'exécution était critique (ceci dit pour ces applications, et pour des démonstrations de force purement algorithmiques il était imbattable jusqu'il y a peu, et j'ai pu apprécier ça à plusieurs reprises c'est vrai), mais pour deux raisons: l'idiome RAII, qui permet d'avoir une destruction déterministe des objets (ce dont je suis fan) et d'écrire certaines portions de code de façon extrêmement élégante, et dont je trouve que les équivalents dans d'autres langages ('with' en Python ou 'using' en C# par exemple) sont beaucoup moins commodes; et la meta-programmation avec les templates qui permet dans 99% des cas de se passer d'héritage virtuel (que je déteste).

Et puis ensuite j'ai découvert Rust.
 
Inscrit
6 Octobre 2015
Messages
38
Reactions
0
#38
C'est toi même qui a dit qu'on était pas obligé d'utiliser std::string.

Et si, tu auras forcément à retoucher un système de ce genre à un moment, même dans des projets où tous les contributeurs sont des gourous du langage (au hasard le compilateur Rust vu que je le connais bien) il faut régulièrement changer des pans entiers du code parce que quelque chose n'avait pas été prévu (pour la raison que ce n'était simplement pas prévisible). Ce n'est pas un hasard si aujourd'hui la plupart des gros acteurs de l'informatique essayent de s'éloigner le plus possible du C++.

Si tu veux savoir, je fais du C++ depuis 7 ans, et malgré ses défauts ça a longtemps été un de mes langages favoris, pas pour les performances non car je n'ai jamais écrit d'application dont le temps d'exécution était critique (ceci dit pour ces applications, et pour des démonstrations de force purement algorithmiques il était imbattable jusqu'il y a peu, et j'ai pu apprécier ça à plusieurs reprises c'est vrai), mais pour deux raisons: l'idiome RAII, qui permet d'avoir une destruction déterministe des objets (ce dont je suis fan) et d'écrire certaines portions de code de façon extrêmement élégante, et dont je trouve que les équivalents dans d'autres langages ('with' en Python ou 'using' en C# par exemple) sont beaucoup moins commodes; et la meta-programmation avec les templates qui permet dans 99% des cas de se passer d'héritage virtuel (que je déteste).

Et puis ensuite j'ai découvert Rust.
Le python a une syntaxe horrible je trouve, et personnellement je préfère l'héritage virtuel je trouve les templates chiant et très pas élégant, pour le std::string c'était un exemple
Je connais pas le rust mais ça a l'air de ressembler a du c/c++, ça semble pas mal ^^
Les plus sympathique a développer je trouve que c'est le C# et le node
 
Inscrit
22 Octobre 2011
Messages
34
Reactions
0
#39
Pourtant toi qui aime les performances tu devrais savoir que l'héritage virtuel ça impacte sacrément les perfs ;)

Mais bon bref pour clore ce débat, c'est une bonne chose de connaître le C++ dans tous les cas car il y a de très nombreux projets écrits en C++ et ça risque de durer encore un bout de temps car il est très coûteux de tout réécrire, de plus il y a tout de même des bonnes choses dans ce langage et qu'on trouve difficilement ailleurs comme je l'ai dit (et ça inclut la possibilité de faire du très bas niveau dans les cas extrêmes). Et je réitère ce que j'ai dit écrire un émulateur est un excellent moyen de s'y former. Mais c'est toujours mieux en open source si jamais tu changes d'avis ;)
 
Inscrit
6 Octobre 2015
Messages
38
Reactions
0
#40
Pourtant toi qui aime les performances tu devrais savoir que l'héritage virtuel ça impacte sacrément les perfs ;)

Mais bon bref pour clore ce débat, c'est une bonne chose de connaître le C++ dans tous les cas car il y a de très nombreux projets écrits en C++ et ça risque de durer encore un bout de temps car il est très coûteux de tout réécrire, de plus il y a tout de même des bonnes choses dans ce langage et qu'on trouve difficilement ailleurs comme je l'ai dit (et ça inclut la possibilité de faire du très bas niveau dans les cas extrêmes). Et je réitère ce que j'ai dit écrire un émulateur est un excellent moyen de s'y former. Mais c'est toujours mieux en open source si jamais tu changes d'avis ;)
Je vais suivre ton conseil et le share en open source, on verra ce que ça donne :p
 
Haut Bas