Datasection, lecture et conso mémoire ?

[Ar-S]

Salut,

J'ai une question concernant la gloutonistaion mémoire dans l'utilisation de datasection.
Est-ce que le contenu non utilisé en datasection réside en mémoire ou est-ce qu'il est prend de la mémoire lors de son appel par un read ?

Dans l'exemple suivant, selon la langue choisis Fichier$ sera égale à "Fichier" ou à "File".
(File dans l'exemple)

Comment sont alors gérées les données FR présentent ? Elles sont dans l'exe Ok mais entraine t elles uin conso de RAM ?
je subodore que non mais j'aimerai confirmation.

Code : Tout sélectionner

; -------------------- GESTION DES LANGUES --------------------
#UK = 0
#FR = 1

DataSection
	FR_MENU:
	Data.s "Fichier"
	
	UK_MENU:
	Data.s "File"
	
EndDataSection

;
MENU = #UK

If MENU = #FR
      Restore FR_MENU
ElseIf MENU = #UK
      Restore UK_MENU
EndIf 

Read.s Fichier$

[G-Rom]

les data section sont "en dur" sur ton disque , plus précisément dans une "zone spéciale" de ton exécutable ( lisible avec un editeur hexa )
en les "readant" elles sont copié dans la ram.

[Backup]

je ne pense pas non

la datasection correspond a une section de Ram !
chaque section d'un programme ( section Data, BSS,text )
est loader au moment du lancement d'un programme



la datasection est donc bien présente en Ram , c'est un segment de Ram
le Read est un pointeur qu'on deplace en Ram

la datasection peut etre lue avec un Debuggeur style OllyDbg lorsque le programme tourne

d'ailleurs a une époque on pouvais faire du débordement de ram en continuant de lire (avec READ ) apres le dernier Data
Fred a corrigé ce bug depuis .... ça nous faisait un lecteur de Ram pour pas cher


donc pour repondre a la question

Est-ce que le contenu non utilisé en datasection réside en mémoire

oui !
la datasection reserve une partie de Ram et
Read deplace un pointeur de lecture sur cette Zone de la Ram !


on peut constater le phenomene , de prise de Ram lorsqu'on charge des binaires (images, sons) en Datasection avec les includes
le programme augmente de façon significative (sur disque et en Ram)... je crois meme que ceci est indiqué dans la Doc au rayon Include Binary

[Backup]

voici comment tu peux modifier le contenu de la DataSection
pendant l'execution du prg
( utilisez le Debugger et le mode Pas a Pas (Step) pour voir le résultat )

Code : Tout sélectionner

; exemple de code qui mofdifie en Ram 
; le contenu de la DataSection :o)

calldebugger
; utilisation normal
restore toto ; on se place au label de la datasection
read.s a$ ; on lis le contenu du premier Data
debug a$ ; affiche "toto"  .... normal quoi :)
debug ?toto  ; affiche l'adresse Ram du label

; on va utiliser cette adresse pour modifier son contenu
pokeS(?toto,"titi") ; on va remplacer "toto" par "titi"

restore toto ; on se replace au debut de la Datasection
read.s a$ ; on lis le contenu
debug a$ ; tiens, le contenu n'est plus "toto" mais "titi"
; ceci prouve que la Datasection est bien en Ram  puisqu'on l'a modifié :)
; ça peut etre vue comme du code automodifié LOL

DataSection
	toto:
	data.s "toto"
EndDataSection; EPB

[Ar-S]

C'est intéressant. C'est donc moins gourmand d'utiliser un fichier texte pour les langues, on ne charge que se que l'on voudra.
C'était le sens final de cette question.

Note : dommage qu'on ne puisse pas faire un Debug Read.s texte.s

Dernière question tant qu'a en finir avec les datasections, y'a t il un moyen de connaitre le nombre de datas par lignes ?

Code : Tout sélectionner

FR_MENU:
	Data.s "Fichier","Nouveau", "Ouvrir", "Enregistrer", "Fermer" ; ici 5

[graph100]

dudulle c'est un pointeur.
Dobro a raison là.

Tu peux accéder aux datas sans restore, rien qu'avec des pointeurs, ce qui montre que le contenu est dans la ram.
De toute façon, si tu fais un programme avec plusieurs langues, c'est beaucoup mieux de mettre les data de langue dans un fichier externe.

Code : Tout sélectionner

For a = 0 To 4
	Debug PeekL(?mon_label + a * SizeOf(Long))
Next

*pointeur = ?Deuxieme_label

Debug PeekS(*pointeur)


DataSection
	mon_label:
	
	Data.l 1, 2, 3, 4, 5
	
	Deuxieme_label:
	
	Data.s "UNE CHAINE DE CARACTERE"
EndDataSection

[Ar-S]

Merci pour ces précisions, j'ai édité mon message de dessus pendant que tu postais le tiens.
En tout cas la gestion des datasections me plait de plus en plus. Je reste fébrile devant l'utilisation des pointeurs même si à force ça commence à venir.

[Backup]

Dernière question tant qu'a en finir avec les datasections, y'a t il un moyen de connaitre le nombre de datas par lignes ?

Code : Tout sélectionner

FR_MENU:
	Data.s "Fichier","Nouveau", "Ouvrir", "Enregistrer", "Fermer" ; ici 5

perso lorsque je veux connaitre la fin des data ( au total ) j'ajoute une info qui n'a rien a voir

exemple ici j'ajoute "-1" qui me permet de connaitre la fin du block
note que c'est un exemple scolaire, on peut eviter de faire ainsi , mais je dois reconnaitre
que j'utilise souvent cette methode pour diverses raisons

