Discussion :

[tasna]

Bonjour,

J'ai un probl�me avec ce code :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
 
//Je crée une chaîne de caractères pouvant en contenir 65538
char *Line=new char[65538];
if(Line!=0)
{
     //Je lis une ligne dans un fichier et je la stocke dans la chaîne de caractères
     fgets(Line,65538,hConfigurationFile);
     //Je crée une variable qui va contenir la longueur de la chaîne de caractères
     int *LineLen=new int;
     if(LineLen!=0)
     {
          *LineLen=strlen(Line);
          //Si le dernier caractère est un caractère de nouvelle ligne ou si le nombre de caractères dépasse 65536
          if(Line[*LineLen-1]=='\n' || *LineLen>65536)
          {
               //J'efface le dernier caractère
               Line[*LineLen]=0;
               //Je décrémente la variable qui contient la longueur de la chaîne de caractères
               *--LineLen;
          }
          delete LineLen;
     }
     delete[] Line;
}

Le probl�me est qu'apr�s la d�cr�mentation de la variable LineLen celle-ci contient une valeur erron�e.

A l'instant LineLen est �gal � 11 et apr�s la d�cr�mentation �tait �gal � 17.

D'avance merci de votre aide.

[Bousk]

Bonjour,

il faut se calmer sur l'allocation dynamique.

Pour le reste, les op�rateurs ont une pr�c�dence qui d�termine leur priorit�.
Et il se trouve que -- est r�alis� avant *.
Donc *--lineLen- d�cr�mente le pointeur, soit la zone point�e
- pointe du coup sur une zone invalide
- l'op�rateur * qui prend la valeur de cette zone ne sert � rien

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

(*lineLen)--;

Mais l'allocation dynamique ne sert � rien dans tes 2 cas.

http://en.wikipedia.org/wiki/Operators_in_C_and_C%2B%2B

ps: std::string, std::istream

[koala01]

Salut:

Je rejoins Bousk, mais je vais meme encore plus loin : il n'y a strictement aucune raison de recourrir � l'allocation dynamique de la m�mire, et tu pourrais, de plus, te simplifier �norm�ment la vie en travaillant dans une optique C++ et non dans une optique C

Ton code pourrait devenir quelque chose comme :
std::ifsream ifs("fichier.txt")
std::string configLine;

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
while(std::getline(configLine , ifs))
{
    /* si on passe ici, on est sur
     * 
     * 1- qu'une ligne non vide a bel et bien été lue
     * 2- qu'on s'est arrêté au retour à la ligne
     */
}

Avoue que c'est quand meme plus simple, non

[tasna]

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
 
struct Rule
{
     bool InputAllowed;
     bool OutputAllowed;
     bool Redirect;
     char RedirectIpv4Addr[16];
     int RedirectPort;
};
 
Rule *Rules=new Rule[65535];

�a va faire un peu beaucoup de m�moire utilis�e si j'alloue un tableau statique de 65535 structures.

Et puis je vais devoir parcourir ce tableau compl�tement et le plus rapidement possible alors il vaut mieux que j'utilise un tableau dynamique.

Je me suis pench� sur l'allocation dynamique seulement hier et aujourd'hui et maintenant que je comprend l'utilit� des pointeurs et de l'allocation dynamique je pr�f�re l'utiliser partout quitte � avoir plus de lignes de code.

Je sais que les chances de tomber sur un syst�me ne disposant plus que de 1Ko de m�moire disponible sont tr�s faibles et que d�clarer des pointeurs � tout bout de champ peut s�av�rer long et pas tr�s utile mais je trouve que bien contr�ler sa consommation de m�moire est important.

J'aime bien d�sallouer les variables que je n'utilise plus.

[gl]

Je sais que les chances de tomber sur un syst�me ne disposant plus que de 1Ko de m�moire disponible sont tr�s faibles et que d�clarer des pointeurs � tout bout de champ peut s�av�rer long et pas tr�s utile mais je trouve que bien contr�ler sa consommation de m�moire est important.

Ah! Et en quoi contr�les-tu mieux ta consommation de la sorte qu'en utilisant un tableau statique, un std::vector ou une std::string (pour l'exemple initial) avec un scope correctement g�r� ?

