Je m'interroge sur une construction peu orthodoxe que je dois utiliser
en C (=E0 savoir un pointeur de tableaux).
J'ai une fonction dont le prototype est =E0 peu pr=E8s le suivant :
void f(float (*tab)[N], /* reste des arguments */);
Jusque l=E0, tout va bien. Dans le main(), j'alloue "tab" =E0 l'aide des
lignes suivantes :
#define M ...
#define N ...
int main(void)
{
/* d=E9clarations ... */
float (*t)[N];
t =3D malloc(sizeof(float) * M * N);
if (t =3D=3D NULL) { /* gestion d'erreur */ }
/* ... */
f(t, ...);
return 0;
}
J'ai cherch=E9 un peu partout, demand=E9 =E0 des personnes qui =E0 ma
connaissance connaissent bien la norme, et ce code semble l=E9gal.
J'aimerais d'une part avoir confirmation, et d'autre part savoir si
quelqu'un pourrait me dire o=F9 dans la norme je peux confirmer cela.
Horrible. Ça signifie mémoire statique avec tous les inconvénients qui s'y rattachent.
(...)
Évidemment, cela n'est pas adapté à des jeux de données dynamiques en taille, comme un programme de tri ou un butineur web. Mais c'est souvent bien adapté aux programmes où on peut déterminer (ou majorer) la taille des données à traiter, par exemple un code de calcul... ou un serveur !
Jean-Claude Arbaut a écrit :
Horrible. Ça signifie mémoire statique avec tous les inconvénients qui s'y rattachent. Le sujet a été traité des zillion de fois. Pas de statiques. (sauf dans le main(, éventuellement)).
Ca dépend ce qu'on veut faire. Si on programme un serveur web, on va éviter.
Bon en définitive, pour un serveur web, la mémoire statique est adaptée ou pas ?
Antoine Leca a écrit :
Horrible. Ça signifie mémoire statique avec tous les inconvénients qui
s'y rattachent.
(...)
Évidemment, cela n'est pas adapté à des jeux de données dynamiques en
taille, comme un programme de tri ou un butineur web. Mais c'est souvent
bien adapté aux programmes où on peut déterminer (ou majorer) la taille
des données à traiter, par exemple un code de calcul... ou un serveur !
Jean-Claude Arbaut a écrit :
Horrible. Ça signifie mémoire statique avec tous les inconvénients qui
s'y rattachent. Le sujet a été traité des zillion de fois. Pas de
statiques. (sauf dans le main(, éventuellement)).
Ca dépend ce qu'on veut faire. Si on programme un serveur web,
on va éviter.
Bon en définitive, pour un serveur web, la mémoire statique est adaptée ou pas ?
Horrible. Ça signifie mémoire statique avec tous les inconvénients qui s'y rattachent.
(...)
Évidemment, cela n'est pas adapté à des jeux de données dynamiques en taille, comme un programme de tri ou un butineur web. Mais c'est souvent bien adapté aux programmes où on peut déterminer (ou majorer) la taille des données à traiter, par exemple un code de calcul... ou un serveur !
Jean-Claude Arbaut a écrit :
Horrible. Ça signifie mémoire statique avec tous les inconvénients qui s'y rattachent. Le sujet a été traité des zillion de fois. Pas de statiques. (sauf dans le main(, éventuellement)).
Ca dépend ce qu'on veut faire. Si on programme un serveur web, on va éviter.
Bon en définitive, pour un serveur web, la mémoire statique est adaptée ou pas ?
Stéphane Zuckerman
Bonjour,
On Jun 3, 4:10 pm, candide wrote:
Si je regarde le code source C de Python par exemple, je trouve plein de variable en mémoire statique y compris des variables locales, au hasard en faisant une rapide recherche :
Effectivement, « au bûcher ». :-) À cause de ce genre de trucs, l e modèle de threads de Python est fait de coroutines/threads utilisateurs. À moins de ne vouloir faire que du C purement ANSI/ISO, et avec l'avènement des machines multi-cur, c'est tout de même dommage.
Sinon en effet, dans ce cas précis, il s'agissait d'un « bête » #define M <constante>. Cependant mon objectif était d'allouer mon tableau de la façon la plus proche possible de ce qui est fait en Fortran 90 : je suis en train d'optimiser une routine chaude issue d'un code F90, et pour tout un tas de raisons j'ai dû le convertir en C -- entre autres parce que je connais beaucoup mieux le C que le Fortran, et que pour effectuer certaines opérations non-portables (comme l'utilisation d'instructions SIMD ou de code assembleur) je préfère passer par du C au départ, avant de revenir au code Fortran original. Bref, le code que j'utilise est un tout petit programme destiné à simplement reproduire une partie du comportement d'un autre programme bien plus gros écrit en Fortran.
Bonjour,
On Jun 3, 4:10 pm, candide <cand...@free.invalid> wrote:
Si je regarde le code source C de Python par exemple, je trouve plein de
variable en mémoire statique y compris des variables locales, au hasard en
faisant une rapide recherche :
Effectivement, « au bûcher ». :-) À cause de ce genre de trucs, l e
modèle de threads de Python est fait de coroutines/threads
utilisateurs. À moins de ne vouloir faire que du C purement ANSI/ISO,
et avec l'avènement des machines multi-cur, c'est tout de même
dommage.
Sinon en effet, dans ce cas précis, il s'agissait d'un « bête
» #define M <constante>. Cependant mon objectif était d'allouer mon
tableau de la façon la plus proche possible de ce qui est fait en
Fortran 90 : je suis en train d'optimiser une routine chaude issue
d'un code F90, et pour tout un tas de raisons j'ai dû le convertir en
C -- entre autres parce que je connais beaucoup mieux le C que le
Fortran, et que pour effectuer certaines opérations non-portables
(comme l'utilisation d'instructions SIMD ou de code assembleur) je
préfère passer par du C au départ, avant de revenir au code Fortran
original. Bref, le code que j'utilise est un tout petit programme
destiné à simplement reproduire une partie du comportement d'un autre
programme bien plus gros écrit en Fortran.
Si je regarde le code source C de Python par exemple, je trouve plein de variable en mémoire statique y compris des variables locales, au hasard en faisant une rapide recherche :
Effectivement, « au bûcher ». :-) À cause de ce genre de trucs, l e modèle de threads de Python est fait de coroutines/threads utilisateurs. À moins de ne vouloir faire que du C purement ANSI/ISO, et avec l'avènement des machines multi-cur, c'est tout de même dommage.
Sinon en effet, dans ce cas précis, il s'agissait d'un « bête » #define M <constante>. Cependant mon objectif était d'allouer mon tableau de la façon la plus proche possible de ce qui est fait en Fortran 90 : je suis en train d'optimiser une routine chaude issue d'un code F90, et pour tout un tas de raisons j'ai dû le convertir en C -- entre autres parce que je connais beaucoup mieux le C que le Fortran, et que pour effectuer certaines opérations non-portables (comme l'utilisation d'instructions SIMD ou de code assembleur) je préfère passer par du C au départ, avant de revenir au code Fortran original. Bref, le code que j'utilise est un tout petit programme destiné à simplement reproduire une partie du comportement d'un autre programme bien plus gros écrit en Fortran.
Jean-Claude Arbaut
On 3 juin, 16:20, candide wrote:
Bon en définitive, pour un serveur web, la mémoire statique est adapt ée ou pas ?
Je pense qu'Antoine a raison, et j'ai pris un mauvais exemple ;-) Pour un serveur, si on peut borner à l'avance la ram utilisée, c'est une bonne chose, puisqu'on est sûr qu'il ne va pas bouffer toute la ram plus tard. Pour les codes de calcul par contre c'est particulièrement évident que l'on peut, il suffit de voir les masses de codes écrits en fortran pré-90 depuis plus de 50 ans. (au passage, fortran a eu longtemps un avantage sur le C à propos d'une histoire d'aliasing, et je crois avoir vu que c'est corrigé dans le standard C actuel, avec des pointeurs "restrict", à moins que j'aie rêvé ?)
On 3 juin, 16:20, candide <cand...@free.invalid> wrote:
Bon en définitive, pour un serveur web, la mémoire statique est adapt ée ou pas ?
Je pense qu'Antoine a raison, et j'ai pris un mauvais exemple ;-)
Pour un serveur, si on peut borner à l'avance la ram utilisée,
c'est une bonne chose, puisqu'on est sûr qu'il ne va pas
bouffer toute la ram plus tard. Pour les codes de calcul par
contre c'est particulièrement évident que l'on peut, il suffit de voir
les masses de codes écrits en fortran pré-90 depuis plus de 50 ans.
(au passage, fortran a eu longtemps un avantage sur le C à propos
d'une histoire d'aliasing, et je crois avoir vu que c'est corrigé dans
le standard C actuel, avec des pointeurs "restrict", à moins que j'aie
rêvé ?)
Bon en définitive, pour un serveur web, la mémoire statique est adapt ée ou pas ?
Je pense qu'Antoine a raison, et j'ai pris un mauvais exemple ;-) Pour un serveur, si on peut borner à l'avance la ram utilisée, c'est une bonne chose, puisqu'on est sûr qu'il ne va pas bouffer toute la ram plus tard. Pour les codes de calcul par contre c'est particulièrement évident que l'on peut, il suffit de voir les masses de codes écrits en fortran pré-90 depuis plus de 50 ans. (au passage, fortran a eu longtemps un avantage sur le C à propos d'une histoire d'aliasing, et je crois avoir vu que c'est corrigé dans le standard C actuel, avec des pointeurs "restrict", à moins que j'aie rêvé ?)
Lucas Levrel
Le 3 juin 2009, Jean-Claude Arbaut a écrit :
En prime, on pourra effectivement faire un cast dans la fonction appelante vers un (*)[n][n], et on pourra indicer si on y tient.
En fait, pourquoi *ici* utiliser le type (*)[][] plutôt que [][][], sachant qu'on travaille sur un tableau 3D (autrement dit toutes les rangées ont la même taille) ?
-- LL
Le 3 juin 2009, Jean-Claude Arbaut a écrit :
En prime, on pourra effectivement faire un cast dans la fonction
appelante vers un (*)[n][n], et on pourra indicer si on y tient.
En fait, pourquoi *ici* utiliser le type (*)[][] plutôt que [][][],
sachant qu'on travaille sur un tableau 3D (autrement dit toutes les
rangées ont la même taille) ?
En prime, on pourra effectivement faire un cast dans la fonction appelante vers un (*)[n][n], et on pourra indicer si on y tient.
En fait, pourquoi *ici* utiliser le type (*)[][] plutôt que [][][], sachant qu'on travaille sur un tableau 3D (autrement dit toutes les rangées ont la même taille) ?
-- LL
Jean-Claude Arbaut
On 3 juin, 17:38, Lucas Levrel wrote:
En fait, pourquoi *ici* utiliser le type (*)[][] plutôt que [][][], sachant qu'on travaille sur un tableau 3D (autrement dit toutes les rangées ont la même taille) ?
-- LL
Heu... joker :o)
On 3 juin, 17:38, Lucas Levrel <lucas.lev...@univ-paris12.fr> wrote:
En fait, pourquoi *ici* utiliser le type (*)[][] plutôt que [][][],
sachant qu'on travaille sur un tableau 3D (autrement dit toutes les
rangées ont la même taille) ?
En fait, pourquoi *ici* utiliser le type (*)[][] plutôt que [][][], sachant qu'on travaille sur un tableau 3D (autrement dit toutes les rangées ont la même taille) ?
C'est toi seul qui me prêtes des intentions de puriste en matière d'orthographe pour essayer de faire artificiellement cadrer tes propos à ce que j'écris. Connaissant mes faiblesses, je me suis toujours gardé de jouer les croisés en la matière. Ce qui ne m'a pas empêché de remettre à leur place les zélotes, souvent les premiers à défaillir (ça me rappelle un échange cocasse entre Gabriel dos Reis et E. Delahaye qui jouait au petit jeu de l'orthographe et qui avait pris une bonne fessée à cette occasion).
À l'instar d'E. Delahaye qui en essayant de me faire dire que les macroconstantes sont des constantes trahit peut-être que dans un passé plus ou moins ancien il partageait les propos qu'il me prête, je pense que la mise en cause que tu provoques cache tes défaillances en la matière, c'est assez classique. Et je me suis dit qu'en parcourant ton livre
.................."Programmez en assembleur" (2004)..................
et en cherchant un peu, je devrais trouver exactement le même genre de fautes d'orthographe que tu me reproches ci-dessus.
*) page 568, ligne 9 : Ce comportement peu évoquer l'effet papillon (...)
[confusion "peu" et "peut", niveau CM2]
*) page 537, dernière ligne : mais sur des données de 16 bits signées (SW) et 8 bits non signés (UB).
[des hésitations sexuelles M. Maurette ?]
*) page 259, ligne 21 : Dans le fichier source, rajoutez la ligne win.inc, où un autre gros fichier d'en-tête (...)
[confusion "ou" et "où", niveau CM2]
*) page 254, ligne 9 : Quand à la ligne 11, (...)
[confusion "quand" et "quant", niveau 6ème]
*) page 254, ligne 3 ou encore page 325, ligne -5 : à priori
[confusion "à" et "a" latin, consulter les pages roses] ----------------- >8 --------------------------------
Et tu n'as pas l'excuse d'écrire ça sur un forum de discussions.
Pierre Maurette a écrit :
Ai-je dis cela ?
C'est grave, pour un puriste...
C'est toi seul qui me prêtes des intentions de puriste en matière d'orthographe
pour essayer de faire artificiellement cadrer tes propos à ce que j'écris.
Connaissant mes faiblesses, je me suis toujours gardé de jouer les croisés en la
matière. Ce qui ne m'a pas empêché de remettre à leur place les zélotes, souvent
les premiers à défaillir (ça me rappelle un échange cocasse entre Gabriel dos
Reis et E. Delahaye qui jouait au petit jeu de l'orthographe et qui avait pris
une bonne fessée à cette occasion).
À l'instar d'E. Delahaye qui en essayant de me faire dire que les
macroconstantes sont des constantes trahit peut-être que dans un passé plus ou
moins ancien il partageait les propos qu'il me prête, je pense que la mise en
cause que tu provoques cache tes défaillances en la matière, c'est assez
classique. Et je me suis dit qu'en parcourant ton livre
.................."Programmez en assembleur" (2004)..................
et en cherchant un peu, je devrais trouver exactement le même genre de fautes
d'orthographe que tu me reproches ci-dessus.
C'est toi seul qui me prêtes des intentions de puriste en matière d'orthographe pour essayer de faire artificiellement cadrer tes propos à ce que j'écris. Connaissant mes faiblesses, je me suis toujours gardé de jouer les croisés en la matière. Ce qui ne m'a pas empêché de remettre à leur place les zélotes, souvent les premiers à défaillir (ça me rappelle un échange cocasse entre Gabriel dos Reis et E. Delahaye qui jouait au petit jeu de l'orthographe et qui avait pris une bonne fessée à cette occasion).
À l'instar d'E. Delahaye qui en essayant de me faire dire que les macroconstantes sont des constantes trahit peut-être que dans un passé plus ou moins ancien il partageait les propos qu'il me prête, je pense que la mise en cause que tu provoques cache tes défaillances en la matière, c'est assez classique. Et je me suis dit qu'en parcourant ton livre
.................."Programmez en assembleur" (2004)..................
et en cherchant un peu, je devrais trouver exactement le même genre de fautes d'orthographe que tu me reproches ci-dessus.
*) page 568, ligne 9 : Ce comportement peu évoquer l'effet papillon (...)
[confusion "peu" et "peut", niveau CM2]
*) page 537, dernière ligne : mais sur des données de 16 bits signées (SW) et 8 bits non signés (UB).
[des hésitations sexuelles M. Maurette ?]
*) page 259, ligne 21 : Dans le fichier source, rajoutez la ligne win.inc, où un autre gros fichier d'en-tête (...)
[confusion "ou" et "où", niveau CM2]
*) page 254, ligne 9 : Quand à la ligne 11, (...)
[confusion "quand" et "quant", niveau 6ème]
*) page 254, ligne 3 ou encore page 325, ligne -5 : à priori
[confusion "à" et "a" latin, consulter les pages roses] ----------------- >8 --------------------------------
Et tu n'as pas l'excuse d'écrire ça sur un forum de discussions.
candide
Pierre Maurette a écrit :
candide, le 03/06/2009 a écrit :
[...]
Ai-je dis cela ?
C'est grave, pour un puriste...
Pierre Maurette, "Programmez en assembleur", Micro Application (2004), page 358, ligne -12 :
"il aura suffit de saisir"
J'en ai d'autres à ta disposition. C'est grave, pour un auteur... T'as trouvé personne pour te relire ?
Le sous-titre du livre : "Maîtrisez les bases du langage machine". Et si tu commençais par maîtriser les bases du langage écrit de tous les jours ... Un bon lien : http://www.leconjugueur.com/php5/index.php?v=suffire
Mais bien sûr, je suis certain que la qualité du contenu de l'ouvrage fait oublier celle de son orthographe ...
Au fait, l'errata de ton livre, il est accessible à quelle url ?
Pierre Maurette a écrit :
candide, le 03/06/2009 a écrit :
[...]
Ai-je dis cela ?
C'est grave, pour un puriste...
Pierre Maurette, "Programmez en assembleur", Micro Application (2004),
page 358, ligne -12 :
"il aura suffit de saisir"
J'en ai d'autres à ta disposition. C'est grave, pour un auteur...
T'as trouvé personne pour te relire ?
Le sous-titre du livre : "Maîtrisez les bases du langage machine".
Et si tu commençais par maîtriser les bases du langage écrit de tous les jours
... Un bon lien : http://www.leconjugueur.com/php5/index.php?v=suffire
Mais bien sûr, je suis certain que la qualité du contenu de l'ouvrage fait
oublier celle de son orthographe ...
Au fait, l'errata de ton livre, il est accessible à quelle url ?
Pierre Maurette, "Programmez en assembleur", Micro Application (2004), page 358, ligne -12 :
"il aura suffit de saisir"
J'en ai d'autres à ta disposition. C'est grave, pour un auteur... T'as trouvé personne pour te relire ?
Le sous-titre du livre : "Maîtrisez les bases du langage machine". Et si tu commençais par maîtriser les bases du langage écrit de tous les jours ... Un bon lien : http://www.leconjugueur.com/php5/index.php?v=suffire
Mais bien sûr, je suis certain que la qualité du contenu de l'ouvrage fait oublier celle de son orthographe ...
Au fait, l'errata de ton livre, il est accessible à quelle url ?
Stéphane Zuckerman
On Jun 3, 5:38 pm, Lucas Levrel wrote:
Le 3 juin 2009, Jean-Claude Arbaut a écrit :
> En prime, on pourra effectivement faire un cast dans la fonction > appelante vers un (*)[n][n], et on pourra indicer si on y tient.
En fait, pourquoi *ici* utiliser le type (*)[][] plutôt que [][][], sachant qu'on travaille sur un tableau 3D (autrement dit toutes les rangées ont la même taille) ?
À ma connaissance, à moins d'avoir déclaré le tableau en début de fonction, et donc de l'avoir alloué sur la pile, déclarer un objet de type « type o[M][N][K] » ne sert à « rien » concernant la pre mière dimension. Les tableaux « multidimensionnels » à N dimensions, mê me déclarés avec toutes leurs dimensions, sont vus par le compilateur comme un pointeur vers des tableaux à N-1 dimensions, si je ne me trompe pas :
On Jun 3, 5:38 pm, Lucas Levrel <lucas.lev...@univ-paris12.fr> wrote:
Le 3 juin 2009, Jean-Claude Arbaut a écrit :
> En prime, on pourra effectivement faire un cast dans la fonction
> appelante vers un (*)[n][n], et on pourra indicer si on y tient.
En fait, pourquoi *ici* utiliser le type (*)[][] plutôt que [][][],
sachant qu'on travaille sur un tableau 3D (autrement dit toutes les
rangées ont la même taille) ?
À ma connaissance, à moins d'avoir déclaré le tableau en début de
fonction, et donc de l'avoir alloué sur la pile, déclarer un objet de
type « type o[M][N][K] » ne sert à « rien » concernant la pre mière
dimension. Les tableaux « multidimensionnels » à N dimensions, mê me
déclarés avec toutes leurs dimensions, sont vus par le compilateur
comme un pointeur vers des tableaux à N-1 dimensions, si je ne me
trompe pas :
> En prime, on pourra effectivement faire un cast dans la fonction > appelante vers un (*)[n][n], et on pourra indicer si on y tient.
En fait, pourquoi *ici* utiliser le type (*)[][] plutôt que [][][], sachant qu'on travaille sur un tableau 3D (autrement dit toutes les rangées ont la même taille) ?
À ma connaissance, à moins d'avoir déclaré le tableau en début de fonction, et donc de l'avoir alloué sur la pile, déclarer un objet de type « type o[M][N][K] » ne sert à « rien » concernant la pre mière dimension. Les tableaux « multidimensionnels » à N dimensions, mê me déclarés avec toutes leurs dimensions, sont vus par le compilateur comme un pointeur vers des tableaux à N-1 dimensions, si je ne me trompe pas :
> Bon en définitive, pour un serveur web, la mémoire statique est ada ptée ou pas ?
Je pense qu'Antoine a raison, et j'ai pris un mauvais exemple ;-) Pour un serveur, si on peut borner à l'avance la ram utilisée, c'est une bonne chose, puisqu'on est sûr qu'il ne va pas bouffer toute la ram plus tard. Pour les codes de calcul par contre c'est particulièrement évident que l'on peut, il suffit de voi r les masses de codes écrits en fortran pré-90 depuis plus de 50 ans. (au passage, fortran a eu longtemps un avantage sur le C à propos d'une histoire d'aliasing, et je crois avoir vu que c'est corrigé dans le standard C actuel, avec des pointeurs "restrict", à moins que j'aie rêvé ?)
En C99 on peut utiliser « restrict » pour indiquer que deux pointeurs pointent vers des zones mémoires disjointes, oui. Concernant le calcul scientifique, on est généralement capable de mettre une borne sur les problèmes oui, mais ça veut surtout dire qu'on est capable de dire « pour traiter tel cas précis avec telle méthode, il me faudra tant de mémoire ». On fait ça aussi lorsqu'on dimensionne une base de données, ou tout autre application critique ramophage non ? Même un serveur web est configurable pour indiquer le nombre de connexions maximum qu'on peut effectuer dessus (par exemple à cause des contraintes de bande-passante...).
On Jun 3, 5:28 pm, Jean-Claude Arbaut <micromegas...@gmail.com> wrote:
On 3 juin, 16:20, candide <cand...@free.invalid> wrote:
> Bon en définitive, pour un serveur web, la mémoire statique est ada ptée ou pas ?
Je pense qu'Antoine a raison, et j'ai pris un mauvais exemple ;-)
Pour un serveur, si on peut borner à l'avance la ram utilisée,
c'est une bonne chose, puisqu'on est sûr qu'il ne va pas
bouffer toute la ram plus tard. Pour les codes de calcul par
contre c'est particulièrement évident que l'on peut, il suffit de voi r
les masses de codes écrits en fortran pré-90 depuis plus de 50 ans.
(au passage, fortran a eu longtemps un avantage sur le C à propos
d'une histoire d'aliasing, et je crois avoir vu que c'est corrigé dans
le standard C actuel, avec des pointeurs "restrict", à moins que j'aie
rêvé ?)
En C99 on peut utiliser « restrict » pour indiquer que deux pointeurs
pointent vers des zones mémoires disjointes, oui.
Concernant le calcul scientifique, on est généralement capable de
mettre une borne sur les problèmes oui, mais ça veut surtout dire
qu'on est capable de dire « pour traiter tel cas précis avec telle
méthode, il me faudra tant de mémoire ». On fait ça aussi lorsqu'on
dimensionne une base de données, ou tout autre application critique
ramophage non ? Même un serveur web est configurable pour indiquer le
nombre de connexions maximum qu'on peut effectuer dessus (par exemple
à cause des contraintes de bande-passante...).
> Bon en définitive, pour un serveur web, la mémoire statique est ada ptée ou pas ?
Je pense qu'Antoine a raison, et j'ai pris un mauvais exemple ;-) Pour un serveur, si on peut borner à l'avance la ram utilisée, c'est une bonne chose, puisqu'on est sûr qu'il ne va pas bouffer toute la ram plus tard. Pour les codes de calcul par contre c'est particulièrement évident que l'on peut, il suffit de voi r les masses de codes écrits en fortran pré-90 depuis plus de 50 ans. (au passage, fortran a eu longtemps un avantage sur le C à propos d'une histoire d'aliasing, et je crois avoir vu que c'est corrigé dans le standard C actuel, avec des pointeurs "restrict", à moins que j'aie rêvé ?)
En C99 on peut utiliser « restrict » pour indiquer que deux pointeurs pointent vers des zones mémoires disjointes, oui. Concernant le calcul scientifique, on est généralement capable de mettre une borne sur les problèmes oui, mais ça veut surtout dire qu'on est capable de dire « pour traiter tel cas précis avec telle méthode, il me faudra tant de mémoire ». On fait ça aussi lorsqu'on dimensionne une base de données, ou tout autre application critique ramophage non ? Même un serveur web est configurable pour indiquer le nombre de connexions maximum qu'on peut effectuer dessus (par exemple à cause des contraintes de bande-passante...).
