Gestion mémoire et new CWnd

Cyrille Szymanski

30/04/2006 à 15:53

"Arnaud Debaene" wrote in
news:445304f5$0$21254$:

Quoi, "using" à la place de RAII? C'est vraiement la solution du
pauvre... C'est C++/CLI qui propose une vraie notion de RAII dans un
langage .NET, grâce au "stack semantic".

Le C++ managé n'a pas trop la cote, pourtant ça devrait intéresser du monde
de pouvoir gérer la mémoire finement sous .Net... Peut-être que ça aurait
eu plus de succès s'ils lui avaient donné un autre nom, genre C* ? Mais
hélas, le C# est plus sexy, et le C++/CLI va rester le motto de quelques
happy few.

--
Cyrille Szymanski

Arnaud Debaene

30/04/2006 à 18:21

Cyrille Szymanski wrote:

"Arnaud Debaene" wrote in
news:445304f5$0$21254$:

Quoi, "using" à la place de RAII? C'est vraiement la solution du
pauvre... C'est C++/CLI qui propose une vraie notion de RAII dans un
langage .NET, grâce au "stack semantic".

Le C++ managé n'a pas trop la cote, pourtant ça devrait intéresser du
monde de pouvoir gérer la mémoire finement sous .Net... Peut-être que
ça aurait eu plus de succès s'ils lui avaient donné un autre nom,
genre C* ? Mais hélas, le C# est plus sexy, et le C++/CLI va rester
le motto de quelques happy few.

J'ai entendu dire que en tout cas, en interne chez MS, C++/CLI retrouve une
certaine importance grâce à sa syntaxe un peu plus "buvable" que celle de
MC++. De plus, il est évident que c'est le langage .NET qui propose le plus
de possibilités et de flexibilité. On peut faire des trucs marrants par
exemple en mélangeant generics et templates....
De mon point de vue, ces "stack semantics" sont un argument suffisant à eux
seuls, si le projet dépasse un certaine taille.

Arnaud
MVP - VC

Arnold McDonald $AMcD$

30/04/2006 à 19:05

Arnaud Debaene wrote:

De plus, il est évident que c'est le
langage .NET qui propose le plus de possibilités et de flexibilité.

C'est pas pour lancer un petit troll avant de vous quitter quelques
semaines, mais pour moi, il est évident que le langage qui a le plus de
possibilités, c'est bien le langage d'assemblage. Aucune limite, aucune.
Pour la flexibilité, c'est sûr, on repassera...

On peut faire des trucs marrants par exemple en mélangeant generics
et templates...

Heu moi, c'est loin de me faire rire ce genre de trucs. Cela me rappelle les
code C++ dits "professionels", des milliers de templates, de surcharges,
d'héritage. Au final, c'est absolument imaintenable si ce n'est par ceux qui
l'ont écrit. Comme quoi, on a pas progressé beaucoup de ce côté là depuis 20
ans :-).

--
Arnold McDonald (AMcD)

http://arnold.mcdonald.free.fr/

Cyrille Szymanski

30/04/2006 à 22:29

"Arnold McDonald (AMcD)" wrote in
news:4454ee72$0$18276$:

C'est pas pour lancer un petit troll avant de vous quitter quelques
semaines, mais pour moi, il est évident que le langage qui a le plus
de possibilités, c'est bien le langage d'assemblage. Aucune limite,
aucune. Pour la flexibilité, c'est sûr, on repassera...

Si la puce que l'on programme est pourrie à la base, l'ASM n'arrangera
pas les choses. L'architecture x86 est connue pour être l'une des plus
mal foutues et heureusement qu'il existe des langages de haut niveau
pour en abstraire les atrocités.

Ce qui rend les assembleurs sympathiques à utiliser c'est toutes les
petites choses comme les macros, les méta-instructions etc. Alors autant
faire de l'inline ASM en C. Et tant qu'à faire, autant ajouter les
classes. Et pourquoi pas les templates qui ne sont rien de plus qu'un
système de macro de luxe. Et pourquoi pas les generics qui sont un bon
compagnon des templates...

Ce n'est pas à toi que je vais apprendre que l'assembleur en tant que
"langage" ça ne veut rien dire du tout. Que tu me dises que tu aimes
programmer en ASM sur AS/400 parce que l'architecture est bien foutue,
je comprends. Mais sous x86 ???!!

Comme quoi, on a pas progressé beaucoup de ce côté là depuis 20 ans
:-).

