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
2 3 4 5 6
Avatar
pjb
Fabien LE LEZ writes:

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.



Il y a des entreprises qui utilisent lisp comme arme secrête (et donc
il y a quelques emplois pour des programmeurs lisp), mais il devrait y
en avoir plus.


Sortons du cercle vicieux!


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".



La liberté du programmeur C++, c'est celle d'un funambule, qui peut
aussi bien aller à droite qu'à gauche qu'en avant ou en arrière, mais
qui se casse la gueule s'il ne va pas en avant ou en arrière avec le
bon équilibre.

La liberté du programmeur Lisp est supérieure, c'est celle d'un
marcheur sur une surface plane, il peut aller dans toutes les
directions sans tomber.


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.



Tu fais preuve de beaucoup d'optimisme!


--
__Pascal Bourguignon__
Avatar
espie
In article ,
Pascal J. Bourguignon wrote:
Fabien LE LEZ writes:

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.



Il y a des entreprises qui utilisent lisp comme arme secrête (et donc
il y a quelques emplois pour des programmeurs lisp), mais il devrait y
en avoir plus.



Bof, il y a aussi quelques entreprises qui utilisent smalltalk, et plein
qui utilisent d'autres langages. Ca veut dire quoi ? au bout du compte
pas grand chose.

Les langages qui comptent ne sont pas les langages les mieux concus, mais
ceux qui discutent le mieux avec le monde exterieur. On est dans un monde
informatique domine par le procedural, de tres, tres loin. Tous les langages
qui sont *vraiment* representes sont ceux qui ont des facons "habituelles"
de discuter par du procedural.

J'ai pas mal joue avec du scheme ou du smalltalk. Quand je dis `jouer', je
pese mes mots. Le gros probleme etant que, des qu'on veut faire quelque
chose de reel, qui s'interface bien avec le reste, eh bien il faut sortir
du paradigme du langage pour retomber dans du procedural.

Et bizarrement, plutot que de faire des trucs un peu tordus avec scheme
ou smalltalk, en general, je ressors mon perl/c/c++...
Avatar
Fabien LE LEZ
On Mon, 11 Aug 2008 10:07:39 +0200, Pascal J. Bourguignon :

il y a quelques emplois pour des programmeurs lisp), mais il devrait y
en avoir plus.

Sortons du cercle vicieux!



J'invite les programmeurs Lisp à prouver au monde que Lisp est un
langage utile, par exemple en créant un logiciel open-source populaire
en Lisp.


La liberté du programmeur C++, c'est celle d'un funambule, qui peut
aussi bien aller à droite qu'à gauche qu'en avant ou en arrière, mais
qui se casse la gueule s'il ne va pas en avant ou en arrière avec le
bon équilibre.



Quitte à aller dans la métaphore, je choisirais plutôt celle de la
boîte à outils : il y a là-dedans des trucs dangereux, comme une scie
sauteuse, mais qu'on utilise quand même (avec précautions !) car ils
rendent quand même de bons services.
Ce qui manque le plus, à la rigueur, c'est le mode d'emploi. Il y a eu
quelques discussions ici même à ce sujet, et on a trouvé exactement 1
(un) bouquin destiné aux débutants en C++ (Accelerated C++ je crois).


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.



Tu fais preuve de beaucoup d'optimisme!



Non, d'expérience.
Avatar
espie
In article ,
Fabien LE LEZ wrote:
On Mon, 11 Aug 2008 10:07:39 +0200, Pascal J. Bourguignon :

il y a quelques emplois pour des programmeurs lisp), mais il devrait y
en avoir plus.

Sortons du cercle vicieux!



J'invite les programmeurs Lisp à prouver au monde que Lisp est un
langage utile, par exemple en créant un logiciel open-source populaire
en Lisp.



