Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement Langage C++ [Debutant] Probleme de destruction

[Debutant] Probleme de destruction

120 réponses
Avatar
Yoxoman
Bonjour à tous.

Je me permet de vous soumettre ce petit programme, qui représente en
gros la partie qui me pose problème d'un truc plus gros :

#include <iostream>

using namespace std;

class Vecteur
{
public:
double *val;
int taille;

Vecteur() {}
Vecteur(int i);
~Vecteur() {cout << "detruit" << endl; delete[] val;}

Vecteur foisDeux();
Vecteur &operator=(const Vecteur &v);
};

Vecteur::Vecteur(int i)
{
taille=i;
val=new double[i];
}

Vecteur Vecteur::foisDeux()
{
Vecteur temp(taille);

for (int i=0; i<taille; i++)
{
temp.val[i]=2*val[i];
}

return temp; //(1)
}

Vecteur &Vecteur::operator=(const Vecteur &v)
{
taille=v.taille;
val=new double[taille];

for (int i=0; i<taille; i++)
{
val[i]=v.val[i];
}

return *this;
}

int main(void)
{
Vecteur v1(3);
Vecteur v2;

v2=v1.foisDeux(); //(2)

return 0;
}

Segmentation fault.
J'ai tout d'abord eu du mal à identifier le problème, mais j'ai réussi
grâce à des supers pouvoirs hérités de Goldorak.
En fait, à la fin de la fonction foisDeux(), la variable temporaire
temp est détruite. Logique. En même temps, la fonction renvoie une
copie de l'objet, qui possède donc dans ses attributs un pointeur sur
une zone mémoire inaccessible (action du delete[]). Problème donc à la
destruction de ce dernier.

En fait, je ne sais pas trop comment arranger ce problème. Je ne
voudrais pas modifier *directement* les attributs de v1 dans la
fonction foisDeux(), pour garder ce vecteur en stock.

Merci d'avance pour votre aide.
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
8 9 10 11 12
Avatar
Olivier Azeau
wrote:
Olivier Azeau wrote:
C'est pour cela que j'ai, légitimement je pense, un peu "peur" quand
on veut faire passer le C++ pour un langage de haut-niveau : dans
beaucoup de contextes, même si on essaie de faire évoluer les choses,
cela n'est pas la réalité quotidienne.


C'est la réalité dans les boîtes où j'ai travaillé -- le « bas
niveau »
qui nous a intéressé n'était jamais celui de C++, mais des sockets,
les
threads, et des bases de données. Et même là, il y avait toujours un
petit groupe qui s'y connaissaient, et qui encapsulait pour que les
autres n'avaient pas à y connaître. Mais ça dépend du domaine de
l'application, évidemment.

[SNIP]


La même chose vaut pour la programmation. Si on connaît les détails
du
bas niveau, c'est fort possible qu'on saurait mieux programmer. Mais la
différence ne se ferait pas sentir si on ne travaille que sur des
applications ; si on veut travailler sur des projets comme celui où je
travaille actuellement, et la question se pose où investir le temps
d'apprentissage, des choses comme l'UML, les bases de données, et
même
la législation boursière me semble plus important que l'arithmétique
des
pointeurs. Y compris pour écrire du C++.



Si on est dans un environnement bien encadré, où l'on écrit des
applications à partir d'une feuille blanche et où il n'y a pas trop de
mélanges technologiques, il n'y a pas de problème.

Mais la réalité de plusieurs projets sur lesquels j'ai travaillé c'est
de la reprise d'existant (au moins en partie) dont plus personne ne
maîtrise complètement le coeur de l'appli et où les principaux reproches
ne sont jamais fonctionnels : (dans le désordre) "c'est trop lent" / "la
conso mémoire ne cesse d'augmenter" / "l'appli a crashé, on ne sait pas
le reproduire mais il faudrait corriger ça".
Bref, il vaut mieux avoir un minimum de connaissance sur les techniques
de recherche de fuite mémoire et de profiling, donc, entre autres,
comprendre les implications de l'utilisation de telle ou telle classe,
voire être capable d'en tracer le comportement.
Et surtout être capable de rentrer dans du code C++ qui est souvent tout
sauf "académique".


