Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Développement Développement Langage C++ Warning

Warning

71 réponses
Avatar
Sébastien M.
Bonjour,

Cela vous semble-t-il normal que ce code compile normalement, sans
m=EAme un warning ?
(test=E9 avec gcc 3.4, VS 2003 et VS 2005)


#include<iostream>
using namespace std;

struct A
{
A() : a(0) {}
int a;
};

struct B : public A
{
B() : b(1), c(1), d(1) {}
int b,c,d;
};

int main()
{
A* tab =3D new B[16];

cout << '\n';
for(int i=3D0; i<16; i++)
{
cout << tab[i].a << ' ';
}
cout << endl;
}
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
1 2 3 4 5
Avatar
Sébastien M.
> Il a ecrit new[] pas new.



Il est temps que je parte en vacances, je me met à raconter n'importe
quoi et à lire de travers.

(Je dois en avoir ecrit mais je ne me souviens pas d'occasions ou vector< >
ou une classe similaire n'aurait pas ete en fait une meilleure solution).


C'est vrai qu'à part celui que j'ai du faire il y a quelques jours
contraint et forcé par l'API qu'on utilise, je ne me souviens pas
d'avoir utilisé new[] sauf peut-être dans mes premiers programmes en c+
+.
Avatar
James Kanze
On Aug 8, 11:50 am, Sébastien M. wrote:
> Pour confirmer : je pratique le C++ depuis prèsque 20 ans, à
> tous les niveaux (de l'implémentation des vecteur et des chaînes
> à l'époque avant la norme, jusqu'aux applications complètes), et
> je n'ai jamais eu la moindre occasion d'utiliser un new[].



Sauf si on utilise un "allocator" développé par quelqu'un d'autre je
pense qu'on doit avoir au moins un new dans le programme si on
implémente soit même les classes de base :-D



Évidemment qu'il y a des new, beaucoup même. Mais pas de new[].

Après je suis d'accord qu'on ne doit pas avoir de "new" si on
utilise la STL et pas plus d'un "new" si on implémente tout
depuis le début.



Même sans la STL (qui n'existait pas quand j'ai commencé le
C++), je ne vois pas une utilisation pour new[]. Si tu n'as pas
la STL, la première chose, c'est d'en implémenter quelque chose
de plus ou moins semblable. Moins complet, évidemment, mais
souvent mieux conçu ou plus adapté à tes besoins.

--
James Kanze (GABI Software) email:
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
James Kanze
On Aug 8, 11:16 am, Sébastien M. wrote:
On 8 août, 04:46, Fabien LE LEZ wrote:



> On Thu, 7 Aug 2008 08:38:00 -0700 (PDT), Sébastien M. :



> >Oui mais malheureusement on doit parfois utiliser des APIs
> >mal faites qui nous obligent à faire ce genre de choses (
> >new[] à la place de vector ).



> Uh ? Dans quel cas ?



Dans cette API, on est sensé hérité d'une classe mère pour
ajouté des comportement.



Il y a des donnée 'protected' de la classe mère qui doivent
être initialisées par les classes filles dont un tableau
d'objet. Cette nouvelle classe doit faire le new sinon la
classe mère n'a pas ce quelle veut ... (évidement on n'a pas
accès au code de la classe mère)



Et &v[0] d'un vector convenablement dimensionné ne ferait-il pas
l'affaire ? (Ou est-ce que la classe mère ferait elle-même le
delete[] ?)

(Je n'ai jamais eu à le faire, mais l'implémentation de
strstreambuf doit bien exiger un new[]. Puisque il garantit que
le client peut faire un delete[] sur le pointeur renvoyé par
str(); c'est donc difficile de faire autrement.)

--
James Kanze (GABI Software) email:
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
Sébastien M.
> > Dans cette API, on est sensé hérité d'une classe mère pour
> ajouté des comportement.
> Il y a des donnée 'protected' de la classe mère qui doivent
> être initialisées par les classes filles dont un tableau
> d'objet. Cette nouvelle classe doit faire le new sinon la
> classe mère n'a pas ce quelle veut ... (évidement on n'a pas
> accès au code de la classe mère)