Il y a des logiciels open-source utiles en lisp, typiquement du cote
du calcul formel (maxima, open-axiom, et j'en passe).

Le chiendent, c'est qu'une grosse partie des lisp open-source sont
inadaptes au monde moderne. Par exemple, gnu common lisp reclame de
pouvoir recharger une image memoire a une adresse precise, ce qui ne
marche pas dans un univers ou tu randomises les adresses memoire pour
te proteger contre certaines attaques...
Evidemment, ca marche sous linux. Pas tres surprenant, vu que linux est
un OS ou tu as plein de mecanismes de securite *en theorie* mais qui sont
tous debrayables *en pratique* lorsqu'ils entravent le bon fonctionnement
des logiciels (ce qui fait de la liste de features pour managers, puisqu'en
pratique, personne ne corrige jamais les divers problemes qui forcent a
desactiver ces mecanismes).

J'etais tombe sur ecl (embedded common lisp) qui est nettement mieux
foutu de ce cote-la, mais pas encore completement fini.

En tant que mauvaise langue, il faut aussi que je rappelle que RMS est
un programmeur lisp, a la base, et que tous les projets de la FSF finissent
tot ou tard par avoir un interpreteur lisp dans le ventre. GCC, par exemple,
manipule essentiellement des listes, et la description des divers procs
n'est pas loin d'etre du lisp (ce qui explique en partie sa lenteur et
ses problemes de gestion memoire), gnu-emacs est en lisp, et autoconf
embarque un gros bout d'interpreteur lisp ecrit en m4 (confere m4sugar,
par exemple)... mais bon, ce ne sont pas du tout des exemples a suivre.
Avatar
pjb
Fabien LE LEZ writes:

On Mon, 11 Aug 2008 10:07:39 +0200, Pascal J. Bourguignon :

il y a quelques emplois pour des programmeurs lisp), mais il devrait y
en avoir plus.

Sortons du cercle vicieux!



J'invite les programmeurs Lisp à prouver au monde que Lisp est un
langage utile, par exemple en créant un logiciel open-source populaire
en Lisp.



Comme emacs?

--
__Pascal Bourguignon__
Avatar
pjb
(Marc Espie) writes:

In article ,
Fabien LE LEZ wrote:
On Mon, 11 Aug 2008 10:07:39 +0200, Pascal J. Bourguignon :

il y a quelques emplois pour des programmeurs lisp), mais il devrait y
en avoir plus.

Sortons du cercle vicieux!



J'invite les programmeurs Lisp à prouver au monde que Lisp est un
langage utile, par exemple en créant un logiciel open-source populaire
en Lisp.



Il y a des logiciels open-source utiles en lisp, typiquement du cote
du calcul formel (maxima, open-axiom, et j'en passe).

Le chiendent, c'est qu'une grosse partie des lisp open-source sont
inadaptes au monde moderne.



Ce n'est pas le monde "moderne", si tu y attache une conotation
positive, c'est le monde de Matrix, où on tourne en boucle dans le
piège unix/c. Il y a des solutions pour en sortir, mais ça ne se fera
pas en suivant le troupeau.


Par exemple, gnu common lisp reclame de
pouvoir recharger une image memoire a une adresse precise, ce qui ne
marche pas dans un univers ou tu randomises les adresses memoire pour
te proteger contre certaines attaques...



Protection nécessaire uniquement quand on programme en C ou C++, mais
pas en Lisp. On se demande pourquoi? http://yosefk.com/c++fqa/index.html


Evidemment, ca marche sous linux. Pas tres surprenant, vu que linux est
un OS ou tu as plein de mecanismes de securite *en theorie* mais qui sont
tous debrayables *en pratique* lorsqu'ils entravent le bon fonctionnement
des logiciels (ce qui fait de la liste de features pour managers, puisqu'en
pratique, personne ne corrige jamais les divers problemes qui forcent a
desactiver ces mecanismes).

J'etais tombe sur ecl (embedded common lisp) qui est nettement mieux
foutu de ce cote-la, mais pas encore completement fini.

En tant que mauvaise langue, il faut aussi que je rappelle que RMS est
un programmeur lisp, a la base, et que tous les projets de la FSF finissent
tot ou tard par avoir un interpreteur lisp dans le ventre. GCC, par exemple,
manipule essentiellement des listes, et la description des divers procs
n'est pas loin d'etre du lisp (ce qui explique en partie sa lenteur et
ses problemes de gestion memoire), gnu-emacs est en lisp, et autoconf
embarque un gros bout d'interpreteur lisp ecrit en m4 (confere m4sugar,
par exemple)... mais bon, ce ne sont pas du tout des exemples a suivre.




--
__Pascal Bourguignon__
Avatar
Mickaël Wolff
Pascal J. Bourguignon a écrit :

Ce n'est pas le monde "moderne", si tu y attache une conotation
positive, c'est le monde de Matrix, où on tourne en boucle dans le
piège unix/c. Il y a des solutions pour en sortir, mais ça ne se fera
pas en suivant le troupeau.



