J'ai défini une classe Signature qui utilise plusieurs structures
personnelles (mais aucune autre classe).
Mon problème, c'est que mon programme plante après 2 ou 3 créations
d'objets. Après avoir créé dynamiquement 2 objets, l'allocation me
génère un coredump (sous Linux), avant même l'appel du constructeur.
Signature *s = new Signature();
// ou encore
Signature *s = (Signature*)malloc(sizeof(Signature));
alors que Signature s; fonctionne sans erreur.
Je croyais qu'une allocation mémoire impossible renvoyait NULL, mais
ne générait pas d'erreur.
Quelqu'un comprend t-il comment le programme peut planter à la
création de l'objet ?
classes et structures sont identiques en C++. Et mélanger l'usage de new/delete et malloc/free n'est pas tellement conseillé. Donc pour matrice utilise de préférence new/delete.
Il s'agit d'une structure définie dans une bibliothèque d'images que j'utilise, ayant ses propres fonctions d'initialisation. Je ne peux donc pas remplacer l'utilisation de malloc (interne) par un new.
Il n'est jamais appelé ou bien il ne doit jamais être appelé ? Quoi qu'il en soit la désactivation du constructeur par copie permet de s'en assurer.
Je viens d'en créer un pour être sûr, et il n'est jamais appelé.
classes et structures sont identiques en C++. Et mélanger l'usage de
new/delete et malloc/free n'est pas tellement conseillé.
Donc pour matrice utilise de préférence new/delete.
Il s'agit d'une structure définie dans une bibliothèque d'images que
j'utilise, ayant ses propres fonctions d'initialisation. Je ne peux
donc pas remplacer l'utilisation de malloc (interne) par un new.
Il n'est jamais appelé ou bien il ne doit jamais être appelé ?
Quoi qu'il en soit la désactivation du constructeur par copie permet de
s'en assurer.
Je viens d'en créer un pour être sûr, et il n'est jamais appelé.
classes et structures sont identiques en C++. Et mélanger l'usage de new/delete et malloc/free n'est pas tellement conseillé. Donc pour matrice utilise de préférence new/delete.
Il s'agit d'une structure définie dans une bibliothèque d'images que j'utilise, ayant ses propres fonctions d'initialisation. Je ne peux donc pas remplacer l'utilisation de malloc (interne) par un new.
Il n'est jamais appelé ou bien il ne doit jamais être appelé ? Quoi qu'il en soit la désactivation du constructeur par copie permet de s'en assurer.
Je viens d'en créer un pour être sûr, et il n'est jamais appelé.
drkm
writes:
drkm wrote in message news:...
Gaël Jaffré writes:
Mais même en testant les 2 cas, et en rattrapant l'exception,
Est-elle réellement lancée ?
Il a parlé d'un problème au bout de deux ou trois allocations. Je doute réelement qu'il ait épuisé toute le mémoire disponible aussi vite.
Effectivement. C'est bien pour cela que je posais la question.
--drkm
kanze@gabi-soft.fr writes:
drkm <usenet.fclcxx@fgeorges.org> wrote in message
news:<wkwu3b3qys.fsf@fgeorges.org>...
Gaël Jaffré <jaffre@irit.fr> writes:
Mais même en testant les 2 cas, et en rattrapant l'exception,
Est-elle réellement lancée ?
Il a parlé d'un problème au bout de deux ou trois allocations. Je doute
réelement qu'il ait épuisé toute le mémoire disponible aussi vite.
Effectivement. C'est bien pour cela que je posais la question.
On Tue, 18 May 2004 10:37:13 +0200, Gaël Jaffré wrote:
Le programme s'arrête avant même l'appel du constructeur, car l'affichage (1ère ligne) ne se fait même pas.
Il se peut que la sortie standard soit bufferisée, et que le programme plante avant que les données à afficher aillent du buffer à l'écran.
Mais il termine sa chaîne par un retour à la ligne. Cela n'implique-t-il pas un flush (j'ai un gros doute, tout d'un coup) ?
[...]
Signature::Signature(void)
le "void" pour indiquer l'absence d'argument, même s'il est accepté par le langage C++, c'est plutôt du C.
Et du vieux, encore. Non ?
[...]
printf("__Construction__n");
--drkm
kanze
Fabien LE LEZ wrote in message news:...
[...]
this->nb_couleurs = 0;
Le "this->" est inutile, il ne sert qu'à alourdir le code et à le rendre moins lisible (ce qui est peut-être le but).
Au moins qu'il a simplifié d'un template, ou qu'il compte le convertir en template une fois que le code marche. Dans un template, le this-> sert à dire au compilateur que le nom qui suis est dépendant.
-- James Kanze GABI Software 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
Fabien LE LEZ <gramster@gramster.com> wrote in message
news:<tqjja0p8l4hqa3rn187jgtqau3o632hmhq@4ax.com>...
[...]
this->nb_couleurs = 0;
Le "this->" est inutile, il ne sert qu'à alourdir le code et à le
rendre moins lisible (ce qui est peut-être le but).
Au moins qu'il a simplifié d'un template, ou qu'il compte le convertir
en template une fois que le code marche. Dans un template, le this->
sert à dire au compilateur que le nom qui suis est dépendant.
--
James Kanze GABI Software
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
Le "this->" est inutile, il ne sert qu'à alourdir le code et à le rendre moins lisible (ce qui est peut-être le but).
Au moins qu'il a simplifié d'un template, ou qu'il compte le convertir en template une fois que le code marche. Dans un template, le this-> sert à dire au compilateur que le nom qui suis est dépendant.
-- James Kanze GABI Software 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
Fabien LE LEZ
On 18 May 2004 15:30:16 +0200, drkm wrote:
Mais il termine sa chaîne par un retour à la ligne. Cela n'implique-t-il pas un flush (j'ai un gros doute, tout d'un coup) ?
Non. cout << "hellon"; est différent de cout << "hello" << endl;
Par contre, pour cerr/stderr, il me semble que la probabilité pour qu'un n fasse un flush est assez forte.
-- ;-) FLL, Epagneul Breton
On 18 May 2004 15:30:16 +0200, drkm <usenet.fclcxx@fgeorges.org>
wrote:
Mais il termine sa chaîne par un retour à la ligne. Cela
n'implique-t-il pas un flush (j'ai un gros doute, tout d'un coup) ?
Non.
cout << "hellon";
est différent de
cout << "hello" << endl;
Par contre, pour cerr/stderr, il me semble que la probabilité pour
qu'un n fasse un flush est assez forte.
Mais il termine sa chaîne par un retour à la ligne. Cela n'implique-t-il pas un flush (j'ai un gros doute, tout d'un coup) ?
Non. cout << "hellon"; est différent de cout << "hello" << endl;
Par contre, pour cerr/stderr, il me semble que la probabilité pour qu'un n fasse un flush est assez forte.
-- ;-) FLL, Epagneul Breton
drkm
Fabien LE LEZ writes:
On 18 May 2004 15:30:16 +0200, drkm wrote:
Mais il termine sa chaîne par un retour à la ligne. Cela n'implique-t-il pas un flush (j'ai un gros doute, tout d'un coup) ?
Non. cout << "hellon"; est différent de cout << "hello" << endl;
Yep.
Par contre, pour cerr/stderr, il me semble que la probabilité pour qu'un n fasse un flush est assez forte.
Oui, je crois que tu as raison. Je pense avoir confondu la différence entre flux C et C++ (le PO utilisait printf), et entre sortie standard et d'erreur.
--drkm
Fabien LE LEZ <gramster@gramster.com> writes:
On 18 May 2004 15:30:16 +0200, drkm <usenet.fclcxx@fgeorges.org>
wrote:
Mais il termine sa chaîne par un retour à la ligne. Cela
n'implique-t-il pas un flush (j'ai un gros doute, tout d'un coup) ?
Non.
cout << "hellon";
est différent de
cout << "hello" << endl;
Yep.
Par contre, pour cerr/stderr, il me semble que la probabilité pour
qu'un n fasse un flush est assez forte.
Oui, je crois que tu as raison. Je pense avoir confondu la
différence entre flux C et C++ (le PO utilisait printf), et entre
sortie standard et d'erreur.
Mais il termine sa chaîne par un retour à la ligne. Cela n'implique-t-il pas un flush (j'ai un gros doute, tout d'un coup) ?
Non. cout << "hellon"; est différent de cout << "hello" << endl;
Yep.
Par contre, pour cerr/stderr, il me semble que la probabilité pour qu'un n fasse un flush est assez forte.
Oui, je crois que tu as raison. Je pense avoir confondu la différence entre flux C et C++ (le PO utilisait printf), et entre sortie standard et d'erreur.
--drkm
kanze
drkm wrote in message news:...
Fabien LE LEZ writes:
le "void" pour indiquer l'absence d'argument, même s'il est accepté par le langage C++, c'est plutôt du C.
Et du vieux, encore. Non ?
Non. La formulation « function() » signifie toujours « nombre et types de paramètres non spécifiés » en C99.
-- James Kanze GABI Software 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
drkm <usenet.fclcxx@fgeorges.org> wrote in message
news:<wkfz9xkglz.fsf@fgeorges.org>...
Fabien LE LEZ <gramster@gramster.com> writes:
le "void" pour indiquer l'absence d'argument, même s'il est accepté
par le langage C++, c'est plutôt du C.
Et du vieux, encore. Non ?
Non. La formulation « function() » signifie toujours « nombre et types
de paramètres non spécifiés » en C99.
--
James Kanze GABI Software
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
le "void" pour indiquer l'absence d'argument, même s'il est accepté par le langage C++, c'est plutôt du C.
Et du vieux, encore. Non ?
Non. La formulation « function() » signifie toujours « nombre et types de paramètres non spécifiés » en C99.
-- James Kanze GABI Software 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
drkm
writes:
drkm wrote in message news:...
Fabien LE LEZ writes:
le "void" pour indiquer l'absence d'argument, même s'il est accepté par le langage C++, c'est plutôt du C.
Et du vieux, encore. Non ?
Non. La formulation « function() » signifie toujours « nombre et types de paramètres non spécifiés » en C99.
Merci. J'étais presque sûr du contraire. Ca m'étonne même pas mal. Je trouve tout de même bizarre que le C99 ait introduit les tableaux à longueur dynamique, par exemple, et garde cet archaïsme. Mais ce n'est que mon avis, en somme pas très éclairé, et déformé par mon expérience en C++.
PS: Il ne m'a pas semblé nécessaire de cross-poster et de fixer le fu2 vers fclc. Pensez-y éventuellement si vous répondez à ce message.
--drkm
kanze@gabi-soft.fr writes:
drkm <usenet.fclcxx@fgeorges.org> wrote in message
news:<wkfz9xkglz.fsf@fgeorges.org>...
Fabien LE LEZ <gramster@gramster.com> writes:
le "void" pour indiquer l'absence d'argument, même s'il est accepté
par le langage C++, c'est plutôt du C.
Et du vieux, encore. Non ?
Non. La formulation « function() » signifie toujours « nombre et types
de paramètres non spécifiés » en C99.
Merci. J'étais presque sûr du contraire. Ca m'étonne même pas mal.
Je trouve tout de même bizarre que le C99 ait introduit les tableaux à
longueur dynamique, par exemple, et garde cet archaïsme. Mais ce
n'est que mon avis, en somme pas très éclairé, et déformé par mon
expérience en C++.
PS: Il ne m'a pas semblé nécessaire de cross-poster et de fixer le
fu2 vers fclc. Pensez-y éventuellement si vous répondez à ce message.
le "void" pour indiquer l'absence d'argument, même s'il est accepté par le langage C++, c'est plutôt du C.
Et du vieux, encore. Non ?
Non. La formulation « function() » signifie toujours « nombre et types de paramètres non spécifiés » en C99.
Merci. J'étais presque sûr du contraire. Ca m'étonne même pas mal. Je trouve tout de même bizarre que le C99 ait introduit les tableaux à longueur dynamique, par exemple, et garde cet archaïsme. Mais ce n'est que mon avis, en somme pas très éclairé, et déformé par mon expérience en C++.
PS: Il ne m'a pas semblé nécessaire de cross-poster et de fixer le fu2 vers fclc. Pensez-y éventuellement si vous répondez à ce message.
--drkm
James Kanze
drkm writes:
|> writes:
|> > drkm wrote in message |> > news:...
|> >> Fabien LE LEZ writes:
|> >> > le "void" pour indiquer l'absence d'argument, même s'il est |> >> > accepté par le langage C++, c'est plutôt du C.
|> >> Et du vieux, encore. Non ?
|> > Non. La formulation « function() » signifie toujours « |> > nombre et types de paramètres non spécifiés » en C99.
|> Merci. J'étais presque sûr du contraire. Ca m'étonne |> même pas mal. Je trouve tout de même bizarre que le C99 ait |> introduit les tableaux à longueur dynamique, par exemple, et |> garde cet archaïsme. Mais ce n'est que mon avis, en somme pas |> très éclairé, et déformé par mon expérience en |> C++.
Le problème, c'est qu'il existe déjà du code en C ; il en a même existé lorsqu'on a écrit C90. Et un comité de normalisation responsable ne casse pas le code existant, dans la mésure où c'est possible de l'éviter.
-- James Kanze 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
drkm <usenet.fclcxx@fgeorges.org> writes:
|> kanze@gabi-soft.fr writes:
|> > drkm <usenet.fclcxx@fgeorges.org> wrote in message
|> > news:<wkfz9xkglz.fsf@fgeorges.org>...
|> >> Fabien LE LEZ <gramster@gramster.com> writes:
|> >> > le "void" pour indiquer l'absence d'argument, même s'il est
|> >> > accepté par le langage C++, c'est plutôt du C.
|> >> Et du vieux, encore. Non ?
|> > Non. La formulation « function() » signifie toujours «
|> > nombre et types de paramètres non spécifiés » en C99.
|> Merci. J'étais presque sûr du contraire. Ca m'étonne
|> même pas mal. Je trouve tout de même bizarre que le C99 ait
|> introduit les tableaux à longueur dynamique, par exemple, et
|> garde cet archaïsme. Mais ce n'est que mon avis, en somme pas
|> très éclairé, et déformé par mon expérience en
|> C++.
Le problème, c'est qu'il existe déjà du code en C ; il en a
même existé lorsqu'on a écrit C90. Et un comité de
normalisation responsable ne casse pas le code existant, dans la
mésure où c'est possible de l'éviter.
--
James Kanze
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
|> >> > le "void" pour indiquer l'absence d'argument, même s'il est |> >> > accepté par le langage C++, c'est plutôt du C.
|> >> Et du vieux, encore. Non ?
|> > Non. La formulation « function() » signifie toujours « |> > nombre et types de paramètres non spécifiés » en C99.
|> Merci. J'étais presque sûr du contraire. Ca m'étonne |> même pas mal. Je trouve tout de même bizarre que le C99 ait |> introduit les tableaux à longueur dynamique, par exemple, et |> garde cet archaïsme. Mais ce n'est que mon avis, en somme pas |> très éclairé, et déformé par mon expérience en |> C++.
Le problème, c'est qu'il existe déjà du code en C ; il en a même existé lorsqu'on a écrit C90. Et un comité de normalisation responsable ne casse pas le code existant, dans la mésure où c'est possible de l'éviter.
-- James Kanze 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