Avatar
Gabriel Dos Reis
Olivier Azeau writes:

[...]

| Et surtout être capable de rentrer dans du code C++ qui est souvent
| tout sauf "académique".

Mais cela ne nécessite pas qu'on commence l'enseignement de la
programmation avec C++ avec la gestion manuelle de la mémoire.

À moins bien sûr, que par « académique », tu veux dire du code C++
propre et maintenable. Dans ce cas, j'en ai vu plus dans l'industrie
qu'à l'école.

-- Gaby
Avatar
Olivier Azeau
Matthieu Moy wrote:
Olivier Azeau writes:


Je vois pour ma part des personnes qui connaissent des langages
évolués, dont le C++, et qui savent faire des bons trucs mais, quand
on gratte la surface pour aller sur un comportement plus bas niveau,
il n'y a plus personne.



Je te rassure, la réciproque est vraie aussi, surtout avec le C++
qu'un programmeur C peut prétendre connaitre s'il sait faire "mv
toto.c toto.cpp" ... Je pourrais citer l'exemple (vecu) de quelqu'un
faisant du C++ depuis 3 ans pour son boulot, et qui vient de découvrir
std::vector !



Je suis parfaitement conscient de la réciproque qui est tout aussi
inacceptable.

Pour ton exemple, de 2 choses l'une :
- soit personne n'a jamais regardé le code de cette personne depuis 3 ans
- soit les personnes qui ont regardé sont incompétentes (ou fourbes ce
qui est même pire)
Dans les 2 cas, il y a un problème flagrant d'organisation.


Avatar
Marc Boyer
In article <BE0wd.4482$, Olivier Azeau wrote:
wrote:
En C (et en C++), il y a aussi l'arithmétique sur pointeurs -- le
pointeur en C ou en C++, c'est vraiment le pointeur au niveau hardware.
Et souvent, quand on parle d'enseigner les pointeurs, c'est de ça
qu'on
parle. Or, ça, c'est bon si on fait un cours sur la programmation de
bas
niveau (ce qu'on doit faire si on veut devenir ingenieur en
informatique, disons à la troisième ou à la quatrième année). Mais
personnellement, je n'en vois pas l'intérêt dans un cours « C++ »,
où le
seul but est d'apprendre aux gens d'écrire des programmes. Pourquoi
enseigner quelque chose qui ne doit jamais servir à la plupart des
élèves ?



En fait je crois que c'est là le fond du débat :

Pourquoi enseigner le C++ à des gens qui ne feront de ttes façons que
des programmes qu'ils feraient de manière beaucoup plus efficace avec un
autre langage ?


Ben, ça, c'est le genre d'affirmation qui demande argumentation.
A quels gens apprend-on le C++ alors qu'un autre langage (lequel ?)
les rendraient plus efficace ?

Marc Boyer
--
Je ne respecte plus le code de la route à vélo depuis une double fracture
due au fait que j'étais le seul à le respecter.


Avatar
kanze
Marc Boyer wrote:
In article <BE0wd.4482$, Olivier Azeau
wrote:

wrote:



[...]
En fait je crois que c'est là le fond du débat :

Pourquoi enseigner le C++ à des gens qui ne feront de ttes
façons que des programmes qu'ils feraient de manière
beaucoup plus efficace avec un autre langage ?



En effet. Si on pense qu'un autre langage leur serait plus
utile, pourquoi leur enseigner le C++ ?

Ben, ça, c'est le genre d'affirmation qui demande
argumentation. A quels gens apprend-on le C++ alors qu'un
autre langage (lequel ?) les rendraient plus efficace ?


Ça dépend ce qu'il doivent faire. Et aussi ce qu'on entend par
« plus efficace » -- il existe de beaux langages en principe,
mais s'ils n'ont pas de compilateur pour la plateforme qui
m'intéressent, ils ne me rendent pas plus efficace.

Dans la pratique, je crois pouvoir dire que mon choix de
langages est assez limité : C, C++, et peut-être Java et
Ada. Parmi ces langages-là, pour efficacité du programmeur dans
mon domaine d'application (serveurs importants, avec des clients
dédiés), on peut écarter immédiatement le C, et assez vite le
Java. L'Ada, c'est peut-être un alternatif intéressant, mais il
manque de l'infrastruture et les outils de développement par
rapport au C++.