Oui tu as raison, un code nul, qu'il soit en C# ou en ASM restera un
code nul. C# n'est pas gage de qualité et ne signifie pas que le code
soit forcément flexible.

--
Cyrille Szymanski

Arnold McDonald $AMcD$

30/04/2006 à 23:28

Cyrille Szymanski wrote:

Si la puce que l'on programme est pourrie à la base, l'ASM n'arrangera
pas les choses. L'architecture x86 est connue pour être l'une des plus
mal foutues et heureusement qu'il existe des langages de haut niveau
pour en abstraire les atrocités.

Hola, hola, hola. Le 386 était truffé d'incohérence, j'agrée. Qu'as-tu
contre un PIV par exemple ? Mal foutu ? Où ça ? C'est justement truffé de
tas de choses, SSE, SSE2, SSE3, caches, monitoring, tout un tas de trucs
système qu'aucun langage de "haut niveau" ne gère pas si bien que soit. Et
encore, quand ça l'est, t'as pas vraiment une grosse latitude dans les
paramètres, le contrôle, etc.

Ce qui rend les assembleurs sympathiques à utiliser c'est toutes les
petites choses comme les macros, les méta-instructions etc.

Absolument pas. Macros, meta-instruction et cie, ce n'est pas de
l'assembleur. Ce qui rend l'ASM sympatique c'est, par exemple, de faire
absolument ce que tu veux en mode protégé.

Alors
autant faire de l'inline ASM en C.

C'est extrêment limité et ne présente quasiment aucun intérêt.

Et tant qu'à faire, autant ajouter
les classes. Et pourquoi pas les templates qui ne sont rien de plus
qu'un système de macro de luxe. Et pourquoi pas les generics qui sont
un bon compagnon des templates...

Je programme avant tout en C. Je n'ai jamais eu besoin de classes, templates
et cie.

Ce n'est pas à toi que je vais apprendre que l'assembleur en tant que
"langage" ça ne veut rien dire du tout. Que tu me dises que tu aimes
programmer en ASM sur AS/400 parce que l'architecture est bien foutue,
je comprends. Mais sous x86 ???!!

Moi, pour certains cas particuliers, j'aime bien coder en ASM l'API WIN32.
Le gain principal se situe au niveau de la taille des exécutables et du
contrôle du déroulement de ton application. Le gain en taille peut atteindre
60, 70 ou 80 %. Le contrôle du déroulement, c'est bypasser 350 layer de
check de pile et autres stupidités qui rendent ton code indebuggable sans
aspirine et l'analyse post-mortem imbuvable.

J'ai plus de Net à 23h59'59''. Pas cool de me relancer sur le sujet :-).

--
Arnold McDonald (AMcD)

http://arnold.mcdonald.free.fr/

Cyrille Szymanski wrote:

Si la puce que l'on programme est pourrie à la base, l'ASM n'arrangera
pas les choses. L'architecture x86 est connue pour être l'une des plus
mal foutues et heureusement qu'il existe des langages de haut niveau
pour en abstraire les atrocités.

Hola, hola, hola. Le 386 était truffé d'incohérence, j'agrée. Qu'as-tu
contre un PIV par exemple ? Mal foutu ? Où ça ? C'est justement truffé de
tas de choses, SSE, SSE2, SSE3, caches, monitoring, tout un tas de trucs
système qu'aucun langage de "haut niveau" ne gère pas si bien que soit. Et
encore, quand ça l'est, t'as pas vraiment une grosse latitude dans les
paramètres, le contrôle, etc.

Ce qui rend les assembleurs sympathiques à utiliser c'est toutes les
petites choses comme les macros, les méta-instructions etc.

Absolument pas. Macros, meta-instruction et cie, ce n'est pas de
l'assembleur. Ce qui rend l'ASM sympatique c'est, par exemple, de faire
absolument ce que tu veux en mode protégé.

Alors
autant faire de l'inline ASM en C.

C'est extrêment limité et ne présente quasiment aucun intérêt.

Et tant qu'à faire, autant ajouter
les classes. Et pourquoi pas les templates qui ne sont rien de plus
qu'un système de macro de luxe. Et pourquoi pas les generics qui sont
un bon compagnon des templates...

Je programme avant tout en C. Je n'ai jamais eu besoin de classes, templates
et cie.

Ce n'est pas à toi que je vais apprendre que l'assembleur en tant que
"langage" ça ne veut rien dire du tout. Que tu me dises que tu aimes
programmer en ASM sur AS/400 parce que l'architecture est bien foutue,
je comprends. Mais sous x86 ???!!

Moi, pour certains cas particuliers, j'aime bien coder en ASM l'API WIN32.
Le gain principal se situe au niveau de la taille des exécutables et du
contrôle du déroulement de ton application. Le gain en taille peut atteindre
60, 70 ou 80 %. Le contrôle du déroulement, c'est bypasser 350 layer de
check de pile et autres stupidités qui rendent ton code indebuggable sans
aspirine et l'analyse post-mortem imbuvable.

J'ai plus de Net à 23h59'59''. Pas cool de me relancer sur le sujet :-).

--
Arnold McDonald (AMcD)

http://arnold.mcdonald.free.fr/

Vous avez filtré cet utilisateur ! Consultez son message

Cyrille Szymanski wrote:

Si la puce que l'on programme est pourrie à la base, l'ASM n'arrangera
pas les choses. L'architecture x86 est connue pour être l'une des plus
mal foutues et heureusement qu'il existe des langages de haut niveau
pour en abstraire les atrocités.

Hola, hola, hola. Le 386 était truffé d'incohérence, j'agrée. Qu'as-tu
contre un PIV par exemple ? Mal foutu ? Où ça ? C'est justement truffé de
tas de choses, SSE, SSE2, SSE3, caches, monitoring, tout un tas de trucs
système qu'aucun langage de "haut niveau" ne gère pas si bien que soit. Et
encore, quand ça l'est, t'as pas vraiment une grosse latitude dans les
paramètres, le contrôle, etc.

Ce qui rend les assembleurs sympathiques à utiliser c'est toutes les
petites choses comme les macros, les méta-instructions etc.

Absolument pas. Macros, meta-instruction et cie, ce n'est pas de
l'assembleur. Ce qui rend l'ASM sympatique c'est, par exemple, de faire
absolument ce que tu veux en mode protégé.

Alors
autant faire de l'inline ASM en C.

C'est extrêment limité et ne présente quasiment aucun intérêt.

Et tant qu'à faire, autant ajouter
les classes. Et pourquoi pas les templates qui ne sont rien de plus
qu'un système de macro de luxe. Et pourquoi pas les generics qui sont
un bon compagnon des templates...

Je programme avant tout en C. Je n'ai jamais eu besoin de classes, templates
et cie.

Ce n'est pas à toi que je vais apprendre que l'assembleur en tant que
"langage" ça ne veut rien dire du tout. Que tu me dises que tu aimes
programmer en ASM sur AS/400 parce que l'architecture est bien foutue,
je comprends. Mais sous x86 ???!!

Moi, pour certains cas particuliers, j'aime bien coder en ASM l'API WIN32.
Le gain principal se situe au niveau de la taille des exécutables et du
contrôle du déroulement de ton application. Le gain en taille peut atteindre
60, 70 ou 80 %. Le contrôle du déroulement, c'est bypasser 350 layer de
check de pile et autres stupidités qui rendent ton code indebuggable sans
aspirine et l'analyse post-mortem imbuvable.

J'ai plus de Net à 23h59'59''. Pas cool de me relancer sur le sujet :-).

--
Arnold McDonald (AMcD)

http://arnold.mcdonald.free.fr/

Cyrille Szymanski

01/05/2006 à 11:55

"Arnold McDonald (AMcD)" wrote in
news:44552bf1$0$2650$:

Hola, hola, hola. Le 386 était truffé d'incohérence, j'agrée. Qu'as-tu
contre un PIV par exemple ? Mal foutu ? Où ça ? C'est justement truffé
de tas de choses, SSE, SSE2, SSE3, caches, monitoring, tout un tas de
trucs système qu'aucun langage de "haut niveau" ne gère pas si bien
que soit. Et encore, quand ça l'est, t'as pas vraiment une grosse
latitude dans les paramètres, le contrôle, etc.

Je dois avouer que depuis les extensions MMX j'ai pas trop pratiqué ces
choses là. Donc oui je te fais entièrement confiance.

Pour la petite histoire, je me suis arrêté au mode protégé, j'ai été
impressionné par les possibilités offertes (du genre wahou il sait faire
tout ça mon ordi !!), mais je me suis vite rendu compte que l'OS avait pris
plein de décisions pour moi et que mon seul salut était de coder mon propre
système d'exploitation.

J'ai plus de Net à 23h59'59''. Pas cool de me relancer sur le sujet
:-).

Désolé

--
Cyrille Szymanski

Yalbrieux

01/05/2006 à 21:28

Bonsoir,

Le w.e. a été un peu dur mais je peux encore vous répondre :)

[...]

J'adore l'info de cette époque. 8 Ko de mémoire ! Pourtant, le gars

devant,

t'as l'impression qu'il pilote une console à la NASA :-).

[...]
Comme je l'ai écrit je n'ai pas bossé sur ce modèle précis.
La console que j'ai utilisée ressemblait plutôt à un scope de radar tout
rond.

[...]

D'ailleurs, question à ceux qui ont usé de ce truc. Vous faisiez quoi avec

?

Quel type de calcul ? Les gars qui mettaient 60 KUSD (de 1962!!!) dans

cette

machine, c'était pour quelle finalité ? Parce qu'avec 8 Ko...

[...]
Les CDC étaient très prisés pour le calcul scientifique et l'on bossait en
Fortran.

[...]

Autre photo :
http://209.165.152.119/bob/5b.jpg (4 unités à bandes !)

[...]
Les mêmes unités de bandes CDC étaient utilisées sur bien des machines non
CDC. Je connais bien celles-là.
Superbes systèmes, rapides, avec des puits à vide (les 2 raies parallèles
verticale en dessous des bobines)
Ca faisait des pchiiipfoutprout à la fermeture ou à l'ouverture de la glace
de protection, des schleurfff lorsque la bande partait dans les puits, des
dziiitdziiiiit à la lecture par blocs. Hi hi. J'ai encore ça dans l'oreille.

Il y avait aussi les MSD, les gamelles de disque durs gros comme des
cocottes minute pour famille nombreuse, contenant des galettes superposées,
que l'on vissait dans l'unité grâce au couvercle protecteur ! ! Des disques
géants de 50, 100, 200 Mo ! Voire 400Mo dans la haute période :)
Votre photo du 6600 en montre trois à côté d'une opératrice, en bas.
Chaque périphérique mériterait des volumes d'anecdotes (les lecteurs de
cartes sur table vibrantes, les imprimantes à bande, etc.)
Il faudrait aussi parler de la faune qui tournait autour de ces bêtes : les
perfo-vérif's, les préparateurs, les opérateurs, les préparateurs, ... Il
faudrait parler des modes : le batch, le time-sharing, le temps réel, le
multitraitement, ... Et la faune des utilisateurs donc !

Bref l'époque n'est plus, mais que de souvenirs que ne laissent pas les
machines actuelles. La raison en est de la révolution de la micro qui est
tout à fait comparable à celle du moteur électrique :
Autrefois les usines étaient construites autour de la machine à vapeur
centrale et chaque poste d'exploitation y était relié par une courroie
débrayable. Le moteur électrique à révolutionné cela en mettant un ou
plusieurs moteurs dans le dit poste de travail. Votre rasoir électrique en
contient un qui n'est utilisé que quelques minutes par jours mais personne
ne crie au scandale et à la sous-utilisation.
De même, la révolution de la micro fait qu'il y a des puces jusque dans la
machine à laver et que personne ne s'insurge contre ce fait.
Au contraire. L'époque des machines en millions de francs ou de dollars
n'est plus et la sous utilisation d'un micro n'est plus un sujet
émoustillant. Les moniteurs hard ou soft, qui analysaient l'utilisation et
l'optimisation de "l'Ordinateur" autour duquel tournait tout un monde, sont
désormais inutiles.
Il ne faut pas chercher à comparer les puissances respectives des machines
de l'époque et du plus simple PC d'aujourd'hui car ce n'est plus du même
monde et ils n'ont plus les mêmes objectifs.
Restons en là.
Cordialement
Yves

Bonsoir,

Le w.e. a été un peu dur mais je peux encore vous répondre :)

[...]

J'adore l'info de cette époque. 8 Ko de mémoire ! Pourtant, le gars

devant,

t'as l'impression qu'il pilote une console à la NASA :-).

[...]
Comme je l'ai écrit je n'ai pas bossé sur ce modèle précis.
La console que j'ai utilisée ressemblait plutôt à un scope de radar tout
rond.

[...]

D'ailleurs, question à ceux qui ont usé de ce truc. Vous faisiez quoi avec

?

Quel type de calcul ? Les gars qui mettaient 60 KUSD (de 1962!!!) dans

cette

machine, c'était pour quelle finalité ? Parce qu'avec 8 Ko...

[...]
Les CDC étaient très prisés pour le calcul scientifique et l'on bossait en
Fortran.

[...]

Autre photo :
http://209.165.152.119/bob/5b.jpg (4 unités à bandes !)

[...]
Les mêmes unités de bandes CDC étaient utilisées sur bien des machines non
CDC. Je connais bien celles-là.
Superbes systèmes, rapides, avec des puits à vide (les 2 raies parallèles
verticale en dessous des bobines)
Ca faisait des pchiiipfoutprout à la fermeture ou à l'ouverture de la glace
de protection, des schleurfff lorsque la bande partait dans les puits, des
dziiitdziiiiit à la lecture par blocs. Hi hi. J'ai encore ça dans l'oreille.

Il y avait aussi les MSD, les gamelles de disque durs gros comme des
cocottes minute pour famille nombreuse, contenant des galettes superposées,
que l'on vissait dans l'unité grâce au couvercle protecteur ! ! Des disques
géants de 50, 100, 200 Mo ! Voire 400Mo dans la haute période :)
Votre photo du 6600 en montre trois à côté d'une opératrice, en bas.
Chaque périphérique mériterait des volumes d'anecdotes (les lecteurs de
cartes sur table vibrantes, les imprimantes à bande, etc.)
Il faudrait aussi parler de la faune qui tournait autour de ces bêtes : les
perfo-vérif's, les préparateurs, les opérateurs, les préparateurs, ... Il
faudrait parler des modes : le batch, le time-sharing, le temps réel, le
multitraitement, ... Et la faune des utilisateurs donc !

Bref l'époque n'est plus, mais que de souvenirs que ne laissent pas les
machines actuelles. La raison en est de la révolution de la micro qui est
tout à fait comparable à celle du moteur électrique :
Autrefois les usines étaient construites autour de la machine à vapeur
centrale et chaque poste d'exploitation y était relié par une courroie
débrayable. Le moteur électrique à révolutionné cela en mettant un ou
plusieurs moteurs dans le dit poste de travail. Votre rasoir électrique en
contient un qui n'est utilisé que quelques minutes par jours mais personne
ne crie au scandale et à la sous-utilisation.
De même, la révolution de la micro fait qu'il y a des puces jusque dans la
machine à laver et que personne ne s'insurge contre ce fait.
Au contraire. L'époque des machines en millions de francs ou de dollars
n'est plus et la sous utilisation d'un micro n'est plus un sujet
émoustillant. Les moniteurs hard ou soft, qui analysaient l'utilisation et
l'optimisation de "l'Ordinateur" autour duquel tournait tout un monde, sont
désormais inutiles.
Il ne faut pas chercher à comparer les puissances respectives des machines
de l'époque et du plus simple PC d'aujourd'hui car ce n'est plus du même
monde et ils n'ont plus les mêmes objectifs.
Restons en là.
Cordialement
Yves

Vous avez filtré cet utilisateur ! Consultez son message

Bonsoir,

Le w.e. a été un peu dur mais je peux encore vous répondre :)

[...]

J'adore l'info de cette époque. 8 Ko de mémoire ! Pourtant, le gars

devant,

t'as l'impression qu'il pilote une console à la NASA :-).

[...]
Comme je l'ai écrit je n'ai pas bossé sur ce modèle précis.
La console que j'ai utilisée ressemblait plutôt à un scope de radar tout
rond.

[...]

D'ailleurs, question à ceux qui ont usé de ce truc. Vous faisiez quoi avec

?

Quel type de calcul ? Les gars qui mettaient 60 KUSD (de 1962!!!) dans

cette

machine, c'était pour quelle finalité ? Parce qu'avec 8 Ko...

[...]
Les CDC étaient très prisés pour le calcul scientifique et l'on bossait en
Fortran.

[...]

Autre photo :
http://209.165.152.119/bob/5b.jpg (4 unités à bandes !)

[...]
Les mêmes unités de bandes CDC étaient utilisées sur bien des machines non
CDC. Je connais bien celles-là.
Superbes systèmes, rapides, avec des puits à vide (les 2 raies parallèles
verticale en dessous des bobines)
Ca faisait des pchiiipfoutprout à la fermeture ou à l'ouverture de la glace
de protection, des schleurfff lorsque la bande partait dans les puits, des
dziiitdziiiiit à la lecture par blocs. Hi hi. J'ai encore ça dans l'oreille.