Le troupeau à déjà quitté le monde Unix, et la majorité des
développeurs s'installent sous Java et C#, il y a une évolution (quitte
à troller, autant sauter les deux pieds dedans).

--
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org
Avatar
espie
In article ,
Pascal J. Bourguignon wrote:
Ce n'est pas le monde "moderne", si tu y attache une conotation
positive, c'est le monde de Matrix, où on tourne en boucle dans le
piège unix/c. Il y a des solutions pour en sortir, mais ça ne se fera
pas en suivant le troupeau.



Pas d'accord.

Les problemes de securite sont causes par un etat d'esprit. Si tu evites
les problemes `bas niveau' de gestion memoire, tu vas tomber sur d'autres
problemes. Ces derniers sont moins d'actualite (un pirate ne va pas s'embeter
a trouver de nouvelles techniques si les classiques font tres bien l'affaire),
mais ca ne change rien au fond du probleme.

Meme sans ca, ca suppose que tu as toute confiance dans ta machine virtuelle...
ce qui, vu les nombreuses lignes de code necessaire pour avoir une
implementation lisp/java/autre efficace, n'est pas gagne d'avance.

Pour moi, les choses sont claires: les langages plus sophistiques deplacent
juste le probleme. Il y a peu de recherche active en securite sur eux, parce
que ca ne sert a rien tant qu'ils ne sont pas repandus.

Et meme si tu peux prouver plein de choses sur eux, au bout du compte, on
veut toujours resoudre des problemes complexes, et on finit toujours par
sortir du cadre de ce qui est verifiable automatiquement (ou plus exactement:
il n'y a pas de rentabilite economique a produire du logiciel prouve a 100%,
sauf dans quelques tres rares cas de figure)...
Avatar
pjb
Mickaël Wolff writes:

Pascal J. Bourguignon a écrit :

Ce n'est pas le monde "moderne", si tu y attache une conotation
positive, c'est le monde de Matrix, où on tourne en boucle dans le
piège unix/c. Il y a des solutions pour en sortir, mais ça ne se fera
pas en suivant le troupeau.



Le troupeau à déjà quitté le monde Unix, et la majorité des
développeurs s'installent sous Java et C#, il y a une évolution
(quitte à troller, autant sauter les deux pieds dedans).



Ce serait déjà ça. Il faudrait faire un étude plus précise.

Mais en ce qui concerne Microsoft (pour C#), ils ont toujours su
utiliser des machines virtuelles pour déveloper leurs applications,
déjà Microsoft Word en 1984 (SJMSB) utilisait une machine virtuelle.

Quand aux logiciel libres, bon, il y a peut être le poids de
l'existant mais est ce que ça bouge vraiment?

--
__Pascal Bourguignon__
Avatar
pjb
(Marc Espie) writes:

In article ,
Pascal J. Bourguignon wrote:
Ce n'est pas le monde "moderne", si tu y attache une conotation
positive, c'est le monde de Matrix, où on tourne en boucle dans le
piège unix/c. Il y a des solutions pour en sortir, mais ça ne se fera
pas en suivant le troupeau.



Pas d'accord.

Les problemes de securite sont causes par un etat d'esprit. Si tu evites
les problemes `bas niveau' de gestion memoire, tu vas tomber sur d'autres
problemes. Ces derniers sont moins d'actualite (un pirate ne va pas s'embeter
a trouver de nouvelles techniques si les classiques font tres bien l'affaire),
mais ca ne change rien au fond du probleme.

Meme sans ca, ca suppose que tu as toute confiance dans ta machine virtuelle...
ce qui, vu les nombreuses lignes de code necessaire pour avoir une
implementation lisp/java/autre efficace, n'est pas gagne d'avance.

Pour moi, les choses sont claires: les langages plus sophistiques deplacent
juste le probleme. Il y a peu de recherche active en securite sur eux, parce
que ca ne sert a rien tant qu'ils ne sont pas repandus.

Et meme si tu peux prouver plein de choses sur eux, au bout du compte, on
veut toujours resoudre des problemes complexes, et on finit toujours par
sortir du cadre de ce qui est verifiable automatiquement (ou plus exactement:
il n'y a pas de rentabilite economique a produire du logiciel prouve a 100%,
sauf dans quelques tres rares cas de figure)...



Oui, c'est pour ça que c'est intéressant de travailler dans un
environnement géré (managed environment comme dit la FQA), où les
bogues peuvent être plus facilement détectées et traitées durant
l'exécution.

--
__Pascal Bourguignon__
2 3 4 5 6