Et &v[0] d'un vector convenablement dimensionné ne ferait-il pas
l'affaire ? (Ou est-ce que la classe mère ferait elle-même le
delete[] ?)



C'est en effet la classe mère qui fait le delete[].
Avatar
pjb
Sébastien M. writes:
Cela vous semble-t-il normal que ce code compile normalement, sans
même un warning ?
(testé avec gcc 3.4, VS 2003 et VS 2005)

A* tab = new B[16];



Ce qui se passe ici, c'est la confluence de deux mécanismes de C++
pour donner un résultat imprévu.

La première, c'est l'équivalence tableau-pointeur:

new B[16] retourne un tableau de 16 Bs. Comme en C/C++, les tableaux
sont équivalent aux pointeurs nous avons en fait un pointeur sur un B,
qui est le premier de 16 B alloués.

B* seize_b=new B[16];


La seconde, c'est la possibilité depointer vers une instance d'une
sous-classe avec un pointeur d'une superclasse:

B* b;
A* a=b;

a et b pointent vers la même instance de B qui est aussi une instance
(indirecte) de A.


Quand on mélange les deux,

A* a=new B[16];

on obtient que a pointe vers la première instance de B dans le tableau
de 16 B. Du fait de l'équivalence pointeur-tableau, on peut s'amuser
à écrire a[i], mais ça n'a aucun sens pour i!=0.



Est ce que ça me semble normal?

Non. Les concepteurs de C++ sont des dingues qu'il faudrait
enfermer et encamisoler. De mon propre chef, je n'utiliserais
jamais C++.


Est ce que ça me semble normal que ce comde compile normalement?

Oui, étant donné les règles de fous donnés dans la définition de C
et C++, rien de plus "normal".


Est ce que ça me semble normal que ce comde compile normalement, sans
même un warning?

Non. Quand on paye pour un compilateur, on voudrait que les
concepteurs du compilateurs nous aident à lutter contre la folie des
auteurs du langage. Un fort warning serait en effet attendu.



Dans tous les cas, ça ne parle pas en faveur du C++, où chaque
combinaison de mécanisme provoque plus de problème. C'est assez
inadmissible, quand on a l'exemple de LISP, inventé il y a 50 ans,
normalisé avec Common Lisp en 1984 (le premier language orienté objet
normalisé, et toujours insupérable), dans lequel les mécanismes
définis ne font que se combiner harmonieusement pour augmenter
l'expressivité et la puissance du langage.


--
__Pascal Bourguignon__ http://www.informatimago.com/

READ THIS BEFORE OPENING PACKAGE: According to certain suggested
versions of the Grand Unified Theory, the primary particles
constituting this product may decay to nothingness within the next
four hundred million years.
Avatar
Fabien LE LEZ
fr.comp.lang.c++
On Fri, 08 Aug 2008 19:57:35 +0200, (Pascal J.
Bourguignon):

Dans tous les cas, ça ne parle pas en faveur du C++, où chaque
combinaison de mécanisme provoque plus de problème. C'est assez
inadmissible, quand on a l'exemple de LISP



Après avoir lu un article de Paul Graham, je suis allé faire un tour
sur comp.lang.lisp. L'impression générale y était quelque chose comme
"Lisp est génial, pourquoi n'est-il pas plus utilisé ? Je connais Lisp
sur le bout des doigts, pourquoi suis-je chômeur ?"

C++ est à l'inverse : il est loin d'être parfait, mais on fait des
choses avec.

Bon, je caricature un peu, car je n'ai eu qu'un petit aperçu très
partiel du "monde Lisp", mais le fait est que C++ est utilisable et
utilisé, et raisonnablement simple pour peu qu'on ne s'approche pas
trop des trucs inutiles et dangereux.


