Contigüité des éléments d'un `std::vector´

Gabriel Dos Reis

17/07/2003 à 14:40

"Alain Naigeon" writes:

| "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.

Peux-tu poster un concret sur lequel on peut baser la suite de la
discussion ?

[...]

| 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.

En réalité, ma question portait sur ce que tu reprochais au *C++*,
comme je l'ai soulignée.

| Quant au caractère verbeux de Pascal, souvent moqué,

encore une fois, la question ne porte pas sur Pascal.

| 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 ;

que les parenthèses soient abusées en C (puis en C++) n'a jamais fait
l'objet d'un mystère. C'est ce que tu reproches à C++ ?

| - 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++.

je trouve C++ à la fois verbeux et concis.

| 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.

Je présume que cela s'applique aussi à ta réponse ci-dessus ;-)

-- Gaby

"Alain Naigeon" <anaigeon@free.fr> writes:

| "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.

Peux-tu poster un concret sur lequel on peut baser la suite de la
discussion ?

[...]

| 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.

En réalité, ma question portait sur ce que tu reprochais au *C++*,
comme je l'ai soulignée.

| Quant au caractère verbeux de Pascal, souvent moqué,

encore une fois, la question ne porte pas sur Pascal.

| 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 ;

que les parenthèses soient abusées en C (puis en C++) n'a jamais fait
l'objet d'un mystère. C'est ce que tu reproches à C++ ?

| - 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++.

je trouve C++ à la fois verbeux et concis.

| 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.

Je présume que cela s'applique aussi à ta réponse ci-dessus ;-)

-- Gaby

Vous avez filtré cet utilisateur ! Consultez son message

"Alain Naigeon" writes:

| "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.

Peux-tu poster un concret sur lequel on peut baser la suite de la
discussion ?

[...]

| 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.

En réalité, ma question portait sur ce que tu reprochais au *C++*,
comme je l'ai soulignée.

| Quant au caractère verbeux de Pascal, souvent moqué,

encore une fois, la question ne porte pas sur Pascal.

| 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 ;

que les parenthèses soient abusées en C (puis en C++) n'a jamais fait
l'objet d'un mystère. C'est ce que tu reproches à C++ ?

| - 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++.

je trouve C++ à la fois verbeux et concis.

| 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.

Je présume que cela s'applique aussi à ta réponse ci-dessus ;-)

-- Gaby

Alain Naigeon

17/07/2003 à 14:42

"Arnaud Meurgues" a écrit dans le message
news: 3f168416$0$23533$

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.

Apparemment, ce qui vous manque pour tomber d'accord,
c'est une conceptualisation du pragmatisme ;-)

--

Français *==> "Musique renaissance" <==* English
midi - facsimiles - ligatures - mensuration
http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/
Alain Naigeon - - Strasbourg, France

Frederic Py

17/07/2003 à 15:17

Gabriel Dos Reis wrote:

En ce qui concerne ma question, c'est que auto_ptr<> utilise de
manière essentielle une fonctionnalité obscure (détournement devrait
être plus exact) très peu connue du grand public, pour faire croire
que son utilisation n'est pas problématique. Beaucoup de gens pensent
savoir (à juste titre ou non) qu'ils savent comment auto_ptr<>
marche. Mais peu savent ce qui le fait marcher réellement.

D'un seul coup je suis fortement intrigue meme si je n'asi jamais eu la
pretention de dire que ja savais comment fonctionnait exactement les
auto_ptr -- n'ayant pas compulse le code outre mesure -- Je pensait que
ce dernier avait un fonctionnement relativement simple et ne faisant pas
appel a un "detournement" de fonctionnalite ...

Pourriez vous, toi et/ou un autre, expliquer plus precisement de quoi il
en retourne plus precisement ou donner des pointeurs sur ceci ?

--
Frederic Py

Gabriel Dos Reis

17/07/2003 à 15:17

"Alain Naigeon" writes:

| > Le C vient d'une culture beaucoup plus pragmatique.
|
| Je n'aime pas trop ce mot, ou plutôt l'absence de rigueur
| qu'il recouvre souvent.

En fait je n'ai pas pas ce mot lorsqu'il est utilisé lorsqu'il y a
absence manifeste d'arguments solides.

| Qu'est-ce qui empêche de définir en
| C un style de programmation, et des règles très précises pour
| aboutir à quelque chose d'efficace et de raisonnablement sûr ?

Rien, sauf que ce serait contre nature ;-)

[...]

| Le simple refus de privilégier un paradigme n'est pas en soi
| une position claire.

et pourtant cette position a toujours été clair pour C++. Elle fait
même partie explicitement des règles générales qui ont guidé
l'évolution de C++.

| Dans une constitution, il y a un préambule
| qui en définit l'esprit général, et qui guide les gens pour des
| décisions difficiles. J'ai bien peur que certains débats (réticences
| et retard à introduire "bool", par exemple !!) prouvent qu'une telle
| ligne directrice fait cruellement défaut.

Qui te dit qu'il n'y a pas de ligne directrice pour l'évolution de C++ ?

J'ai mentionné à multiples occasions, « The Design and Evolution of
C++ », et je le répète encore : il est essentiel de l'avoir lu
lorsqu'on participe à des débats comme celui-ci.
Bien que le D&E ne soit publié lui-même qu'en 1993-1994, beaucoup des
règles clé étaient déjà énoncées après TC++PL1.

Chapitre 4

C++ Language Design Rules

If the map and the terrain disagree,
trust the terrain.

-- Swiss army aphorism

(la citation est amusante, vu le calvinisme supposé des suisses que
certains évoquent dans cette discussion).

4.1. Rules and Principles

To be genuinely useful and pleasant to work with, a programming
language must be designed according to an overall view that guides
the design of its individual language features. For C++, this
overall view takes the form of a set of rules and constraints. I
call them /rules/ because I find the term /principles/ pretentious
in a field as poor in guenuine scientific principles as programming
language design. Also, to many people the term principle implies
the unrealistic implication that no exceptions are acceptable.
My rules for the design of C++ most certainly have exceptions. In
fact, if a rule and practical experience are in conflict, the rule
gives way. This may sound crude, but it is a variant of the
principle that theory must account for experimental data or be
replaced by a better theory.

[...]

General Rules:
C++ evolution must be driven by real problems.
Don't get involved in a sterile quest for perfection.
C++ must be useful /now/.
Every feature must have a reasonably obvious implementation.
Always provide a transition path.
C++ is a language, nor a complete system.
Provide comprehensive support for each supported style.
Don't try to force people.

[...]

Don't try to force people: Programmers are smart people. [...]
Trying to seriously constrain programmers to do "only what is right"
is inherently wrongheaded and will fail. Programmers will find a
way around rules and restrictions they find unaccpetable. The
language should support a range of reasonable design and programming
styles rather than to force people into adopting a single notion.

[...] and no feature is added or subtracted from C++ exclusively to
prevent a coherent style of programming.

I am well aware that not everyone appreciates choice and variety.
However, people who prefer a more restrictive environment can impose
one through style rules in C++ or choose a language designed to
provide the programmer with a smaller set of alternatives.

La question que j'ai envie de poser est « est-ce que choisir un
langage autre que C++ est un choix restreint ou pas » ;-)

-- Gaby

"Alain Naigeon" <anaigeon@free.fr> writes:

| > Le C vient d'une culture beaucoup plus pragmatique.
|
| Je n'aime pas trop ce mot, ou plutôt l'absence de rigueur
| qu'il recouvre souvent.

En fait je n'ai pas pas ce mot lorsqu'il est utilisé lorsqu'il y a
absence manifeste d'arguments solides.

| Qu'est-ce qui empêche de définir en
| C un style de programmation, et des règles très précises pour
| aboutir à quelque chose d'efficace et de raisonnablement sûr ?

Rien, sauf que ce serait contre nature ;-)

