Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Petite question sur le C++

jeanno11

Voilà je post ici (je sais pas trop où poster) pour demander si c'est possible en c++ de mettre tous les fichiers d'entête dans une DLL qui peut servir d'api, un peu comme Rebirth ? (Je débute dans le langage et j'ai suivi le tutoriel du site du zéro).

BlueDream

C'est en effet possible comme dans tout langage de programmation mais ce ne sera pas aussi simple qu'en .Net.

jeanno11

Oui mais ça permet de faire des programmes plus performant

BlueDream

Exact mais le travail est 10 fois plus long et plus dur, nécessitant beaucoup de connaissances.

Mais si tu es motivé et que tu as du temps, lance toi ;)

jeanno11

Je vais tenter alors, merci de ton encouragement ;)

scalexm

Tu ne peux pas à proprement parler mettre des fichiers d'entête dans une DLL. Une DLL c'est du code compilé, qui contient les définitions de tes fonctions/classes. Ensuite, tu fournis les déclarations à l'utilisateur de ta DLL, dans des fichiers .h donc (sauf si tu veux en plus de ta DLL fournir du code compilé linké statiquement, mais bon on s'écarte). Les avantages d'une DLL étant les suivants:

- tu n'as pas besoin de recompiler le code qui utilise la DLL dans le cas où tu ne changes pas l'interface (c'est à dire les déclarations que tu fournis à l'utilisateur). Tu dois juste recompiler la DLL et donner la nouvelle version de la DLL

- une DLL peut être partagée entre plusieurs processus

- dans une moindre mesure, si tu as plusieurs exécutables/bibliothèques qui utilisent effectivement du code commun, les linker dynamiquement à une DLL réduira la taille des exécutables par rapport à un linkage statique (où tous les symboles sont copiés dans chaque binaire utilisant le code commun)

Il est n'est pas vrai que coder en C++ est 10 fois plus long, plus dur, et nécessitant beaucoup plus de connaissances qu'en C# par exemple. À vrai dire si tu t'en tiens au C++ moderne et aux derniers standards (C++14, C++11), tu as moyen de pouvoir écrire des programmes relativement conséquents avec un temps d'apprentissage court. Il est toutefois vrai qu'il te faudra plus de temps pour maîtriser toutes les subtilités du langage.

Il n'est pas non plus vrai que ton code sera nécessairement plus performant. Un code écrit en C++ est souvent plus performant en effet, ce notamment grâce aux optimisations que le compilateur est capable de faire directement sur le code ASM généré. Les langages utilisant de la compilation JIT ou une machine virtuelle peuvent avoir plus de mal à faire certaines optimisations, bien qu'ils soient en progrès constant.

Les vrais gains de performance apparaissent souvent sur des machines peu performantes, car ici les optimisations faites par le compilateur ET les optimisations faites par le développeur lui même ont beaucoup plus d'importance. Mais aujourd'hui, sur nos machines, qui a vraiment besoin d'optimiser son code? À part si tu travailles sur du code dont le temps d'exécution est CRITIQUE, tu ne devrais pas à avoir à penser aux performances. Tu devrais écrire ton code de la façon la plus concise et la plus expressive possible, et aujourd'hui sur ta machine il sera performant quoiqu'il arrive.

Je parle bien sûr d'optimisations bas niveau directement au niveau du code, et non au niveau des algorithmes. Évidemment, on préfèrera toujours des algorithmes d'une complexité minimale.

Vouloir changer de langage sous prétexte qu'il offre de meilleures performances est TRÈS souvent une erreur.

BlueDream

Tout est dit :o

Vas plutôt te pencher vers du C# ou du VB, un bot ca ne nécessite pas d'énorme performances c'est que du traffic réseau.

GenesisMoreder