Non. Les concepteurs de C++ sont des dingues qu'il faudrait
enfermer et encamisoler.



C++ est un compromis. Il y a plein de fonctionnalités qui ont été
mises là pour de bonnes raisons, mais qu'on n'utilise quasiment
jamais.
Le résultat est une liberté aussi complète que possible : on peut
programmer raisonnablement, via le ou les paradigmes qu'on veut, mais
on peut aussi faire n'importe quoi. En d'autres termes, le langage C++
lui-même est basé sur le principe "garbage in, garbage out".

"new[]" est une fonctionnalité très peu utilisée (sauf dans des cas
ubuesques comme le cas que Sébastien a présenté dans
<news:).
Le simple fait de sa présence indique qu'on doit apporter une
attention particulière au code -- le compilo ne suffit pas.

Au contraire, le code "de tous les jours" présente peu de pièges, et
généralement on peut se reposer sur le compilo et quelques règles de
base.
Avatar
James Kanze
On Aug 8, 7:57 pm, (Pascal J. Bourguignon)
wrote:
Sébastien M. writes:
> Cela vous semble-t-il normal que ce code compile
> normalement, sans même un warning ?
> (testé avec gcc 3.4, VS 2003 et VS 2005)



> A* tab = new B[16];



Ce qui se passe ici, c'est la confluence de deux mécanismes de
C++ pour donner un résultat imprévu.



Il est prévu par la norme : comportement indéfini:-).

La première, c'est l'équivalence tableau-pointeur:



Il n'y a pas d'équivalence tableau-pointeur. Un pointeur n'est
pas un tableau, et un tableau n'est pas un pointeur. (Il y a
bien une conversion de tableau en pointeur dans certains
contextes, mais ça ne s'applique pas dans le cas en question.)

new B[16] retourne un tableau de 16 Bs.



Plus exactement : « new B[ 16 ] » alloue un tableau de 16 B's.
L'expression renvoie un pointeur au premier B du tableau.

Comme en C/C++, les tableaux sont équivalent aux pointeurs
nous avons en fait un pointeur sur un B, qui est le premier de
16 B alloués.



Parce qu'une expression new[] renvoie un pointeur, on a un
pointeur.

B* seize_b=new B[16];



La seconde, c'est la possibilité depointer vers une instance
d'une sous-classe avec un pointeur d'une superclasse:



B* b;
A* a=b;



a et b pointent vers la même instance de B qui est aussi une
instance (indirecte) de A.



b pointe vers une instance de B. a pointe vers le classe de base
A dans cette instance.

Quand on mélange les deux,



A* a=new B[16];



on obtient que a pointe vers la première instance de B dans le
tableau de 16 B.



Justement non. On obtient un pointeur vers le sous-objet de type
A qui est une base du premier objet dans le tableau. Le
problème, justement, c'est que ce pointeur ne pointe pas à un
élément du tableau ; il pointe à un élément du premier élémen t
du tableau.

Du fait de l'équivalence pointeur-tableau, on peut s'amuser à
écrire a[i], mais ça n'a aucun sens pour i!=0.



Formellement, même pas pour a[0] (mais je ne vois franchement
pas comment ça pourrait poser des problèmes).

Est ce que ça me semble normal?



Dans la mesure qu'on a voulu une certaine compatibilité avec le
C, oui. Sinon...

Dans le comité de normalisation du C++, tout au début, on a bien
discuté la possibilité de « réparer » les tableaux (qui en effet
ne marche pas logiquement). À la fin, le sentiment c'était que
toute correction qui valait la peine casserait trop la
compatibilité C, et qu'avec des classes, des templates, et du
surcharge des opérateurs, on pourrait faire quelque chose de
nouveau qui marchait, et ne garder les anciens tableaux à la C
que pour la compatibilité.

Non. Les concepteurs de C++ sont des dingues qu'il faudrait
enfermer et encamisoler. De mon propre chef, je
n'utiliserais jamais C++.



