Je viens de tomber sur un message de Michel, d'il y a un mois, dont
voici un extrait :
> From: "Michel Michaud" <mm@gdzid.com>
> Subject: Re: buffer et std::vector<char> passage de l'un a l'autre
> Message-ID: <pQnHa.816$5d.225371@news20.bellglobal.com>
> Date: Mon, 16 Jun 2003 14:16:52 -0400
> Avec
> vector<char> v(taille);
> &v[0] est un char* qui peut être passé aux fonctions attendant un
> char[]/char*. La norme ne dit pas explicitement que les char sont
> contigus, mais c'est un fait et il y a une correction à la norme qui
> l'indique aussi.
J'avais toujours entendu dire que la contigüités des éléments d'un
vecteur était garantie. Apparemment non. Pour ce qui est de la
correction à la norme, je suppose que tu parlais d'un DR. En as-tu la
référence, stp ?
| > | calviniste. Il faut interdire ce qui est Mal (par exemple, modifier | > | l'indice d'une boucle for dans le corps de la boucle). | > Que dire d'Ada? | Ada a puisé ses bases dans Pascal, il me semble. Ce ne serait pas | étonnant d'y voir des similitudes. qu'en est-il de la culture pramatique alors ?
Quelle culture pragmatique ? Si je ne m'abuse, Ada a été développé par une équipe française pour répondre à un appel d'offre du DoD.
Je trouve que les fondements de Pascal ou d'Ada sont tout aussi pragmatiques.
Ah. Moi j'ai l'impression qu'ils sont plus partis de principes que de pragmatisme. Mais bon.
Arnaud
Gabriel Dos Reis wrote:
| > | calviniste. Il faut interdire ce qui est Mal (par exemple, modifier
| > | l'indice d'une boucle for dans le corps de la boucle).
| > Que dire d'Ada?
| Ada a puisé ses bases dans Pascal, il me semble. Ce ne serait pas
| étonnant d'y voir des similitudes.
qu'en est-il de la culture pramatique alors ?
Quelle culture pragmatique ? Si je ne m'abuse, Ada a été développé par
une équipe française pour répondre à un appel d'offre du DoD.
Je trouve que les fondements de Pascal ou d'Ada sont tout aussi
pragmatiques.
Ah. Moi j'ai l'impression qu'ils sont plus partis de principes que de
pragmatisme. Mais bon.
| > | calviniste. Il faut interdire ce qui est Mal (par exemple, modifier | > | l'indice d'une boucle for dans le corps de la boucle). | > Que dire d'Ada? | Ada a puisé ses bases dans Pascal, il me semble. Ce ne serait pas | étonnant d'y voir des similitudes. qu'en est-il de la culture pramatique alors ?
Quelle culture pragmatique ? Si je ne m'abuse, Ada a été développé par une équipe française pour répondre à un appel d'offre du DoD.
Je trouve que les fondements de Pascal ou d'Ada sont tout aussi pragmatiques.
Ah. Moi j'ai l'impression qu'ils sont plus partis de principes que de pragmatisme. Mais bon.
Arnaud
Arnaud Meurgues
Gabriel Dos Reis wrote:
| > Comme dirait Steve Clamage, C++ te protège de Murphy, pas de Machiavel. | :-D J'aime beaucoup. | Mais j'ai un doute sur le réalisme de cette déclaration. en quel sens ?
En ce sens que C++ a parfois des comportement machiavéliques. J'entends par là des comportement éloignés de ceux attendus.
| Dans le cas | cité par Jean-Marc, par exemple, sur les passage de paramètres avec | des auto_ptr, j'y vois du machiavelisme de C++ et non une protection | contre Murphy... explique un peu plus.
l'utilisation de void f(auto_ptr<T> p1, auto_ptr<T> p2); par f(new T, new T); peut provoquer un memory leak si une exception est lancée par un le constructeur de T. Faire une fonction de ce genre ne me semble pas être une utilisation « machiavélique » de C++ (contrairement à un reinterpret_cast, par exemple). Pourtant, cela pose un problème qui ne saute pas aux yeux immédiatement. Le problème me semble plus tenir de Murphy (c'est la coïncidence de l'ordre aléatoire de l'évaluation des paramètre et d'une exception lancée par un constructeur qui crée le problème) que de Machiavel.
En ce qui concerne la phrase BS, il suffit de lire D&E ;-)
Vi... :) J'ai compris le message. Quand je l'ai lu, je l'avais emprunté à une bibliothèque. Je vais finir par l'acheter...
Arnaud
Gabriel Dos Reis wrote:
| > Comme dirait Steve Clamage, C++ te protège de Murphy, pas de Machiavel.
| :-D J'aime beaucoup.
| Mais j'ai un doute sur le réalisme de cette déclaration.
en quel sens ?
En ce sens que C++ a parfois des comportement machiavéliques. J'entends
par là des comportement éloignés de ceux attendus.
| Dans le cas
| cité par Jean-Marc, par exemple, sur les passage de paramètres avec
| des auto_ptr, j'y vois du machiavelisme de C++ et non une protection
| contre Murphy...
explique un peu plus.
l'utilisation de
void f(auto_ptr<T> p1, auto_ptr<T> p2);
par
f(new T, new T);
peut provoquer un memory leak si une exception est lancée par un le
constructeur de T.
Faire une fonction de ce genre ne me semble pas être une utilisation «
machiavélique » de C++ (contrairement à un reinterpret_cast, par
exemple). Pourtant, cela pose un problème qui ne saute pas aux yeux
immédiatement.
Le problème me semble plus tenir de Murphy (c'est la coïncidence de
l'ordre aléatoire de l'évaluation des paramètre et d'une exception
lancée par un constructeur qui crée le problème) que de Machiavel.
| > Comme dirait Steve Clamage, C++ te protège de Murphy, pas de Machiavel. | :-D J'aime beaucoup. | Mais j'ai un doute sur le réalisme de cette déclaration. en quel sens ?
En ce sens que C++ a parfois des comportement machiavéliques. J'entends par là des comportement éloignés de ceux attendus.
| Dans le cas | cité par Jean-Marc, par exemple, sur les passage de paramètres avec | des auto_ptr, j'y vois du machiavelisme de C++ et non une protection | contre Murphy... explique un peu plus.
l'utilisation de void f(auto_ptr<T> p1, auto_ptr<T> p2); par f(new T, new T); peut provoquer un memory leak si une exception est lancée par un le constructeur de T. Faire une fonction de ce genre ne me semble pas être une utilisation « machiavélique » de C++ (contrairement à un reinterpret_cast, par exemple). Pourtant, cela pose un problème qui ne saute pas aux yeux immédiatement. Le problème me semble plus tenir de Murphy (c'est la coïncidence de l'ordre aléatoire de l'évaluation des paramètre et d'une exception lancée par un constructeur qui crée le problème) que de Machiavel.
En ce qui concerne la phrase BS, il suffit de lire D&E ;-)
Vi... :) J'ai compris le message. Quand je l'ai lu, je l'avais emprunté à une bibliothèque. Je vais finir par l'acheter...
Arnaud
Gabriel Dos Reis
Arnaud Meurgues writes:
| Gabriel Dos Reis wrote: | | > | > | calviniste. Il faut interdire ce qui est Mal (par exemple, modifier | > | > | l'indice d'une boucle for dans le corps de la boucle). | > | > Que dire d'Ada? | > | Ada a puisé ses bases dans Pascal, il me semble. Ce ne serait pas | > | étonnant d'y voir des similitudes. | > qu'en est-il de la culture pramatique alors ? | | Quelle culture pragmatique ?
celle qui a conduit au lancement du projet et à son adoption.
| Si je ne m'abuse, Ada a été développé par | une équipe française pour répondre à un appel d'offre du DoD.
et le projet a été jugé acceptable par ceux qui ont lancé l'appel d'offre, qui n'est pas vraiment un sujet d'expression libre.
http://www.cs.fit.edu/~ryan/ada/ada-hist.html
| > Je trouve que les fondements de Pascal ou d'Ada sont tout aussi | > pragmatiques. | | Ah. Moi j'ai l'impression qu'ils sont plus partis de principes que de | pragmatisme. Mais bon.
Je dirais plutôt qu'ils sont partis de considérations tout à fait pragmatiques.
| Gabriel Dos Reis wrote:
|
| > | > | calviniste. Il faut interdire ce qui est Mal (par exemple, modifier
| > | > | l'indice d'une boucle for dans le corps de la boucle).
| > | > Que dire d'Ada?
| > | Ada a puisé ses bases dans Pascal, il me semble. Ce ne serait pas
| > | étonnant d'y voir des similitudes.
| > qu'en est-il de la culture pramatique alors ?
|
| Quelle culture pragmatique ?
celle qui a conduit au lancement du projet et à son adoption.
| Si je ne m'abuse, Ada a été développé par
| une équipe française pour répondre à un appel d'offre du DoD.
et le projet a été jugé acceptable par ceux qui ont lancé l'appel
d'offre, qui n'est pas vraiment un sujet d'expression libre.
http://www.cs.fit.edu/~ryan/ada/ada-hist.html
| > Je trouve que les fondements de Pascal ou d'Ada sont tout aussi
| > pragmatiques.
|
| Ah. Moi j'ai l'impression qu'ils sont plus partis de principes que de
| pragmatisme. Mais bon.
Je dirais plutôt qu'ils sont partis de considérations tout à fait
pragmatiques.
| Gabriel Dos Reis wrote: | | > | > | calviniste. Il faut interdire ce qui est Mal (par exemple, modifier | > | > | l'indice d'une boucle for dans le corps de la boucle). | > | > Que dire d'Ada? | > | Ada a puisé ses bases dans Pascal, il me semble. Ce ne serait pas | > | étonnant d'y voir des similitudes. | > qu'en est-il de la culture pramatique alors ? | | Quelle culture pragmatique ?
celle qui a conduit au lancement du projet et à son adoption.
| Si je ne m'abuse, Ada a été développé par | une équipe française pour répondre à un appel d'offre du DoD.
et le projet a été jugé acceptable par ceux qui ont lancé l'appel d'offre, qui n'est pas vraiment un sujet d'expression libre.
http://www.cs.fit.edu/~ryan/ada/ada-hist.html
| > Je trouve que les fondements de Pascal ou d'Ada sont tout aussi | > pragmatiques. | | Ah. Moi j'ai l'impression qu'ils sont plus partis de principes que de | pragmatisme. Mais bon.
Je dirais plutôt qu'ils sont partis de considérations tout à fait pragmatiques.
Arnaud Meurgues
Gabriel Dos Reis wrote:
| > | > | calviniste. Il faut interdire ce qui est Mal (par exemple, modifier | > | > | l'indice d'une boucle for dans le corps de la boucle). | > | > Que dire d'Ada? | > | Ada a puisé ses bases dans Pascal, il me semble. Ce ne serait pas | > | étonnant d'y voir des similitudes. | > qu'en est-il de la culture pramatique alors ? | Quelle culture pragmatique ? celle qui a conduit au lancement du projet et à son adoption.
Ah. Hé bien, curieusement, elle n'a pas créé le langage.
| > Je trouve que les fondements de Pascal ou d'Ada sont tout aussi | > pragmatiques. | | Ah. Moi j'ai l'impression qu'ils sont plus partis de principes que de | pragmatisme. Mais bon. Je dirais plutôt qu'ils sont partis de considérations tout à fait pragmatiques.
Les commanditaires, oui. Les concepteurs, moins.
Arnaud
Gabriel Dos Reis wrote:
| > | > | calviniste. Il faut interdire ce qui est Mal (par exemple, modifier
| > | > | l'indice d'une boucle for dans le corps de la boucle).
| > | > Que dire d'Ada?
| > | Ada a puisé ses bases dans Pascal, il me semble. Ce ne serait pas
| > | étonnant d'y voir des similitudes.
| > qu'en est-il de la culture pramatique alors ?
| Quelle culture pragmatique ?
celle qui a conduit au lancement du projet et à son adoption.
Ah. Hé bien, curieusement, elle n'a pas créé le langage.
| > Je trouve que les fondements de Pascal ou d'Ada sont tout aussi
| > pragmatiques.
|
| Ah. Moi j'ai l'impression qu'ils sont plus partis de principes que de
| pragmatisme. Mais bon.
Je dirais plutôt qu'ils sont partis de considérations tout à fait
pragmatiques.
| > | > | calviniste. Il faut interdire ce qui est Mal (par exemple, modifier | > | > | l'indice d'une boucle for dans le corps de la boucle). | > | > Que dire d'Ada? | > | Ada a puisé ses bases dans Pascal, il me semble. Ce ne serait pas | > | étonnant d'y voir des similitudes. | > qu'en est-il de la culture pramatique alors ? | Quelle culture pragmatique ? celle qui a conduit au lancement du projet et à son adoption.
Ah. Hé bien, curieusement, elle n'a pas créé le langage.
| > Je trouve que les fondements de Pascal ou d'Ada sont tout aussi | > pragmatiques. | | Ah. Moi j'ai l'impression qu'ils sont plus partis de principes que de | pragmatisme. Mais bon. Je dirais plutôt qu'ils sont partis de considérations tout à fait pragmatiques.
Les commanditaires, oui. Les concepteurs, moins.
Arnaud
Gabriel Dos Reis
Arnaud Meurgues writes:
| Gabriel Dos Reis wrote: | | > | > | > | calviniste. Il faut interdire ce qui est Mal (par exemple, modifier | > | > | > | l'indice d'une boucle for dans le corps de la boucle). | > | > | > Que dire d'Ada? | > | > | Ada a puisé ses bases dans Pascal, il me semble. Ce ne serait pas | > | > | étonnant d'y voir des similitudes. | > | > qu'en est-il de la culture pramatique alors ? | > | Quelle culture pragmatique ? celle qui a conduit au lancement du | > projet et à son adoption. | | Ah. Hé bien, curieusement, elle n'a pas créé le langage. | | > | > Je trouve que les fondements de Pascal ou d'Ada sont tout aussi | > | > pragmatiques. | > | | Ah. Moi j'ai l'impression qu'ils sont plus partis de principes | > que de | > | pragmatisme. Mais bon. | > Je dirais plutôt qu'ils sont partis de considérations tout à fait | > pragmatiques. | | Les commanditaires, oui. Les concepteurs, moins.
et le produit final devait remplir un certain cahier de charge mis en place par les commanditaires et ils pouvaient rejeter le produit si cela ne leur convenaint pas.
| Gabriel Dos Reis wrote:
|
| > | > | > | calviniste. Il faut interdire ce qui est Mal (par exemple, modifier
| > | > | > | l'indice d'une boucle for dans le corps de la boucle).
| > | > | > Que dire d'Ada?
| > | > | Ada a puisé ses bases dans Pascal, il me semble. Ce ne serait pas
| > | > | étonnant d'y voir des similitudes.
| > | > qu'en est-il de la culture pramatique alors ?
| > | Quelle culture pragmatique ? celle qui a conduit au lancement du
| > projet et à son adoption.
|
| Ah. Hé bien, curieusement, elle n'a pas créé le langage.
|
| > | > Je trouve que les fondements de Pascal ou d'Ada sont tout aussi
| > | > pragmatiques.
| > | | Ah. Moi j'ai l'impression qu'ils sont plus partis de principes
| > que de
| > | pragmatisme. Mais bon.
| > Je dirais plutôt qu'ils sont partis de considérations tout à fait
| > pragmatiques.
|
| Les commanditaires, oui. Les concepteurs, moins.
et le produit final devait remplir un certain cahier de charge mis en
place par les commanditaires et ils pouvaient rejeter le produit si
cela ne leur convenaint pas.
| Gabriel Dos Reis wrote: | | > | > | > | calviniste. Il faut interdire ce qui est Mal (par exemple, modifier | > | > | > | l'indice d'une boucle for dans le corps de la boucle). | > | > | > Que dire d'Ada? | > | > | Ada a puisé ses bases dans Pascal, il me semble. Ce ne serait pas | > | > | étonnant d'y voir des similitudes. | > | > qu'en est-il de la culture pramatique alors ? | > | Quelle culture pragmatique ? celle qui a conduit au lancement du | > projet et à son adoption. | | Ah. Hé bien, curieusement, elle n'a pas créé le langage. | | > | > Je trouve que les fondements de Pascal ou d'Ada sont tout aussi | > | > pragmatiques. | > | | Ah. Moi j'ai l'impression qu'ils sont plus partis de principes | > que de | > | pragmatisme. Mais bon. | > Je dirais plutôt qu'ils sont partis de considérations tout à fait | > pragmatiques. | | Les commanditaires, oui. Les concepteurs, moins.
et le produit final devait remplir un certain cahier de charge mis en place par les commanditaires et ils pouvaient rejeter le produit si cela ne leur convenaint pas.
-- Gaby
Alain Naigeon
"Gabriel Dos Reis" a écrit dans le message news:
| Concernant le point abordé, on s'est mal compris ; mon passage | en question regrettait la persistance de tournures de "bas niveau", | héritées de C, permettant de faire tout et n'importe quoi.
telles que ?
Il y a tant d'exemples : en fin de fonction je peux, mais je ne dois pas, retourner un pointeur sur une variable de pile, qui n'existe plus ; je peux, mais je ne dois pas, détruire deux fois le même objet, ou détruire un objet que je n'ai pas alloué ; etc, etc...
| L'argument consistant à dire qu'il suffit de ne pas s'en servir ne me | va pas du tout, il permet de justifier aussi l'usage de données | publiques, tant qu'on y est, puisqu'il suffit de ne pas les modifier à | mauvais escient...
Je ne crois pas que ce soit de le rôle de C++ de forcer les gens à aller dans Une Seule Direction. S'il n'y a rien à protéger, je ne vois pas pourquoi la donnée membre devrait être no-publique. I.e. pourquoi std::<> ne devrait pas avoir ses données membres publiques ?
Peut-être parce qu'on ne sait pas faire autrement sans alourdir énormément le code, ou son usage ? Peut-être aussi que ma répulsion pour les données publiques m'a été inspirée par trop de lectures de gens célèbres.
Comme dirait Steve Clamage, C++ te protège de Murphy, pas de Machiavel.
Les cas que je cite au début sont hélas très fréquents, ils représentent un gros pourcentage d'erreurs en pratique. La question sous-jacente, l'alternative au repris de justice, c'est : est-ce qu'un langage qui fait en permanence appel à l'expertise, la concentration et la bonne foi de l'usager est un langage sûr ? Ou, peut-être même cette question : est-ce que la sûreté est la première qualité attendue par les adeptes de C++ ? J'ai de plus en plus de doutes à ce sujet. En ce sens que, lorsque cette sûreté est mise en balance avec autre chose dans une décision à prendre, elle semble rarement considérée comme prioritaire, en regard du pragmatisme, de la compatibilité, etc.
--
Français *==> "Musique renaissance" <==* English midi - facsimiles - ligatures - mensuration http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/ Alain Naigeon - - Strasbourg, France
"Gabriel Dos Reis" <gdr@integrable-solutions.net> a écrit dans le message
news: m3d6g9k5ad.fsf@uniton.integrable-solutions.net...
| Concernant le point abordé, on s'est mal compris ; mon passage
| en question regrettait la persistance de tournures de "bas niveau",
| héritées de C, permettant de faire tout et n'importe quoi.
telles que ?
Il y a tant d'exemples : en fin de fonction je peux, mais je ne dois pas,
retourner un pointeur sur une variable de pile, qui n'existe plus ; je peux,
mais je ne dois pas, détruire deux fois le même objet, ou détruire un
objet que je n'ai pas alloué ; etc, etc...
| L'argument consistant à dire qu'il suffit de ne pas s'en servir ne me
| va pas du tout, il permet de justifier aussi l'usage de données
| publiques, tant qu'on y est, puisqu'il suffit de ne pas les modifier à
| mauvais escient...
Je ne crois pas que ce soit de le rôle de C++ de forcer les gens à
aller dans Une Seule Direction. S'il n'y a rien à protéger, je ne vois
pas pourquoi la donnée membre devrait être no-publique. I.e. pourquoi
std::<> ne devrait pas avoir ses données membres publiques ?
Peut-être parce qu'on ne sait pas faire autrement sans alourdir
énormément le code, ou son usage ?
Peut-être aussi que ma répulsion pour les données publiques
m'a été inspirée par trop de lectures de gens célèbres.
Comme dirait Steve Clamage, C++ te protège de Murphy, pas de Machiavel.
Les cas que je cite au début sont hélas très fréquents, ils représentent
un gros pourcentage d'erreurs en pratique. La question sous-jacente,
l'alternative au repris de justice, c'est : est-ce qu'un langage qui fait
en permanence appel à l'expertise, la concentration et la bonne foi
de l'usager est un langage sûr ? Ou, peut-être même cette question :
est-ce que la sûreté est la première qualité attendue par les adeptes
de C++ ? J'ai de plus en plus de doutes à ce sujet. En ce sens que,
lorsque cette sûreté est mise en balance avec autre chose dans une
décision à prendre, elle semble rarement considérée comme prioritaire,
en regard du pragmatisme, de la compatibilité, etc.
--
Français *==> "Musique renaissance" <==* English
midi - facsimiles - ligatures - mensuration
http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/
Alain Naigeon - anaigeon@free.fr - Strasbourg, France
| Concernant le point abordé, on s'est mal compris ; mon passage | en question regrettait la persistance de tournures de "bas niveau", | héritées de C, permettant de faire tout et n'importe quoi.
telles que ?
Il y a tant d'exemples : en fin de fonction je peux, mais je ne dois pas, retourner un pointeur sur une variable de pile, qui n'existe plus ; je peux, mais je ne dois pas, détruire deux fois le même objet, ou détruire un objet que je n'ai pas alloué ; etc, etc...
| L'argument consistant à dire qu'il suffit de ne pas s'en servir ne me | va pas du tout, il permet de justifier aussi l'usage de données | publiques, tant qu'on y est, puisqu'il suffit de ne pas les modifier à | mauvais escient...
Je ne crois pas que ce soit de le rôle de C++ de forcer les gens à aller dans Une Seule Direction. S'il n'y a rien à protéger, je ne vois pas pourquoi la donnée membre devrait être no-publique. I.e. pourquoi std::<> ne devrait pas avoir ses données membres publiques ?
Peut-être parce qu'on ne sait pas faire autrement sans alourdir énormément le code, ou son usage ? Peut-être aussi que ma répulsion pour les données publiques m'a été inspirée par trop de lectures de gens célèbres.
Comme dirait Steve Clamage, C++ te protège de Murphy, pas de Machiavel.
Les cas que je cite au début sont hélas très fréquents, ils représentent un gros pourcentage d'erreurs en pratique. La question sous-jacente, l'alternative au repris de justice, c'est : est-ce qu'un langage qui fait en permanence appel à l'expertise, la concentration et la bonne foi de l'usager est un langage sûr ? Ou, peut-être même cette question : est-ce que la sûreté est la première qualité attendue par les adeptes de C++ ? J'ai de plus en plus de doutes à ce sujet. En ce sens que, lorsque cette sûreté est mise en balance avec autre chose dans une décision à prendre, elle semble rarement considérée comme prioritaire, en regard du pragmatisme, de la compatibilité, etc.
--
Français *==> "Musique renaissance" <==* English midi - facsimiles - ligatures - mensuration http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/ Alain Naigeon - - Strasbourg, France
Arnaud Meurgues
Gabriel Dos Reis wrote:
Dans ce cas précis, c'est auto_ptr<> que je trouve machiavélique.
La bibliothèque, donc.
Tu sais comment marche auto_ptr ?
Je crois, oui.
Ce qui le fait marcher ?
Heu... Je ne comprends pas trop la question. Je ne vois pas trop en quoi elle diffère de la précédente.
je crois que ce serait un bon investissement ;-) -- non, je n'ai pas d'action chez AW.
Certes. Il faut après trouver le temps de le (re)lire. En ce moment, mes lectures ne sont pas vraiment informatiques...
Mais il est vrai que je gagnerais sans doute beaucoup plus à le lire maintenant que lorsque je l'ai lu la première fois.
Arnaud
Gabriel Dos Reis wrote:
Dans ce cas précis, c'est auto_ptr<> que je trouve machiavélique.
La bibliothèque, donc.
Tu sais comment marche auto_ptr ?
Je crois, oui.
Ce qui le fait marcher ?
Heu... Je ne comprends pas trop la question. Je ne vois pas trop en quoi
elle diffère de la précédente.
je crois que ce serait un bon investissement ;-) -- non, je n'ai pas
d'action chez AW.
Certes. Il faut après trouver le temps de le (re)lire. En ce moment, mes
lectures ne sont pas vraiment informatiques...
Mais il est vrai que je gagnerais sans doute beaucoup plus à le lire
maintenant que lorsque je l'ai lu la première fois.
Dans ce cas précis, c'est auto_ptr<> que je trouve machiavélique.
La bibliothèque, donc.
Tu sais comment marche auto_ptr ?
Je crois, oui.
Ce qui le fait marcher ?
Heu... Je ne comprends pas trop la question. Je ne vois pas trop en quoi elle diffère de la précédente.
je crois que ce serait un bon investissement ;-) -- non, je n'ai pas d'action chez AW.
Certes. Il faut après trouver le temps de le (re)lire. En ce moment, mes lectures ne sont pas vraiment informatiques...
Mais il est vrai que je gagnerais sans doute beaucoup plus à le lire maintenant que lorsque je l'ai lu la première fois.
Arnaud
Jean-Marc Bourguet
"Alain Naigeon" writes:
Donc, le choix d'un langage s'effectue, en principe, sur des bases rationnelles.
La rationalite du choix c'est generalement, on continue dans la voie deja choisie parce qu'on ne commence jamais un projet a zero.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
"Alain Naigeon" <anaigeon@free.fr> writes:
Donc, le choix d'un langage s'effectue, en principe, sur des bases
rationnelles.
La rationalite du choix c'est generalement, on continue dans la voie
deja choisie parce qu'on ne commence jamais un projet a zero.
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Donc, le choix d'un langage s'effectue, en principe, sur des bases rationnelles.
La rationalite du choix c'est generalement, on continue dans la voie deja choisie parce qu'on ne commence jamais un projet a zero.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Jean-Marc Bourguet
Arnaud Meurgues writes:
Tu sais comment marche auto_ptr ?
Je crois, oui.
Tu peux m'expliquer comment ca ce fait qu'on peut retourner un auto_ptr comme resultat d'une fonction?
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Tu peux m'expliquer comment ca ce fait qu'on peut retourner un
auto_ptr comme resultat d'une fonction?
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Tu peux m'expliquer comment ca ce fait qu'on peut retourner un auto_ptr comme resultat d'une fonction?
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Alain Naigeon
"Gabriel Dos Reis" a écrit dans le message news:
Qu'est-ce que tu reproches à C++ dans ce cas-ci ? Qu'un type intervalle ne soit pas codé directement dans el langage ou qu'il te donne les moyens d'en définir un si tu en avais besoin ?
Soit une ligne et un colonne dans un programme d'échecs, toutes deux comprises entre 1 et 8. Oui, je peux définir une classe coordonnée, en faire dériver deux autres pour ligne et colonne, contrôler les valeurs construites ou assignées pour les restreindre à 1..8, etc ; après cela, effectivement, si par malheur je passe en argument d'une fonction un objet ligne à la place d'une colonne, j'ai un diagnostic puisque la classe fille ne correspond pas à celle attendue. Par contre, le test sur les bornes ne sera fait qu'à l'exécution, pas à la compilation, c'est déjà un petit "moins".
En Pascal je définissais deux types intervalle, différents bien que prenant leurs valeurs sur le même sous-ensemble des entiers, de sorte que toutes les erreurs possibles étaient diagnostiquées dès la compilation. Et je n'avais aucun boulot à faire en amont. (notons bien qu'un diagnostic syntaxique (eh oui !) a l'avantage que je n'ai pas à me torturer l'esprit pour savoir quoi faire en cas de mauvaise valeur passée : ne rien faire, et ne pas le signaler ? ne rien faire, mais en passant une valeur de retour permettant de détecter le problème ? lancer une exception ? pas toujours facile de trouver la bonne solution ; et si un jour je passe à des classes templates, ce sera encore pire, car la bonne façon de traiter l'erreur peut être différente selon le contexte d'utilisation...)
Bien sûr c'est l'éternel débat entre le "tout fait" et la boîte à outils puissante. J'imagine qu'il a eu lieu, par exemple, au moment d'introduire "bool" en C++, alors, chacun met la limite où il veut, question... de goût, là encore.
Il se peut qu'il y ait une façon de faire plus concise en C++, que celle suggérée ci-dessus, qui m'échapperait. De plus, il est clair qu'on ne juge pas un langage sur un seul petit point particulier. Enfin, il est clair que le débat est faussé, et n'a plus d'intérêt concret, vu que Pascal n'a pas évolué. Mais ce n'est pas juste, à mes yeux, de dire qu'il n'y *rien* à regretter de sa disparition.
Quant au caractère verbeux de Pascal, souvent moqué, il devrait maintenant être apprécié à la lumière de : - une remarque de Stroustrup lui-même admettant que C++ fait un usage immodéré des parenthèses ; - et, paradoxalement, de ce qu'est devenue la STL ;-) D'ailleurs, j'ai souvent entendu des Cistes exprimer leur dégoût devant le caractère "verbeux" de C++. Chaque génération a ses propres blocages, différents des précédents, mais ce sont toujours les mêmes arguments qui reviennent pour les "justifier", ce qui prouve leur absence de contenu rigoureux.
--
Français *==> "Musique renaissance" <==* English midi - facsimiles - ligatures - mensuration http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/ Alain Naigeon - - Strasbourg, France
"Gabriel Dos Reis" <gdr@integrable-solutions.net> a écrit dans le message
news: m3isq1k5jf.fsf@uniton.integrable-solutions.net...
Qu'est-ce que tu reproches à C++ dans ce cas-ci ? Qu'un type intervalle
ne soit pas codé directement dans el langage ou qu'il te donne les
moyens d'en définir un si tu en avais besoin ?
Soit une ligne et un colonne dans un programme d'échecs,
toutes deux comprises entre 1 et 8. Oui, je peux définir une
classe coordonnée, en faire dériver deux autres pour ligne
et colonne, contrôler les valeurs construites ou assignées
pour les restreindre à 1..8, etc ; après cela, effectivement,
si par malheur je passe en argument d'une fonction un
objet ligne à la place d'une colonne, j'ai un diagnostic
puisque la classe fille ne correspond pas à celle attendue.
Par contre, le test sur les bornes ne sera fait qu'à l'exécution,
pas à la compilation, c'est déjà un petit "moins".
En Pascal je définissais deux types intervalle, différents bien
que prenant leurs valeurs sur le même sous-ensemble des
entiers, de sorte que toutes les erreurs possibles étaient
diagnostiquées dès la compilation. Et je n'avais aucun boulot
à faire en amont.
(notons bien qu'un diagnostic syntaxique (eh oui !) a l'avantage
que je n'ai pas à me torturer l'esprit pour savoir quoi faire
en cas de mauvaise valeur passée : ne rien faire, et ne pas
le signaler ? ne rien faire, mais en passant une valeur de
retour permettant de détecter le problème ? lancer une
exception ? pas toujours facile de trouver la bonne solution ;
et si un jour je passe à des classes templates, ce sera encore
pire, car la bonne façon de traiter l'erreur peut être différente
selon le contexte d'utilisation...)
Bien sûr c'est l'éternel débat entre le "tout fait" et la boîte
à outils puissante. J'imagine qu'il a eu lieu, par exemple,
au moment d'introduire "bool" en C++, alors, chacun met la
limite où il veut, question... de goût, là encore.
Il se peut qu'il y ait une façon de faire plus concise en C++,
que celle suggérée ci-dessus, qui m'échapperait.
De plus, il est clair qu'on ne juge pas un langage sur un seul
petit point particulier.
Enfin, il est clair que le débat est faussé, et n'a plus d'intérêt
concret, vu que Pascal n'a pas évolué. Mais ce n'est pas juste,
à mes yeux, de dire qu'il n'y *rien* à regretter de sa disparition.
Quant au caractère verbeux de Pascal, souvent moqué,
il devrait maintenant être apprécié à la lumière de :
- une remarque de Stroustrup lui-même admettant que
C++ fait un usage immodéré des parenthèses ;
- et, paradoxalement, de ce qu'est devenue la STL ;-)
D'ailleurs, j'ai souvent entendu des Cistes exprimer leur
dégoût devant le caractère "verbeux" de C++.
Chaque génération a ses propres blocages, différents des
précédents, mais ce sont toujours les mêmes arguments qui
reviennent pour les "justifier", ce qui prouve leur absence de
contenu rigoureux.
--
Français *==> "Musique renaissance" <==* English
midi - facsimiles - ligatures - mensuration
http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/
Alain Naigeon - anaigeon@free.fr - Strasbourg, France
Qu'est-ce que tu reproches à C++ dans ce cas-ci ? Qu'un type intervalle ne soit pas codé directement dans el langage ou qu'il te donne les moyens d'en définir un si tu en avais besoin ?
Soit une ligne et un colonne dans un programme d'échecs, toutes deux comprises entre 1 et 8. Oui, je peux définir une classe coordonnée, en faire dériver deux autres pour ligne et colonne, contrôler les valeurs construites ou assignées pour les restreindre à 1..8, etc ; après cela, effectivement, si par malheur je passe en argument d'une fonction un objet ligne à la place d'une colonne, j'ai un diagnostic puisque la classe fille ne correspond pas à celle attendue. Par contre, le test sur les bornes ne sera fait qu'à l'exécution, pas à la compilation, c'est déjà un petit "moins".
En Pascal je définissais deux types intervalle, différents bien que prenant leurs valeurs sur le même sous-ensemble des entiers, de sorte que toutes les erreurs possibles étaient diagnostiquées dès la compilation. Et je n'avais aucun boulot à faire en amont. (notons bien qu'un diagnostic syntaxique (eh oui !) a l'avantage que je n'ai pas à me torturer l'esprit pour savoir quoi faire en cas de mauvaise valeur passée : ne rien faire, et ne pas le signaler ? ne rien faire, mais en passant une valeur de retour permettant de détecter le problème ? lancer une exception ? pas toujours facile de trouver la bonne solution ; et si un jour je passe à des classes templates, ce sera encore pire, car la bonne façon de traiter l'erreur peut être différente selon le contexte d'utilisation...)
Bien sûr c'est l'éternel débat entre le "tout fait" et la boîte à outils puissante. J'imagine qu'il a eu lieu, par exemple, au moment d'introduire "bool" en C++, alors, chacun met la limite où il veut, question... de goût, là encore.
Il se peut qu'il y ait une façon de faire plus concise en C++, que celle suggérée ci-dessus, qui m'échapperait. De plus, il est clair qu'on ne juge pas un langage sur un seul petit point particulier. Enfin, il est clair que le débat est faussé, et n'a plus d'intérêt concret, vu que Pascal n'a pas évolué. Mais ce n'est pas juste, à mes yeux, de dire qu'il n'y *rien* à regretter de sa disparition.
Quant au caractère verbeux de Pascal, souvent moqué, il devrait maintenant être apprécié à la lumière de : - une remarque de Stroustrup lui-même admettant que C++ fait un usage immodéré des parenthèses ; - et, paradoxalement, de ce qu'est devenue la STL ;-) D'ailleurs, j'ai souvent entendu des Cistes exprimer leur dégoût devant le caractère "verbeux" de C++. Chaque génération a ses propres blocages, différents des précédents, mais ce sont toujours les mêmes arguments qui reviennent pour les "justifier", ce qui prouve leur absence de contenu rigoureux.
--
Français *==> "Musique renaissance" <==* English midi - facsimiles - ligatures - mensuration http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/ Alain Naigeon - - Strasbourg, France