scalexm a dit : "Tu ne peux pas à proprement parler mettre des fichiers d'entête dans une DLL. Une DLL c'est du code compilé, qui contient les définitions de tes fonctions/classes. Ensuite, tu fournis les déclarations à l'utilisateur de ta DLL, dans des fichiers .h donc (sauf si tu veux en plus de ta DLL fournir du code compilé linké statiquement, mais bon on s'écarte). Les avantages d'une DLL étant les suivants:
- tu n'as pas besoin de recompiler le code qui utilise la DLL dans le cas où tu ne changes pas l'interface (c'est à dire les déclarations que tu fournis à l'utilisateur). Tu dois juste recompiler la DLL et donner la nouvelle version de la DLL
- une DLL peut être partagée entre plusieurs processus
- dans une moindre mesure, si tu as plusieurs exécutables/bibliothèques qui utilisent effectivement du code commun, les linker dynamiquement à une DLL réduira la taille des exécutables par rapport à un linkage statique (où tous les symboles sont copiés dans chaque binaire utilisant le code commun)
Il est n'est pas vrai que coder en C++ est 10 fois plus long, plus dur, et nécessitant beaucoup plus de connaissances qu'en C# par exemple. À vrai dire si tu t'en tiens au C++ moderne et aux derniers standards (C++14, C++11), tu as moyen de pouvoir écrire des programmes relativement conséquents avec un temps d'apprentissage court. Il est toutefois vrai qu'il te faudra plus de temps pour maîtriser toutes les subtilités du langage.
Il n'est pas non plus vrai que ton code sera nécessairement plus performant. Un code écrit en C++ est souvent plus performant en effet, ce notamment grâce aux optimisations que le compilateur est capable de faire directement sur le code ASM généré. Les langages utilisant de la compilation JIT ou une machine virtuelle peuvent avoir plus de mal à faire certaines optimisations, bien qu'ils soient en progrès constant.
Les vrais gains de performance apparaissent souvent sur des machines peu performantes, car ici les optimisations faites par le compilateur ET les optimisations faites par le développeur lui même ont beaucoup plus d'importance. Mais aujourd'hui, sur nos machines, qui a vraiment besoin d'optimiser son code? À part si tu travailles sur du code dont le temps d'exécution est CRITIQUE, tu ne devrais pas à avoir à penser aux performances. Tu devrais écrire ton code de la façon la plus concise et la plus expressive possible, et aujourd'hui sur ta machine il sera performant quoiqu'il arrive.
Je parle bien sûr d'optimisations bas niveau directement au niveau du code, et non au niveau des algorithmes. Évidemment, on préfèrera toujours des algorithmes d'une complexité minimale.
Vouloir changer de langage sous prétexte qu'il offre de meilleures performances est TRÈS souvent une erreur."

I see a really good explanation, I have a question:

In fact you say the time of dev is more less in .NET platform, but what types of projects is good to use c ++?

I see and the bots and emulator have a very big code, but you can it make more faster in .net and losing a little performance... And c++? ^^'

Je vois une très bonne explication, je dois une question:

En fait, vous dites que le temps de dev est plus moins dans la plateforme .NET, mais quels types de projets est bon d'utiliser C ++?

Je vois et les bots et émulateur avoir un très grand code, mais vous pouvez faire plus vite, il en .net et perdre un peu de performance ... Et c ++?

jeanno11

Nan c'est pas que pour les performances mais je préfère le c++ surtout pour le multi-plateformes, après je connais le java donc je sais pas lequel des deux choisir.

Enfaite je pense que je vais aller vers du java car je le maitrise à peut près mais après c'est la protection du code qui laisse à désirer...

scalexm

L'argument de la portabilité est en effet un argument raisonnable, quoique Mono qui permet de compiler des programmes en C#/VB de façon portable a énormément progressé et peut maintenant faire tourner une grande majorité de programmes initialement écrits pour le framework .NET.

Si par "protection du code" tu entends le fait que les exécutables Java puissent être décompilés facilement: premièrement il y a des techniques d'obfuscation très efficaces; deuxièmement si tu débutes, ne t'attend pas à écrire le prochain émulateur 2.0 ou le prochain bot à la mode, je te conseille de développer tout ça en open source de façon à pouvoir recevoir des avis de développeurs compétents (pas moi, je ne suis pas spécialement compétent en Java), ça te sera bien plus bénéfique. Ensuite, tu trouveras des moyens de protéger ton code si vraiment tu tiens à faire un gros projet closed-source.