Le problème n'est pas du C++, mais est hérité du C. Personne, à
ma connaissance, en est content, mais la compatibilité C est une
des raisons que C++ s'est imposé vis-à-vis d'autres langages.
C'est donc important aussi, même si ce n'est pas du tout beau.

Est ce que ça me semble normal que ce code compile
normalement?



Oui, étant donné les règles de fous donnés dans la
définition de C et C++, rien de plus "normal".



Est ce que ça me semble normal que ce comde compile
normalement, sans même un warning?



Non. Quand on paye pour un compilateur, on voudrait que les
concepteurs du compilateurs nous aident à lutter contre la
folie des auteurs du langage. Un fort warning serait en
effet attendu.



Comme quelqu'un a déjà dit dans ce thread, l'intention en C++,
c'est que tu ne te servs pas des tableaux de type C. Du coup,
les auteurs de compilateur n'y investissent pas à améliorer les
avertissements qui les concernent.

Dans tous les cas, ça ne parle pas en faveur du C++,



D'un point de vu formel, non. De l'autre côté, la compatibilité
C a certainement été la raison prédominante pourquoi c'est le
C++ qui s'est imposé, et non le Modula-3 ou l'Eiffel ou que
sais-je. Il y a des motivations pragmatiques, voire pûrement
marketing, dont il faut bien tenir compte.

--
James Kanze (GABI Software) email:
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
Fabien LE LEZ
On Sat, 9 Aug 2008 02:26:16 -0700 (PDT), James Kanze
:

De l'autre côté, la compatibilité
C a certainement été la raison prédominante pourquoi c'est le
C++ qui s'est imposé, et non le Modula-3 ou l'Eiffel ou que
sais-je. Il y a des motivations pragmatiques, voire pûrement
marketing, dont il faut bien tenir compte.



L'élégance d'un langage ne semble pas influer beaucoup sur sa
popularité. Y'a qu'à voir Perl et PHP...
Avatar
pjb
James Kanze writes:

On Aug 8, 7:57 pm, (Pascal J. Bourguignon)
wrote:
Dans tous les cas, ça ne parle pas en faveur du C++,



D'un point de vu formel, non. De l'autre côté, la compatibilité
C a certainement été la raison prédominante pourquoi c'est le
C++ qui s'est imposé, et non le Modula-3 ou l'Eiffel ou que
sais-je. Il y a des motivations pragmatiques, voire pûrement
marketing, dont il faut bien tenir compte.



Oui, mais ce n'est pas ma grand mère qui choisi le langage de
programmation de son téléphone.

Que Bjarne soit un bon psychologue, et que les programmeurs soient bon
public, n'excuse pas le "black social hacking" qu'il a réalisé avec C++.

Il aurait mieux fait de travailler sur la promotion Modula-3 ou
Eiffel. Il a quand même responsabilité de s'être donné comme objectif
l'acceptation de C++ sur des bases psychologiques au lieu de
techniques.


--
__Pascal Bourguignon__ http://www.informatimago.com/
The rule for today:
Touch my tail, I shred your hand.
New rule tomorrow.
Avatar
James Kanze
On Aug 9, 11:56 am, Fabien LE LEZ wrote:
On Sat, 9 Aug 2008 02:26:16 -0700 (PDT), James Kanze
:



>De l'autre côté, la compatibilité
>C a certainement été la raison prédominante pourquoi c'est le
>C++ qui s'est imposé, et non le Modula-3 ou l'Eiffel ou que
>sais-je. Il y a des motivations pragmatiques, voire pûrement
>marketing, dont il faut bien tenir compte.



L'élégance d'un langage ne semble pas influer beaucoup sur sa
popularité. Y'a qu'à voir Perl et PHP...



On dirait souvent que c'est le contraire. Une manque d'élégance
est une condition nécessaire pour qu'un langage devient
populaire.

--
James Kanze (GABI Software) email:
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
1 2 3 4 5