[...]

| Le simple refus de privilégier un paradigme n'est pas en soi
| une position claire.

et pourtant cette position a toujours été clair pour C++. Elle fait
même partie explicitement des règles générales qui ont guidé
l'évolution de C++.

| Dans une constitution, il y a un préambule
| qui en définit l'esprit général, et qui guide les gens pour des
| décisions difficiles. J'ai bien peur que certains débats (réticences
| et retard à introduire "bool", par exemple !!) prouvent qu'une telle
| ligne directrice fait cruellement défaut.

Qui te dit qu'il n'y a pas de ligne directrice pour l'évolution de C++ ?

J'ai mentionné à multiples occasions, « The Design and Evolution of
C++ », et je le répète encore : il est essentiel de l'avoir lu
lorsqu'on participe à des débats comme celui-ci.
Bien que le D&E ne soit publié lui-même qu'en 1993-1994, beaucoup des
règles clé étaient déjà énoncées après TC++PL1.

Chapitre 4

C++ Language Design Rules

If the map and the terrain disagree,
trust the terrain.

-- Swiss army aphorism

(la citation est amusante, vu le calvinisme supposé des suisses que
certains évoquent dans cette discussion).

4.1. Rules and Principles

To be genuinely useful and pleasant to work with, a programming
language must be designed according to an overall view that guides
the design of its individual language features. For C++, this
overall view takes the form of a set of rules and constraints. I
call them /rules/ because I find the term /principles/ pretentious
in a field as poor in guenuine scientific principles as programming
language design. Also, to many people the term principle implies
the unrealistic implication that no exceptions are acceptable.
My rules for the design of C++ most certainly have exceptions. In
fact, if a rule and practical experience are in conflict, the rule
gives way. This may sound crude, but it is a variant of the
principle that theory must account for experimental data or be
replaced by a better theory.

[...]

General Rules:
C++ evolution must be driven by real problems.
Don't get involved in a sterile quest for perfection.
C++ must be useful /now/.
Every feature must have a reasonably obvious implementation.
Always provide a transition path.
C++ is a language, nor a complete system.
Provide comprehensive support for each supported style.
Don't try to force people.

[...]

Don't try to force people: Programmers are smart people. [...]
Trying to seriously constrain programmers to do "only what is right"
is inherently wrongheaded and will fail. Programmers will find a
way around rules and restrictions they find unaccpetable. The
language should support a range of reasonable design and programming
styles rather than to force people into adopting a single notion.

[...] and no feature is added or subtracted from C++ exclusively to
prevent a coherent style of programming.

I am well aware that not everyone appreciates choice and variety.
However, people who prefer a more restrictive environment can impose
one through style rules in C++ or choose a language designed to
provide the programmer with a smaller set of alternatives.

La question que j'ai envie de poser est « est-ce que choisir un
langage autre que C++ est un choix restreint ou pas » ;-)

-- Gaby

Vous avez filtré cet utilisateur ! Consultez son message

"Alain Naigeon" writes:

| > Le C vient d'une culture beaucoup plus pragmatique.
|
| Je n'aime pas trop ce mot, ou plutôt l'absence de rigueur
| qu'il recouvre souvent.

En fait je n'ai pas pas ce mot lorsqu'il est utilisé lorsqu'il y a
absence manifeste d'arguments solides.

| Qu'est-ce qui empêche de définir en
| C un style de programmation, et des règles très précises pour
| aboutir à quelque chose d'efficace et de raisonnablement sûr ?

Rien, sauf que ce serait contre nature ;-)

[...]

| Le simple refus de privilégier un paradigme n'est pas en soi
| une position claire.

et pourtant cette position a toujours été clair pour C++. Elle fait
même partie explicitement des règles générales qui ont guidé
l'évolution de C++.

| Dans une constitution, il y a un préambule
| qui en définit l'esprit général, et qui guide les gens pour des
| décisions difficiles. J'ai bien peur que certains débats (réticences
| et retard à introduire "bool", par exemple !!) prouvent qu'une telle
| ligne directrice fait cruellement défaut.

