appréhension sur les "break"

In article <hjnsqvgt46a2h5i5m0sq8akkqf3iqlunp7@4ax.com>,
Fabien LE LEZ <usenet2@gramster.com> wrote:

On Sun, 9 Nov 2003 14:34:28 +0000 (UTC), espie@tetto.gentiane.org
(Marc Espie) wrote:

J'avoue que je ne vois pas trop l'interet d'utiliser un langage si, dans
le meme temps, on nie certaines des constructions idiomatiques les plus
repandues du-dit langage...

Mais break est-il une "expression idiomatique" ou une "sale bidouille
à la 'goto'" ? That is the question...

La reponse est claire: break ne pose aucun des problemes poses par goto.
Le gros probleme de goto, c'est un saut non local de n'importe ou a
n'importe ou. En presence de goto, on ne peut plus rien ecrire qui
ressemble a une pre-condition ou une post-condition (enfin si, on peut,
mais bonjour l'explosion combinatoire).

Pour ce qui est de break, on sait ou on arrive, on sait d'ou on vient,
et ca reste purement local.

C'est purement mecanique de transformer un programme avec break en
programme sans break, par exemple. Tandis qu'eliminer des goto, c'est
un peu plus complique.

Cote semantique, entre exprimer des conditions tordues a coup de variables
locales booleennes (toujours vachement evident a formaliser dans un
prouveur automatique, ca) et laisser trainer quelques break bien places,
le choix est vite fait... surtout que pour pas mal de problemes, on se
plante moins avec le break qu'avec la variable a la con...

Ca me parait de toutes facons bien moins sujet a controverse que la gestion
des exceptions, qui elles, sont un exemple de branchement non local
extremement peu intuitif a maitriser...

espie@tetto.gentiane.org (Marc Espie) writes:

| J'avoue que je ne vois pas trop l'interet d'utiliser un langage si, dans
| le meme temps, on nie certaines des constructions idiomatiques les plus
| repandues du-dit langage...

et l'utilisation de « break » est si répandue que ça dans les codes de
qualité ?

-- Gaby

espie@tetto.gentiane.org (Marc Espie) writes:

| In article <hjnsqvgt46a2h5i5m0sq8akkqf3iqlunp7@4ax.com>,
| Fabien LE LEZ <usenet2@gramster.com> wrote:
| >On Sun, 9 Nov 2003 14:34:28 +0000 (UTC), espie@tetto.gentiane.org
| >(Marc Espie) wrote:
| >
| >>J'avoue que je ne vois pas trop l'interet d'utiliser un langage si, dans
| >>le meme temps, on nie certaines des constructions idiomatiques les plus
| >>repandues du-dit langage...
| >
| >Mais break est-il une "expression idiomatique" ou une "sale bidouille
| >à la 'goto'" ? That is the question...
|
| La reponse est claire: break ne pose aucun des problemes poses par goto.

hmm, je ne suis pas convaincu.

Tu reconnias probablement le bout code de code suivant

/* Decode the list of parameter types for a function type.
Given the list of things declared inside the parens,
return a list of types.

We determine whether ellipsis parms are used by PARMLIST_ELLIPSIS_P
flag. If unset, we append void_list_node. A parmlist declared
as `(void)' is accepted as the empty parmlist.

Also set last_function_parms to the chain of PARM_DECLs. */

static tree
grokparms (tree first_parm)
{
tree result = NULL_TREE;
tree decls = NULL_TREE;
int ellipsis = !first_parm || PARMLIST_ELLIPSIS_P (first_parm);
tree parm, chain;
int any_error = 0;

my_friendly_assert (!first_parm || TREE_PARMLIST (first_parm), 20001115);

for (parm = first_parm; parm != NULL_TREE; parm = chain)
{
tree type = NULL_TREE;
tree decl = TREE_VALUE (parm);
tree init = TREE_PURPOSE (parm);
tree specs, attrs;

chain = TREE_CHAIN (parm);
/* @@ weak defense against parse errors. */
if (TREE_CODE (decl) != VOID_TYPE
&& TREE_CODE (decl) != TREE_LIST)
{
/* Give various messages as the need arises. */
if (TREE_CODE (decl) == STRING_CST)
error ("invalid string constant `%E'", decl);
else if (TREE_CODE (decl) == INTEGER_CST)
error ("invalid integer constant in parameter list, did you forget to give parameter name?");
continue;
}

if (parm == void_list_node)
break;

split_specs_attrs (TREE_PURPOSE (decl), &specs, &attrs);
decl = grokdeclarator (TREE_VALUE (decl), specs,
PARM, init != NULL_TREE, &attrs);
if (! decl || TREE_TYPE (decl) == error_mark_node)
continue;

if (attrs)
cplus_decl_attributes (&decl, attrs, 0);

type = TREE_TYPE (decl);
if (VOID_TYPE_P (type))
{
if (same_type_p (type, void_type_node)
&& !DECL_NAME (decl) && !result && !chain && !ellipsis)
/* this is a parmlist of `(void)', which is ok. */
break;
cxx_incomplete_type_error (decl, type);
/* It's not a good idea to actually create parameters of
type `void'; other parts of the compiler assume that a
void type terminates the parameter list. */
type = error_mark_node;
TREE_TYPE (decl) = error_mark_node;
}

if (type != error_mark_node)
{
/* Top-level qualifiers on the parameters are
ignored for function types. */
type = cp_build_qualified_type (type, 0);
if (TREE_CODE (type) == METHOD_TYPE)
{
error ("parameter `%D' invalidly declared method type", decl);
type = build_pointer_type (type);
TREE_TYPE (decl) = type;
}
else if (abstract_virtuals_error (decl, type))
any_error = 1; /* Seems like a good idea. */
else if (POINTER_TYPE_P (type))
{
/* [dcl.fct]/6, parameter types cannot contain pointers
(references) to arrays of unknown bound. */
tree t = TREE_TYPE (type);
int ptr = TYPE_PTR_P (type);

while (1)
{
if (TYPE_PTR_P (t))
ptr = 1;
else if (TREE_CODE (t) != ARRAY_TYPE)
break;
else if (!TYPE_DOMAIN (t))
break;
t = TREE_TYPE (t);
}
if (TREE_CODE (t) == ARRAY_TYPE)
error ("parameter `%D' includes %s to array of unknown bound `%T'",
decl, ptr ? "pointer" : "reference", t);
}

if (!any_error && init)
init = check_default_argument (decl, init);
else
init = NULL_TREE;
}

TREE_CHAIN (decl) = decls;
decls = decl;
result = tree_cons (init, type, result);
}
decls = nreverse (decls);
result = nreverse (result);
if (!ellipsis)
result = chainon (result, void_list_node);
last_function_parms = decls;

return result;
}


-- Gaby

In article <m3fzgxmjt7.fsf@uniton.integrable-solutions.net>,
Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:

Tu reconnias probablement le bout code de code suivant

Ouais, mais la, commence par formatter ca autrement qu'avec cette atrocite
de gnu coding standards, et ca deviendra peut-etre un tantinet plus clair.

Il y aussi le coup d'ecrire du lisp en C qui est passablement douteux.


Et enfin, rien que quand on voit les commentaires, ca laisse reveur...

/* Decode the list of parameter types for a function type.
Given the list of things declared inside the parens,
return a list of types.

We determine whether ellipsis parms are used by PARMLIST_ELLIPSIS_P
flag. If unset, we append void_list_node. A parmlist declared
as `(void)' is accepted as the empty parmlist.

Also set last_function_parms to the chain of PARM_DECLs. */

static tree
grokparms (tree first_parm)
{
tree result = NULL_TREE;
tree decls = NULL_TREE;
int ellipsis = !first_parm || PARMLIST_ELLIPSIS_P (first_parm);
tree parm, chain;
int any_error = 0;

my_friendly_assert (!first_parm || TREE_PARMLIST (first_parm), 20001115);

for (parm = first_parm; parm != NULL_TREE; parm = chain)
{
tree type = NULL_TREE;
tree decl = TREE_VALUE (parm);
tree init = TREE_PURPOSE (parm);
tree specs, attrs;

chain = TREE_CHAIN (parm);
/* @@ weak defense against parse errors. */
if (TREE_CODE (decl) != VOID_TYPE
&& TREE_CODE (decl) != TREE_LIST)
{
/* Give various messages as the need arises. */
if (TREE_CODE (decl) == STRING_CST)
error ("invalid string constant `%E'", decl);
else if (TREE_CODE (decl) == INTEGER_CST)
error ("invalid integer constant in parameter list, did
you forget to give parameter name?");
continue;
}

if (parm == void_list_node)
break;

split_specs_attrs (TREE_PURPOSE (decl), &specs, &attrs);
decl = grokdeclarator (TREE_VALUE (decl), specs,
PARM, init != NULL_TREE, &attrs);
if (! decl || TREE_TYPE (decl) == error_mark_node)
continue;

if (attrs)
cplus_decl_attributes (&decl, attrs, 0);

type = TREE_TYPE (decl);
if (VOID_TYPE_P (type))
{
if (same_type_p (type, void_type_node)
&& !DECL_NAME (decl) && !result && !chain && !ellipsis)
/* this is a parmlist of `(void)', which is ok. */
break;
cxx_incomplete_type_error (decl, type);
/* It's not a good idea to actually create parameters of
type `void'; other parts of the compiler assume that a
void type terminates the parameter list. */
type = error_mark_node;
TREE_TYPE (decl) = error_mark_node;
}

if (type != error_mark_node)
{
/* Top-level qualifiers on the parameters are
ignored for function types. */
type = cp_build_qualified_type (type, 0);
if (TREE_CODE (type) == METHOD_TYPE)
{
error ("parameter `%D' invalidly declared method type", decl);
type = build_pointer_type (type);
TREE_TYPE (decl) = type;
}
else if (abstract_virtuals_error (decl, type))
any_error = 1; /* Seems like a good idea. */
else if (POINTER_TYPE_P (type))
{
/* [dcl.fct]/6, parameter types cannot contain pointers
(references) to arrays of unknown bound. */
tree t = TREE_TYPE (type);
int ptr = TYPE_PTR_P (type);

while (1)
{
if (TYPE_PTR_P (t))
ptr = 1;
else if (TREE_CODE (t) != ARRAY_TYPE)
break;
else if (!TYPE_DOMAIN (t))
break;
t = TREE_TYPE (t);
}
if (TREE_CODE (t) == ARRAY_TYPE)
error ("parameter `%D' includes %s to array of unknown
bound `%T'",
decl, ptr ? "pointer" : "reference", t);
}

if (!any_error && init)
init = check_default_argument (decl, init);
else
init = NULL_TREE;
}

TREE_CHAIN (decl) = decls;
decls = decl;
result = tree_cons (init, type, result);
}
decls = nreverse (decls);
result = nreverse (result);
if (!ellipsis)
result = chainon (result, void_list_node);
last_function_parms = decls;

return result;
}


-- Gaby

Ne penses tu pas qu une imbrication de if then else peut rendre un
algorithme

presque illisible ?

Jusqu'à un certain niveau c'est acceptable. Après il vaut mieux créer une
fonction, surtout pour la réutisabilité. On retrouve souvent un même
algorithme à plusieurs endroits d'un programme, vive les fonctions.

Niveau lisibilité, un programme bien indenté est toujours plus facile à
comprendre qu'un programme un peu plus linéaire avec des break. Rien
n'indique "le label" auquel fait sauter le break, sauf l'accolade larmoyante
de notre pauvre if conditionné :).

L appel d une fonction a un cout, non ?

Ahah :). Non sérieusement je me posais la question quand j'étais sous DOS à
programmer en assembleur sur mon Cyrix 166 mais ce sont les boucles
critiques d'un programme qui importent. Un appel de fonction se résumer à
empiler des valeurs, déplacer un pointeur mémoire et dépiler pour exécuter
le corps de la fonction. Même quand je faisais du "hardcoding" je me suis
vite rendu compte que les appels de fonctions ne coûtaient vraiment rien.
Une solution peut consister à déclarer sa fonction inline pour éviter tout
cette gestion d'assiettes, la pile peut se casser la gueule :)

Je suis pret a te soumettre une methode dirigee par une profonde
imbrication

de if then else, sous la contrainte que l efficacite est essentielle.

Si tu penses qu'on peut t'aider, n'hésite pas à poster !

Bof, bof, bof... dans pas mal de cas, pour moi, le break et le continue
sont juste la facon `naturelle' de continuer. Par exemple, lorsque je

suis en train de traiter un fichier de configuration `oriente ligne',
zapper les lignes de commentaires avec un `continue' marche tres bien.

En fait il ne faut pas oublier qu'il s'agit de répondre à un état.
Dans le cas d'un break il n'y a plus de notion d'état. Si il y a un OUI, il
y a toujours un NON conditionnel. Le si sinon.
En utilisant un break on perd le contrôle d'un état, le OUI ou le NON. Pire
encore s'il s'agit d'une condition multiple (if imbriqués combinés par des
opérateurs logiques ET/OU).

En effet. Mais il faut tout de même faire attention. On ne va pas non plus
se mettre à utiliser goto à tour de bras parce qu'il fait partie du

langage...

Excellente remarque.
Certains n'en sont pas convaincus mais je pense que la démonstration est
toute simple.
Un break/continue peut-être très facilement remplacé par un goto. Il suffit
de renommer son break ou continue en goto avec le nom du label (ça remonte à
l'époque où je programmais en QBASIC ^^) et de créer un label (une étiquette
?) à l'endroit où le break ou le continue nous conduit.
Le break/continue ou le goto n'est pas une instruction de contrôle à
proprement parlé, elle peut être contrôlé par une instruction de contrôle
comme un if.

Mais break est-il une "expression idiomatique" ou une "sale bidouille
à la 'goto'" ? That is the question...

Pour moi c'est une solution de facilité pour éviter de trop penser aux
moyens dont l'on dispose pour résoudre un problème donné. Au début je
passais pas mal de temps à élaborer un algo puis chemin faisant on s'en sort
mieux qu'en utilisant des break à tort et à travers.

La reponse est claire: break ne pose aucun des problemes poses par goto.
Le gros probleme de goto, c'est un saut non local de n'importe ou a

n'importe ou. En presence de goto, on ne peut plus rien ecrire qui
ressemble a une pre-condition ou une post-condition (enfin si, on peut,
mais bonjour l'explosion combinatoire).

C'est un peu vrai mais le break ne reste qu'un goto camouflé avec un champ
limité d'action, celui des blocs d'instructions. Le goto peut agir sur des
labels, le break et le continue sur les fins ou débuts de blocs.

Cote semantique, entre exprimer des conditions tordues a coup de variables
locales booleennes (toujours vachement evident a formaliser dans un

prouveur automatique, ca) et laisser trainer quelques break bien places,
le choix est vite fait... surtout que pour pas mal de problemes, on se
plante moins avec le break qu'avec la variable a la con...

Autre avantage, de ne pas utiliser des break, c'est de pouvoir donner un nom
à un état. En utilisant des variables et des instructions de contrôle comme
le if, on peut déterminer à un instant donné, l'état de notre programme.
Quand on utilise un débogueur, c'est vital ! Et quand on parle de POO c'est
encore plus vrai puis que tout n'est qu'objet, états et opérations. Quand un
break est "triggeré" (je compare vraiment ça aux exceptions - mais j'adore
les exceptions :p) comment peut-on déterminer l'état du programme ? Est-ce
que le break nous indique où on en est ? Quels sont les états de nos objets
? La seule solution c'est de remonter le temps, de faire du backward
debugging en quelque sorte et de retrouver les instructions précédemment
exécutées... Affections, appels de fonctions... Jusqu'au if (ou autre) qui a
justement conditionné notre break.

Et si on en arrive à nos intructions de contrôle, on se demande alors...
Mais à quoi sert notre break dans tout ça ? Qui dit SI (if), dit SINON (else
if). L'un de DOIT PAS aller sans l'autre. On peut comparer ça aux vieux
couplex Mme Constructeur et Mr Destructeur, new et delete (vive les
smart_ptr ^^), etc...

Note : faut quand même relativiser toute cette théorie comme on me l'a fait
remarquer. Si quelqu'un s'en sort avec des breaks, autant faire avec. Pas
besoin de changer ses habitudes (qui ne sont pas forcément mauvaises, plutôt
bénéfiques pour vous même). Mais vous pouvez toujours comparer. J'ai encore
peu d'expérience mais j'ai commencé à développer en assembleur sur Thomson
MO5, j'en ai vu passer des atrocités, de la programmation avec lignes
numérotées... Alors maintenant que je peux disposer d'outils plus logiques
et plus puissants, je fais avec :)

Mlle Si épousa Mr Sinon, ils eurent beaucoup de petits enfants : Éxception
pour la petite dernière :p
JM

--
Clé AntiPourriel : PASUNPOURRIEL (ne pas retirer)

espie@tetto.gentiane.org (Marc Espie) wrote in message
news:<bolj9k$1muu$1@biggoron.nerim.net>...

Bof, bof, bof... dans pas mal de cas, pour moi, le break et le
continue sont juste la facon `naturelle' de continuer. Par exemple,
lorsque je suis en train de traiter un fichier de configuration
`oriente ligne', zapper les lignes de commentaires avec un `continue'
marche tres bien.

Utiliser un streambuf filtrant marche encore mieux, et nécessite pas de
continue:-). Melanger le filtrage des commentaires et le traitement de
la ligne, c'est bien faire une fonction qui en fait trop.

Il y a aussi toutes ces boucles ou la condition d'arret s'exprime au
milieu de la boucle qui donnent naturellement des

while (1) {
debut_de_boucle();
if (cond)
break;
fin_de_boucle();
}

Sauf que dans tous les exemples réels que j'ai vu, ça quelque chose du
genre :

for ( debut_de_boucle() ; cond ; debut_de_boucle() ) {
fin_de_boucle() ;
}

est en fait plus clairs. (Je ne dis pas qu'il n'y a pas d'execptions,
seulement que je n'en ai pas encore vues.)

Lorsque je n'ai pas de STL sous la main, une bonne boucle de recherche
dans un tableau ressemble souvent a:

for (i = 0; i < n; i++) {
if (element_trouve)
break;
}

pour moi...

Et non :

for ( i = 0 ; i < n && ! element_trouve ; i ++ ) {
}

?

(et, dans des cas plus compliques, c'est souvent plus immediat de
faire le boulot directement que d'aller pondre l'adaptateur qui va
bien pour utiliser un algo standard... et si c'est du code qui ne sera
pas etendu plus tard, ca ne sert a rien de vouloir faire general a
outrance)

c'est infiniment plus clair de separer proprement le parcours du
tableau de la recherche de l'element. Je trouve particulierement
atroce la variante pascalienne

for (i = 0; i < n && !found; i++) {
if (element_trouve)
found = true;
}

Le `found', dans ce contexte, n'ajoute pour moi que du bruit, et n'est
clairement pas idiomatique, ni du C, ni du C++.

Ça dépend de la condition. Si la condition est complex, lui donner un
nom apporte de la lucidité.

Il faut dire qu'en général, si tu recherches un élément, c'est pour en
faire quelque chose avec lui après. Donc, immédiatement après la boucle,
il y aurait un :

if ( found ) {
// fait ce qu'il faut...
}

(Mais j'imagine que n'importe quel programmeur digne du nom n'a pas
attendue la STL pour écrire sa propre fonction de recherche linéaire.
Avant la STL, j'aurais écris quelque chose du genre :

int i = find( table, length, condition ) ;
if ( i >= 0 ) {
// fait ce qu'il faut ...
}

En terme de robustesse du code, il n'apporte rien non plus. Aucune des
deux variantes n'est plus difficile a prouver que l'autre.

J'avoue que je ne vois pas trop l'interet d'utiliser un langage si,
dans le meme temps, on nie certaines des constructions idiomatiques
les plus repandues du-dit langage...

Ce n'est pas parce que j'écrivais du C que j'écrivais :

while ( *s ++ = *t ++ ) ;

Ce n'est pas parce que c'est possible qu'il faut le faire.

--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

Gabriel Dos Reis <gdr@integrable-solutions.net> wrote in message
news:<m3llqpmkb7.fsf@uniton.integrable-solutions.net>...

espie@tetto.gentiane.org (Marc Espie) writes:

| J'avoue que je ne vois pas trop l'interet d'utiliser un langage si,
| dans le meme temps, on nie certaines des constructions idiomatiques
| les plus repandues du-dit langage...

et l'utilisation de « break » est si répandue que ça dans les codes de
qualité ?

Dans les switch, oui. Autrement... Il n'y en a pas dans le code à
gabi-soft.fr:-).

--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

kanze@gabi-soft.fr writes:

| Gabriel Dos Reis <gdr@integrable-solutions.net> wrote in message
| news:<m3llqpmkb7.fsf@uniton.integrable-solutions.net>...
| > espie@tetto.gentiane.org (Marc Espie) writes:
|
| > | J'avoue que je ne vois pas trop l'interet d'utiliser un langage si,
| > | dans le meme temps, on nie certaines des constructions idiomatiques
| > | les plus repandues du-dit langage...
|
| > et l'utilisation de « break » est si répandue que ça dans les codes de
| > qualité ?
|
| Dans les switch, oui.

J'ai naturellement excepté les switch (comme l'indiquait le posteur
initial) -- même si je m'attend à moins de switch dans un programme
C++ que dans un programme C.

| Autrement... Il n'y en a pas dans le code à gabi-soft.fr:-).

-- Gaby

Gabriel Dos Reis <gdr@integrable-solutions.net> wrote in message
news:<m34qxceedm.fsf@uniton.integrable-solutions.net>...

kanze@gabi-soft.fr writes:

| Gabriel Dos Reis <gdr@integrable-solutions.net> wrote in message
| news:<m3llqpmkb7.fsf@uniton.integrable-solutions.net>...
| > espie@tetto.gentiane.org (Marc Espie) writes:

| > | J'avoue que je ne vois pas trop l'interet d'utiliser un langage
| > | si, dans le meme temps, on nie certaines des constructions
| > | idiomatiques les plus repandues du-dit langage...

| > et l'utilisation de « break » est si répandue que ça dans les
| > codes de qualité ?

| Dans les switch, oui.

J'ai naturellement excepté les switch (comme l'indiquait le posteur
initial) -- même si je m'attend à moins de switch dans un programme
C++ que dans un programme C.

Tout à fait. Je ne m'en sers que très modéremment aujourd'hui.
Prèsqu'exclusivement quand il s'agit de parser une entrée, d'ailleurs.

--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

"Marc Espie" <espie@tetto.gentiane.org> a écrit dans le message de
news:bolj9k$1muu$1@biggoron.nerim.net...

Bof, bof, bof... dans pas mal de cas, pour moi, le break et le continue
sont juste la facon `naturelle' de continuer. Par exemple, lorsque je
suis en train de traiter un fichier de configuration `oriente ligne',
zapper les lignes de commentaires avec un `continue' marche tres bien.

Il y a aussi toutes ces boucles ou la condition d'arret s'exprime au
milieu de la boucle qui donnent naturellement des

while (1) {
debut_de_boucle();
if (cond)
break;
fin_de_boucle();
}
<snip>

une solution du genre :

bool bSortir = false;
while(!bSortir)
{
if( test_condition_de_bord)
bSortie = true;
else if(test_autre_condition_de_sortie)
bSortie = true;
// etc... qq else if sur chaque test qui peut mettre fin à la boucle
else
{...} // ici le code executé dans la boucle
}

plus propre, certes, lisible même avec 36 else if... j'aime assez ;-)
Evidement, ici c'est brut mais ce type de truc évite la plupart du temps
break/continue et les imbrications, peu lisibles il est vrai.

Pour moi, break c'est de l'assembleur ;-) on dirait presque un goto / JMP.
A éviter, à mon avis.
C'est pour ça que je ne fais pas souvent de switch, j'aime pas trop comme il
est implémenté. Et pi y marche que sur des int.