@Genesis: il n'y a pas de "bons" ou de "mauvais" projets à écrire en C++. Le C++ est un langage très polyvalent, la question du choix du langage est avant tout une question de goût et de connaissance. J'ai longtemps fait du C++ car c'est un langage que je maîtrise parfaitement et que j'aime beaucoup, un aspect principal m'ayant séduit (et me séduisant toujours) est la destruction déterministe des objets. Certains n'aiment pas le C++ ou trouvent que cela met plus de temps à développer qu'en C# (ça n'est pas mon avis, pour peu qu'on ait des bons outils et des bonnes bibliothèques à disposition), c'est leur choix et je le respecte.

Après bien sûr, si l'idée est juste d'écrire un petit programme (ou même un plus gros) avec un temps de développement minimal, alors ni le C++ ni le C# ne sont vraiment adaptés. Il vaut mieux se tourner vers des langages beaucoup plus haut niveau comme Python ou Perl6.

jeanno11

Merci beaucoup scalexm

GenesisMoreder

Thanks @scalexm!!

Labo

"Perl6" :lol:

scalexm

Un problème avec Perl 6? :)

Labo

Déjà, Perl 5 est un langage qui devient rapidement illisible. Parfait pour modifier du texte, très puissant pour les regex, mais je ne me hasarderais pas à l'utiliser pour un projet de taille moyenne ou grande.

Perl 6 c'est Perl 5, mais avec moins de documentation.

Après, je n'ai pas plus de problèmes avec Perl 6 qu'avec Rust :P

scalexm

Haha Perl 6 et Perl 5 sont à des années lumière l'un de l'autre, je connais des gens qui auraient des envies de meurtre en lisant une telle phrase! Ceci dit je ne me hasarderais pas non plus à l'utiliser dans un projet de grande envergure, non pas parce que ça deviendrait illisible, surtout parce que pour le coup les performances sont quand même bien moindres qu'un langage comme C#/Java/C++.

