Position sous-chaine

Antoine Leca

11/08/2003 à 19:05

Vincent Lefevre écrivit:

Il n'y a pas que la contrainte de 6.5.6. Dans 6.5.6#9, le
comportement n'est défini que dans ce cas:

[#9] When two pointers are subtracted, both shall point to
elements of the same array object, or one past the last
element of the array object;

Je ne lis pas comme toi (mais là, c'est de l'interprétation
libre): pour moi, le « même objet » n'implique pas identité,
et encore moins compatibilité, de type. Cela fait seulement
référence au "object" du 3.15, laquelle notion signifie
globalement que cela a été alloué en une seule fois.

Il faudrait alors que la norme dise ce qui se passe dans le cas de
tableaux différents. Par exemple, lorsque les éléments ont la même
taille (et le même alignement).

Pour moi, je ne vois pas de difficultés (dans le cas précis
des types caractères), grâce à ce que dit 6.2.6.1.

Dans l'article <bh88lc$f7l$,
Antoine Leca écrit:
Dans ce cas, tu ne "peux plus" renvoyer 0, il "faut" renvoyer la
valeur logique et naturelle, sur laquelle il n'y a pas ce me semble
d'ambiguité, même dans le cas des architectures tordues

Mais la norme ne parle pas de logique et de naturel.

Si si. 3p1, 3e phrase. Et ISO 2382 est du même tonneau.

Antoine

bs

11/08/2003 à 19:39

You can find my opinions on key C/C++ issues in four papers linked
from my publications list: http://www.research.att.com/~bs/papers.http

- Bjarne Stroustrup

Laurent Deniau

11/08/2003 à 19:54

Antoine Leca wrote:

Laurent Deniau écrivit:

Antoine Leca wrote:

Laurent Deniau écrivit:

Abstract Data Type. Un objet dont l'utilisateur n'a absoluement rien
a savoir hormis les fonctions qui lui sont applicables (interface).

Ah. Quelque chose comme

struct adt;

Non.

Cela t'ennuierais de me (nous ?) dire pourquoi ?

parce que le code presente' ne donne pas de warning.

typedef struct elem array[];
typedef struct list_elem list;

^^^^^^^^^

Ce n'est pas du tout ce que je veux.

Hmmm.
Tu émets un besoin. J'essaye de formuler une solution
qui y répond, à mon sens. Si c'est pas ce que tu veux,
c'est que je n'ai compris le besoin (merci de reformuler).

ADT veux dire que l'utilisateur ne sait rien sur ce qui est derriere et donc que
ce que tu vois dans le header n'est pas la realite. Pourquoi attachez-vous
(j'inclus Gaby) autant d'importance au contenu de la structure alors que depuis
le debut il est dis que c'est un ADT?

Pour revenir a ta proposition, comment fais-tu pour declarer un list ou le
passer comme parametre si tu n'utilises pas de pointeur ou si tu ne definis pas
struct list_elem (type incomplet tel que tu le presentes)? Ce que je veux dire,
c'est qu'un ADT est forcement un pointeur. Je considere d'ailleurs que
l'utilisateur n'a meme pas a savoir si ADT est un pointeur ou non, c'est
pourquoi le '*' est inclu dans la definition du type. Mais si tu fais cela avec
un typedef, alors tous les alias de ADT sont equivalent, ce que je ne veux pas
comme le montre le bout de code. Voila pourquoi tes proposition ne me convenait pas.

Mais si ce que tu veux, c'est ta solution et rien d'autre,
même si c'est minimalement différent, le dialogue va
être difficile.

J'essaie pourtant d'etre clair :-)

Si tu y tiens,

typedef struct elem object;

Mais cela n'apporte rien, àmha.

Si.

Deuxième excuses-moi: En quoi ?

Le 'si' portait sur ce que je presentais, et pas ce que tu proposais. Le code,
me semble-t-il, etait clair sur ce point.

Pour etre plus clair, voici un code qui montre le probleme:

<couic>

/* pas de warnings avec ce cas
struct adt;
typedef struct adt *list;

^^^^^

typedef struct adt *array;

C'est sûr que si tu changes ma proposition, elle ne va
pas te convenir...

Je n'ai rien change depuis le debut. C'est ta proposition qui ne correspond pas
a mes besoins. ADT a un '*' a la fin et ce n'est pas par hasard.

Pour moi, une liste (avec les sens conventionels),
c'est un objet complexe, donc implémenté par une
structure ad-hoc, et sûrement pas par un pointeur
(à la rigueur deux).

Du cote utilisateur, ca n'a pas d'importance c'est un ADT! Puisqu'il semble que
la comprehension de ma reponse a Gaby sans qu'un minimum de l'implementation ne
soit devoilee, voici comment l'implementation gere l'ADT:

typedef struct list_ { ... } *list_;

qui definit le veritable 'layout' de list et accompagne' de deux fonctions

static list_ toList_(list l ) { ... }
static list toList (list_ l_) { ... }

qui permettent de passer de l'un a l'autre, generalement par un cast ou un
changement d'offset ou les deux.

voila,

a+, ld.

--
[ Laurent Deniau -- Scientific Computing & Data Analysis ]
[ CERN -- European Center for Nuclear Research ]
[ - http://cern.ch/Laurent.Deniau ]
[ -- One becomes old when dreams become regrets -- ]

Antoine Leca wrote:

Laurent Deniau écrivit:

Antoine Leca wrote:

Laurent Deniau écrivit:

Abstract Data Type. Un objet dont l'utilisateur n'a absoluement rien
a savoir hormis les fonctions qui lui sont applicables (interface).

Ah. Quelque chose comme

struct adt;

Non.

Cela t'ennuierais de me (nous ?) dire pourquoi ?

parce que le code presente' ne donne pas de warning.

typedef struct elem array[];
typedef struct list_elem list;

^^^^^^^^^

Ce n'est pas du tout ce que je veux.

Hmmm.
Tu émets un besoin. J'essaye de formuler une solution
qui y répond, à mon sens. Si c'est pas ce que tu veux,
c'est que je n'ai compris le besoin (merci de reformuler).

ADT veux dire que l'utilisateur ne sait rien sur ce qui est derriere et donc que
ce que tu vois dans le header n'est pas la realite. Pourquoi attachez-vous
(j'inclus Gaby) autant d'importance au contenu de la structure alors que depuis
le debut il est dis que c'est un ADT?

Pour revenir a ta proposition, comment fais-tu pour declarer un list ou le
passer comme parametre si tu n'utilises pas de pointeur ou si tu ne definis pas
struct list_elem (type incomplet tel que tu le presentes)? Ce que je veux dire,
c'est qu'un ADT est forcement un pointeur. Je considere d'ailleurs que
l'utilisateur n'a meme pas a savoir si ADT est un pointeur ou non, c'est
pourquoi le '*' est inclu dans la definition du type. Mais si tu fais cela avec
un typedef, alors tous les alias de ADT sont equivalent, ce que je ne veux pas
comme le montre le bout de code. Voila pourquoi tes proposition ne me convenait pas.

Mais si ce que tu veux, c'est ta solution et rien d'autre,
même si c'est minimalement différent, le dialogue va
être difficile.

J'essaie pourtant d'etre clair :-)

Si tu y tiens,

typedef struct elem object;

Mais cela n'apporte rien, àmha.

Si.

Deuxième excuses-moi: En quoi ?

Le 'si' portait sur ce que je presentais, et pas ce que tu proposais. Le code,
me semble-t-il, etait clair sur ce point.

Pour etre plus clair, voici un code qui montre le probleme:

<couic>

/* pas de warnings avec ce cas
struct adt;
typedef struct adt *list;

^^^^^

typedef struct adt *array;

C'est sûr que si tu changes ma proposition, elle ne va
pas te convenir...

Je n'ai rien change depuis le debut. C'est ta proposition qui ne correspond pas
a mes besoins. ADT a un '*' a la fin et ce n'est pas par hasard.

Pour moi, une liste (avec les sens conventionels),
c'est un objet complexe, donc implémenté par une
structure ad-hoc, et sûrement pas par un pointeur
(à la rigueur deux).

Du cote utilisateur, ca n'a pas d'importance c'est un ADT! Puisqu'il semble que
la comprehension de ma reponse a Gaby sans qu'un minimum de l'implementation ne
soit devoilee, voici comment l'implementation gere l'ADT:

typedef struct list_ { ... } *list_;

qui definit le veritable 'layout' de list et accompagne' de deux fonctions

static list_ toList_(list l ) { ... }
static list toList (list_ l_) { ... }

qui permettent de passer de l'un a l'autre, generalement par un cast ou un
changement d'offset ou les deux.

voila,

a+, ld.

--
[ Laurent Deniau -- Scientific Computing & Data Analysis ]
[ CERN -- European Center for Nuclear Research ]
[ Laurent.Deniau@cern.ch - http://cern.ch/Laurent.Deniau ]
[ -- One becomes old when dreams become regrets -- ]

Vous avez filtré cet utilisateur ! Consultez son message

Antoine Leca wrote:

Laurent Deniau écrivit:

Antoine Leca wrote:

Laurent Deniau écrivit:

Abstract Data Type. Un objet dont l'utilisateur n'a absoluement rien
a savoir hormis les fonctions qui lui sont applicables (interface).

Ah. Quelque chose comme

struct adt;

Non.

Cela t'ennuierais de me (nous ?) dire pourquoi ?

parce que le code presente' ne donne pas de warning.

typedef struct elem array[];
typedef struct list_elem list;

^^^^^^^^^

Ce n'est pas du tout ce que je veux.

Hmmm.
Tu émets un besoin. J'essaye de formuler une solution
qui y répond, à mon sens. Si c'est pas ce que tu veux,
c'est que je n'ai compris le besoin (merci de reformuler).

ADT veux dire que l'utilisateur ne sait rien sur ce qui est derriere et donc que
ce que tu vois dans le header n'est pas la realite. Pourquoi attachez-vous
(j'inclus Gaby) autant d'importance au contenu de la structure alors que depuis
le debut il est dis que c'est un ADT?

Pour revenir a ta proposition, comment fais-tu pour declarer un list ou le
passer comme parametre si tu n'utilises pas de pointeur ou si tu ne definis pas
struct list_elem (type incomplet tel que tu le presentes)? Ce que je veux dire,
c'est qu'un ADT est forcement un pointeur. Je considere d'ailleurs que
l'utilisateur n'a meme pas a savoir si ADT est un pointeur ou non, c'est
pourquoi le '*' est inclu dans la definition du type. Mais si tu fais cela avec
un typedef, alors tous les alias de ADT sont equivalent, ce que je ne veux pas
comme le montre le bout de code. Voila pourquoi tes proposition ne me convenait pas.

Mais si ce que tu veux, c'est ta solution et rien d'autre,
même si c'est minimalement différent, le dialogue va
être difficile.

J'essaie pourtant d'etre clair :-)

Si tu y tiens,

typedef struct elem object;

Mais cela n'apporte rien, àmha.

Si.

Deuxième excuses-moi: En quoi ?

Le 'si' portait sur ce que je presentais, et pas ce que tu proposais. Le code,
me semble-t-il, etait clair sur ce point.

Pour etre plus clair, voici un code qui montre le probleme:

<couic>

/* pas de warnings avec ce cas
struct adt;
typedef struct adt *list;

^^^^^

typedef struct adt *array;

C'est sûr que si tu changes ma proposition, elle ne va
pas te convenir...

Je n'ai rien change depuis le debut. C'est ta proposition qui ne correspond pas
a mes besoins. ADT a un '*' a la fin et ce n'est pas par hasard.

Pour moi, une liste (avec les sens conventionels),
c'est un objet complexe, donc implémenté par une
structure ad-hoc, et sûrement pas par un pointeur
(à la rigueur deux).

Du cote utilisateur, ca n'a pas d'importance c'est un ADT! Puisqu'il semble que
la comprehension de ma reponse a Gaby sans qu'un minimum de l'implementation ne
soit devoilee, voici comment l'implementation gere l'ADT:

typedef struct list_ { ... } *list_;

qui definit le veritable 'layout' de list et accompagne' de deux fonctions

static list_ toList_(list l ) { ... }
static list toList (list_ l_) { ... }

qui permettent de passer de l'un a l'autre, generalement par un cast ou un
changement d'offset ou les deux.

voila,

a+, ld.

--
[ Laurent Deniau -- Scientific Computing & Data Analysis ]
[ CERN -- European Center for Nuclear Research ]
[ - http://cern.ch/Laurent.Deniau ]
[ -- One becomes old when dreams become regrets -- ]

Richard Delorme

11/08/2003 à 20:15

Gabriel Dos Reis écrivit:
"Antoine Leca" writes:
void *my_memcpy(void* a, const void* b, int c).{ return
memcpy(a,b,c); }

non, pas ças -- il est notoire que memcpy sur certaines
implémentations sont très lentes.

Mmmm... C'est memmove() qui craint, pas memcpy().
memcpy() doit même exister dans V7, ou pas loin.

Je n'ai pas dit que je voulais implémenter la bibliothèque standard C.

Qui as dit que tu voulais le faire ?
Je te réponds simplement que pour faire les opérations identiques
à ce qui est dans la bibliothèque standard, il suffit d'utiliser la
dite bibliothèque. Et que memcpy() et qsort() ne sont pas des
exceptions (et maintenant, on ajoutera que memmove() peut
éventuellement en être une).

Quand on lance xine, un programme pour lire les DVD sous linux (et autres),
on peut lire :

Benchmarking memcpy methods (smaller is better):
glibc memcpy() : 629413447
linux kernel memcpy() : 625738622
MMX optimized memcpy() : 549848141
MMXEXT optimized memcpy() : 335734572
SSE optimized memcpy() : 332004112

Et on s'aperçoit qu'il sélectionne un memcpy 2 fois plus rapide (*) que ce
que fournit la bibliothèque C standard sur mon implémentation. Mais c'est
vrai qu'il faut en avoir l'usage.

D'autre part, j'explique à ceux qui voudraient bien nous faire
l'honneur de nous lire, que la bibliothèque C ne doit pas
obligatoirement etc. Parce que je pense que notre échange
pourrait enduire d'erreur certains. Je me préoccupe de
pédagogie, je me chauffe pour septembre, quoi...

(*) D'après le source, le chiffre est le nombre de cycles nécessaire pour
copier 100 fois 1 Mo.

--
Richard

Vincent Lefevre

11/08/2003 à 21:10

Dans l'article ,
Gabriel Dos Reis écrit:

Vincent Lefevre <vincent+ writes:

| Dans l'article ,
| Gabriel Dos Reis écrit:
|
| > mouais, mais alors le même argument s'applique pour la conversion
| > implicite void* -> T* pour n'importe quel T, type d'objet. Cette
| > conversion implicite est beaucoup plus pernicieuse que l'arithmétique.
|
| Pourquoi? Le programmeur n'est-il pas censé connaître son langage et
| programmer en conséquence?

Oui et alors ? Tu n'as jamais fait d'erreur ?

Il semble alors que tu sois devenu plus sage, car quand je (ou autres
utilisateurs) me plaignais de certains choix du C, tu n'étais pas du
même avis. Il devait y avoir le fait de pouvoir utiliser

for (...)
blah();

au lieu d'un

for (...)
{
blah();
}

obligatoire et autres choses du genre, ainsi que l'utilité des warnings
d'un compilo.

--
Vincent Lefèvre - Web: <http://www.vinc17.org/> - 100%
validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International
des Jeux Mathématiques et Logiques, TETRHEX, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Vincent Lefevre

11/08/2003 à 21:12

Dans l'article ,
Gabriel Dos Reis écrit:

Vincent Lefevre <vincent+ writes:

| Dans l'article ,
| Gabriel Dos Reis écrit:
|
| > Moi, je garderais char et virerais les deux autres avatards.
|
| Mais un char qui aurait quelles fonctionnalités?

représenter un charactère.

OK, et dans ce cas on n'aurait plus forcément sizeof(char) == 1.

--
Vincent Lefèvre - Web: <http://www.vinc17.org/> - 100%
validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International
des Jeux Mathématiques et Logiques, TETRHEX, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Gabriel Dos Reis

11/08/2003 à 21:39

--=-=- Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Richard Delorme writes:

| > Qui as dit que tu voulais le faire ?
| > Je te réponds simplement que pour faire les opérations identiques
| > à ce qui est dans la bibliothèque standard, il suffit d'utiliser la
| > dite bibliothèque.

--=-=- Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: quoted-printable

"Il suffit d'utiliser la dite bibliothèque" n'est pas forcement une
réponse adaptée à toutes les situations.

--=-=- Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

| Et que memcpy() et qsort() ne sont pas des
| > exceptions (et maintenant, on ajoutera que memmove() peut
| > éventuellement en être une).
|
| Quand on lance xine, un programme pour lire les DVD sous linux (et autres),
| on peut lire :
|
| Benchmarking memcpy methods (smaller is better):
| glibc memcpy() : 629413447
| linux kernel memcpy() : 625738622
| MMX optimized memcpy() : 549848141
| MMXEXT optimized memcpy() : 335734572
| SSE optimized memcpy() : 332004112
|
| Et on s'aperçoit qu'il sélectionne un memcpy 2 fois plus rapide (*) que ce
| que fournit la bibliothèque C standard sur mon implémentation. Mais c'est
| vrai qu'il faut en avoir l'usage.

--=-=- Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: quoted-printable

La preuve par l'exemple. Merci. Mais je pense que Antoine avait vu où je
voulais en venir.

--=-=- Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

|
| > D'autre part, j'explique à ceux qui voudraient bien nous faire
| > l'honneur de nous lire, que la bibliothèque C ne doit pas
| > obligatoirement etc. Parce que je pense que notre échange
| > pourrait enduire d'erreur certains. Je me préoccupe de
| > pédagogie, je me chauffe pour septembre, quoi...

Tu fais prof maintenant ?

-- Gaby

--=-=-=--

Gabriel Dos Reis

11/08/2003 à 21:41

--=-=- Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Laurent Deniau writes:

| Gabriel Dos Reis wrote:
| > Laurent Deniau writes:
| > | Antoine Leca wrote:
| > | > Laurent Deniau écrivit:
| > | >
| > | >>Typiquement mon ADT en C ressemble a ca:
| > | > Heu, excusez la question du Neu-neu, ADT, que es aco?
| > | | Abstract Data Type. Un objet dont l'utilisateur n'a absoluement
| > rien a
| > | savoir hormis les fonctions qui lui sont applicables (interface).
| > | | >>#define D_ADT struct { void const * const _; } *
| > | > Dangereux cela, tu définis un structure anonyme (différente)
| > | > à chaque invocation de la macro; c'est peut-être ce que tu
| > | > veux, mais d'autres pourrait facilement se méprendre...
| > | | C'est exactement ce que je veux. C'est pour palier au probleme
| > des alias.
| > ------------------------------------------------------------------------
| > Comment ? À partir du moment où tu mets void* en début de ta
| > structure, tu dis au compilo que n'importe quel pointeur de données
| > peut aliaser ta structure. I.e. tu fais exactement el contraire de ce
| > que tu voudrais.
|
| Ce qui est dans la structure n'est pas important et j'aurais pu mettre
| n'importe quoi d'autre. C'est le fait que ce soit une structure qui
| est important.

--=-=- Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: quoted-printable

Non, pas forcement. Le point crucial est que compatibilité est
découplée d'aliasing.

| Le * final t'aurait-il echappe? array et list sont des pointeurs.

Non, il ne m'a pas échappé.

-- Gaby

--=-=-=--

Gabriel Dos Reis

11/08/2003 à 21:43

Laurent Deniau writes:

| ADT veux dire que l'utilisateur ne sait rien sur ce qui est derriere
| et donc que ce que tu vois dans le header n'est pas la
| realite. Pourquoi attachez-vous (j'inclus Gaby) autant d'importance au
| contenu de la structure alors que depuis le debut il est dis que c'est
| un ADT?

Parce que tu as parlé d'aliasing Et aliasing s'en fout de ADT :-)

-- Gaby

Vincent Lefevre

11/08/2003 à 21:58

Dans l'article <bh8idp$2ev$,
Antoine Leca écrit:

Vincent Lefevre écrivit:
Il n'y a pas que la contrainte de 6.5.6. Dans 6.5.6#9, le
comportement n'est défini que dans ce cas:

[#9] When two pointers are subtracted, both shall point to
elements of the same array object, or one past the last
element of the array object;

Je ne lis pas comme toi (mais là, c'est de l'interprétation
libre): pour moi, le « même objet » n'implique pas identité,
et encore moins compatibilité, de type. Cela fait seulement
référence au "object" du 3.15, laquelle notion signifie
globalement que cela a été alloué en une seule fois.

Ici, le type de l'objet est important (car le résultat dépend du type
en question). D'autre part, si on considère que les types peuvent être
différents, cela pose des problèmes de définition (cf ci-dessous).

Il faudrait alors que la norme dise ce qui se passe dans le cas de
tableaux différents. Par exemple, lorsque les éléments ont la même
taille (et le même alignement).

Pour moi, je ne vois pas de difficultés (dans le cas précis
des types caractères), grâce à ce que dit 6.2.6.1.

Ça ne pose peut-être pas de problèmes dans le cas des types caractères,
mais dans les autres cas, ça en pose un. Accepter le fait que les types
puissent être différents signifierait que la norme contiendrait des
passages qui n'ont pas toujours de sens.

Dans l'article <bh88lc$f7l$,
Antoine Leca écrit:
Dans ce cas, tu ne "peux plus" renvoyer 0, il "faut" renvoyer la
valeur logique et naturelle, sur laquelle il n'y a pas ce me semble
d'ambiguité, même dans le cas des architectures tordues

Mais la norme ne parle pas de logique et de naturel.

Si si. 3p1, 3e phrase. Et ISO 2382 est du même tonneau.

Celle-ci?

rule. Terms explicitly defined in this International
Standard are not to be presumed to refer implicitly to
similar terms defined elsewhere. Terms not defined in this

Quel est le rapport avec logique et naturel?

--
Vincent Lefèvre - Web: <http://www.vinc17.org/> - 100%
validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International
des Jeux Mathématiques et Logiques, TETRHEX, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Dans l'article <bh8idp$2ev$1@shakotay.alphanet.ch>,
Antoine Leca <root@localhost.gov> écrit:

Vincent Lefevre écrivit:

Il n'y a pas que la contrainte de 6.5.6. Dans 6.5.6#9, le
comportement n'est défini que dans ce cas:

[#9] When two pointers are subtracted, both shall point to
elements of the same array object, or one past the last
element of the array object;

Je ne lis pas comme toi (mais là, c'est de l'interprétation
libre): pour moi, le « même objet » n'implique pas identité,
et encore moins compatibilité, de type. Cela fait seulement
référence au "object" du 3.15, laquelle notion signifie
globalement que cela a été alloué en une seule fois.

Ici, le type de l'objet est important (car le résultat dépend du type
en question). D'autre part, si on considère que les types peuvent être
différents, cela pose des problèmes de définition (cf ci-dessous).

Il faudrait alors que la norme dise ce qui se passe dans le cas de
tableaux différents. Par exemple, lorsque les éléments ont la même
taille (et le même alignement).

Pour moi, je ne vois pas de difficultés (dans le cas précis
des types caractères), grâce à ce que dit 6.2.6.1.

Ça ne pose peut-être pas de problèmes dans le cas des types caractères,
mais dans les autres cas, ça en pose un. Accepter le fait que les types
puissent être différents signifierait que la norme contiendrait des
passages qui n'ont pas toujours de sens.

Dans l'article <bh88lc$f7l$1@shakotay.alphanet.ch>,
Antoine Leca <root@localhost.gov> écrit:

Dans ce cas, tu ne "peux plus" renvoyer 0, il "faut" renvoyer la
valeur logique et naturelle, sur laquelle il n'y a pas ce me semble
d'ambiguité, même dans le cas des architectures tordues

Mais la norme ne parle pas de logique et de naturel.

Si si. 3p1, 3e phrase. Et ISO 2382 est du même tonneau.

Celle-ci?

rule. Terms explicitly defined in this International
Standard are not to be presumed to refer implicitly to
similar terms defined elsewhere. Terms not defined in this

Quel est le rapport avec logique et naturel?

--
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> - 100%
validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International
des Jeux Mathématiques et Logiques, TETRHEX, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Vous avez filtré cet utilisateur ! Consultez son message

Dans l'article <bh8idp$2ev$,
Antoine Leca écrit:

Vincent Lefevre écrivit:
Il n'y a pas que la contrainte de 6.5.6. Dans 6.5.6#9, le
comportement n'est défini que dans ce cas:

[#9] When two pointers are subtracted, both shall point to
elements of the same array object, or one past the last
element of the array object;

Je ne lis pas comme toi (mais là, c'est de l'interprétation
libre): pour moi, le « même objet » n'implique pas identité,
et encore moins compatibilité, de type. Cela fait seulement
référence au "object" du 3.15, laquelle notion signifie
globalement que cela a été alloué en une seule fois.

Ici, le type de l'objet est important (car le résultat dépend du type
en question). D'autre part, si on considère que les types peuvent être
différents, cela pose des problèmes de définition (cf ci-dessous).

Il faudrait alors que la norme dise ce qui se passe dans le cas de
tableaux différents. Par exemple, lorsque les éléments ont la même
taille (et le même alignement).

Pour moi, je ne vois pas de difficultés (dans le cas précis
des types caractères), grâce à ce que dit 6.2.6.1.

Ça ne pose peut-être pas de problèmes dans le cas des types caractères,
mais dans les autres cas, ça en pose un. Accepter le fait que les types
puissent être différents signifierait que la norme contiendrait des
passages qui n'ont pas toujours de sens.

Dans l'article <bh88lc$f7l$,
Antoine Leca écrit:
Dans ce cas, tu ne "peux plus" renvoyer 0, il "faut" renvoyer la
valeur logique et naturelle, sur laquelle il n'y a pas ce me semble
d'ambiguité, même dans le cas des architectures tordues

Mais la norme ne parle pas de logique et de naturel.

Si si. 3p1, 3e phrase. Et ISO 2382 est du même tonneau.

Celle-ci?

rule. Terms explicitly defined in this International
Standard are not to be presumed to refer implicitly to
similar terms defined elsewhere. Terms not defined in this

Quel est le rapport avec logique et naturel?

--
Vincent Lefèvre - Web: <http://www.vinc17.org/> - 100%
validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International
des Jeux Mathématiques et Logiques, TETRHEX, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Position sous-chaine

10 réponses

Veuillez sélectionner un problème