Qui te dit qu'il n'y a pas de ligne directrice pour l'évolution de C++ ?

J'ai mentionné à multiples occasions, « The Design and Evolution of
C++ », et je le répète encore : il est essentiel de l'avoir lu
lorsqu'on participe à des débats comme celui-ci.
Bien que le D&E ne soit publié lui-même qu'en 1993-1994, beaucoup des
règles clé étaient déjà énoncées après TC++PL1.

Chapitre 4

C++ Language Design Rules

If the map and the terrain disagree,
trust the terrain.

-- Swiss army aphorism

(la citation est amusante, vu le calvinisme supposé des suisses que
certains évoquent dans cette discussion).

4.1. Rules and Principles

To be genuinely useful and pleasant to work with, a programming
language must be designed according to an overall view that guides
the design of its individual language features. For C++, this
overall view takes the form of a set of rules and constraints. I
call them /rules/ because I find the term /principles/ pretentious
in a field as poor in guenuine scientific principles as programming
language design. Also, to many people the term principle implies
the unrealistic implication that no exceptions are acceptable.
My rules for the design of C++ most certainly have exceptions. In
fact, if a rule and practical experience are in conflict, the rule
gives way. This may sound crude, but it is a variant of the
principle that theory must account for experimental data or be
replaced by a better theory.

[...]

General Rules:
C++ evolution must be driven by real problems.
Don't get involved in a sterile quest for perfection.
C++ must be useful /now/.
Every feature must have a reasonably obvious implementation.
Always provide a transition path.
C++ is a language, nor a complete system.
Provide comprehensive support for each supported style.
Don't try to force people.

[...]

Don't try to force people: Programmers are smart people. [...]
Trying to seriously constrain programmers to do "only what is right"
is inherently wrongheaded and will fail. Programmers will find a
way around rules and restrictions they find unaccpetable. The
language should support a range of reasonable design and programming
styles rather than to force people into adopting a single notion.

[...] and no feature is added or subtracted from C++ exclusively to
prevent a coherent style of programming.

I am well aware that not everyone appreciates choice and variety.
However, people who prefer a more restrictive environment can impose
one through style rules in C++ or choose a language designed to
provide the programmer with a smaller set of alternatives.

La question que j'ai envie de poser est « est-ce que choisir un
langage autre que C++ est un choix restreint ou pas » ;-)

-- Gaby

Alain Naigeon

17/07/2003 à 15:20

"Gabriel Dos Reis" a écrit dans le message
news:

"Alain Naigeon" writes:

| "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 ?

Reproche est trop fort ; je dis simplement qu'on n'a pas un plateau
de la balance très chargé et l'autre avec rien dessus. C'est bien qu'on
ait les moyens de définir ce dont on a besoin, mais le cas que j'évoque
(re-précisé ci-dessous) est si fréquent qu'il est dommage de ne pas avoir
sa solution codée dans le langage.

|
| Soit une ligne et un colonne dans un programme d'échecs,
| toutes deux comprises entre 1 et 8.
[...]

Peux-tu poster un concret sur lequel on peut baser la suite de la
discussion ?

Si tu veux du code Pascal, c'est impossible : je n'ai plus ni compilateur,
ni souvenir tout à fait précis de la syntaxe, ni même aucun livre pour
la retrouver. Je faisais simplement allusion à la déclaration d'un type
intervalle par quelque chose comme [1..8]. Si je déclarais deux tels
types avec les mêmes bornes, mais nommés différemment, ils étaient
considérés comme deux types différents. Ca implique que si j'ai une
fonction qui attend ligne puis colonne, je ne peux pas me tromper
en lui passant colonne puis ligne.