--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34


Avatar
Olivier Azeau
wrote:
Marc Boyer wrote:

In article <BE0wd.4482$, Olivier Azeau


wrote:

wrote:




[...]

En fait je crois que c'est là le fond du débat :




Pourquoi enseigner le C++ à des gens qui ne feront de ttes
façons que des programmes qu'ils feraient de manière
beaucoup plus efficace avec un autre langage ?




En effet. Si on pense qu'un autre langage leur serait plus
utile, pourquoi leur enseigner le C++ ?


Ben, ça, c'est le genre d'affirmation qui demande
argumentation. A quels gens apprend-on le C++ alors qu'un
autre langage (lequel ?) les rendraient plus efficace ?



Ça dépend ce qu'il doivent faire. Et aussi ce qu'on entend par
« plus efficace » -- il existe de beaux langages en principe,
mais s'ils n'ont pas de compilateur pour la plateforme qui
m'intéressent, ils ne me rendent pas plus efficace.

Dans la pratique, je crois pouvoir dire que mon choix de
langages est assez limité : C, C++, et peut-être Java et
Ada. Parmi ces langages-là, pour efficacité du programmeur dans
mon domaine d'application (serveurs importants, avec des clients
dédiés), on peut écarter immédiatement le C, et assez vite le
Java. L'Ada, c'est peut-être un alternatif intéressant, mais il
manque de l'infrastruture et les outils de développement par
rapport au C++.



J'ai eu l'occasion de travailler sur des serveurs de calcul qui devaient
traiter de gros volumes de flux de données en "temps-réel" - ce qui
signifiait en l'occurrence que le débit du flux de sortie ne doit pas
être inférieur à celui d'entrée - et, effectivement, le C++ était
probablement le meilleur choix *car* il y avait un grand souci de
rapidité et de gestion de l'occupation mémoire.

Ces 2 facteurs semblent essentiels. Dès qu'il s'agit de mêler une bonne
dose de fonctionnel le C++ n'est plus le 1er choix : pour des raisons de
sécurité (manque de contrôle sur les possibilités du binaire généré),
pour des raisons d'évolutivité (compilation, dépendances binaires), ...
Je ne compte plus les projets où l'on réserve le C++ aux parties
pointues et où l'on introduit des langages plus légers et aux contours
mieux limités, javascript par exemple, pour le fonctionnel ou l'intégration.

Pour ce qui est de la disponibilité des outils, C++ est peut-être en
tête mais on constate tout de même que c'est loin d'être un choix
systématique. cf par exemple les statistiques SourceForge sur
http://c2.com/cgi/wiki?ProgrammingLanguagePopularity : C++ est en tête
mais représente moins de 20% de l'ensemble.
Et pourtant ces statistiques sur du logiciel libre n'incluent pas
l'armada incontournable de MS avec tous les VisualXXX, sans oublier le
VBA dans Office.
On peut lire aussi sur
http://c2.com/cgi/wiki?ProgrammingLanguageUsageStatistics : "According
to IDC, out of 13 million developer seats worldwide in 1999, Visual
Basic had 7.2 million vs. 3.6 million for C/C++ seats and 1.3 million
Java seats. By 2003, Visual basic should still be ahead with 7.4
million, but the race will be closer with 5.2 million C/C++ developer
seats, and 4.4 million Java seats."
Sans compter que dans le lot C++, on compte bien évidemment les
"dialectes" comme COM/C++ qui est très présent et qui n'est qu'un
lointain cousin d'un C++ qui se voudrait proche de Ada.



Avatar
Gabriel Dos Reis
Olivier Azeau writes:

[...]

| Ces 2 facteurs semblent essentiels. Dès qu'il s'agit de mêler une
| bonne dose de fonctionnel le C++ n'est plus le 1er choix : pour des
| raisons de sécurité (manque de contrôle sur les possibilités du
| binaire généré), pour des raisons d'évolutivité (compilation,
| dépendances binaires), ...

Par « fonctionnel » tu veux dire quoi exactement ?