Il y avait aussi les MSD, les gamelles de disque durs gros comme des
cocottes minute pour famille nombreuse, contenant des galettes superposées,
que l'on vissait dans l'unité grâce au couvercle protecteur ! ! Des disques
géants de 50, 100, 200 Mo ! Voire 400Mo dans la haute période :)
Votre photo du 6600 en montre trois à côté d'une opératrice, en bas.
Chaque périphérique mériterait des volumes d'anecdotes (les lecteurs de
cartes sur table vibrantes, les imprimantes à bande, etc.)
Il faudrait aussi parler de la faune qui tournait autour de ces bêtes : les
perfo-vérif's, les préparateurs, les opérateurs, les préparateurs, ... Il
faudrait parler des modes : le batch, le time-sharing, le temps réel, le
multitraitement, ... Et la faune des utilisateurs donc !

Bref l'époque n'est plus, mais que de souvenirs que ne laissent pas les
machines actuelles. La raison en est de la révolution de la micro qui est
tout à fait comparable à celle du moteur électrique :
Autrefois les usines étaient construites autour de la machine à vapeur
centrale et chaque poste d'exploitation y était relié par une courroie
débrayable. Le moteur électrique à révolutionné cela en mettant un ou
plusieurs moteurs dans le dit poste de travail. Votre rasoir électrique en
contient un qui n'est utilisé que quelques minutes par jours mais personne
ne crie au scandale et à la sous-utilisation.
De même, la révolution de la micro fait qu'il y a des puces jusque dans la
machine à laver et que personne ne s'insurge contre ce fait.
Au contraire. L'époque des machines en millions de francs ou de dollars
n'est plus et la sous utilisation d'un micro n'est plus un sujet
émoustillant. Les moniteurs hard ou soft, qui analysaient l'utilisation et
l'optimisation de "l'Ordinateur" autour duquel tournait tout un monde, sont
désormais inutiles.
Il ne faut pas chercher à comparer les puissances respectives des machines
de l'époque et du plus simple PC d'aujourd'hui car ce n'est plus du même
monde et ils n'ont plus les mêmes objectifs.
Restons en là.
Cordialement
Yves

Thierry

02/05/2006 à 09:54

"Arnaud Debaene" wrote in
news:445304f5$0$21254$:

Quoi, "using" à la place de RAII? C'est vraiement la solution du
pauvre...

C'est mieux que de devoir appeller explicitement un dispose, appel que l'on
va soit oublier de faire, soit le placer au mauvaise endroit (avant des
appel a l'objet, par exemple).

C'est C++/CLI qui propose une vraie notion de RAII dans un

langage .NET, grâce au "stack semantic". Grosso-modo, ca s'écrit comme
çà :

ref class RessourceHolder : public IDisposable

L'avantage est que toutes les instances seront RAII par défaut.

--
Cherche boulot informaticien sur Toulouse, Nantes et Bordeaux de
préférence.
CV par retour de courrier. (gros systèmes s'abstenir)

Thierry

02/05/2006 à 12:05

"Arnold McDonald (AMcD)" wrote in
news:44552bf1$0$2650$:

Moi, pour certains cas particuliers, j'aime bien coder en ASM l'API
WIN32. Le gain principal se situe au niveau de la taille des
exécutables et du contrôle du déroulement de ton application. Le gain
en taille peut atteindre 60, 70 ou 80 %. Le contrôle du déroulement,
c'est bypasser 350 layer de check de pile et autres stupidités qui
rendent ton code indebuggable sans aspirine et l'analyse post-mortem
imbuvable.

C'est le compilo C qu'il faut mettre en cause pour ces points, pas le
language en lui même.

--
Cherche boulot informaticien sur Toulouse, Nantes et Bordeaux de préférence.
CV par retour de courrier. (gros systèmes s'abstenir)

Aurelien Regat-Barrel

03/05/2006 à 10:00

Thierry a écrit :

Quoi, "using" à la place de RAII? C'est vraiement la solution du
pauvre...

C'est mieux que de devoir appeller explicitement un dispose, appel que l'on
va soit oublier de faire, soit le placer au mauvaise endroit (avant des
appel a l'objet, par exemple).

Petit papier sur le sujet:
http://blogs.msdn.com/hsutter/archive/2004/07/31/203137.aspx
et un autre:
http://pluralsight.com/blogs/hsutter/archive/2004/11/23/3666.aspx

Pour aller dans le sens de ce dernier, du temps où j'avais fait du C#
(1.0), j'avais eu affaire à une lib qui usait et abusait du using. Ben
c'est pas super lisible :/

--
Aurélien Regat-Barrel

Gestion mémoire et new CWnd

10 réponses

Veuillez sélectionner un problème