Et allez soyons honnêtes, je ne pense pas que tu connaisses quoique ce soit à Rust (ou alors tu me surprendrais positivement, je rencontre très peu de personnes qui sont capables de me parler de Rust de façon approfondie), et il n'y a absolument aucune raison d'avoir des problèmes avec ce langage (mais je conçois parfaitement qu'on puisse en avoir avec Perl).

Labo

Je ne connais en effet que très mal l'implémentation de Rust, par contre j'ai déjà manipulé à peu près tous les mécanismes dont il dispose, et je trouve qu'en agréger autant donne un langage sans aucune expressivité :

Je n'aime pas les déclarations en trait/impl

On peut pas écrire let x=1; x = 2

La syntaxe est plutôt bizarre (genre les closures)

Et l'inférence de type est presque un crime pour un langage bas lvl.

Ce qui est cool, c'est

le pattern matching parce que c'est vraiment pratique

les macros qui sont des vraies macros pas comme en C

la possibilité de mettre de l'ASM dans le code, quoique ça doit pas être utile tous les jours

la gestion de la mémoire

Pour moi, c'est un langage prometteur, mais encore trop brouillon et patchwork pour être pleinement utilisable. Le C/C++ a encore de belles années devant lui, ne parlons même pas de Cython…

scalexm

L'inférence de type est un crime pour un langage bas niveau? Et auto du C++11 alors? Et var du C# (même si on est déjà un tout petit peu plus haut niveau)?

Inférence de type n'est pas synonyme de typage dynamique, hein. Rust est très fortement typé, tout autant que C++ (et même plus en fait étant donné qu'en C++ il y a toujours les trucs du genre reinterpret_cast, const_cast et j'en passe).

Les traits, c'est le futur. Et pour avoir fait BEAUCOUP de C++, et pas mal de Rust, une chose est absolument sûre: Rust est bien plus expressif que C++. Et c'est pas du tout brouillon, éventuellement ça l'a été dans ses toutes premières versions (normal), mais depuis qu'il est passé en 1.0 (c'est-à-dire il y a un bout de temps déjà) c'est un langage tout à fait mature.

Parmi les features de premier plan de Rust, tu oublies quand même:

- le fait que tu puisses écrire du code extrêmement safe, avec de très nombreuses choses vérifiées à la compilation

- le code générique qui justement utilise les traits, beaucoup plus maniable que les templates C++, beaucoup moins de risque d'erreur

- les éléments de programmation fonctionnelle (itérateurs paresseux entre autres) qui sont d'ailleurs très à la mode dans la plupart des langages modernes

- une vraie séparation du code avec les modules (ici je compare plutôt au C++ évidemment, la plupart des autres langages n'ont pas de soucis à se faire sur ce point) et par extension des temps de compilation bien plus courts qu'en C++

- la compatibilité avec le C (donc par extension avec tous les langages en fait)

- le fait qu'il soit compilé nativement, ce qui peut en faire un langage de choix pour les applications dont le temps d'exécution est critique, et possibilité de faire de l'embarqué

Et j'en passe...

Je pense que si tu regardais un peu les différents gros projets écrits en Rust sur github, tu verrais qu'il est plus que pleinement utilisable.

Et s'il te plaît, ne me parle pas du C comme s'il avait un quelconque avenir. Aujourd'hui, les gens qui écrivent du C pour autre chose que de l'embarqué, du très très bas niveau ou pour maintenir du legacy code sont des âmes perdues. Le C n'a plus sa place aujourd'hui dans les gros projets, quand on voit tous les dégâts qu'il a causé au fil de l'histoire. N'en déplaise à Mr. Torvalds.

Je pensais que les X étaient un peu plus ouverts d'esprit...

Labo

Inférence de type n'est pas synonyme de typage dynamique, hein.

Ce que je n'aime pas, c'est l'inférence de types, pas le typage dynamique, qui d'ailleurs n'est pas vraiment utilisable par un langage bas niveau, pas besoin de me prendre pour un con.

Les traits, c'est le futur.

J'aimerais bien dans ce cas que tu m'expliques l'intérêt des traits.

Par ailleurs, je n'ai pas dit que tout était à jeter, je trouve assez novateur par exemple le fait de mélanger programmation fonctionnelle et bas niveau, mais j'ai du mal à imaginer comment se passe la compilation. Pour le coup, ça doit diminuer les performances, même si OCaml est assez performant par exemple… (Par contre, je ne sais pas ce qu'est la compilation native.)

Le C (et le vieux C++ avant 11) n'a pas forcément beaucoup d'avenir, il a juste de belles années devant lui, parce que pour l'instant Rust n'a pas une grande communauté. Quand on regarde les derniers langages créés comme Go ou Swift (même si je n'ai pas essayé à fond ce dernier), on se dit que Rust est pas si mal.

Cependant, le C++ aussi évolue, et maintenant que l'on peut compiler Python et mélanger les deux avec Cython, on peut se demander si Rust arrivera à percer.

Enfin, Rust utilise tellement de nouveaux mots-clefs qu'il est assez difficile à lire pour quelqu'un qui ne le connaît pas et aussi à apprendre.

Je pense que si tu veux vraiment continuer le débat, il faudrait le déplacer dans le bar, parce que là, ça devient vraiment hors-sujet. Surtout qu'au début je t'aimais bien pour avoir mentionné Python…

scalexm

Les aspects fonctionnels n'ont aucun impact sur les performances, à la fin le code ASM généré est le même que si tu avais écrit le code à la main, du coup l'évaluation paresseuse peut très souvent être bénéfique.

Sinon les traits ben en fait ça a le même intérêt que les traits C++ qui sont une technique majeure de template metaprogramming: écrire du code très générique (notamment) très élégamment (et avec bien sûr aucun overhead au runtime).

Par compilé nativement, j'entendais juste qu'il est compilé directement en langage machine tout comme le C/C++. Alors oui aujourd'hui beaucoup de langages peuvent faire de la compilation JIT etc mais ils sont avant tout prévus pour être exécutés sur une machine virtuelle, les techniques d'optimisation sont donc différentes.

Je suis d'accord sur le fait que Rust est difficile à apprendre, bien que ce soit déjà beaucoup plus facile si on vient de C++ (>=11 bien sûr, il faut avoir l'habitude de manier les move semantics et la gestion automatique de la mémoire).

Et je suis aussi d'accord sur le fait que ce débat soit hors sujet, tu as raison mieux vaut s'en arrêter là. PS: j'adore le python (et c'est vrai)

Page suivante »