Mettre une liste chainée en global, c possible?
-
Pacificator
- Messages : 43
- Inscription : mer. 15/déc./2004 16:28
Mettre une liste chainée en global, c possible?
That is the question...
-
Le Soldat Inconnu
- Messages : 4312
- Inscription : mer. 28/janv./2004 20:58
- Localisation : Clermont ferrand OU Olsztyn
- Contact :
moi ça me derangerai !
parceque le fait que ce soit globale je trouve ça pratique !!
les variables locale ne servent qu'a ceux qui manque d'imagination !
et dans le but d'un confort intellectuel !
en effet il suffit d'utiliser des variables globales avec un nom different
pour ne pas avoir de problem !
rien ne vous empeche d'utiliser un prefixe dans le nom des variables pour pas vous melanger les pedales !
du genre loc_variable <- pour considerer cette variable globale que dans une procedure (comme une variable local)
j'ai toujours pensé que type "global" etait un minimum
et que "local" etait une facilité pour les programmeur en manque d'imagination
on peut tres bien programmer en se passant des variables locales
(qu'elle y soient , c'est tres bien mais pas indispensable)
alors qu'on ne peut pas se passer des variable globale !!
vouloir suprimer ce fait est un non sens !
ps : je trouve deja debile d'avoir a passer par les pointeurs pour les arguments des procedures avec les structure
plus ont simplifie un langage , plus il deviens populaire , plus on aime l'utiliser
la , j'ai l'impression que vous desirez le transformer en un espece de "C"
incomprehensible des non initiés !
laissez nous , a nous simple d'esprit nos variables globale , c'est plus simple comme ça , et encore il y aurai des amelioration de simplicité a apporter ! (le passage de parametre des procedure )
pour creer un tableau en mode local , je veux bien , mais en utilisant une
nouvelle commande du genre L_DIM
mais ne touchez pas a DIM et a ce qui existe deja !! SVP !
parceque le fait que ce soit globale je trouve ça pratique !!
les variables locale ne servent qu'a ceux qui manque d'imagination !
et dans le but d'un confort intellectuel !
en effet il suffit d'utiliser des variables globales avec un nom different
pour ne pas avoir de problem !
rien ne vous empeche d'utiliser un prefixe dans le nom des variables pour pas vous melanger les pedales !
du genre loc_variable <- pour considerer cette variable globale que dans une procedure (comme une variable local)
j'ai toujours pensé que type "global" etait un minimum
et que "local" etait une facilité pour les programmeur en manque d'imagination
on peut tres bien programmer en se passant des variables locales
(qu'elle y soient , c'est tres bien mais pas indispensable)
alors qu'on ne peut pas se passer des variable globale !!
vouloir suprimer ce fait est un non sens !
ps : je trouve deja debile d'avoir a passer par les pointeurs pour les arguments des procedures avec les structure
plus ont simplifie un langage , plus il deviens populaire , plus on aime l'utiliser
la , j'ai l'impression que vous desirez le transformer en un espece de "C"
incomprehensible des non initiés !
laissez nous , a nous simple d'esprit nos variables globale , c'est plus simple comme ça , et encore il y aurai des amelioration de simplicité a apporter ! (le passage de parametre des procedure )
pour creer un tableau en mode local , je veux bien , mais en utilisant une
nouvelle commande du genre L_DIM
mais ne touchez pas a DIM et a ce qui existe deja !! SVP !
Pas d'accord avec toi Dobro
Les 2 types sont interessants et on leur utilité.
La récursivité en est une et certains problèmes sont difficilement solvables sans récursivité qui soit dit en passant n'est pas du C ou je ne sais quoi mais une méthode de programmation.
La plupart des variables en récursivité doivent rester locales justement du au principe même de cette méthode.
Je crois que tous les types de variables devraient pouvoir être déclarés en local ou en global. Au choix du programmeur. En règle générale, il vaut mieux limiter les variables globales qui sont sources d'erreurs (effet de bord) difficiles parfois à trouver.
Sinon rien n'empêche un programme de disposer de commandes avancées et là encore chacun programme avec les commandes qu'il veut.
Chacun doit rester libre de faire ce qu'il veut, libre ou non d'utiliser le jeu de commandes dans la globalité.
Les pointeurs Purebasic sont souvent inutiles dans bien des cas (on peut mettre une variable normale à la place) et source d'embrouilles et d'erreurs. Ils sont indispensables pour passer des paramètres comme des variables basés sur une structure, Fred l'a décidé comme il voulait.
Les 2 types sont interessants et on leur utilité.
La récursivité en est une et certains problèmes sont difficilement solvables sans récursivité qui soit dit en passant n'est pas du C ou je ne sais quoi mais une méthode de programmation.
La plupart des variables en récursivité doivent rester locales justement du au principe même de cette méthode.
Je crois que tous les types de variables devraient pouvoir être déclarés en local ou en global. Au choix du programmeur. En règle générale, il vaut mieux limiter les variables globales qui sont sources d'erreurs (effet de bord) difficiles parfois à trouver.
Sinon rien n'empêche un programme de disposer de commandes avancées et là encore chacun programme avec les commandes qu'il veut.
Chacun doit rester libre de faire ce qu'il veut, libre ou non d'utiliser le jeu de commandes dans la globalité.
Les pointeurs Purebasic sont souvent inutiles dans bien des cas (on peut mettre une variable normale à la place) et source d'embrouilles et d'erreurs. Ils sont indispensables pour passer des paramètres comme des variables basés sur une structure, Fred l'a décidé comme il voulait.
je n'ai jamais dit le contraire puisque je dit " (qu'elle y soient , c'est tres bien mais pas indispensable) "Denis a écrit :Pas d'accord avec toi Dobro
Les 2 types sont interessants et on leur utilité.
je n'ai jamais dit que la recursivité etait un language !!La récursivité en est une et certains problèmes sont difficilement solvables sans récursivité qui soit dit en passant n'est pas du C ou je ne sais quoi mais une méthode de programmation.
je sais tres bien qu'une procedure recursive est une procedure qui s'appelle elle-meme !
je dit que leur intention de vouloir tout rendre en mode locale est pas bon !! , et que l'on va etre confronté au difficulté du C si l'on cloisone le system des variables globale , qui, je le rappel , sont la caracteristique du language basic !
soit ! mais elle ne sont pas obligatoire pour faire de la recurcivité !La plupart des variables en récursivité doivent rester locales justement du au principe même de cette méthode.
deux variables globale avec un nom different remplace l'emploi
d'un seul nom de variable qui est globale a l'exterieur et local a l'interieur d'une procedure ! (en fait cela reste 2 variables differente meme si elle ont le meme nom ! )
Je suis d'accord !Je crois que tous les types de variables devraient pouvoir être déclarés en local ou en global. Au choix du programmeur.
et d'ailleurs le pure propose "STATIC et GLOBAL"
ha c'est quoi ça les effets de bords ??En règle générale, il vaut mieux limiter les variables globales qui sont sources d'erreurs (effet de bord) difficiles parfois à trouver.
tout a fait d'accord avec toi !!Sinon rien n'empêche un Language de disposer de commandes avancées et là encore chacun programme avec les commandes qu'il veut.
Chacun doit rester libre de faire ce qu'il veut, libre ou non d'utiliser le jeu de commandes dans la globalité.
Les pointeurs Purebasic sont souvent inutiles dans bien des cas (on peut mettre une variable normale à la place) et source d'embrouilles et d'erreurs. Ils sont indispensables pour passer des paramètres comme des variables basés sur une structure, Fred l'a décidé comme il voulait.
et c'est quand meme un peut dommage !!
Effet de bord
extrait du site http://developpeur.journaldunet.com/tut ... on1a.shtml
http://www.linux-france.org/prj/jargonf ... _bord.html
http://dept-info.labri.u-bordeaux.fr/~s ... ode55.html
Sinon pour la récursivité, à priori on ne connais pas le nombre de variable, il sera défini par la condition d'arrêt d'ou l'impossibilité de connaître à l'avance le nombre de variables.
extrait du site http://developpeur.journaldunet.com/tut ... on1a.shtml
voir aussiEffets de bords
Les effets de bords (side effects) ne sont pas une spécificité de la programmation fonctionnelle - ce serait même plutôt l'inverse : on en trouve avant tout dans la programmation impérative où ils sont d'ailleurs sources de nombreux bogues...
Un effet de bord correspond à un résultat inattendu d'une fonction, et par extension à toute modification au sein de l'environnement (modification de la valeur d'une variable, par exemple). Pour bien comprendre l'effet de bord, replaçons-les dans leur contexte favori : la programmation impérative.
Dans ce cas de figure, la portée d'une variable est le plus souvent limitée à la procédure où elle est définie, le compilateur prenant en charge l'allocation/désallocation de mémoire. Cependant il peut arriver qu'une variable ou une zone mémoire dispose d'une portée qui dépasse la procédure qui la contient, ceci afin d'être accessible à partir d'autres procédures. Certaines procédures peuvent ainsi modifier une variable ou une zone mémoire dans le seul but de les maintenir dans un état donné, fixé par le développeur.
Cette capacité d'une fonction de modifier l'état d'une valeur (variable globale ou statique, argument d'une autre fonction, affichage ou écriture des données) autre que celle qu'elle renvoie définit l'effet de bord.
Ce mécanisme crée une sorte d'interdépendance entre les fonctions, rendant souvent plus complexe la compréhension d'un programme... D'autant que la modification d'une fonction peut dès lors avoir des conséquences inattendues sur le résultat d'autres fonctions "liées".
Mais la programmation impérative (comme les programmeurs OO le reconnaîtront) se base quasi uniquement sur les effets de bord. La programmation fonctionnelle pure les refuse pour sa part. Toutes les fonctions peuvent ainsi facilement être testées de manière unitaire, accélérant le déboguage et facilitant l'optimisation.
http://www.linux-france.org/prj/jargonf ... _bord.html
http://dept-info.labri.u-bordeaux.fr/~s ... ode55.html
Sinon pour la récursivité, à priori on ne connais pas le nombre de variable, il sera défini par la condition d'arrêt d'ou l'impossibilité de connaître à l'avance le nombre de variables.
ouf !! je pensais que cela etait un bug system qui faisai deborder le contenu de certaine variable dans les autres !!Cette capacité d'une fonction de modifier l'état d'une valeur (variable globale ou statique, argument d'une autre fonction, affichage ou écriture des données) autre que celle qu'elle renvoie définit l'effet de bord.
en fait pour simplifier (et si j'ai bien compris
) cela est en fait du a une mauvaise gestion du programmeur des variables global !!en clair si l'on attribut une variable global a une seul fonction (utilité)
on devrai pas se marcher sur les pieds !
car enfin , on peut programmer sans trop de difficulté sans variables local non ?
elle n'ont pas toujours existées , c'est bien juste une question de confort non ?
une meme variable global (une variable normal quoi
)peut etre utilisé dans la recursivité , a partir du moment ou cette variable n'est pas modifié ailleurs ! bref que cette variable n'a que cette utilité "localisé a la procedure"
je reconnais que les variables global demande un suivi plus fort
mais , pour moi elle sont tres pratique car on peut modifier et lire se valeur quant on veux , meme en dehors d'une procedure !!
(mem si c'est ça que vous trouvez dommage, moi je pense que c'est un avantage au contraire !! )
les variables local permettent un code plus cloisoné ou il faut faire appel a toute une gymnastique pour recuperer leur valeur en dehors de leur procedure
perso je n'utilise jamais les variables local !!
par contre les sous-programme oui !
les procedures sont une espece de sous-program confortable
qui ne devrai pas etres utilisé comme des sous-programme , mais comme des fonctions (dont c'est le vrai nom !)
et la effectivement les variable local ont leur utilitées
par contre vouloir changer les tableau (dim) est une betise a mon sens !
ou alors il faudrai crer une nouvelle commande L_DIM () pour
local tableau !!
mais je n'en vois pas l'interet !
Je pense que les variables locales ont toujours existée, elles se situent sur la pile que ton program utuilise (allouée par le système). Ce n'est pas un confort.
Plus tu ajoutes de variable globales, plus la taille du fichier augmente. Elle augmente aussi avec les locales mais 5-6 lignes de code asm permettent de reserver et de libérer un octet ou 500 Ko, alors que si tu réserve 500 Ko en globale ton fichier va au moins faire 500 Ko de plus.
Effectivement les variables globales sont pratiques, j'ai pas dit qu'il faut tout en local!
Sinon, essaye de lire des posts sur la récursivité car je pense que tu ne saisie pas pourquoi il faut des variables locales pour l'utiliser.
En gros, toutes les variables déclarées dans une procédure PB sont locales sauf les tableaux et listes chainées.
Donc elles se situent sur la piles et leur adresse dépend de comment tourne ton prog etc.
La récursivité est donc une procédure qui s'appelle elle-même. Pour pouvoir arrêter ces appels, il doit et c'est obligatoire d'avoir une condition qui stoppe cette récursivité sinon en quelques milli-secondes tu as une erreur de pile.
Un exemple parmi tant d'autre, il y en a sur le forum, c'est la scrutation des dossiers et sous-dossiers.
Plus tu ajoutes de variable globales, plus la taille du fichier augmente. Elle augmente aussi avec les locales mais 5-6 lignes de code asm permettent de reserver et de libérer un octet ou 500 Ko, alors que si tu réserve 500 Ko en globale ton fichier va au moins faire 500 Ko de plus.
Effectivement les variables globales sont pratiques, j'ai pas dit qu'il faut tout en local!
Sinon, essaye de lire des posts sur la récursivité car je pense que tu ne saisie pas pourquoi il faut des variables locales pour l'utiliser.
En gros, toutes les variables déclarées dans une procédure PB sont locales sauf les tableaux et listes chainées.
Donc elles se situent sur la piles et leur adresse dépend de comment tourne ton prog etc.
La récursivité est donc une procédure qui s'appelle elle-même. Pour pouvoir arrêter ces appels, il doit et c'est obligatoire d'avoir une condition qui stoppe cette récursivité sinon en quelques milli-secondes tu as une erreur de pile.
Un exemple parmi tant d'autre, il y en a sur le forum, c'est la scrutation des dossiers et sous-dossiers.
Je pense que les variables locales ont toujours existée
il y a un malentendu !!
je parle en basic !!! le purebasic est un basic meme evolué !!
donc ma vision des choses et mes termes que j'utilise se rapporte au language basic pas a l'assembleur ou au COBOL ou au FORTH et a la programmation en general !!!
je pense etre capable de reprendre un exemple recursif et de n'utiliser que des variables global !
par ailleurs je pense que les variable locale ne sont utile que dans la mesure ou l'on desire reutiliser une fonction dans d'autres aplications !!
la variable local sert dans ce cas a rendre autonome la fonction !!
et uniquement dans ce cas !
mais a l'interieur d'un mem programme c'est pour moi un confort !
rien d'autre , il n'existe pas de fonctionalité qu'une variable local puisse faire qu'une variable global ne puisse faire !
La 1ere fois que j'ai fait du basic c'était dans les années 80.
Basic interpreté.
Mais bon, je pense que quel que soit le langage, les variables locales ont toujours existées.
Donnes-moi un exemple récursif avec des variables globales.
En règle générale, les calculs intermédiares sont stockés sur la pile par l'appel récursif dans les variables locales, c'est pour ça qu'il y a un problème avec les tableaux qui ne sont que globaux.
Basic interpreté.
Mais bon, je pense que quel que soit le langage, les variables locales ont toujours existées.
Donnes-moi un exemple récursif avec des variables globales.
En règle générale, les calculs intermédiares sont stockés sur la pile par l'appel récursif dans les variables locales, c'est pour ça qu'il y a un problème avec les tableaux qui ne sont que globaux.
Dernière modification par Anonyme2 le dim. 19/déc./2004 20:13, modifié 1 fois.