malloc() revoit un void*, et pourtant cette fonction a fait ses preuves et est encore très utilisée.
D'ailleurs, il est assez probable que new appelle malloc(), mais seuls les théoriciens du C++ pourraient répondre.
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
malloc() revoit un void*, et pourtant cette fonction a fait ses preuves et est encore très utilisée
D'ailleurs, il est assez probable que new appelle malloc(), mais seuls les théoriciens du C++ pourraient répondre.
J'ai peur que les grands théoriciens aient plus de goût pour les beaux croquis avec de belles boites et de nombreuses flèchesEnvoyé par Pierre Dolez
malloc() revoit un void*, et pourtant cette fonction a fait ses preuves et est encore très utilisée
D'ailleurs, il est assez probable que new appelle malloc(), mais seuls les théoriciens du C++ pourraient répondre.
Je confirme votre hypothèse. New est la version objet de malloc(), calloc()
Par contre la gestion du C++ en ce qui concerne le delete() est aussi peu sécurisée que free() en C : crash si le pointeur résultant de l'instance parente (argument) n'a pas fait fait l'objet d'un new. dispose() en C# est sécurisé et renvoie une erreur bien propre si on essaye de "libérer" une constante par exemple. dispose() est en outre optionnel (merci la GC). En C++ sans GC delete() est complètement obligatoire (memory leak et crash aléatoire sinon)
Dernière modification par Invité ; 22/07/2010 à 16h13.
Je dirai quand même que les points les plus délicats ne sont pas à mon sens la surcharge d'opérateur ou les pointeurs.
La surcharge d'opérateurs n'est nuisible que si c'est une fonctionnalité mal utilisée, quant aux pointeurs, il existe des solutions du côté des smart pointers. Le toolkit Qt par exemple, utilise des objets copy-on-write très confortables qu'on peut tranquillement balader entre les fonctions, conserver en référence dans une classe, le tout sans risque de destruction prématurée.
Le problème des déclarations sur deux fichiers h/cpp vient à mon sens de la duplication possible de la documentation, et les déclarations inline salissent un peu l'avantage de séparation cité par certains. En refactoring, la nécessité de modifier systématiquement à plusieurs endroits peut s'avérer pénible.
J'ai par ailleurs toujours trouvé dommage que les développeurs C++ soient aussi réservés à l'égard des exceptions, préférant créer une tonne de valeurs de retour spécialisées. Balader un code d'erreur et un texte d'erreur sur plusieurs fonctions de profondeur (A appelle B appelle C appelle D appelle E) sachant que A a l'accès à l'interface utilisateur et permet d'afficher l'erreur tient du cauchemar. De nombreux if/else sont nécessaires aux tests de ces valeurs de retour et le code à écrire peut vite tripler de taille.
Mais c'est là une question philosophique et un avis personnel surtout.
Actuellement le C++ est, je trouve désavantagé par rapport aux technos managées qui proposent toutes un grand panel d'outils pour les applications client-serveur, webservice, SOAP et tout cela. Le travail pour exploiter un webservice XML un peu sophistiqué en C++ peut être vite un peu fastidieux, même chose pour ce qui est service web.
Et les clients légers, les applications webs ainsi que les RIA sont des domaines dont la demande a augmenté passablement, et malheureusement C++ a peu de cartes en main dans ces secteurs.
C'est là encore non pas une question de *capacité* du langage, mais d'écosystème et de simplicité de mise en oeuvre avec les technos et frameworks disponibles.
new utilise malloc (et c'est même pas obligatoire), mais renvoie une chose typé est c'est très très loin d'être un hasard.
De plus, bon nombre d'implémentations de la lib C ajoutent bien des choses comme une vérification des tailles, utilisation de canaries etc.
L'illusion du contrôle du C++.
Merci Skip, point de vue très intérressant. Je me demandais si un spécialiste QT allait s'interresser à nous..
Tout à fait d'accord, mais je m'hasard à une explication à la faiblesse de l'écosystème : Le nombre d'intervenant dans la norme et leurs motivations cachées.C'est là encore non pas une question de *capacité* du langage, mais d'écosystème et de simplicité de mise en oeuvre avec les technos et frameworks disponibles.
Malloc est une convention des OS qui s'occupent de la réservation mémoire. malloc() est la version C qui fait cet appel systeme avec plus ou moins de vérifications. Les OS étant tous en C/C++, les deux forment une seule entité.new utilise malloc (et c'est même pas obligatoire), mais renvoie une chose typé est c'est très très loin d'être un hasard.
De plus, bon nombre d'implémentations de la lib C ajoutent bien des choses comme une vérification des tailles, utilisation de canaries etc.
L'illusion du contrôle du C++.
J'aime bien le pointeur void * sur un morceau de ram moi ...
Parfois j'y range des types simples ou structs, parfois des files, des buffers... En embarqué parfois, je fais ma propre gestion ram en "empilant" les objets comme dans un flux de comm. Hormis le fait qu'il soit très chatouilleux et que le free() soit difficile à forcer en cas d'erreur par exemple, je n'ai rien à lui reprocher.
En fait le typage d'un ptr est surtout utile pour les sizeof() (preprocesseur) ou l'arithmétique sur pointeurs, procédé ôô combien performant et ne me pose pas de problème éthique. Mais peut être qu'un théoricien va me crier dessus...
Je me rappelle avoir expliqué ça à un conseil d'admin d'une société du cac40 , ils étaient tous restés comme deux ronds de flan. Par la suite ils avaient tranché en ma faveur en disant qu'ils voulaient un logiciel "aux normes" de ma maquette. Ils ne s'étaient pas risqués sur des termes techniques, ils voulaient juste "la même chose"
En fait , je suppose que tous ceux qui n'aiment pas les pointeurs doivent trouver insupportable tout ce qu'on peut faire avec et qui est impossible avec des references...
J'entends dire du mal des pointeurs depuis que java est sorti et depuis cette date , je les utilise de plus en plus , avec bonheur, efficacité et performances
Il y a de quoi les mettre en pétard. Moi je suis fondé à me poser de questions sur les gourous qui disent ce qui est bien et mal. Un programme qui marche depuis 15 ans sans un bug , c'est mal ?
Dernière modification par Invité ; 22/07/2010 à 16h58.
new appelle bien malloc qui appelle quelquechose de système dépendant (sous Linux / BSD, ça doit être brk / sbrk()). void* peut avoir son utilité, quand on fait du système / bas-niveau. C++ est aussi un langage de haut-niveau, avec un système de typage fort. Ce typage fort permet :
1/ de détecter un certain nombre d'erreur
2/ faire des optimisations
Dans ce cadre, utiliser void* (ou boost::any) on perd toutes ces informations, et donc toutes les garanties qui vont avec. Dans certains cas, c'est donc bien / voir nécessaire. Dans la grande majorité des cas, c'est une hérésie qui fait perdre un bon nombre d'avantages d'avoir un langage compilé à typage fort.
Comment outiller, vérifier ou tester automatiquement votre bout de code ?
Un programme sans bug, cela n'existe pas.Un programme qui marche depuis 15 ans sans un bug
Il y a toujours des cas d'utilisation qui le fera pêter en vol, par exemple, le programme de Voyageur 2 sous le rayonnement solaire au bout de 33 ans.
Avec un outillage correct il est possible de faire un patchage automatique de ce genre de problème.
Non, on peut faire des « new int » et des « new int[n] », rien à voir avec les objets.
J'ai plutôt envie de dire que « new » est la version type-safe de « malloc() ».
C'est cela… et les smart pointers servent juste à faire joli.Par contre la gestion du C++ en ce qui concerne le delete() est aussi peu sécurisée que free() en C : crash si le pointeur résultant de l'instance parente (argument) n'a pas fait fait l'objet d'un new. dispose() en C# est sécurisé et renvoie une erreur bien propre si on essaye de "libérer" une constante par exemple. dispose() est en outre optionnel (merci la GC). En C++ sans GC delete() est complètement obligatoire (memory leak et crash aléatoire sinon)
D'autant plus qu'un GC ne peut pas empêcher toutes les fuites mémoire. Se reposer aveuglément sur le GC est une imprudence trop répandue.
je comprend ça.
Mais l'embarqué, c'est la loi de la jungle.
D'autre part, on fait toujours un malloc avec son cast. Cela répond à cette question, on peut refaire le cast quand on veut.... je ne vois vraiment pas ou est le problème.
Enfin, j'apprécie dans C et moindre mesure C++ la possibilité de trouver du boulot dans l'embarqué de qualité spatiale ou militaire !!!!! Ce n'est pas avec des généralités qu'on obtient un projet top niveau, c'est avec des résultats.
Le C le permet, c'est fonctionnel, testé avec protocoles. C'est documenté.
Ca marche. Certains me l'ont accordé à reculons mais ils ont dû reconnaitre que je diminuais le coût du hardware , controleur moins rapide, batterie de capacité inférieure.
L'argument de conformité n'a pas suffi , sinon j'aurais perdu la mission ! Il faut quand même dire qu'en situation de marché, le client a son mot à dire.
Je dois vous avouer que si emporter une compétition comme celle là consiste à chercher les failles d'ingénieur et violer igniominieusement les dogmes , c'est un exercice que je trouve extraordinairement gratifiant. Qu'un tel projet intéresse Boeing et la Nasa relativise sur la méthode. Même si ces deux sociétés ont juste demandé de l'information.
Hé bien si, il y en un là.
Bien sûr que si, enfin.
Tu n'as jamais vu les pubs pour Google Chrome dans le métro ?
Cela me rappel un bug dans une librairie qui était en prod depuis plus de 15 dans des centaines d'exécutables utilisés par des centaines de traders tous les jours.
Le hic, c'est qu'avec l'inflation et le montant astronomique des deals, et bien la taille d'un buffer en dur à foutu la merde pendant des mois, voir des années pour certaines applications.
Mais elle ne pouvait pas être bogué, cette librairie multi-plateforme utilisée pendant plus de 15 ans par des centaines de développeur. C'est I-M-P-O-S-S-I-B-L-E.
Mais sinon, le premier vol d’Ariane 5 ce n’est pas un bug, on a juste pas lu les spécifications détaillées des composants logiciels.
J’attends toujours le programme sans bug.
je rends grâce à votre étonnant sens du détail. Il se peut que ce que vous dites ait du sens dans votre contexte. Mais dans le mien , ça n'en a aucun. De quel genre de projet vous occupez-vous ?
Pourriez vous mieux préciser ?
Labondance du recours au smiley et la typographie sont elles destinées a suggérer le mécanisme de zygomatiques ? sérotonine, mimétisme ? empathie ?Cela me rappel un bug dans une librairie qui était en prod depuis plus de 15 dans des centaines d'exécutables utilisés par des centaines de traders tous les jours.
Le hic, c'est qu'avec l'inflation et le montant astronomique des deals, et bien la taille d'un buffer en dur à foutu la merde pendant des mois, voir des années pour certaines applications.
Mais elle ne pouvait pas être bogué, cette librairie multi-plateforme utilisée pendant plus de 15 ans par des centaines de développeur. C'est I-M-P-O-S-S-I-B-L-E.
Mais sinon, le premier vol d’Ariane 5 ce n’est pas un bug, on a juste pas lu les spécifications détaillées des composants logiciels.
J’attends toujours le programme sans bug.
Les blagues de potaches sur les bugs abondent mais celle ci est elle vraiment
Le problème d'Ariane provenait d'un défaut de testing, les parties incriminées étaient fonctionnelles sur d'autres plateformes. Le protocole a été fortement amendé depuis. Ce bug n'était pas une bonne nouvelle pour l'ingénierie européenne et française en particulier. Pas plus que les accidents de navette ou qu'un crash d'avion.
Dernière modification par Invité ; 22/07/2010 à 17h57.
La théorie ? new appelle qui il veut.
La pratique ? Par défaut il appelle régulièrement malloc. Mais il peut aussi préférer telle ou telle autre fonction propriétaire que le fournisseur a jugée plus adaptée au cas par défaut.
La pratique bis ? On (nous, quoi) peut faire en sorte que new appelle ce que l'on veut. Par exemple, on peut le faire aller piocher dans un pool plutôt que dans le truc par défaut (malloc ou autre). Dans le même genre, on peut plugger facilement un truc qui s'occupe de surveiller les double-libérations.
Ce que tu décris c'est surtout la fonction "accesseur sur une zone mémoire" des pointeurs. Bref, quelque chose qu'on peut tout a fait proposer dans d'autres langages (C++, Java, ...) sans pour autant que cela soit le coeur du fonctionnement du langage comme dans le C.
En effet, rien n'empêche de définir une classe qui manipule une zone mémoire linéaire et fournit des accesseurs, de la sérialisation, ...
Le C va plus loin dans le sens où tout ce qui est alloué par le langage (les variables, les fonctions) est accessible sous forme de pointeur, un peu à la manière de la reflection. D'ailleurs j'utilise parfois la technique "C Objet" pour disposer du principe des instances dans des programmes en pur C.
Ce que je voulais dire, c'est que je trouve dommage de se dire qu'on utilise new juste parce qu'« on fait de l'objet ».
Je perçois new comme une avancée par rapport à malloc(). À vrai dire, je ne perçois pas l'intérêt d'utiliser malloc() en C++.
En ce moment, je travaille sur une bibliothèque d'analyse de code C++ (voir signature), écrite elle-même en C++. Difficile pour moi de cacher mon attrait pour ce langageDe quel genre de projet vous occupez-vous ?
Concernant les smart pointers (ou pointeurs intelligents), je crois qu'il existe des articles sur DVP qui te répondront mieux que moi.Pourriez vous mieux préciser ?
Concernant les fuites mémoires des GC, même chose, je te conseille la lecture d'un article sur WeakReference (c'est du Java, mais il n'y a pas de raison que le GC de C# n'ait pas le même problème).
Bien vu pour le pool et les liberations à répétitions, que d'écrans bleus en moins..
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager