[LG]Allocation Memoire : des variables de taille predefinis ?

Version imprimable

31/12/2003, 03h26
wwwroom

[LG]Allocation Memoire : des variables de taille predefinis ?

Salut, :)

Donc voici mon probleme, j'ai besoin de gerer la memoire (variables) pour un programme.
En effet, utiliser un variable de type BYTE, ça m'embete....car je sais qu'a peine 50% de l'espace ainsi alloué ne sera pas utilisé.

Je voudrais donc savoir si c'est possible (et comment ?) de creer des variables de taille definies par mes soins :roll:

par ex :

var variable : BYTE; { prend 1octet et stock des valeurs de 0 a 255 }

est il possible de cree des variables qui ne stockerais des valeurs que de 0 a 100 par exemple ? (en ecrivant ceci je me rend compte que cela voudrais dire creer des variables de moins d'un octet...sur le papier ça reste crédible mais dans la réalité j'ai des doutes...)

var variable : MONTYPE;

....tout le probleme reside dans la facon de creer MONTYPE....j'ai chercher a droite a gauche, sans resultats concluants, d'ou ma presence ici :p

Merci de votre aide, ++
31/12/2003, 11h26
M.Dlb

L'idée est bonne car c'est un problème que beaucoup de programmeurs peuvent se poser dans un souci d'optimisation... Malheureusement, les plus petits registres des processeurs 8086 sont de type byte, et il n'est pas possible de les "découper", donc une variable aura au minimum 8 bits ! On voit qu'il existe déjà un problème avec des bolléens, car^ils prennent 2 valeurs possibles, donc 1 bit serait possible, mais ils sont en réalité stockés sur 8 bits donc 7 bits sont "inutilisés" d'un point de vue conceptuel !
a+
31/12/2003, 16h20
wwwroom

Je viens de trouver quelques papiers sur les pointeurs, getmem (ou new) et freemem (ou dispose).

Si je declare qqc du style :

type blu = array[1..400] of Integer;
var pblu : ^blu;

begin
{ici g pas besoin de mon tableau en faite, dc logiquement il est pas declarer en memoire ? }

new(pblu); {a supposer que j'en ai besoin maintenant }
{ je fait mes traitements, le tableau existe }
dispose(pblu);
{ bye bye le tableau ! (: }
end.

Enfaite ce que j'ai du mal a assimiler c'est la taille finale de l'exe generer, car mon tableau n'existe que pdt un cours laps de temps...et j'crois pas qu'un exe passe de 2ko a 10ko en cours d'execution!
31/12/2003, 16h35
wwwroom

apres reflexion il semblerais que je confonde ram et rom !

Mon exe finale doit faire une taille X ko au max, mais apres je sais pas combien j'ai de ram(p'te X aussi!), saloperie de client qui donne jamais tous les renseignements (:

considérons les 2 petits programmes suivants compilés avec TP7
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 program tableau1; type ttab = array [1..10000] of integer; var tab : ttab; i : integer; begin for i:=1 to 10000 do tab[i] := 0; writeln ('bibi'); readln; end.
rapport de compile : 2064 bytes code, 20672 bytes data

taille .exe sur disque = 3KO (seul le code est mémorisé)
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 program tableau2; type ttab = array [1..10000] of integer; var tab : ^ttab; i : integer; begin for i:=1 to 10000 do tab^[i] := 0; writeln ('bibi'); readln; end.
rapport de compile : 2064 bytes code, 676 bytes data

taille .exe sur disque = 3KO (idem)
----------------
chargé en mémoire le 1er prend 22736 bytes et le 2nd 2740 bytes

question : que veut le client en final ? sur quoi exactement porte
l'optimisation ?

31/12/2003, 18h34
M.Dlb

Oula oulala... Quand on crée une variable dynamique (qui necéssite un pointeur pour y accéder), l'espace mémoire alloué est "pris" dans la mémoire dynamique. Cet espace mémoire n'est alloué qu'à l'exécution du programme, pas lors de la compilation, donc comme l'a démontré HRS, l'exe fait la même taille à quelques octets près...
En ce qui concerne RAM et ROM, la ROM est une zone de mémoire morte, on ne peut y écrire mais on peut y lire, contrairement à la RAM que l'on peut modifier et lire. La ROM contient généralement le BIOS (et d'autres petits programmes (interruptions) ?), la RAM contient le reste :). Donc tout programme utilise la RAM et non pas la ROM.
Ensuite, pour la RAM avec Turbo Pascal : TP en mode réel ne peut utiliser au mieux que les 640Ko alloués au programmes sous DOS... Donc il faut passer par des utilitaires de gestion de mémoire pour avoir plus... Si ton client a un 286 avec 1Mo de RAM ca marchera !...
J'espère que j'ai pas dit trop de conneries cette fois :D
a+
01/01/2004, 19h29
Eric Sigoillot

Ca peut aller Worm, pas trop de conneries, lol ;)

Bon, la ROM, dite mémoire morte en Français (ce qui ne dit rien à tous les néophites), et dont la signification est "Read Only Memory", soit Mémoire en Lecture Seule (bien plus explicite en Anglais, non ?) était en effet inaccessible en écriture il y a de ça quelque temps. Ca a changé d'ici peu, avec les BIOS flashables. Mais passons, c'est sans importance.

HRS a fait un programme qui lui fait honte. Ne pas initialiser les variables dynamiques, c'est une des plus grosses erreurs que l'on peut faire lorsque l'on touche aux pointeurs.

Il a aussi dit des bêtises :

Citation:

taille .exe sur disque = 3KO (seul le code est mémorisé)

Faux ! Le code ET les données statiques sont stockées dans l'exe. Sinon, où seraient situées les constantes par exemples ?

Turbo Pascal ne peut comptabiliser que les éléments statiques de ton programme : le code, et les variables statiques (pas de pointeurs).

Ainsi, à la compilation, et lorsque ton programme est chargée en RAM par le Dos, un pointeur prendra 4 octets de mémoire.

Ensuite, tu peux allouer de la mémoire dynamique, dans une limite de 640 Ko, dans la mémoire dite conventionnelle (tu retrouveras ce nom si tu tapes MEM à l'invite du Dos).

Comment savoir combien ton prog prend de mémoire ? Avec les fonctions MemAvail et MaxAvail.

MemAvail renvoie la quantité de mémoire conventionnelle libre. MaxAvail renvoie la taille du plus grand bloc allouable dynamiquement (avec New ou GetMem).

Si tu veux savoir combien de RAM au mamximum prend ton prog, alors utilises ces fonctions après les appels à GetMem ou New (on peut les utiliser avant aussi, pours avoir s'il reste assez de RAM).

Pour la mémoire autre que conventionnelle, il faut penser à l'EMS (présente sur tous les pC depuis le 286, et l'XMS (sur tous les PC depuis le 386), à condition de charger en RAM le driver nécessaire (comme HIMEM.SYS et associés).

Au fait : il y a un langage qui permet de faire ce que tu veux (assigner un certain nombre de bits à une variable), c'est le C/C++, désolé de devoir citer son nom :oops:

A+
02/01/2004, 10h18
HRS

j'ai simplifié pour mieux me faire comprendre

Certes le professeur hdd34 a raison, mais est-ce bien pertinent qu'il
consacre une grande partie de ses interventions a obscursir le débat
dans le seul but de démontrer que les autres disent des "bêtises" et
qu'ils devraient "avoir honte"
02/01/2004, 13h55
charly

tout a fais daccord , ca devient flippant a force d'avoir raison , on deverait lui imposer un seuil d'erreur obligatoire
02/01/2004, 17h20
Eric Sigoillot

A trop vouloir simplifer on écrit des conneries, ne t'en déplaise. Il y a des de vrais débutants sur le forum, et certains n'hésitent pas reprendre un code direct et essaient de le lancer tel quel.

Si tu veux vraiment simplifer, en sachant pertinament que le code n'est pas fonctionnel, alors fait au moins en sorte qu'il ne se compile pas, en ajoutant, par exemple, des points de suspension. Tu es modérateur, c'est à toi d'y veiller.

De plus, certains sont très heureux d'apprendre des détails supplémentaires en plus de la réponse à leur question. Je ne vois pas pourquoi je devrais m'interdire de les fournir, quand ils sont en rapport avec ce qui a été dit précédemment.

Je ne vois pas non plus en quoi "j'obscurcis" le débat. wwwroom cherche à faire la part des choses entre mémoire statique et dynamique, même si ce n'est pas clairement explicité. Je lui donne les moyen de le faire, et de comprendre ce qu'il fait.

Pas content ? Attendons au moins de voir ce qu'en pense le principal intéressé.

A+
02/01/2004, 20h54
M.Dlb

On se calme !!

PS : on aurait besoin d'un modérateur qui soit plus présent, ca règlerait énormément de problèmes :lol:
03/01/2004, 01h17
Sub0

Arf! Où est le problème? Vos interventions ont été très biens je trouve.
La critique de l'un permet de faire évoluer l'autre.
Et puis un peu de baston de temps en temps entre les meilleurs, c'est bien, on s'ennuit pas au moins! :lol:
Malgré tout, je suis sûr que votre participation au forum est très appréciée, à+

En fait c pour une petite précision concernant l'"^"qui est dans ce prog...il sert à koi???
merci

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
 
program tableau2; 
type 
   ttab = array [1..10000] of integer; 
var 
   tab : ^ttab; 
   i : integer; 
begin 
   for i:=1 to 10000 do 
       tab^[i] := 0; 
   writeln ('bibi'); 
   readln; 
end.

05/01/2004, 19h00
M.Dlb

le ^ est lié à la terminologie pointeurs sous Pascal... Quand il est situé avant un identifiant, il signifie "étant pointé sur" et quand il est après un identifiant il signifie "pointant sur" ( je sais pas si c'est très clair... ).
Par exemple, dans var tab:^ttab; on déclare un pointeur étant pointé sur une variable de type ttab ( je m'embourbe :roll: ) La variable n'existe pas réellement, mais l'espace mémoire lui est réservée en mémoire dynamique, le pointeur servant à accéder à cet espace mémoire... tab^[i]:=0 signifie qui l'on affecte à la variable tab[i] pointée en mémoire par tab^[i] la valeur 0 (de même on a un tableau en mémoire dynamique, pointé par tab^...)
Est-ce que je m'en suis bien sorti ?? N'hésite pas si tu n'as pas compris quelque chose !!
a+