Si tu veux du code C++, pourquoi pas, si c'est la condition que tu
mets pour me répondre. Je vais faire une classe de base désignant
une coordonnée (si j'ai assez de choses à partager), et deux autres
dérivées pour ligne et colonne, pour les cas où il est vital de les
distinguer. De sorte qu'une fonction n'acceptera pas de recevoir
l'une pour l'autre. C'est tout de même une belle machinerie pour
tuer une mouche. Je ne peux pas te faire ça avant ce soir au minimum,
encore que j'aimerais savoir l'utilité ; est-ce que mon propos n'est pas
clair - c'est bien possible ; est-ce que tu as des doutes sur ma capacité
à écrire ces 3 petites classes - c'est ton droit ; je veux juste ne pas
tartiner pour rien...

| 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.

En réalité, ma question portait sur ce que tu reprochais au *C++*,
comme je l'ai soulignée.

| Quant au caractère verbeux de Pascal, souvent moqué,

encore une fois, la question ne porte pas sur Pascal.

C'est exact que tu n'a jamais évoqué Pascal. Quelqu'un d'autre
l'a fait, et dans un fil public ce n'est pas complètement hors de
propos de faire écho à plusieurs arguments.

| 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.

Je présume que cela s'applique aussi à ta réponse ci-dessus ;-)

Je présume que "aussi" ne signifiant pas "seulement", cela ne dit
toujours rien sur les arguments dont je parlais.

--

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: m31xwpz5pp.fsf@uniton.integrable-solutions.net...

"Alain Naigeon" <anaigeon@free.fr> writes:

| "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 ?

Reproche est trop fort ; je dis simplement qu'on n'a pas un plateau
de la balance très chargé et l'autre avec rien dessus. C'est bien qu'on
ait les moyens de définir ce dont on a besoin, mais le cas que j'évoque
(re-précisé ci-dessous) est si fréquent qu'il est dommage de ne pas avoir
sa solution codée dans le langage.

|
| Soit une ligne et un colonne dans un programme d'échecs,
| toutes deux comprises entre 1 et 8.
[...]

Peux-tu poster un concret sur lequel on peut baser la suite de la
discussion ?

Si tu veux du code Pascal, c'est impossible : je n'ai plus ni compilateur,
ni souvenir tout à fait précis de la syntaxe, ni même aucun livre pour
la retrouver. Je faisais simplement allusion à la déclaration d'un type
intervalle par quelque chose comme [1..8]. Si je déclarais deux tels
types avec les mêmes bornes, mais nommés différemment, ils étaient
considérés comme deux types différents. Ca implique que si j'ai une
fonction qui attend ligne puis colonne, je ne peux pas me tromper
en lui passant colonne puis ligne.

Si tu veux du code C++, pourquoi pas, si c'est la condition que tu
mets pour me répondre. Je vais faire une classe de base désignant
une coordonnée (si j'ai assez de choses à partager), et deux autres
dérivées pour ligne et colonne, pour les cas où il est vital de les
distinguer. De sorte qu'une fonction n'acceptera pas de recevoir
l'une pour l'autre. C'est tout de même une belle machinerie pour
tuer une mouche. Je ne peux pas te faire ça avant ce soir au minimum,
encore que j'aimerais savoir l'utilité ; est-ce que mon propos n'est pas
clair - c'est bien possible ; est-ce que tu as des doutes sur ma capacité
à écrire ces 3 petites classes - c'est ton droit ; je veux juste ne pas
tartiner pour rien...

| 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.

En réalité, ma question portait sur ce que tu reprochais au *C++*,
comme je l'ai soulignée.

| Quant au caractère verbeux de Pascal, souvent moqué,

encore une fois, la question ne porte pas sur Pascal.

C'est exact que tu n'a jamais évoqué Pascal. Quelqu'un d'autre
l'a fait, et dans un fil public ce n'est pas complètement hors de
propos de faire écho à plusieurs arguments.

| 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.

Je présume que cela s'applique aussi à ta réponse ci-dessus ;-)

Je présume que "aussi" ne signifiant pas "seulement", cela ne dit
toujours rien sur les arguments dont je parlais.

--

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

Vous avez filtré cet utilisateur ! Consultez son message

"Gabriel Dos Reis" a écrit dans le message
news:

"Alain Naigeon" writes:

| "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 ?

Reproche est trop fort ; je dis simplement qu'on n'a pas un plateau
de la balance très chargé et l'autre avec rien dessus. C'est bien qu'on
ait les moyens de définir ce dont on a besoin, mais le cas que j'évoque
(re-précisé ci-dessous) est si fréquent qu'il est dommage de ne pas avoir
sa solution codée dans le langage.

|
| Soit une ligne et un colonne dans un programme d'échecs,
| toutes deux comprises entre 1 et 8.
[...]

Peux-tu poster un concret sur lequel on peut baser la suite de la
discussion ?

Si tu veux du code Pascal, c'est impossible : je n'ai plus ni compilateur,
ni souvenir tout à fait précis de la syntaxe, ni même aucun livre pour
la retrouver. Je faisais simplement allusion à la déclaration d'un type
intervalle par quelque chose comme [1..8]. Si je déclarais deux tels
types avec les mêmes bornes, mais nommés différemment, ils étaient
considérés comme deux types différents. Ca implique que si j'ai une
fonction qui attend ligne puis colonne, je ne peux pas me tromper
en lui passant colonne puis ligne.

Si tu veux du code C++, pourquoi pas, si c'est la condition que tu
mets pour me répondre. Je vais faire une classe de base désignant
une coordonnée (si j'ai assez de choses à partager), et deux autres
dérivées pour ligne et colonne, pour les cas où il est vital de les
distinguer. De sorte qu'une fonction n'acceptera pas de recevoir
l'une pour l'autre. C'est tout de même une belle machinerie pour
tuer une mouche. Je ne peux pas te faire ça avant ce soir au minimum,
encore que j'aimerais savoir l'utilité ; est-ce que mon propos n'est pas
clair - c'est bien possible ; est-ce que tu as des doutes sur ma capacité
à écrire ces 3 petites classes - c'est ton droit ; je veux juste ne pas
tartiner pour rien...

| 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.

En réalité, ma question portait sur ce que tu reprochais au *C++*,
comme je l'ai soulignée.

| Quant au caractère verbeux de Pascal, souvent moqué,

encore une fois, la question ne porte pas sur Pascal.

C'est exact que tu n'a jamais évoqué Pascal. Quelqu'un d'autre
l'a fait, et dans un fil public ce n'est pas complètement hors de
propos de faire écho à plusieurs arguments.

| 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.

Je présume que cela s'applique aussi à ta réponse ci-dessus ;-)

Je présume que "aussi" ne signifiant pas "seulement", cela ne dit
toujours rien sur les arguments dont je parlais.

--

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

17/07/2003 à 15:36

"Alain Naigeon" writes:

| "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 :

je ne demande qu'à les examiner :-)

| en fin de fonction je peux, mais je ne dois pas,
| retourner un pointeur sur une variable de pile, qui n'existe plus ;

Pas tout à fait. Tu peux retourner un pointeur sur une variable locale.
Ce que la norme dit, c'est que si c'est utilisé le fonctionnement est
indéfini. Cela ne veut pas dire que tu ne dois pas. Cela veut dire
simplement que la norme n'impose aucune restriction sur la sémantique
de ton programme. Ton compilateur peut choisir de définir ce
fonctionnement ou non.
Ce premier exemple montre une certaine mécompréhension des règles.
En fait, cela suit une des règles générales de l'évolution de C++ :

Don't try to force people.

[...]

Many programmers particularly dislike being told that something
might be an error when it happens not to be. Consequently,
"potential errors" are not errors in C++. [...]

| 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...

C'est quelque chose que la syntaxe de Pascal interdit ? <g>
Note que pour la destruction multiple d'objets, C++ te donne les
moyens de te prémunir contre.

C'est tout comme « tant d'exemples » ?

| > | 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 ?

Yep.

| 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.

Dois-je en conclure que Stroustrup ou Koenig ne font pas parties de
ces « gens célèbres » ? Ce serait dommage, lorsqu'il s'agit de C++.

| > 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 ?

Je ne sais pas. Mais je pense qu'il remplit l'une de ses missions :

C++ makes programming more enjoyable for serious programmers.

| Ou, peut-être même cette question :
| est-ce que la sûreté est la première qualité attendue par les adeptes
| de C++ ?

La sûreté de quoi ? En général, je ne crie pas au raccolage passif
parce que l'assitante du projet n'est pas habillée en tchador ;-)

Ce qui m'importe, ce n'est pas que le langage soit supposé posséder
une sûreté. C'est plutôt qu'il me donne les moyens de me protéger
contre Murphy.

| 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.

Well, comme je l'ai dit ailleurs, je n'aime pas trop l'argument
template « pragmatisme ».

-- Gaby

"Alain Naigeon" <anaigeon@free.fr> writes:

| "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 :

je ne demande qu'à les examiner :-)

| en fin de fonction je peux, mais je ne dois pas,
| retourner un pointeur sur une variable de pile, qui n'existe plus ;

Pas tout à fait. Tu peux retourner un pointeur sur une variable locale.
Ce que la norme dit, c'est que si c'est utilisé le fonctionnement est
indéfini. Cela ne veut pas dire que tu ne dois pas. Cela veut dire
simplement que la norme n'impose aucune restriction sur la sémantique
de ton programme. Ton compilateur peut choisir de définir ce
fonctionnement ou non.
Ce premier exemple montre une certaine mécompréhension des règles.
En fait, cela suit une des règles générales de l'évolution de C++ :

Don't try to force people.

[...]

Many programmers particularly dislike being told that something
might be an error when it happens not to be. Consequently,
"potential errors" are not errors in C++. [...]

| 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...

C'est quelque chose que la syntaxe de Pascal interdit ? <g>
Note que pour la destruction multiple d'objets, C++ te donne les
moyens de te prémunir contre.

C'est tout comme « tant d'exemples » ?

| > | 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 ?

Yep.

| 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.

Dois-je en conclure que Stroustrup ou Koenig ne font pas parties de
ces « gens célèbres » ? Ce serait dommage, lorsqu'il s'agit de C++.

| > 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 ?

Je ne sais pas. Mais je pense qu'il remplit l'une de ses missions :

C++ makes programming more enjoyable for serious programmers.

| Ou, peut-être même cette question :
| est-ce que la sûreté est la première qualité attendue par les adeptes
| de C++ ?

La sûreté de quoi ? En général, je ne crie pas au raccolage passif
parce que l'assitante du projet n'est pas habillée en tchador ;-)

Ce qui m'importe, ce n'est pas que le langage soit supposé posséder
une sûreté. C'est plutôt qu'il me donne les moyens de me protéger
contre Murphy.

| 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.

Well, comme je l'ai dit ailleurs, je n'aime pas trop l'argument
template « pragmatisme ».

-- Gaby

Vous avez filtré cet utilisateur ! Consultez son message

"Alain Naigeon" writes:

| "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 :

je ne demande qu'à les examiner :-)

| en fin de fonction je peux, mais je ne dois pas,
| retourner un pointeur sur une variable de pile, qui n'existe plus ;

Pas tout à fait. Tu peux retourner un pointeur sur une variable locale.
Ce que la norme dit, c'est que si c'est utilisé le fonctionnement est
indéfini. Cela ne veut pas dire que tu ne dois pas. Cela veut dire
simplement que la norme n'impose aucune restriction sur la sémantique
de ton programme. Ton compilateur peut choisir de définir ce
fonctionnement ou non.
Ce premier exemple montre une certaine mécompréhension des règles.
En fait, cela suit une des règles générales de l'évolution de C++ :

Don't try to force people.

[...]

Many programmers particularly dislike being told that something
might be an error when it happens not to be. Consequently,
"potential errors" are not errors in C++. [...]

| 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...

C'est quelque chose que la syntaxe de Pascal interdit ? <g>
Note que pour la destruction multiple d'objets, C++ te donne les
moyens de te prémunir contre.

C'est tout comme « tant d'exemples » ?

| > | 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 ?

Yep.

| 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.

Dois-je en conclure que Stroustrup ou Koenig ne font pas parties de
ces « gens célèbres » ? Ce serait dommage, lorsqu'il s'agit de C++.

| > 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 ?

Je ne sais pas. Mais je pense qu'il remplit l'une de ses missions :

C++ makes programming more enjoyable for serious programmers.

| Ou, peut-être même cette question :
| est-ce que la sûreté est la première qualité attendue par les adeptes
| de C++ ?

La sûreté de quoi ? En général, je ne crie pas au raccolage passif
parce que l'assitante du projet n'est pas habillée en tchador ;-)

