Aujourd'hui j'ai appris qu'on pouvait faire du RAII en C avec cleanup
marche pas en C :
1> error : 'cleanup': identifier not found
1> error : '__attribute__': identifier not found
Testé avec un compilo conforme C.
Tu as manqué la phrase :
if you don’t mind sacrificing portability outside gcc and clang
--> Aujourd'hui tu as appris qu'on pouvait faire du RAII en C non standard de GCC ou Clang avec cleanup.
(et le non standard, c'est moche et peu respectueux de la liberté des gens qui reçoivent votre code de l'utiliser sur le compilateur de son choix, les standards c'est peut-être chiant mais c'est quand même bien pour l'inter-opérabilité, sans parler que vous ne savez pas quel compilo sera le plus utilisé y compris par vous-même sous Linux dans X années)
Je corrigerai bien leur page
"This is probably the best way to fix code like this if you’re not targeting compilers like the Microsoft one."
-->
"This is a quick (but very ugly) way to fix code like this if you’re not targeting compilers not implementing this non standard / non portable C extension."
Un peu trop facile leur attaque gratuite contre Microsoft alors que dans ce cas précis Microsoft respecte le standard C, et ne pas simplement prévenir que c'est complètement non standard et spécifique à leur compilo préféré repris par son concurrent direct.
PS : testé avec GCC 9.3, ça ne compile pas, faut #define autofree __attribute__((cleanup(free))) et il y a quand même un warning + erreur avec valgrind comme si ignoré. Si quelqu'un arrive à ne pas avoir de warning lors de la compilation et avec Valgrind…
Posté par uso (site web personnel) .
Évalué à 0.
Dernière modification le 28 juin 2021 à 10:32.
TinyCC supporte l’attribut cleanup aussi sur la branch principal du git(mob).
ICC supporte certains GNU C mais je sais pas si il supporte cleanup
Après le truck c'est que le standard C autre que C89 est assez peu supporté, genre MSVC supporte pas C99 et ne supporte C11 que depuis 2019 et très peu des optionnels des C11.
Donc au final on a un standard C qui est moins supporté que certain GNUisme, donc l'argument du "le standard c'est standard donc supporté" me laisse sceptique.
C + cleanup est plus supporté que rust ou go.
Surtout que un compilo C, minimaliste c'est ~10k lignes de code, et yen a beaucoup, donc si ton compilo supporte pas une GNUisme, c'est pas bien compliqué de push le support toi même ou de change de compilateur pour en prendre un qui supporte ton GNUisme.
Oui je sais compilo proprio peu pas toucher au code… Apres si vous avez des tools pourrit aussi…
donc l'argument du "le standard c'est standard donc supporté" me laisse sceptique.
Personne n'a donné cet argument.
Le mien est que c'est non standard donc à ne pas conseiller, surtout quand la version standard de ce dont on parle est supportée partout (oui, même Microsoft support free()).
Et perso, l'argument du "X ne supporte pas quelques détails dont ce n'est pas le sujet de C99 donc autant utiliser un truc non standard" me laisse plus que sceptique, surtout que d'hab on entend ici plutôt râler quand par exemple un site n'était compatible que IE (qui était le plus utilisé et quelle idée de prendre des outils pourris, si on reprend ta façon d'argumenter) à une époque… Les standards, argument à sens unique que quand ça arrange?
de change de compilateur pour en prendre un qui supporte ton GNUisme.
C'est ce qui était répondu aux gens sous Linux face à un site récalcitrant, mais les linuxiens n'acceptaient pas cette "argument", bizarre.
Le mien est que c'est non standard donc à ne pas conseiller, surtout quand la version standard de ce dont on parle est supportée partout (oui, même Microsoft support free()).
Je dirais qu'il faut connaître ça cible, si tu veut faire du code qui marche sur Desktop, téléphone, machine a lavé, et Rover martien effectivement C89 est à conseiller et rien d'autres.
Par contre la ou tu pourrais utiliser rust/go tu peu utiliser GNU C qui sont au moins aussi portable, voir plus.
Et perso, l'argument du "X ne supporte pas quelques détails dont ce n'est pas le sujet de C99 donc autant utiliser un truc non standard
"Quelques détails" est un petit euphémisme on parle des VLAs et des nombres complexe qui étaient 2 des grosse fonctionnalités de C99 qui sont devenu optionnel en C11 (c'est ce qui permet à MSVC d’être un compilo C11 mais pas C99).
surtout que d'hab on entend ici plutôt râler quand par exemple un site n'était compatible que IE (qui était le plus utilisé et quelle idée de prendre des outils pourris, si on reprend ta façon d'argumenter) à une époque… Les standards, argument à sens unique que quand ça arrange?
Bah justement on est dans une citation très différent que celle de IE ou en plus d’être non standard, avais du code non libre, et des avocats Microsoft qui étais prêt a mettre un procès à quiconque essayais d’implémenter leur extensions.
La on est sur des extensions non standard qui sont pour certaines plus portables que n'importe quel bout de go. voir plus portables que certains bouts de C99/C11 standard.
"Quelques détails" est un petit euphémisme on parle des VLAs et des nombres complexe qui étaient 2 des grosse fonctionnalités
Ou pas. tu as tes priorités, soit, ça reste que tu aimes le non standard.
Mais encore une fois : tu fais du hors sujet (X hors sujet pas implémenté) pour ne pas débattre du sujet (que tu t'en fous des standards quand ça t'arrange).
Le pire est que tu sais que tu dis ça juste pour troller, 10 minutes plus tard tu arrives à écrire "ces fonctionnalités n’étais que très peu utilisé".
Je dirais qu'il faut connaître ça cible,
Certes. Ta cible est le non standard, soit, pas la mienne, c'est tout ce que je disais au départ : je préfère quelque chose de standard, interopérable. Pas toi, OK, dit-le donc comme ça que tu n'as rien à faire des standards, et espérons pour ton intégrité que tu acceptes cette réponse quand tu te fais jeter parce que ton OS/etc n'est pas compatible (implémente pour ton truc préféré ou tait-toi).
Je t'attends de pied ferme pour quand un site sera compatible Chrome/Edge/Safari et pas FF et que des gens s'en plaignent ici, pour dire que FF "tout pourri" n'a qu'à implémenter l'option pas standard et sinon les gens peuvent passer à Chrome sinon.
Moi je continuerai à dire préférer les standards quand c'est possible (même si ils "casent" du vieux code, pas le sujet car c'est le standard donc la communauté qui a décidé), et à le dire, et à fustiger les gens qui aiment coder non standard.
Donc mon arguments de dire que "le standard ça veut pas forcement dire grand choses parce-que certaines fonctionnalités du standard, certes peu utilisé, mais standard peuvent être enlevés du jour au lendemain"
est Horst Sujet, parce-que ce que tu préconise c'est pas une utilisation du standard, mais une utilisation d'une soue catégorie du standards définie nulle part, mais qui se base sur la popularité de ces soue catégorie.
Mais par contre dire "peu être que ce qui est intéressent c'est de regarder la popularité au prêt des compilateur et des utilisateurs plus que le standard" est pas ok, parque ce qui est non standard est forcement non portable et non pérenne, parce-que regarde IE, ou le monde du net avec seulement ces 2 moteurs de rendu qui est très très similaire a celui du C et de ces 25 compilateurs et 35 bibliothèques standard ?
Le pire est que tu sais que tu dis ça juste pour troller, 10 minutes plus tard tu arrives à écrire "ces fonctionnalités n’étais que très peu utilisé".
Écoute j'ai pas trouvé de sujet a troll vendredi c'est de plus en plus rare les sujet à troll sur C.
Bon pour développer:
_Complex et VLA étais 2 grosse fonctionnalités de C99 en termes de lignes de code pour leur implémentation et de leur impact sur le code si utilisée.
_Complex n'a jamais était vraiment populaire.
VLA est assez populaire, et était utilisé pendant longtemps dans le noyau Linux, par contre il est impossible dans la plupart des cas d'utilisation de vérifier que le VLA réussie son allocation, donc la fonctionnalité n'est pas conseillé à l'utilisation, sauf dans un sizeof mais c'est pas forcément un technique très connue.
Et le GNUisme change, pour une raison X ou Y, ou pire, le standard l'implémente d'une façon différente. PAF tout cassé ton code non standard.
Ou aussi, tiens du coup tu dois utiliser un compilo non libre parce que le seul à supporter une architecture matérielle qui viens de sortir. Tu as l'habitude d'utiliser un GNUisme, et ce compilateur l'implémente bien, mais pas de la même façon: re-PAF les chocap…
Les intérêts du standard, c'est l'interopérabilité, une certaine garantie que ça ne cassera pas du jour au lendemain, et une documentation souvent plus solide sur ce que la fonctionnalité est censée faire, y compris dans des cas foireux (évidemment, l'inconvénient, c'est une lenteur d'évolution, et le fait que quand des conneries sont faites, elles sont dans le marbre, elles aussi).
Surtout qu'ici on parle de standards ISO, pas juste d'un accord entre 2 projets libres dont on ne sais pas trop combien de temps ils vont durer.
Oui je sais compilo proprio peu pas toucher au code… Apres si vous avez des tools pourrit aussi…
Sauf qu'un code ouvert n'est pas une garantie de qualité (juste qu'il est possible de constater soi-même le niveau qualité, à condition d'avoir le temps et les compétences).
GCC et clang fonctionnent bien dans un très, très grand nombre de cas, je le sais, probablement la majorité, mais ça ne veut absolument pas dire que c'est la totalité.
Quant aux outils pourri… le truc, c'est que, peut-être, ils fournissent, ou l'ont fait et l'histoire fait qu'on peut pas changer, leurs propres extensions au standard, plus utiles que les GNUismes, et que GNU ne fournit pas?
Oui le standard fournie une certaine garantie que ça ne cassera pas du jour au lendemain, mais avoir une extensions GNU utilisé dans le Code de Flatpak, libcloud et systemd (si l'on parle de cleanup) est une garantie qui me semble au moins tout aussi forte que le code ne casseras pas non plus.
Dalleur en parlent de cassage, C11 a cassé la compatibilité avec C99 en rendant des sections du standard optionnels, et C2x va casser la rétrocompatibilité avec toutes les anciennes versions de C en enlevant le support des "Old style C function declaration"
Alors certes on voie ces changements arrivés, et oui que ça soit les VLAs, les _Complex ou les "Old style C function declaration" ces fonctionnalités n’étais que très peu utilisé,
Mais justement avoir des fonctionnalités non standard utilisé par des compagnies qui travaille en même temps sur le standard C, sur les projets utilisant ces fonctionnalité non standard et sur les compilateurs qui implémentes ces fonctionnalités, me semble une garantie beaucoup plus fortes que la fonctionnalité ne va pas cassé du jour au lendemains que du simples fait qu'un code soit standard.
Il n'y a pas besoin de C++20 pour faire l'équivalent de "cleanup". Il me semble dailleurs avoir pris soin de préciser dans mon commentaire que C++98 était suffisant?
C'est donc gcc+clang+icc+open watcom+Microsoft Visual C++, au moins 5 compilateurs.
[…] Cette technique, permet de s'assurer, lors de l'acquisition d'une ressource, que celle-ci sera bien libérée en liant cette acquisition à la durée de vie d'un objet. […]
6 compilateurs, le ++ a incrémenté entre temps ;).
Bah non, vu que le ++ incrément le compilateur, et non le nombre de compilateurs qui supportent C++.
Ce qui en fait un compilateur "C++ + 1" et non C++, donc Microsoft Visual C++ n'est pas un compilateur C++, donc le nombre de compilateurs est de 4.
Sinon je trouve shared_ptr/unique_ptr (donc C++11) beaucoup plus similaire à attribute cleanup que les destructeur C++98, car pour utiliser free sur un "char *" en C++98 il faut passer par une class, avec un shared_ptr on peu juste set free dans le constructeur du shared/unique_ptr comme on le ferait avec l'attribut.
Et oui boost permet d'avoir des shared_ptr en C++98, mais y'a plus standard que boost.
Mais sinon c'est tout à fait possible d'écrire ses propres "smart pointers" ou autres outils de gestion de la mémoire, car il n'y a pas besoin de modifier le compilateur pour ça.
{
char* dynAlloc = malloc(1234);
MemoryDeleter deleter(dynAlloc);
} // La mémoire est libérée avec free() dès qu'on sort de ce bloc
Ça s'utilise très bien avec gcc 2.95.3 (encore utilisé dans Haiku pour la compatibilité avec BeOS). Cette version de gcc est trop ancienne pour implémenter complètement C++98. Donc je pense que n'importe quel compilateur C++ des 25 dernières années ne devrait pas avoir trop de problèmes avec ce code. Ou au pire on peut en écrire une version qui ne nécessite pas de templates, si vraiment on veut utiliser un compilateur datant de la préhistoire :)
c'est tout à fait possible d'écrire ses propres "smart pointers" ou autres outils de gestion de la mémoire
Et heureusement!
Parce que perso, mon unique_res<> est bien pratique pour gérer la mémoire partagée (mmap ne retourne pas NULL en cas d'échec), les file descriptors (qui sont des entiers), les ID opengl (entiers aussi)…
# Aujourd'hui j'ai appris
Posté par Glandos . Évalué à 5.
Qu'on pouvait faire du RAII en C avec
cleanup:[^] # Re: Aujourd'hui j'ai appris
Posté par Zenitram (site web personnel) . Évalué à 8.
marche pas en C :
1> error : 'cleanup': identifier not found
1> error : '__attribute__': identifier not found
Testé avec un compilo conforme C.
Tu as manqué la phrase :
if you don’t mind sacrificing portability outside gcc and clang
--> Aujourd'hui tu as appris qu'on pouvait faire du RAII en C non standard de GCC ou Clang avec cleanup.
(et le non standard, c'est moche et peu respectueux de la liberté des gens qui reçoivent votre code de l'utiliser sur le compilateur de son choix, les standards c'est peut-être chiant mais c'est quand même bien pour l'inter-opérabilité, sans parler que vous ne savez pas quel compilo sera le plus utilisé y compris par vous-même sous Linux dans X années)
Je corrigerai bien leur page
"This is probably the best way to fix code like this if you’re not targeting compilers like the Microsoft one."
-->
"This is a quick (but very ugly) way to fix code like this if you’re not targeting compilers not implementing this non standard / non portable C extension."
Un peu trop facile leur attaque gratuite contre Microsoft alors que dans ce cas précis Microsoft respecte le standard C, et ne pas simplement prévenir que c'est complètement non standard et spécifique à leur compilo préféré repris par son concurrent direct.
PS : testé avec GCC 9.3, ça ne compile pas, faut
#define autofree __attribute__((cleanup(free)))et il y a quand même un warning + erreur avec valgrind comme si ignoré. Si quelqu'un arrive à ne pas avoir de warning lors de la compilation et avec Valgrind…[^] # Re: Aujourd'hui j'ai appris
Posté par uso (site web personnel) . Évalué à 0. Dernière modification le 28 juin 2021 à 10:32.
TinyCC supporte l’attribut cleanup aussi sur la branch principal du git(mob).
ICC supporte certains GNU C mais je sais pas si il supporte cleanup
Après le truck c'est que le standard C autre que C89 est assez peu supporté, genre MSVC supporte pas C99 et ne supporte C11 que depuis 2019 et très peu des optionnels des C11.
Donc au final on a un standard C qui est moins supporté que certain GNUisme, donc l'argument du "le standard c'est standard donc supporté" me laisse sceptique.
C + cleanup est plus supporté que rust ou go.
Surtout que un compilo C, minimaliste c'est ~10k lignes de code, et yen a beaucoup, donc si ton compilo supporte pas une GNUisme, c'est pas bien compliqué de push le support toi même ou de change de compilateur pour en prendre un qui supporte ton GNUisme.
Oui je sais compilo proprio peu pas toucher au code… Apres si vous avez des tools pourrit aussi…
[^] # Re: Aujourd'hui j'ai appris
Posté par Zenitram (site web personnel) . Évalué à 2. Dernière modification le 28 juin 2021 à 10:51.
Personne n'a donné cet argument.
Le mien est que c'est non standard donc à ne pas conseiller, surtout quand la version standard de ce dont on parle est supportée partout (oui, même Microsoft support
free()).Et perso, l'argument du "X ne supporte pas quelques détails dont ce n'est pas le sujet de C99 donc autant utiliser un truc non standard" me laisse plus que sceptique, surtout que d'hab on entend ici plutôt râler quand par exemple un site n'était compatible que IE (qui était le plus utilisé et quelle idée de prendre des outils pourris, si on reprend ta façon d'argumenter) à une époque… Les standards, argument à sens unique que quand ça arrange?
C'est ce qui était répondu aux gens sous Linux face à un site récalcitrant, mais les linuxiens n'acceptaient pas cette "argument", bizarre.
[^] # Re: Aujourd'hui j'ai appris
Posté par uso (site web personnel) . Évalué à 1.
Je dirais qu'il faut connaître ça cible, si tu veut faire du code qui marche sur Desktop, téléphone, machine a lavé, et Rover martien effectivement C89 est à conseiller et rien d'autres.
Par contre la ou tu pourrais utiliser rust/go tu peu utiliser GNU C qui sont au moins aussi portable, voir plus.
"Quelques détails" est un petit euphémisme on parle des VLAs et des nombres complexe qui étaient 2 des grosse fonctionnalités de C99 qui sont devenu optionnel en C11 (c'est ce qui permet à MSVC d’être un compilo C11 mais pas C99).
Bah justement on est dans une citation très différent que celle de IE ou en plus d’être non standard, avais du code non libre, et des avocats Microsoft qui étais prêt a mettre un procès à quiconque essayais d’implémenter leur extensions.
La on est sur des extensions non standard qui sont pour certaines plus portables que n'importe quel bout de go. voir plus portables que certains bouts de C99/C11 standard.
[^] # Re: Aujourd'hui j'ai appris
Posté par Zenitram (site web personnel) . Évalué à 3. Dernière modification le 28 juin 2021 à 14:04.
Ou pas. tu as tes priorités, soit, ça reste que tu aimes le non standard.
Mais encore une fois : tu fais du hors sujet (X hors sujet pas implémenté) pour ne pas débattre du sujet (que tu t'en fous des standards quand ça t'arrange).
Le pire est que tu sais que tu dis ça juste pour troller, 10 minutes plus tard tu arrives à écrire "ces fonctionnalités n’étais que très peu utilisé".
Certes. Ta cible est le non standard, soit, pas la mienne, c'est tout ce que je disais au départ : je préfère quelque chose de standard, interopérable. Pas toi, OK, dit-le donc comme ça que tu n'as rien à faire des standards, et espérons pour ton intégrité que tu acceptes cette réponse quand tu te fais jeter parce que ton OS/etc n'est pas compatible (implémente pour ton truc préféré ou tait-toi).
Je t'attends de pied ferme pour quand un site sera compatible Chrome/Edge/Safari et pas FF et que des gens s'en plaignent ici, pour dire que FF "tout pourri" n'a qu'à implémenter l'option pas standard et sinon les gens peuvent passer à Chrome sinon.
Moi je continuerai à dire préférer les standards quand c'est possible (même si ils "casent" du vieux code, pas le sujet car c'est le standard donc la communauté qui a décidé), et à le dire, et à fustiger les gens qui aiment coder non standard.
[^] # Re: Aujourd'hui j'ai appris
Posté par uso (site web personnel) . Évalué à 3.
Donc mon arguments de dire que "le standard ça veut pas forcement dire grand choses parce-que certaines fonctionnalités du standard, certes peu utilisé, mais standard peuvent être enlevés du jour au lendemain"
est Horst Sujet, parce-que ce que tu préconise c'est pas une utilisation du standard, mais une utilisation d'une soue catégorie du standards définie nulle part, mais qui se base sur la popularité de ces soue catégorie.
Mais par contre dire "peu être que ce qui est intéressent c'est de regarder la popularité au prêt des compilateur et des utilisateurs plus que le standard" est pas ok, parque ce qui est non standard est forcement non portable et non pérenne, parce-que regarde IE, ou le monde du net avec seulement ces 2 moteurs de rendu qui est très très similaire a celui du C et de ces 25 compilateurs et 35 bibliothèques standard ?
Écoute j'ai pas trouvé de sujet a troll vendredi c'est de plus en plus rare les sujet à troll sur C.
Bon pour développer:
_Complex et VLA étais 2 grosse fonctionnalités de C99 en termes de lignes de code pour leur implémentation et de leur impact sur le code si utilisée.
_Complex n'a jamais était vraiment populaire.
VLA est assez populaire, et était utilisé pendant longtemps dans le noyau Linux, par contre il est impossible dans la plupart des cas d'utilisation de vérifier que le VLA réussie son allocation, donc la fonctionnalité n'est pas conseillé à l'utilisation, sauf dans un sizeof mais c'est pas forcément un technique très connue.
[^] # Re: Aujourd'hui j'ai appris
Posté par freem . Évalué à 7.
Et le GNUisme change, pour une raison X ou Y, ou pire, le standard l'implémente d'une façon différente. PAF tout cassé ton code non standard.
Ou aussi, tiens du coup tu dois utiliser un compilo non libre parce que le seul à supporter une architecture matérielle qui viens de sortir. Tu as l'habitude d'utiliser un GNUisme, et ce compilateur l'implémente bien, mais pas de la même façon: re-PAF les chocap…
Les intérêts du standard, c'est l'interopérabilité, une certaine garantie que ça ne cassera pas du jour au lendemain, et une documentation souvent plus solide sur ce que la fonctionnalité est censée faire, y compris dans des cas foireux (évidemment, l'inconvénient, c'est une lenteur d'évolution, et le fait que quand des conneries sont faites, elles sont dans le marbre, elles aussi).
Surtout qu'ici on parle de standards ISO, pas juste d'un accord entre 2 projets libres dont on ne sais pas trop combien de temps ils vont durer.
Sauf qu'un code ouvert n'est pas une garantie de qualité (juste qu'il est possible de constater soi-même le niveau qualité, à condition d'avoir le temps et les compétences).
GCC et clang fonctionnent bien dans un très, très grand nombre de cas, je le sais, probablement la majorité, mais ça ne veut absolument pas dire que c'est la totalité.
Quant aux outils pourri… le truc, c'est que, peut-être, ils fournissent, ou l'ont fait et l'histoire fait qu'on peut pas changer, leurs propres extensions au standard, plus utiles que les GNUismes, et que GNU ne fournit pas?
[^] # Re: Aujourd'hui j'ai appris
Posté par uso (site web personnel) . Évalué à 3.
Oui le standard fournie une certaine garantie que ça ne cassera pas du jour au lendemain, mais avoir une extensions GNU utilisé dans le Code de Flatpak, libcloud et systemd (si l'on parle de cleanup) est une garantie qui me semble au moins tout aussi forte que le code ne casseras pas non plus.
Dalleur en parlent de cassage, C11 a cassé la compatibilité avec C99 en rendant des sections du standard optionnels, et C2x va casser la rétrocompatibilité avec toutes les anciennes versions de C en enlevant le support des "Old style C function declaration"
Alors certes on voie ces changements arrivés, et oui que ça soit les VLAs, les _Complex ou les "Old style C function declaration" ces fonctionnalités n’étais que très peu utilisé,
Mais justement avoir des fonctionnalités non standard utilisé par des compagnies qui travaille en même temps sur le standard C, sur les projets utilisant ces fonctionnalité non standard et sur les compilateurs qui implémentes ces fonctionnalités, me semble une garantie beaucoup plus fortes que la fonctionnalité ne va pas cassé du jour au lendemains que du simples fait qu'un code soit standard.
[^] # Re: Aujourd'hui j'ai appris
Posté par uso (site web personnel) . Évalué à 1.
[^] # Re: Aujourd'hui j'ai appris
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 4.
La bonne solution est simple: ça se fait très bien en C++ standard (même en C++98), et la syntaxe est beaucoup plus lisible.
[^] # Re: Aujourd'hui j'ai appris
Posté par uso (site web personnel) . Évalué à -1.
oui, mais le C++ standard (C++20) est moins supporté que le C non standard avec cleanup.
regarde https://en.cppreference.com/w/cpp/compiler_support/20 2 compilateurs qui supporte C++ 20.
C89 + cleanup c'est clang + gcc + icc + tcc, donc 4 compilateurs.
oui la comparaison est totalement baisais limite malhonnête pour dire GNU C > C++.
[^] # Re: Aujourd'hui j'ai appris
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 5. Dernière modification le 28 juin 2021 à 23:01.
Il n'y a pas besoin de C++20 pour faire l'équivalent de "cleanup". Il me semble dailleurs avoir pris soin de préciser dans mon commentaire que C++98 était suffisant?
C'est donc gcc+clang+icc+open watcom+Microsoft Visual C++, au moins 5 compilateurs.
[^] # Re: Aujourd'hui j'ai appris
Posté par cg . Évalué à 4.
6 compilateurs, le
++a incrémenté entre temps ;).Brève de talivernes, en fait je voulais poster ceci, car je ne connaissais pas l'acronyme RAII :
https://fr.wikipedia.org/wiki/Resource_acquisition_is_initialization
[…] Cette technique, permet de s'assurer, lors de l'acquisition d'une ressource, que celle-ci sera bien libérée en liant cette acquisition à la durée de vie d'un objet. […]
[^] # Re: Aujourd'hui j'ai appris
Posté par uso (site web personnel) . Évalué à 3.
Bah non, vu que le ++ incrément le compilateur, et non le nombre de compilateurs qui supportent C++.
Ce qui en fait un compilateur "C++ + 1" et non C++, donc Microsoft Visual C++ n'est pas un compilateur C++, donc le nombre de compilateurs est de 4.
Sinon je trouve shared_ptr/unique_ptr (donc C++11) beaucoup plus similaire à attribute cleanup que les destructeur C++98, car pour utiliser free sur un "char *" en C++98 il faut passer par une class, avec un shared_ptr on peu juste set free dans le constructeur du shared/unique_ptr comme on le ferait avec l'attribut.
Et oui boost permet d'avoir des shared_ptr en C++98, mais y'a plus standard que boost.
[^] # Re: Aujourd'hui j'ai appris
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 3. Dernière modification le 29 juin 2021 à 13:38.
En C++98 il y avait auto_ptr: https://en.cppreference.com/w/cpp/memory/auto_ptr
Mais sinon c'est tout à fait possible d'écrire ses propres "smart pointers" ou autres outils de gestion de la mémoire, car il n'y a pas besoin de modifier le compilateur pour ça.
Par exemple dans Haiku on a ceci:
https://git.haiku-os.org/haiku/tree/headers/private/shared/AutoDeleter.h#n151
Qui s'utilise comme cela:
Ça s'utilise très bien avec gcc 2.95.3 (encore utilisé dans Haiku pour la compatibilité avec BeOS). Cette version de gcc est trop ancienne pour implémenter complètement C++98. Donc je pense que n'importe quel compilateur C++ des 25 dernières années ne devrait pas avoir trop de problèmes avec ce code. Ou au pire on peut en écrire une version qui ne nécessite pas de templates, si vraiment on veut utiliser un compilateur datant de la préhistoire :)
[^] # Re: Aujourd'hui j'ai appris
Posté par freem . Évalué à 2.
Et heureusement!
Parce que perso, mon unique_res<> est bien pratique pour gérer la mémoire partagée (mmap ne retourne pas NULL en cas d'échec), les file descriptors (qui sont des entiers), les ID opengl (entiers aussi)…
[^] # Re: Aujourd'hui j'ai appris
Posté par freem . Évalué à 2. Dernière modification le 30 juin 2021 à 14:03.
oups. Déjà dis.
[^] # Re: Aujourd'hui j'ai appris
Posté par Zenitram (site web personnel) . Évalué à 4. Dernière modification le 29 juin 2021 à 08:11.
J'avais compris "totalement baisais limite malhonnête" comme indiquant un commentaire totalement humoristique.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.