-- Gaby
Avatar
Olivier Azeau
Gabriel Dos Reis wrote:
Olivier Azeau writes:

[...]

| Ces 2 facteurs semblent essentiels. Dès qu'il s'agit de mêler une
| bonne dose de fonctionnel le C++ n'est plus le 1er choix : pour des
| raisons de sécurité (manque de contrôle sur les possibilités du
| binaire généré), pour des raisons d'évolutivité (compilation,
| dépendances binaires), ...

Par « fonctionnel » tu veux dire quoi exactement ?



Grosso modo, tout ce qui nécessite un importante connaissance métier par
opposition à ce qui nécessite un savoir faire beaucoup plus informatique.
Et qui donc (en général) :
- est plutôt l'apanage de personnes dont la formation principale n'est
pas de faire du logiciel.
- suit des cycles de besoins beaucoup plus changeants par rapport à une
base technique qui arrive plus facilement à converger.

Quand on pousse ce découpage à l'extrême, on a par exemple un Tableur
bien connu réalisé en C++ et de nombreuses applications bâties sur ce
Tableur par des gens qui arrivent à faire pleins de trucs sans connaître
un seul mot clef de C++.

Olivier.

Avatar
Gabriel Dos Reis
Olivier Azeau writes:

| Gabriel Dos Reis wrote:
| > Olivier Azeau writes:
| > [...]
| > | Ces 2 facteurs semblent essentiels. Dès qu'il s'agit de mêler une
| > | bonne dose de fonctionnel le C++ n'est plus le 1er choix : pour des
| > | raisons de sécurité (manque de contrôle sur les possibilités du
| > | binaire généré), pour des raisons d'évolutivité (compilation,
| > | dépendances binaires), ...
| > Par « fonctionnel » tu veux dire quoi exactement ?
| >
|
| Grosso modo, tout ce qui nécessite un importante connaissance métier
| par opposition à ce qui nécessite un savoir faire beaucoup plus
| informatique.

comme les gens (e.g. physicien ou matheux appliqués) qui font du
calcul scientifique par exemple ?

-- Gaby
Avatar
kanze
Olivier Azeau wrote:
wrote:
Marc Boyer wrote:

In article <BE0wd.4482$, Olivier Azeau


wrote:

wrote:



[...]

En fait je crois que c'est là le fond du débat :

Pourquoi enseigner le C++ à des gens qui ne feront de ttes
façons que des programmes qu'ils feraient de manière
beaucoup plus efficace avec un autre langage ?



En effet. Si on pense qu'un autre langage leur serait plus
utile, pourquoi leur enseigner le C++ ?

Ben, ça, c'est le genre d'affirmation qui demande
argumentation. A quels gens apprend-on le C++ alors qu'un
autre langage (lequel ?) les rendraient plus efficace ?


Ça dépend ce qu'il doivent faire. Et aussi ce qu'on entend par
« plus efficace » -- il existe de beaux langages en principe,
mais s'ils n'ont pas de compilateur pour la plateforme qui
m'intéressent, ils ne me rendent pas plus efficace.

Dans la pratique, je crois pouvoir dire que mon choix de
langages est assez limité : C, C++, et peut-être Java et
Ada. Parmi ces langages-là, pour efficacité du programmeur dans
mon domaine d'application (serveurs importants, avec des clients
dédiés), on peut écarter immédiatement le C, et assez vite le
Java. L'Ada, c'est peut-être un alternatif intéressant, mais il
manque de l'infrastruture et les outils de développement par
rapport au C++.


J'ai eu l'occasion de travailler sur des serveurs de calcul
qui devaient traiter de gros volumes de flux de données en
"temps-réel" - ce qui signifiait en l'occurrence que le débit
du flux de sortie ne doit pas être inférieur à celui d'entrée
- et, effectivement, le C++ était probablement le meilleur
choix *car* il y avait un grand souci de rapidité et de
gestion de l'occupation mémoire.