Par contre ainsi tu vas vers du code d�licat � maintenir et probablement moins robuste.

[tasna]

Bah si je me remets � utiliser que des tableaux et variables statiques je ne vais pas pouvoir les d�sallouer quand j'en aurais plus besoin.

C'est vrai qu'utiliser un pointeur pour une variable qu'on va juste incr�menter � un certain moment puis d�sallouer n'est pas tr�s utile au vu de sa consommation de m�moire mais si on faisait tous �a on en gagnerait des Mo.

Mais je me suis vraiment int�ress� � l'allocation dynamique il y a seulement un jour et l� je suis surement atteint de l'effet "J'ai appris quelque chose d'utile alors je l'utilise partout."

Je crois que je vais utiliser l'allocation dynamique pour les longues cha�nes de caract�res de 8192 octets et plus ainsi que les tableaux de structures ou de sockets.

[dourouc05]

Bah si je me remets � utiliser que des tableaux et variables statiques je ne vais pas pouvoir les d�sallouer quand j'en aurais plus besoin.

Non, c'est vrai, ce sera fait automatiquement en sortie du scope, il n'y a plus de risque d'oublier un free() ou un delete quelque part (m�me si tu aimes g�rer �a, c'est une mauvaise pratique, tu le comprendras quand tu auras des applications bien plus lourdes que �a). Si tu veux vraiment en contr�ler l'existence � l'instruction pr�s, tu peux toujours utiliser un nouveau bloc d'instructions.

Le tout n'est pas de bien aimer, de vouloir �conomiser le moindre octet : si, dans deux mois, tu reviens sur ton bout de code, que vas-tu te dire ? "Quel fou d'�crire �a" ou approchant. � vrai dire, �a aurait �t� du Perl que �a ne m'aurait pas �tonn� (la philosophie �tant de pouvoir tout �crire de mani�re aussi cryptique que possible, ses adeptes disent qu'ils font comme �a des programmes tr�s courts). Tu as �t� oblig� de commenter chaque ligne pour te d�patouiller de ce que tu as fait, c'est d�j� mauvais signe.

Aussi, pourquoi cr�er un pointeur sur entier ? Grosso modo, tu doubles ta consommation m�moire ! (Voire un peu plus si tu es sur un syst�me 64 bits.)

[tasna]

Je ne commente jamais.
Oui je sais =

Les commentaire ne font pas partie du code actuel et la variable hConfigurationFile s'appelle m�me hFile. Encore moins explicite.

[Bousk]

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
 
struct Rule
{
     bool InputAllowed;
     bool OutputAllowed;
     bool Redirect;
     char RedirectIpv4Addr[16];
     int RedirectPort;
};
 
Rule *Rules=new Rule[65535];

�a va faire un peu beaucoup de m�moire utilis�e si j'alloue un tableau statique de 65535 structures.

Et puis je vais devoir parcourir ce tableau compl�tement et le plus rapidement possible alors il vaut mieux que j'utilise un tableau dynamique.

Je me suis pench� sur l'allocation dynamique seulement hier et aujourd'hui et maintenant que je comprend l'utilit� des pointeurs et de l'allocation dynamique je pr�f�re l'utiliser partout quitte � avoir plus de lignes de code.

Je sais que les chances de tomber sur un syst�me ne disposant plus que de 1Ko de m�moire disponible sont tr�s faibles et que d�clarer des pointeurs � tout bout de champ peut s�av�rer long et pas tr�s utile mais je trouve que bien contr�ler sa consommation de m�moire est important.

J'aime bien d�sallouer les variables que je n'utilise plus.

Mais c'est tout l'inverse que tu fais.
- l'allocation statique et sa destruction peut �tre totalement contr�l�e avec les scopes
- faut-il rappeler qu'on peut cr�er autant de scope que l'on souhaite avec {} ?
- les 65k structures sont de toutes fa�ons en m�moire
- mais en plus tu as 1 pointeur vers ses structures
=> donc tu "perds" la m�moire inutile d'un pointeur suppl�mentaire, pour ne pas savoir placer des {} et contr�ler des sous-scopes ?