[ALGO] Notation en algorithmique

Version imprimable

Voir 40 message(s) de cette discussion en une page

02/06/2007, 17h20
O( N )

Merci pour ta réponse :king: (au pluriel)

- Non je ne te trouve pas sévère, il faut être clair sinon déjà que ce n'est pas évident de se comprendre
dans une même langue alors si on se donne des difficultés ... :P

- Oui je n'affecte pas un type à une variable (il était un peu tôt (ou tard) désolé)

- Quand je marque Init F(x) = F(2) je veux indiquer que l'algorithme commence par 2
quelquesoit x et F est le nom d'un algorithme.

Par exemple un algorithme utilisant des compteurs
Disons ALGO(i, j, T) ou i et j sont des entiers utilisés comme compteurs et T un Tableau.

Init ALGO(i, j, T) = ALGO(0, 0, T).
Donc l'appel de ALGO(v,w, T) donnera ALGO(0,0, T) quelquesoit v,w.

- Je ne distingue pas l'initialisation de l'affectation,
je montrais comment affecter à une valeur dans ma notation et l'initialisation est une obligation.

Au lieu d'écrire X:=2(pascal...) ou x=2(C...) ou ...
j'écris
MesConditions => MONALGO(x,y,...) = MONALGO(2, y, ...)

- Pour les & et les || je suis d'accord il est important de lire facilement et
donc il serait mieux venu d'écrire ET et OU directement.

- Pour l'arité, ce n'était pas le but ici.

On peut trés bien avoir un algorithme qui ne dépendent que d'une partie des données présentes d'où l'appel que j'ai fait !
Ce n'était peut-être pas bienvenue car effectivement on pouvait le voir aussi comme cela.

On peut tout aussi écrire (a>x) => G(x,a) = F(x, (a-x))

Merci encore...

P.S. : Avec cette méthode d'écriture j'ai appris à voir et calculer les complexités.
Puisque l'algorithme se retrouve à être une liste de
'Pour çà => l'algo(...) = l'algo(...)'
Je peux décelé le cas Max assez rapidement.

Peut-être que d'autres méthodes le font tout aussi mieux voire mieux ! (en tout cas j'ai appris dessus :D )
05/06/2007, 10h32
PRomu@ld

Citation:

- Quand je marque Init F(x) = F(2) je veux indiquer que l'algorithme commence par 2
quelquesoit x et F est le nom d'un algorithme.

Par exemple un algorithme utilisant des compteurs
Disons ALGO(i, j, T) ou i et j sont des entiers utilisés comme compteurs et T un Tableau.

Init ALGO(i, j, T) = ALGO(0, 0, T).
Donc l'appel de ALGO(v,w, T) donnera ALGO(0,0, T) quelquesoit v,w.

Je ne comprend toujours pas pourquoi tu le fais avec le nom de tes fonctions ou procédures (ou algorithme ce qui revient aussi au même).

En fait pourquoi ne pas faire l'initialisation directement après la déclaration de la signature de ton algo.

Citation:

- Je ne distingue pas l'initialisation de l'affectation,