Code : Tout sélectionner

Restore menu:

for i =1 to 255
	Read.s a$
	if a$<>"-1"
		debug a$
		Else 
		Break
	Endif
Next i
End

Datasection
	menu:
	Data.s "Fichier","Nouveau", "Ouvrir", "Enregistrer", "Fermer"
	Data.s "image","son", "imprimer", "modifier", "desintegrer" 
	Data.s "option1","option2", "option3", "option4", "option5","-1"  ; ici le "-1" indique la fin du bloc
EndDataSection

; 

; EPB

donc pour avoir un repere de fin de ligne de Data on peut faire ainsi

Code : Tout sélectionner

;;;calldebugger
Restore menu:

for i =1 to 255
	Read.s a$
	if a$="-1"
		Break
	Endif
	
	while a$<>"1"
		Read.s a$
		ligne$=ligne$+a$
	Wend
	
	while a$<>"2"
		Read.s a$
		ligne2$=ligne2$+a$
	Wend
	
	while a$<>"°"
		Read.s a$
		ligne3$=ligne3$+a$
	Wend
Next i
Debug "la ligne 1 contient :" +Removestring(ligne$,"1") 
Debug "la ligne 2 contient :" +Removestring(ligne2$,"2")
Debug "la ligne 3 contient :" +Removestring(ligne3$,"°")
End

Datasection
	menu:
	Data.s "Fichier","Nouveau", "Ouvrir", "Enregistrer", "Fermer","1"  ; ici le "1" indiquera la fin de ligne
	Data.s "image","son", "imprimer", "modifier", "desintegrer" ,"2" ; ici le "2" indiquera la fin de ligne
	Data.s "option1","option2", "option3", "option4", "option5","°" ; ici le "°" indiquera la fin de ligne ( j'ai utilisé "°" puisqu'il y a des chiffres dans le nom des menus.. ça evite les embrouilles avec le removestring())
	Data.s "-1"  ; ici le "-1" indiquera la fin de bloc
EndDataSection

; 

; EPB

il y a plein de façons de faire ... ça reste un exemple

[G-Rom]

j'ai été un peu vite en besogne , mais tu as bien résumer. sauf que tu ne fait pas que déplacer un pointeur, tu copie ces données dans des variables dynamique , ou tableau , map , liste , etc... , conso x2 :

Code : Tout sélectionner

string.s = Space(?endstr-?string)
PokeS(@string, PeekS(?string,?endstr-?string))

Debug string
End

DataSection
  string:
  Data.s "Copié deux foix dans la ram!"
  endstr:
EndDataSection

[Backup]

oui
lorsque tu fait un Read (utilisation normale c'est pour attribuer le contenu des Data (qui sont en Zone Statique)
a une variable ..

donc forcement , les valeurs des Data sont au moins a 2 endroit différents
de par l'attribution de la "valeur" lue par Read a une variable

on a bien en Zone Statique (dans les Data) la Valeur ; ici "Copié deux foix dans la ram!"
et cette phrase se retrouvera dans une variable utilisé par Read par exemple Read.s a$

une zone Data , doit etre vu comme un Ram disque !!

c'est une zone qui va contenir des valeurs, qu'on va de toute façon réutiliser en prenant ces valeurs et les attribuer a nos variables d'utilisations

mon exemple montre qu'il est possible de modifier le contenu de cette zone en ecriture , on a donc bien Lecture(utilisation normal) / Ecriture (bidouille)
ce qui correspond bien a un Ram Disque

moi c'est comme ça que je vois les Data

je suis d'accord avec graph100 , pour un programme multilangue, le mieux serai un fichier
ne serai ce que pour modifier , ajouter une langue ...ou le faire traduire en Ligne

[Ar-S]

je suis d'accord avec graph100 , pour un programme multilangue, le mieux serai un fichier
ne serai ce que pour modifier , ajouter une langue ...ou le faire traduire en Ligne

C'est ce que je faisais jusqu'à maintenant, je poursuivrai avec un fichier externe sauf éventuellement pour un prog ne comportant que peu de texte (simple menu). Je trouve l’insertion de datasection propre et pratique. Merci pour vos lumières.

[G-Rom]

Pas forcement , tu peu mettre ton langage dans des dll séparés, comme un plugin ( j'ai fait un tuto la dessus ).

[Ar-S]

Pas forcement , tu peu mettre ton langage dans des dll séparés, comme un plugin ( j'ai fait un tuto la dessus ).

Le but premier était d'utiliser le moins de fichiers externes en faite. Du coup DLL ou TXT, ça ne change pas grand chose. Je peux toujours faire de l'includefile de fichier texte mais bon, c'est beaucoup de brassage pour pas grand chose.

[G-Rom]

dans quel but ? je pensais que tu voulais rendre illisible au premier venu les traductions , la solution la plus simple c'est donc d'inclure le tout dans ton exe.

[Ar-S]

En fait plusieurs points se sont croisés, j'utilisais les datasections uniquement pour inclure de la ressources image/son en data afin d'éviter le rip via un editeur de ressources et pour ne pas trop avoir de fichiers avec mon exe.
Je me suis dis que la commande read est tout de même très pratique et que la gestion des datas n'est pas compliquée non plus alors pourquoi ne pas mettre aussi des textes de langues. Mais pour la modification ultérieur, un fichier pref (bien pensé) évite d'avoir à recompiler le prog, ce qui est un plus non négligeable. je voulais donc en savoir plus sur l'utilisation de la mémoire que cela pouvait entrainer car de ce coté j'avais pas vraiment d'idée ni de connaissances sur le sujet.