Discussion :

[PilloBuenaGente]

Bonjour !

je n'arrive pas à savoir à quel moment les ressources de l'ordinateur sont occupées.

J'ai pas mal de textes sous forme de strings dans des fonctions servant à composer différentes interfaces.

exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
void summary()
{
    ConsoleLayout cl;//classe dont les fonctions prennent la référence constante d'une string, effectuant seulement des "cout <<" avec differentes mises en page
    cl.title( "Summary" );
    cl.link( 1, "New Work" );
    cl.enter( 2 );
    cl.link( 9, "Options" );
    cl.ending( 0, "Quit" );
}

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
void options()
{
    ConsoleLayout cl;
    cl.title( "Options" );
    cl.ending( 0, "Summary" );
}

Je peux implémenter ces fonctions soit :

- Dans le fichier source d'une seule classe.

Les strings seront "chargées" en fonction de l'appel de telle ou telle fonction, ou l'ensemble sera "chargé" à l'appel de la classe ?

- Dans différentes classes déjà définies

Là encore les strings seront dans une fonction, elles prendront des ressources seulement à l'appel de cette fonction ?

- Dans différentes classes définies au besoin par héritage selon l'interface

Me semble la meilleure solution, mais est-ce que j'y gagne vraiment ?

Je ne sais pas si j'ai été vraiment clair, mais peut être auriez vous des idées ou des liens pour m'aiguiller ?

Un grand merci.

[koala01]

Salut,
A vrai dire, tu n'as pas vraiment à t'inquiéter de cela, car cela rentre vraiment dans l'optimisation prématurée, que tout le monde sait (ou du moins devrait savoir ) être la voie expresse vers tous les problèmes

Ceci dit, étant donné que je subodore que tu ne te contenteras sans doute pas de cette réponse, je vais essayer d'expliquer clairement ce qui se passe au niveau de la popote interne de ton application (je prendrai sans doute quelques raccourcis, mais c'est surtout pour te faire comprendre le principe )

D'abord, il faut prendre conscience du fait que, si tu déclares une variable de type std::string sous la forme de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

std::string hello("Salut tout le monde");

cela va se traduire par plusieurs choses au niveau du code binaire de ton application:
1- Il y aura un "tableau de caractères" contenant "Salut tout le monde" (sans les guillemets ) qui prendra place dans une partie "read only" de ton exécutable (je crois qu'on appelle cette partie le "data segment"... à vérifier ).

Cela signifie que, si tu ouvres ton binaire avec un éditeurs hexadécimal, ou si tu utilises l'outil strings sous linux, tu pourras parfaitement retrouver cette chaine de caractères "in extenso" quelque part dans le code binaire de ton application.

2- Il y aura un appel au constructeur de std::string qui accepte un const char *, avec transmission de l'adresse à laquelle se trouve cette chaine de caractères "codée en dur".

3- le constructeur de std::string utilisera new[] pour obtenir un espace mémoire suffisant pour représenter l'ensemble de la chaine de caractères

4- le lorsque tu atteins l'accolade fermante du bloc dans lequel ta variable est déclarée, le destructeur de std::string est appelé automatiquement. Ce dernier appelle delete[] sur le pointeur pour faire libérer la mémoire qui avait été allouée précédemment.

Généralement, on conseille très fermement de transmettre les paramètres comme les std::string sous la forme de référence (éventuellement constante) plutôt que sous la forme de valeur.

La raison en est que, si tu transmet un paramètre par valeur, tu provoque obligatoirement la copie de l'objet.

Dans le cas de std::string, cela signifie faire appel à son constructeur de copie, qui ... demandera également l'allocation d'un espace mémoire suffisant pour représenter la chaine de caractères, plus la copie de celle-ci dans l'espace mémoire en question.

Le passage par référence permet d'éviter cette copie, parce qu'au niveau du code assembleur, une référence est strictement identique à un pointeur (donc, à une valeur numérique entière (généralement) non signée qui représente l'adresse à laquelle le processeur va trouver un objet du type indiqué).

Seulement, il faut savoir que, lorsqu'un argument est transmis sous la forme d'une référence constante, il permet la création de ce que l'on appelle une "variable temporaire anonyme".

Autrement dit, lorsque tu invoques ta fonction

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

cl.title( "Summary" );

il y aura création d'une variable temporaire (dans le sens où elle n'existe que pour la durée d'exécution de la fonction title) anonyme (car le nom de la variable est inconnu du développeur) qui contient le terme "Summary" qui sera transmise à title.

C'est à dire que les différentes étapes dont je parlais la tantôt seront exécutées exactement comme ce que je t'ai expliqué .

Si toutes tes chaines de caractères sont "codées en dur", la variable de type std::string sera créée au moment de l'appel de la fonction à laquelle elle est transmise et détruite au moment où l'exécution de cette fonction atteindra l'accolade fermante (au niveau du processeur, cela correspond à "un tout petit peu avant" que le processeur ne commence à récupérer les données de la fonction appelante ).

Par contre, si tu transmets une chaine de caractères existante, sous une forme qui pourrait être proche de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
void foo(){
    std::string str("Salut tout le monde");
    /* ... diverse instructions, dont, pourquoi pas, la manipulation de str*/
    if(test){
        cl.title(str);
    }
}

la variable str existera entre le moment de sa déclaration (std::string str("Salut tout le monde"); et l'accolade fermante finale de foo().

Le constructeur de std::string sera appelé au moment de la déclaration de la variable et son destructeur sera appelé au moment où l'on atteint l'accolade fermante

Note enfin que cette logique se retrouve pour n'importe quelle variable (y compris les variables membres non statiques de classe ) et que la logique est que la création des variables se fait dans l'ordre de leur déclaration et que leur destruction se fait dans l'ordre inverse (parce que l'on travaille réellement sur une "pile" de données )

[Iradrille]

Jolie explication.

Un petit détail m'échappe par contre

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
void f1(const char*);
void f2(const std::string&);
void f3(std::string);
 
f1("abc");
f2("abc");
f3("abc");

Ici, aucune copie pour f1 : juste le passage d'un pointeur,
1 copie pour f2 : création d'un string temporaire (même si le string est const il y a une allocation mémoire ? En mettant de coté les optimisations pour les string de moins de 16 caractères.)
1 ou 2 copies pour f3 ? L'objet temporaire est copié, ou directement passé ?

[jo_link_noir]

Pour f2 il y aura effectivement une allocation dynamique. "abc" n'étant pas un std::string, le constructeur de std::string est appelé.
Pour f3 c'est la même chose. Par contre, le résultat est différent si un std::string est passé:
- si c'est une référence qui est envoyer (variable non temporaire) alors une copie est faite
- si c'est une variable temporaire (f3(std::string("abc"))) par exemple) alors ça dépend des optimisations du compilo. Par défaut il y a élision et la copie n'est pas faite. Donc un seul constructeur est appelé.

À noté quand C++11 il y a le move semantic et le constructeur d'une rvalue (variable temporaire) d'un std::string ne fait pas d'allocation.

[koala01]

Jolie explication.

Un petit détail m'échappe par contre

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
void f1(const char*);
void f2(const std::string&);
void f3(std::string);
 
f1("abc");
f2("abc");
f3("abc");

Ici, aucune copie pour f1 : juste le passage d'un pointeur,
1 copie pour f2 : création d'un string temporaire (même si le string est const il y a une allocation mémoire ? En mettant de coté les optimisations pour les string de moins de 16 caractères.)

Sauf exceptions, tu devrais en tout cas estimer que c'est le cas.

Il n'est pas impossible qu'il puisse exister une spécialisation quelconque qui tende à optimiser la création de petites chaines de caractères (mettons, moins de 8 ) pour utiliser un tableau de taille fixe, sans allocation dynamique, plutôt que pour utiliser un tableau alloué de manière dynamique.

Je ne crois pas que ce soit interdit par la norme, mais je ne sais absolument pas s'il y a un compilateur qui le fait de la sorte

1 ou 2 copies pour f3 ? L'objet temporaire est copié, ou directement passé ?

Il y a soit copie, soit création.

Ce sera le "minimum légal" pour que cela fonctionne.
tu auras une création si tu fais f3("salut");et une copie si tu fais

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
std::string str("salut");
f3(str);

Comme l'argument est nommé, la sémantique de mouvement n'est pas applicable au niveau de l'argument, en tous cas .

Pour f2 il y aura effectivement une allocation dynamique. "abc" n'étant pas un std::string, le constructeur de std::string est appelé.
Pour f3 c'est la même chose.

Jusque là, je suis d'accord.

Par contre, le résultat est différent si un std::string est passé:
- si c'est une référence qui est envoyer (variable non temporaire) alors une copie est faite [/QUOTE]Non, ca crashe (ou en tout cas, ca devrait): renvoyer une référence sur un objet temporaire revient à renvoyer une référence invalide, quelle que soit la manière dont tu envisages la chose

- si c'est une variable temporaire (f3(std::string("abc"))) par exemple) alors ça dépend des optimisations du compilo. Par défaut il y a élision et la copie n'est pas faite. Donc un seul constructeur est appelé.

Il y a bien élision de la copie, mais, comme tu crées explicitement la chaine de caractères, tu ne peux, quoi qu'il arrive, pas éviter l'appel au constructeur de std::string (et donc à l'allocation dynamique de la mémoire)

À noté quand C++11 il y a le move semantic et le constructeur d'une rvalue (variable temporaire) d'un std::string ne fait pas d'allocation.

Oh là... Attention:

A partir du moment où l'argument est nommé, c'est une lvalue, même si c'est un objet temporaire.

Pour profiter de la sémantique de mouvement, il faudrait utiliser explicitement std::move

S'Il est vrai que le constructeur par déplacement n'est pas sensé faire d'allocation dynamique de la mémoire etant donné qu'il "vampirise" la rvalue qu'on lui fournit, on ne peut, quoi qu'il en soit, de toutes manières pas éviter la création de l'objet "vampirisé", et donc l'allocation dynamique qui va avec

Nous en revenons donc au point de départ : au niveau de l'argument (transmis par valeur) en lui-même, il y aura soit une copie, soit une création et la sémantique de mouvement n'est pas applicable (parce que l'argument est nommé), sauf à y faire explicitement appel

[Iradrille]

Merci

J'aurais pas pensé que f2 génère une allocation, juste la création d'un string et copie du pointeur interne, mais pas la copie du contenu.

Toujours bon à savoir.

[koala01]

Merci

J'aurais pas pensé que f2 génère une allocation, juste la création d'un string

Ben, à partir de là, tout est dit

et copie du pointeur interne, mais pas la copie du contenu.

C'est pourtant "logique".

Que ferais le code

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
int main(){
    char * ptr= new char[8];
    memcpy(ptr,"salut\0", 6);
    std::string str(ptr);
    memcpy(ptr,"hello\0", 6);
    // la ligne suivante affiche quoi? pourquoi? qu'est ce que cela afficherait 
    // s'il n'y avait pas copie du contenu?
    sdt::cout<<str<<std::endl;
    delete [] ptr;
    return 0;
}

s'il n'y avait pas copie du contenu, selon toi
(le code est crade, mais il est légal, hein )

[Iradrille]

s'il n'y avait pas copie du contenu, selon toi
(le code est crade, mais il est légal, hein )

Le cas est différent, on avait une constante de compilation, du coup j'imaginais que le compilo se démerdait pour pas faire de copie du contenu.

[Médinoc]

On peut toujours créer une classe qui ne fait pas de copie de la chaîne passée au constructeur, mais comme j'en ai fait l'expérience, ça cause généralement plus de problèmes que ça n'améliore les performances.

Par contre, lors d'une copie d'objet à objet, on peut facilement faire du copy-on-write (généralement avec un comptage de références).

[koala01]

Le cas est différent, on avait une constante de compilation, du coup j'imaginais que le compilo se démerdait pour pas faire de copie du contenu.

Disons qu'il est possible que le compilateur soit éventuellement en mesure de constater qu'un code proche de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
std::string str="salut ";
/* du  code, qui ne fait pas appel à str ici */
str +="le monde";
/* encore du code ici (avec utilisation de str) */

pourrait éventuellement être optimisé sous la forme de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
std::strintg str="salut le monde";
/* tout ce qu'il faut faire */

Mais, s'il fallait commencer à gérer le cas où tu te contentes de récupérer l'adresse du premier caractère parce que tu as affaire à une constante de compilation, puis à gérer tous les cas qui font que la copie en profondeur devient utile/ indispensable, ca deviendrait rapidement un b..del sans nom

[therwald]

Mais, s'il fallait commencer à gérer le cas où tu te contentes de récupérer l'adresse du premier caractère parce que tu as affaire à une constante de compilation, puis à gérer tous les cas qui font que la copie en profondeur devient utile/ indispensable, ca deviendrait rapidement un b..del sans nom

+1
Au compilo les "calculs" compliqués et aveugles, aux développeurs la réflexion, non?

[koala01]

+1
Au compilo les "calculs" compliqués et aveugles, aux développeurs la réflexion, non?

Tout à fait

Le problème, c'est que, s'il est assez facile de repérer les cas où la copie en profondeur devient indispensable -- ce qui nous rapproche du principe copy-on-write (utilisé entre autres par Qt et sa classe QString, il me semble ), il est par contre assez compliqué de faire la distinction entre les cas où le char * utilisé comme argument est, réellement, un pointeur sur une constante de compialtion (std::string str("hello world");) et celui où il s'agit d'un pointeur vers des caractères "classique" (std::string str(ptr); //ptr: constante de compilation ou chaine C style modifiée par ailleurs ???).

Et c'est d'autant plus vrai qu'il faut non seulement veiller à ce que ce soit cohérent en amont du constructeur, mais aussi en aval de ce dernier.

Sans oublier qu'il y aura sans doute un conflit de responsabilités entre le développeur de std::string et celui du compilateur:

Celui qui peut prendre la décision de fournir la possibilité de travailler de la sorte, c'est le développeur de std::string, mais celui qui devra prendre la décision finale, c'est le développeur du compilateur, qui a besoin de connaitre tout le code et tous les chemins qui mènent à l'utilisation du pointeur aussi bien en amont qu'en aval du constructeur afin de prendre sa décision, étant donné que le fait de ne pas faire la copie en profondeur sera dans de très nombreux cas la "mauvaise décision" (celle qui mènera à toutes sortes de catastrophes).

S'il est "facile" d'envisager d'utiliser un tableau de taille fixe pour les petites chaines de caractères (jusqu'à mettons 8 caractères, 0 terminal compris), et un tableau utilisant l'allocation dynamique pour les autres (car toute cette gestion peut se faire exclusivement au niveau de std::string), il est beaucoup plus difficile de gérer le cas où le pointeur est une constante de compilation, car c'est tout le code qui utilise la chaine de caractères et le pointeur en question qui doit être pris en compte

[Iradrille]

Mais, s'il fallait commencer à gérer le cas où tu te contentes de récupérer l'adresse du premier caractère parce que tu as affaire à une constante de compilation, puis à gérer tous les cas qui font que la copie en profondeur devient utile/ indispensable, ca deviendrait rapidement un b..del sans nom

J'en était resté à l'exemple

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
void f2(const std::string&);
f2("abc");

Constante de compilation + const ref, c'est évident ici qu'une copie est inutile. Et si on évite la copie seulement dans les cas sûrs comme celui là, il ne peut pas y avoir de problèmes.

(Il est toujours possible de tout casser avec des const_cast, m'enfin dans tous les cas, si on veut faire un truc qui marche pas on y arrivera )

[PilloBuenaGente]

Encore une fois, merci beaucoup Koala01 !

Salut,
A vrai dire, tu n'as pas vraiment à t'inquiéter de cela, car cela rentre vraiment dans l'optimisation prématurée, que tout le monde sait (ou du moins devrait savoir ) être la voie expresse vers tous les problèmes

C'est en effet dans la signature d'un habitué du forum, et je le garde en tête. Toute ces explications me permettent néanmoins de mieux comprendre ce que je fait.

1- Il y aura un "tableau de caractères" contenant "Salut tout le monde" (sans les guillemets ) qui prendra place dans une partie "read only" de ton exécutable (je crois qu'on appelle cette partie le "data segment"... à vérifier ).

D'après wikipedia (...)
"Data segment" serait une partie de la mémoire "read-write" de taille fixe réservée à l'application.
La partie en "read-only" (pour la plupart des architectures) serait appelée "Code segment".
Ils font aussi allusion à un certain "Rodata" dont j'ai plus de mal à trouver confirmation.

[koala01]

Encore une fois, merci beaucoup Koala01 !
C'est en effet dans la signature d'un habitué du forum, et je le garde en tête. Toute ces explications me permettent néanmoins de mieux comprendre ce que je fait.

Et c'est une citation que j'aime énormément, presque autant que celle de ma propre signature

Mais bon, on n'a droit qu'à un espace limité pour la signature, alors...

D'après wikipedia (...)
"Data segment" serait une partie de la mémoire "read-write" de taille fixe réservée à l'application.
La partie en "read-only" (pour la plupart des architectures) serait appelée "Code segment".
Ils font aussi allusion à un certain "Rodata" dont j'ai plus de mal à trouver confirmation.

Ben voilà, je me coucherai moins bête ce soir que je ne l'étais ce matin en me levant

Merci d'avoir vérifié

[koala01]

Ils font aussi allusion à un certain "Rodata" dont j'ai plus de mal à trouver confirmation.

intrigué, j'ai essayé d'en savoir plus sur la rodata.

Le seul lien concluant que j'ai trouvé est ==>celui-ci<==.

Les autres liens que j'ai trouvé sur le sujet sont tous reliés à l'éditeur de liens ld.

Il semblerait donc que la section rodata soit une "invention" spécifique au monde libre (apparue avec la version 3-x de Gcc).

Je ne serait pas étonné outre mesure qu'ils l'ont introduite afin de faciliter la mise en place du PIC (Position Independant Code), car quelques liens suivis indiquaient qu'il était possible d'affecter une valeur précise comme adresse de départ de cette section dans les scripts utilisés par ld

Pour le reste, tout me porte à croire (peut être à tord ) qu'il ne s'agit en réalité que d'une séparation "artificielle" du segment code en deux parties distinctes... Mais je peux toujours me tromper

[Médinoc]

Pour moi, ce serait plutôt une séparation du segment de données sur différentes pages, mais c'est parce que c'est ce que j'aurais fait.

Sur x86, on veut que toutes les données, inscriptibles ou non (même si on ne peut pas les rendre non-inscriptible sur 8086) soient accessibles par DS, et non CS.

[koala01]

Et sommes toutes, je serais bien tenté de te croire parce que la version 3 de Gcc nous ramène presque vingt ans en arrière (bon, allez, j'exagère un peu là : 12 ans en arrière seulement )

Et comme l'assembleur et moi n'avons jamais été plus copains que ca...