Si, visiblement c'est ce que tu es en train de faire, tu distingues l'initialisation de ton algorithme de l'affectation d'une variable nécessaire à ton algorithme. En fait sur ce que je comprend tu as une approche relativement orienté sur les noms des algorithmes, j'aurai tendance à avoir une orientation plus du coté des variables, ça m'aide à avoir des invariants de boucle ou de structure facilement (surtout au niveau de la lourdeur de l'écriture).
05/06/2007, 11h22
O( N )

Citation:

Envoyé par PRomu@ld

Je ne comprend toujours pas pourquoi tu le fais avec le nom de tes fonctions ou procédures (ou algorithme ce qui revient aussi au même).

En fait pourquoi ne pas faire l'initialisation directement après la déclaration de la signature de ton algo.

Si, visiblement c'est ce que tu es en train de faire, tu distingues l'initialisation de ton algorithme de l'affectation d'une variable nécessaire à ton algorithme.

On peut, y a pas de soucis, j'ai appris comme cela. :D
L'habitude est tenace surtout dans l'erreur...
J'ai rien contre modifié cet aspect.
Je distingue uniquement initialisation de affectation par le mot init devant
sinon c'est la même chose (c'est pour cette raison que j'ai indiqué que je ne les distinguais pas ;) )

Citation:

Envoyé par PRomu@ld

En fait sur ce que je comprend tu as une approche relativement orienté sur les noms des algorithmes, j'aurai tendance à avoir une orientation plus du coté des variables, ça m'aide à avoir des invariants de boucle ou de structure facilement (surtout au niveau de la lourdeur de l'écriture).

Tu peux me montrer comment, je ne vois pas trop là ?
05/06/2007, 11h22
Gueritarish
Salut à tous,

Ayant fait pas mal d'algorithmique, je trouve quelques unes de vos réponses un peu bizarre... (je sais, vous allez dire "le mec, il est même pas membre du club, il a écrit 4 pauvres messages, et il arrive tranquille..." ^^)
Bref, je me permets de rentrer dans cette discussion, parce qu'il me semble que l'algorithmique est quelque chose d'absolument intéressant. (vous allez penser "le fou !!!" :aie: ) En fait, dans la plupart des cours que j'ai eu, on écrivait des algo de la façon la plus proche possible du langage naturel. Je m'explique :
Quand on déclare une variable, on écrit

Code:

Entier x

Pour les affectations de variables, il est vrai qu'il est préférable de les démarquer des tests d'égalité, c'est pourquoi je préfère le

Code:

x := valeur

Les structures de controle doivent avoir des "début" et des "fin"
Code:

1 2 POUR i allant de 0 à 10 FAIRE <div style="margin-left:40px">BEGIN</div><div style="margin-left:40px">...</div><div style="margin-left:40px">END</div>FINPOUR
Généralement, plutôt que d'écrire

Code:

x = F(y)

On préfère détailler ce que fais la fonction et y ajouter ces paramètres du genre

Code:

trier le tableau T en partant de l'indice i

Enfin, tout ces manières de faire peuvent sembler étrange, mais à la relecture de l'algorithme, même quelqu'un qui n'a jamais fais de programmation (ou autre choses velues :mouarf: ...) arrive facilement à comprendre l'algo

Voila, ce sera ma petite comtribution à ce topic ^^

:king:
05/06/2007, 11h36
O( N )

Merci pour ta contribution Gueritarish :king:

Je comprends ce que tu veux dire !
J'ai fait de l'algorithmique comme cela avant et
elle (l'algorithmique) était présentée comme cela pour
s'harmoniser avec un langage de programmation qu'on allaient apprendre après (le pascal) ...

C'est lisible mais pas trés efficace pour calculer les complexités, (détection de cas max, d'appel à d'autres algorithmes ...)
j'ai essayé, mais sinon c'est plus proche d'une langue maternelle c'est sûr ! :P

Comme pour les algorithmes on veut aussi calculer leur performences,
il est intéressant de se poser la question de l'écriture au niveaux de la visibilité des calculs dans ce domaine.

Par suite aussi pour écrire dans un langage commun, nous devons nous rapprocher d'un langage commun.

+ n'est pas écrit différement dans les autres langues ?
mais 'trouver l'élément' n'est pas lisible pour quelqu'un ne parlant pas le français.

Or ce que l'on cherche c'est d'avoir une méthode plus universelle et intuitive
quelquesoit le contexte (langue, langage) de la personne qui lira l'algorithme aprés celui qui l'ai écrit.

Le but étant, je crois le partage d'informations et sa vulgarisation ! ;)
12/06/2007, 10h23
PRomu@ld

Citation:

Or ce que l'on cherche c'est d'avoir une méthode plus universelle et intuitive
quelquesoit le contexte (langue, langage) de la personne qui lira l'algorithme aprés celui qui l'ai écrit.

On a pu voir dans un autre post qu'un langage unique et universel pour décrire un ou des algorithmes n'était pas possible. Je te renvoie à la discussion suivante :

http://www.developpez.net/forums/sho...d.php?t=263397

Citation:

C'est lisible mais pas trés efficace pour calculer les complexités, (détection de cas max, d'appel à d'autres algorithmes ...)
j'ai essayé, mais sinon c'est plus proche d'une langue maternelle c'est sûr !

Comme pour les algorithmes on veut aussi calculer leur performences,
il est intéressant de se poser la question de l'écriture au niveaux de la visibilité des calculs dans ce domaine.

On peut très bien se servir de la notation de Gueritarish pour calculer la complexité d'un algorithme, le tout est je pense une question d'habitude.
13/06/2007, 12h06
Gueritarish

Citation:

On peut très bien se servir de la notation de Gueritarish pour calculer la complexité d'un algorithme, le tout est je pense une question d'habitude

Tout à fait d'accord avec toi (et donc avec moi...8O bizarre)

Dans le principe de ma notation, il s'agit en fait d'écrire un algo par raffinage successif. Je m'explique, on peut écrire

Code:

Trier le tableau T

Puis dans un autre raffinage, expliquer la méthode de trie.

Enfin, voilà, il est vrai que c'est une question d'habitude, mais on peut calculer la complexité de manière assez simple une fois que toutes les parties de l'algo on était raffiné.

Je sais pas si vous m'avez tous suivi, mais c'est une notation possible :mrgreen:
13/06/2007, 12h26
PRomu@ld

Citation:

Puis dans un autre raffinage, expliquer la méthode de trie.

Oui, il faut adapter la verbosité de l'algorithme en fonction du niveau d'abstraction auquel on veut se placer et aussi dont on a besoin.
13/06/2007, 14h02
O( N )

Oui

Biensûr qu'avec n'importe quelle notation on peut, avec ou sans expérience, calculer la complexité. :mouarf:

Oui un langage unique et universelle n'est pas possible ! :mouarf:

Cependant, tu devras re-écrire ton algorithme dans chaque langues pour qu'il soit compris par tous. :P
Ou faire comme les anglais avoir un "monopole linguistique".
(Bien que ce forum soit francophone, l'idée principale est le partage, non ?
C'est dans cette optique que je propose cette différence de point de vue !)

Un algorithme peut s'expliquer en idées avec des mots,
donc lié à une langue ou être traduit dans un langage.

Quelle est la notation recherchée ici ? le français ou une méthode d'écriture
permettant à tous de reconnaitre des idées ?

D'où j'en ai conclu pas de lien entre l'algorithmique et les langues.

Nous pouvons aussi nous lier avec un langage de programmation ((pascal, C, Java, ...)
mais je ne crois pas que cela fera une bonne chose.
L'algorithmique doit être, en mon sens :aie:, une liste d'opérations d'idées représentées par des structures de données et uniquement cela !
Pourquoi l'algorithmique devrait se poser les questions sur la notion d'objet ou encore sur la portabilité d'une variable !

Je pense que ces notions (intéressantes) doivent rester à leur place, dans les langages !
D'où j'en ai conclu pas de lien entre l'algorithmique et les langages informatiques.

Voilà ... ;)
13/06/2007, 14h42
PRomu@ld

Citation:

L'algorithmique doit être, en mon sens , une liste d'opérations d'idées représentées par des structures de données et uniquement cela !
Pourquoi l'algorithmique devrait se poser les questions sur la notion d'objet ou encore sur la portabilité d'une variable !

N'y aurait-il pas un léger lien entre la notion d'objet et de structure de donnée, si on accepte l'un on doit accepter l'autre.

Comme on a pu le voir dans le lien que j'ai mentionné plus haut, la façon dont tu veux décrire ton algorithme devrait être différente suivant le paradigme de programmation utilisé. Si tu utilises un paradigme fonctionnel ou logique, tu ne va pas présenter la chose de la même façon que dans un paradigme itératif.
18/06/2007, 14h35
O( N )

Quand je parle de notion d'objet, je sous-entends ( ce n'était pas claire :oops: ) les questions qui peuvent adhérer.

Pour moi, un objet est définit par une structure de données... d'où le lien ;) .

Mais, je ne souhaite pas intégrer l'objet plus en avant dans la notation,
afin de rester dans une lisibilité du code malgrès le manque de vocabulaire pour certaines notions.

En fait, au lieu d'écrire simplement un objet par une notation apropriée,
je préfère avoir une fonction y faisant référence.

C'est plus long, dans le sens ou l'on cherche à savoir ce que représente l'algorithme,
cependant cela n'alourdit pas la base des connaissances à partager,
et le code écrit devient plus une spécification qu'une connaissance de base
à acquérir en plus dans un vocabulaire de base peut-être déjà trop lourd...:aie:

Par contre j'aurais une question sur le lien entre
l'algorithmique et les paradigmes de programmation.

Peut-on être indépendant des paradigmes ?
Il me semble que non ! D'où , il faudrait savoir lequel serait le plus apte à être lu ?

Dans la méthode que j'utilise :
Conditions => fonction(paramètres) = fonction(paramètres)

On peut clairement voir si tout les cas on été vérifiés en faisant une tableau de Karnaugh.
par exemple la condition (i<0) => algo1(i) = algo1(i+1)
on peut voir qu'il nous manque également les tests sur
(i=0) et (i>0) que l'on peut vérifier aussi !

Si notre algo1 ne nécessite pas de ces deux conditions supplémentaires
alors on aura tester tout les cas pour cette condition.8O
(mais que ferait-il avec i=0 et i>0 ? pas de conditions d'arrêt !)

Dans un cas moins simple :
(i>0) et (j<i) ou (k=j) par exemple
il y aura beaucoup plus de cas à vérifier ...
De cette manière on voit les bornes (i = 0) (j = i) ...
mais le nombre de cas à vérifier vas croissant et même beaucoup plus (ici 3^3 => 27 cas au minimum) :aie:
(i = 0), (i < 0), (i > 0) et
(j = i), (j < i), (j > i) et
(k = j), (k < j), (k > j)

Peut-être est-ce tous => pas de cas de bornes supplémentaires du style (j = k-i) ou d'autres joyeusetés...:aie:

On peut aussi éliminer des cas impossibles comme (i<0) => 9 cas en moins...

Qu'en pensez-vous ...
19/06/2007, 08h36
PRomu@ld

Citation:

En fait, au lieu d'écrire simplement un objet par une notation apropriée,
je préfère avoir une fonction y faisant référence.

Ici, tu restes sur un paradigme impératif, ça ne pose cependant pas trop de problème.

Citation:

Peut-on être indépendant des paradigmes ?
Il me semble que non ! D'où , il faudrait savoir lequel serait le plus apte à être lu ?

La question n'est pas une question de lisibilité. Si tu fais du lambda-calcul pur, tu ne peux pas utiliser les structures FOR, IF, ... . Les utiliser représenterait une erreur, en fait tu auras une notation par paradigme, et on ne parlera pas de lisibilité.
19/06/2007, 10h04
pseudocode

Citation:

Envoyé par O( N )

Par contre j'aurais une question sur le lien entre
l'algorithmique et les paradigmes de programmation.

Peut-on être indépendant des paradigmes ?
Il me semble que non ! D'où , il faudrait savoir lequel serait le plus apte à être lu ?

Par définition, les algorithmes sont: "une suite d'opérations permettant de résoudre par calcul un problème." (wikipedia)

Dès lors, il ressort un aspect "séquentiel" dans les algorithmes. Et donc la programmation impérative semble la plus naturelle.

De toutes facons, de part la nature des processeurs actuels, tout programme finit par etre executé comme une suite séquentielle d'instruction. Ne pas utiliser une description "impérative" pour un algorithme ne fait que repousser le probleme. Tot ou tard, le programme devra etre "serialisé", que ce soit par le compilateur, le run-time, ou l'OS.

Utiliser une description non-impérative, spécifique a un langage n'est plus de l'algorithmie (a mon sens). Ca ressemble plus a un "snippet".
19/06/2007, 10h17
PRomu@ld

Citation:

Utiliser une description non-impérative, spécifique a un langage n'est plus de l'algorithmie (a mon sens).

Donc un algorithme récursif n'a pas de sens selon toi ? De plus, lorsque les processeurs futurs fonctionneront suivant un mode quantique (je sais, nous n'y sommes pas encore), faudra-t-il réécrire tous nos algorithmes suivant ce mode de pensée ?

Je pense que le principal problème est que nous raisons tous sur un modèle plus ou moins proche d'une machine de Turing, mais il ne faut pas oublier qu'il ne s'agit pas du seul modèle.
19/06/2007, 10h59
pseudocode

Citation:

Envoyé par PRomu@ld

Donc un algorithme récursif n'a pas de sens selon toi ?

Ca a un sens tant que l'algorithme utilise des fonctions récursives primitives.

Pour moi, l'ecriture recursive est une maniere élégante (= compacte) pour décrire un algorithme itératif de profondeur variable (quicksort, hanoi, ...).
19/06/2007, 13h46
O( N )

Pour avancer un peu et sortir du Bla Bla

Non que je veuille critiquer les dialogues, mais il serait intéressant d'avancer un peu
et de ne plus discuter autour de ce sujet ! :D

Avez-vous choisie une notation pour laquelle nous pourrions déjà voir des résultats
(pas une précédente notation qui était 'un défaut' avant cette discussion) ? :P

Où sinon pourrait-on écrire des algorithmes simples sous différentes notations
et les faire comparer par autruis pour trouver la notation la plus cohérente ! :mouarf:

qu'en pensez-vous ... ;)

Salut !

Vu qu'il n'est rien proposé depuis un bail, je (re)propose ceci : souligner les mots-clés, indenter, commenter comme C, C++, Java, Pasca, etc. c'est-à-dire selon le langage cible et donc se limiter à :

Code:

// ça, sur 1 ligne
Code:

1 2 /* ça sur plusieurs lignes */
Code:

1 2 (* ou ça *)
Code:

1 2 /** éventuellement ça pour de la doc, mais on entre plutôt dans la programmation et de toutes façons, c'est égal au 2e. */
On devrait permettre l'utilisation des accents, ligatures (œ, etc.) et autres symboles diacritiques (ç, etc.) puisque l'on parle français* ou des lettres grecques, éventuellement, pour ceux qui arrivent à les taper, mais c'est tout.

Voici donc une petite application :
pour une fonction :
Code:

1 2 3 4 5 6 7 8 9 10 11 fonction maFonction(élément : Entier, truc : Réel) : Entier i <- 0 // affectation tant que i < 20 faire i <- i + 1 ftq // fin tant que retourne i fin lexique i : Entier, variable temporaire
Pour une procédure (ES = entrée/sortie):
Code:

1 2 3 4 5 6 7 8 9 10 11 procédure échangerVariables(ES x : Entier, ES y : Entier) tmp <- x x <- y y <- tmp fin lexique tmp : Entier, variable temporaire pour permettre l'échange x : Entier, premier paramètre qui sera remplacé par y y : Entier, second paramètre qui sera remplacé par x
Pour une classe (si nécessaire, on peut toujours la définir, on sait jamais) :
Code:

1 2 3 4 5 6 7 8 9 10 11 classe Arbre /** Un attribut */ attribut : Entier /** Un nœud de l'arbre. Il est aussi un arbre. */ nœud : Arbre constructeur(toto : Entier) // corps du constructeur fin finclasse
* : À moins de ne pas le faire en français mais dans une langue construite (espéranto, lojban, etc.), comme ça pas de jaloux, elles ne sont langues nationales d'aucun pays. :D

28/06/2007, 20h43
PRomu@ld

Citation:

Vu qu'il n'est rien proposé depuis un bail,

Ca n'est pas parce que rien n'a été proposé qu'il faut se forcer, si on a rien à ajouter de plus. ;)

J'ai des doutes sur l'utilisation de blocs de commentaires, je suis plus pour les commentaires c++ ou ada, il débute et se finissent par la fin de ligne, ça permet d'éviter les ambiguïtés.

Citation:

On devrait permettre l'utilisation des accents, ligatures (œ, etc.) et autres symboles diacritiques (ç, etc.) puisque l'on parle français* ou des lettres grecques, éventuellement, pour ceux qui arrivent à les taper, mais c'est tout.

Oui, dans la mesure où on ne multiplie pas les symboles (trop de symboles tuent les symboles).

Citation:

Pour une classe (si nécessaire, on peut toujours la définir, on sait jamais) :

J'aimerai qu'on évite la notion de classe en algo, je trouve ça trop proche des langages. Je préférerais qu'on parle de notion d'objet.

Salut,

A titre personnel, j'utilise le nassi-schneiderman quand je dois créer un algorithme, et je comprend bien qu'il est difficile d'imposer ce point de vue, ne serait-ce que ca fait appel aux "petits dessins"...

Aussi, quand il s'agit de transmettre l'idée de manière verbeuse plutot que de manière imagée, je crois que la solution la plus simple et la plus compréhensible sera toujours la solution la meilleure ;)

N'oublions pas non plus que la balise CODE permet une coloration synthaxique -du moins, dans les autres sections, et on peut regretter le fait qu'il faille préciser le langage utilisé dans celle-ci - qu'il me semble intéressant d'utiliser, car, l'un dans l'autre, tout ce qui peut donner une indication supplémentaire (le fait qu'il s'agisse d'un commentaire, pour aider à comprendre ce qui est fait, par exemple) sera de nature à faciliter la compréhension... ce qui est le but recherché.

Il est, à mon sens, impossible d'envisager de mettre tout le monde d'accord sur une notation trop fixe, justement, parce que la grande partie des propositions sera issue plus ou moins directement inspirée de ce qui est fait dans un langage ou un autre, particulièrement adaptée à ce langage, mais potentiellement désastreuse dans un autre.

Pour les structures de tests et de boucle, je suis d'avis que le début et la fin des structures doivent etre tres clairement définies, ce qui m'inciterait à répéter ce qui a déjà été proposé: majuscule et indentation, avec marqueur explicite de fin de structure:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 SI truc = bidule ce qui doit etre fait SINON ce qui doit etre fait FIN SI POUR a=0 à 10 ce qui doit etre fait FIN POUR TANT QUE test ce qui doit etre fait FIN TANT
L'affectation est à mon sens plus claire, et visiblement admise par tous, si on l'indique avec <-

Code:

a <- nouvelle valeur

L'acces à un élément de structure - que ce soit une valeur/sous structure ou l'appel d'une fonction - peut tres bien etre représenté sous la forme de -> ou de .: aucune des solutions ci-dessous ne pose réellement problème à mon sens
Code:

1 2 3 4 5 a -> suivant <- b -> precedent a.suivant <- b.precedent a <- b->LaFoncitonQuiFaitTruc(valeur) a <- b.LaFonctionQuiFaitTruc(valeur)
Les commentaires sont souvent les bienvenus, pour toute une série de raisons...

Comme je l'ai indiqué plus haut, la balise CODE fournit une coloration synthaxique qu'il serait, à mon sens, domage de ne pas utiliser...

Maintenant, il n'y a, à mon sens, pas énromément d'intéret à se chamailler pour savoir si la notation C est meileure que la notation VB ou delphi, ou pire, à inposer d'écrire un Commentaire: (...)
Code:

1 2 3 4 /* ceci est un commentaire en C */ // ceci est un commentaire en C++ /* un commentaire en COBOL est indiqué par l'étoile en position 7... */
Pour l'introduction aux procédures/fonctions, j'apprécie de fournir les indications pertinantes avant meme de fournir le prototype de la fonction... Encore une fois, la coloration synthaxique des commentaires peut nous venir en aide:
Code:

1 2 3 4 5 6 7 8 /* Fonction dont le but est de (...) * @in: nom et type du premier parametre * nom et type du deuxieme parametre * ... * @out: type du retour éventuel */ type retour LaFonction(param1, param2, param3)
De la meme manière, je n'ai aucun scrupule, si le nombre de variables utilisées est important, ou si l'existance de plusieurs variables d'un meme type sont de nature à rendre la compréhension incertaine, à quarrément préciser leurs nom, types et utilité:
Code:

1 2 3 4 5 6 7 8 9 /* SOIT a est un pointeur sur entier servant à (...) * b est un (...) servant à (...) */ /* debut: pointeur sur structure de type (...) utilisé pour garder une trace du début de la chaine fin: pointeur sur structure de type (...) utilisé pour garder garder une trace de la fin de la chaine */
Au delà des quelques remarques déjà faites sur la représentation des structures de controle et sur l'affectation, cela ne me dérange absolument pas de laisser libre cours aux préférences de chacun pour les autres conventions.

On pourrait, effectivement, essayer de généraliser l'une ou l'autre habitude - de commenter son algorithme, par exemple - mais, toute tentative d'ériger des regles trop strictes à la présentation d'un algorithme serait, à mon sens, contre productive ;)

29/06/2007, 18h41
pseudocode

mouais....
Je ne vois pas trop l'interet de réinventer une enième syntaxe de langage imperatif, structuré par block, ...

J'ai l'impression que vous refusez d'utiliser la syntaxe d'un langage connu (basic, c/java, ...) sous pretexte de respecter la sacro-sainte règle d'indépendance entre algo et langage. A mon sens, ce n'est pas parcequ'un algo est indépendant du langage qu'il est INTERDIT de le définir dans un langage donné (et connu).

Ce qui devrait etre "interdit" c'est juste d'utiliser les fonctionalités spécifiques d'un langage (comme la reflexion, la definition dynamique, ...).

Parceque si c'est juste pour remplacer
Code:

1 2 3 4 FOR a=0 TO 10 ce qui doit etre fait NEXT
par
Code:

1 2 3 4 POUR a=0 à 10 ce qui doit etre fait FIN POUR
je ne vois pas la "valeur ajoutée"... :roll:

Voir 40 message(s) de cette discussion en une page