Ce qui m'importe, ce n'est pas que le langage soit supposé posséder
une sûreté. C'est plutôt qu'il me donne les moyens de me protéger
contre Murphy.

| 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.

Well, comme je l'ai dit ailleurs, je n'aime pas trop l'argument
template « pragmatisme ».

-- Gaby

Jean-Marc Bourguet

17/07/2003 à 15:44

Arnaud Meurgues writes:

Alain Naigeon wrote:

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.

Heu... Excepté qu'on passe rarement une valeur connue à la
compilation, mais plus souvent une variable dont le contenu ne peut
être connu qu'à l'exécution.

Ai-je raté quelque chose ?

Le fait de passer un indice de ligne ou un indice de colonne est
attendu est une erreur de typage en Pascal (ou en Ada) bien programme.

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

Gabriel Dos Reis

17/07/2003 à 15:51

Frederic Py writes:

| Gabriel Dos Reis wrote:
| > En ce qui concerne ma question, c'est que auto_ptr<> utilise de
| > manière essentielle une fonctionnalité obscure (détournement devrait
| > être plus exact) très peu connue du grand public, pour faire croire
| > que son utilisation n'est pas problématique. Beaucoup de gens pensent
| > savoir (à juste titre ou non) qu'ils savent comment auto_ptr<>
| > marche. Mais peu savent ce qui le fait marcher réellement.
|
| D'un seul coup je suis fortement intrigue meme si je n'asi jamais eu
| la pretention de dire que ja savais comment fonctionnait exactement
| les auto_ptr -- n'ayant pas compulse le code outre mesure -- Je
| pensait que ce dernier avait un fonctionnement relativement simple et
| ne faisant pas appel a un "detournement" de fonctionnalite ...