Ces 2 facteurs semblent essentiels. Dès qu'il s'agit de mêler
une bonne dose de fonctionnel le C++ n'est plus le 1er choix :
pour des raisons de sécurité (manque de contrôle sur les
possibilités du binaire généré), pour des raisons
d'évolutivité (compilation, dépendances binaires), ... Je ne
compte plus les projets où l'on réserve le C++ aux parties
pointues et où l'on introduit des langages plus légers et aux
contours mieux limités, javascript par exemple, pour le
fonctionnel ou l'intégration.


Et quel est le premier choix ? L'Ada, peut-être, mais les outils
de développement ne sont pas toujours ce qu'on aimerait. Et
c'est bigrement difficile à trouver des gens expérimentés en Ada
95.

Dans la pratique, quand il s'agit de sécurité, malgré ses
défauts théorique, le C++ en sort plutôt bien. Quoiqu'on dise,
c'est bien possible, et même assez facile, à écrire du mauvais
code en n'importe quel langage. Quand la sécurité entre en jeu,
il n'est pas question de se passer d'un bon processus de
développement.

Or, si le C++ a souvent les choix par défaut qui ne conviennent
pas, il permet toujours à passer outre, et je n'ai pas encore
rencontré une situation où il m'a empéché de faire
ultra-robuste. Chose que je ne peux pas dire pour certains
autres langages modernes qui se vantent de leur fiabilité.

Plus généralement : je n'ai pas eu l'occasion d'essayer un grand
projet en Ada. Je le regrette, parce que d'après le peu que je
connais, je crois que Ada s'y préterait. En revanche, j'ai pas
mal d'expérience en C, en C++ et en Java. Assez pour dire que le
C et le Java n'y conviennent pas, ni si le projet est grand, ni
s'il faut une certaine robustesse.

Pour ce qui est de la disponibilité des outils, C++ est peut-être
en

tête mais on constate tout de même que c'est loin d'être un choix
systématique. cf par exemple les statistiques SourceForge sur
http://c2.com/cgi/wiki?ProgrammingLanguagePopularity : C++ est en
tête

mais représente moins de 20% de l'ensemble.


Je ne prendrais pas un échantionnage des projets pris d'une
façon aléatoire comme mésure de la qualité. Qu'il soit open
source ou privé, la grande majorité des logiciels ne sont pas
d'une qualité qui m'impressionne.

Et pourtant ces statistiques sur du logiciel libre n'incluent pas
l'armada incontournable de MS avec tous les VisualXXX, sans oublier
le

VBA dans Office.


Je n'ai jamais dit que pour les petits bricolages qu'il fallait
préférer C++ à un langage de script. J'utilise beaucoup AWK, par
exemple -- c'est bien plus simple à mettre en oeuvre que le C++,
et largement suffisant pour des applications jusqu'à peu près
mille lignes de code.

Dans un contexte plus moderne, comme des pages de Web,
j'utiliserais bien le Java, par le biais des JSP. Après tout,
mon programme ne serait jamais plus fiable que la plateforme sur
laquelle il tourne (par exemple, Apache), et l'infrastructure
des JSP dépasse largement ce qui est disponible pour le C++.
(C'est pareil, d'ailleurs, pour un client graphique. Swing,
c'est nettement mieux que MFC, et même en Java, tu arrives sans
trop de difficultés à écrire du code plus fiables que Windows.)

On peut lire aussi sur
http://c2.com/cgi/wiki?ProgrammingLanguageUsageStatistics :
"According

to IDC, out of 13 million developer seats worldwide in 1999, Visual
Basic had 7.2 million vs. 3.6 million for C/C++ seats and 1.3 million

Java seats. By 2003, Visual basic should still be ahead with 7.4
million, but the race will be closer with 5.2 million C/C++ developer

seats, and 4.4 million Java seats."
Sans compter que dans le lot C++, on compte bien évidemment les
"dialectes" comme COM/C++ qui est très présent et qui n'est qu'un
lointain cousin d'un C++ qui se voudrait proche de Ada.


Mais quel rapport ? Si tu enseignes des techniciens qui vont
écrire des applications client vite fait, c'est probablement le
VB qu'il faut enseigner, plutôt que le C++. J'avoue être un peu
élitiste, mais je n'appelle pas ça la programmation:-). (Même is
je sais que ce l'est, et que dans son contexte, c'est aussi
valable que ce que je fais.)

--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34




8 9 10 11 12