C'est ce que le comité a réussi à faire croire en donnant à auto_ptr<>
une interface « simple ».

| Pourriez vous, toi et/ou un autre, expliquer plus precisement de quoi
| il en retourne plus precisement ou donner des pointeurs sur ceci ?

Argh, je me suis promis de ne jamais expliquer ce hack.

Bon, je donne quand même un lien

http://www.josuttis.com/libbook/auto_ptr.html

-- Gaby

Arnaud Meurgues

17/07/2003 à 15:51

Jean-Marc Bourguet wrote:

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?

Parce que son constructeur par copie transfert la propriété ?

Arnaud

Gabriel Dos Reis

17/07/2003 à 15:55

Arnaud Meurgues writes:

| Gabriel Dos Reis wrote:
|
| > General Rules:
| > C++ evolution must be driven by real problems.
| > Don't get involved in a sterile quest for perfection.
| > C++ must be useful /now/.
| > Every feature must have a reasonably obvious implementation.
| > Always provide a transition path.
| [...]
| > Don't try to force people.
|
| Voilà un ensemble d'énoncés qui sont des illustrations
| particulièrement frappantes de ce que j'appelle « pragmatisme ».

J'appelle ça plutôt « réalisme et flexibilité ».

-- Gaby

Contigüité des éléments d'un `std::vector´

10 réponses

Veuillez sélectionner un problème