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
4 5 6 7 8
Avatar
pjb
(Marc Espie) writes:

In article ,
Pascal J. Bourguignon wrote:
Fabien LE LEZ writes:

On Mon, 11 Aug 2008 13:48:09 +0200, (Pascal J.
Bourguignon):

Protection nécessaire uniquement quand on programme en C ou C++, mais
pas en Lisp.



En quel langage GNU Common Lisp est-il écrit ?



La plupart des implémentations de Common Lisp sont écrites en Common Lisp.



C'est expres que tu ne reponds pas a la question ?

Il y a quelques implémentations qui sont partiellement écrites en C
(pour l'interface avec le système unix, simplement pour profiter du C
en tant qu'assembleur portable).



Ben voyons.

C'est du foutage de gueule caracterise.

Tu pourrais avoir au moins l'honnetete intellectuelle de commencer par dire
que gnu common lisp est en grande partie ecrit en C, avant d'enchainer sur
des considerations plus philosophiques.



GNU Common Lisp n'est pas l'implémentation de Common Lisp la plus
importante, loin de là.

clisp, sbcl, cmucl, openmcl en libre sont bien plus utilisées et bien
plus à jour.

De celles là, clisp contient des couches basses implémentées en D, un
C fortement pré-processé spécifique. (Mais par exemple, le compilateur
de clisp est implémenté en lisp).

sbcl et cmucl contiennet comme je disais un peu de code C pour le
ramasse miette et l'interface avec le système, mais sinon sont
quasiment entièrement implémentés en lisp.

openmcl est presque à 100% implémenté en lisp.


Ne prend pas tes interlocuteurs pour des cons, pas mal d'entre nous ont
quand meme deja foutu les doigts (aille) dans un compilateur/interpreteur
d'autre chose que du C/C++...



Maintenant, va voir le source de gcc et va me dire qu'il est
implémenté à 100% en C.


--
__Pascal Bourguignon__
Avatar
Michael DOUBEZ
Pascal J. Bourguignon a écrit :
(Marc Espie) writes:

In article ,
Pascal J. Bourguignon wrote:
Fabien LE LEZ writes:

On Mon, 11 Aug 2008 13:48:09 +0200, (Pascal J.
Bourguignon):

Protection nécessaire uniquement quand on programme en C ou C++, mais
pas en Lisp.


En quel langage GNU Common Lisp est-il écrit ?


La plupart des implémentations de Common Lisp sont écrites en Common Lisp.


C'est expres que tu ne reponds pas a la question ?

Il y a quelques implémentations qui sont partiellement écrites en C
(pour l'interface avec le système unix, simplement pour profiter du C
en tant qu'assembleur portable).


Ben voyons.

C'est du foutage de gueule caracterise.

Tu pourrais avoir au moins l'honnetete intellectuelle de commencer par dire
que gnu common lisp est en grande partie ecrit en C, avant d'enchainer sur
des considerations plus philosophiques.



GNU Common Lisp n'est pas l'implémentation de Common Lisp la plus
importante, loin de là.

clisp, sbcl, cmucl, openmcl en libre sont bien plus utilisées et bien
plus à jour.

De celles là, clisp contient des couches basses implémentées en D, un
C fortement pré-processé spécifique. (Mais par exemple, le compilateur
de clisp est implémenté en lisp).

sbcl et cmucl contiennet comme je disais un peu de code C pour le
ramasse miette et l'interface avec le système, mais sinon sont
quasiment entièrement implémentés en lisp.

openmcl est presque à 100% implémenté en lisp.



Je pense que ce que Marc Espie veut dire c'est que dans la mesure où tu
n'es pas sur un processeur LISP, tu doit forcément bootstrapper sur un
programme qui supporte l'exécution de LISP et ce programme est à priori
écrit en C - ou assimilé.

C'est vrai que comparé à des langages comme ruby, python ou lua, LISP
peut théoriquement fonctionner avec relativement peu de C mais l'intérêt
est limité pour l'industrie du logiciel puisqu'il faut de toutes façon
l'interfacer avec l'OS et les librairies existantes.
Il n'y a qu'à voir l'intérêt pour des langages comme C# où AMA la seule
réelle valeur ajoutée par rapport à un autre langage est l'intégration
de composants hétérogènes.

Ne prend pas tes interlocuteurs pour des cons, pas mal d'entre nous ont
quand meme deja foutu les doigts (aille) dans un compilateur/interpreteur
d'autre chose que du C/C++...



Maintenant, va voir le source de gcc et va me dire qu'il est
implémenté à 100% en C.



D'après wikipedia
Nearly all of GCC is written in C with the exception of the Ada
frontend; much of the Ada frontend is written in Ada.

Info ou intox ? :)

--
Michael
Avatar
koollman+nntp
Michael DOUBEZ writes:

Pascal J. Bourguignon a écrit :
(Marc Espie) writes:

GNU Common Lisp n'est pas l'implémentation de Common Lisp la plus
importante, loin de là.
clisp, sbcl, cmucl, openmcl en libre sont bien plus utilisées et
bien
plus à jour.
De celles là, clisp contient des couches basses implémentà ©es en D,
un
C fortement pré-processé spécifique. (Mais par exemple, l e compilateur
de clisp est implémenté en lisp).
sbcl et cmucl contiennet comme je disais un peu de code C pour le
ramasse miette et l'interface avec le système, mais sinon sont
quasiment entièrement implémentés en lisp.
openmcl est presque à 100% implémenté en lisp.



Je pense que ce que Marc Espie veut dire c'est que dans la mesure où
tu n'es pas sur un processeur LISP, tu doit forcément bootstrapper s ur
un programme qui supporte l'exécution de LISP et ce programme est à
priori écrit en C - ou assimilé.



Tu n'es pas non plus sur un processeur C (meme si le C est plus
proche de l'assembleur de base de ce processeur).

Pour un compilo C ecrit en C, il faut donc aussi bootstrapper (par
exemple avec un autre compilateur C).

Pour certains environnement common lisp (typiquement sbcl) cela
fonctionne de la meme maniere. Un environnement lisp est necessaire
pour executer un environnement lisp/sbcl de bootstrap, qui va ensuite
etre utilisé pour compiler le code de sbcl (code common lisp)
en language natif (code x86, par exemple).

C'est vrai que comparé à des langages comme ruby, python ou lua , LISP
peut théoriquement fonctionner avec relativement peu de C mais
l'intérêt est limité pour l'industrie du logiciel puisqu'i l faut de
toutes façon l'interfacer avec l'OS et les librairies existantes.
Il n'y a qu'à voir l'intérêt pour des langages comme C# o ù AMA la
seule réelle valeur ajoutée par rapport à un autre langage est
l'intégration de composants hétérogènes.



La, par contre, il faut effectivement souvent pouvoir s'interfacer
avec une api prevue pour du C. Mais, en lisp comme en C#, rien
n'empeche de faire des wrappers/binding. Evidemment, pour en
revenir au sujet initial, on devient dependant de la technologie
sous-jacente. Il faut que le wrapper soit soigneusement developpé
pour se comporter comme un module/lib/package 'natif' du language,
ce qui n'est pas toujour possible. Par exemple dans la gestion
de la memoire, une API 'C' peut demander pas mal de transformations
pour devenir une classe (ou autre type du language) avec destructeur
appelé correctement, au bon moment.

Ne prend pas tes interlocuteurs pour des cons, pas mal d'entre nous ont
quand meme deja foutu les doigts (aille) dans un compilateur/interprete ur
d'autre chose que du C/C++...


Maintenant, va voir le source de gcc et va me dire qu'il est
implémenté à 100% en C.



D'après wikipedia
Nearly all of GCC is written in C with the exception of the Ada
frontend; much of the Ada frontend is written in Ada.

Info ou intox ? :)




Info. Et c'est compilateur C écrit en C, tout comme un compilateur
common lisp peut etre ecrit en common lisp. (ou un compilateur
python etre ecrit en python, ou autre).

--
Thomas Samson
A witty saying proves nothing, but saying something pointless gets
people's attention.
Avatar
espie
In article ,
Pascal J. Bourguignon wrote:
Maintenant, va voir le source de gcc et va me dire qu'il est
implémenté à 100% en C.



Non, effectivement, et c'est d'ailleurs la source de la plupart de ces
problemes d'efficacite et de maintainabilite. Son bout de code pseudo-lisp
pue franchement.
Avatar
Gabriel Dos Reis
(Pascal J. Bourguignon) writes:

| (Marc Espie) writes:
|
| > In article ,
| > Pascal J. Bourguignon wrote:
| >>Fabien LE LEZ writes:
| >>
| >>> On Mon, 11 Aug 2008 13:48:09 +0200, (Pascal J.
| >>> Bourguignon):
| >>>
| >>>>Protection nécessaire uniquement quand on programme en C ou C++, mais
| >>>>pas en Lisp.
| >>>
| >>> En quel langage GNU Common Lisp est-il écrit ?
| >>
| >>La plupart des implémentations de Common Lisp sont écrites en Common Lisp.
| >
| > C'est expres que tu ne reponds pas a la question ?
| >
| >>Il y a quelques implémentations qui sont partiellement écrites en C
| >>(pour l'interface avec le système unix, simplement pour profiter du C
| >>en tant qu'assembleur portable).
| >
| > Ben voyons.
| >
| > C'est du foutage de gueule caracterise.
| >
| > Tu pourrais avoir au moins l'honnetete intellectuelle de commencer par dire
| > que gnu common lisp est en grande partie ecrit en C, avant d'enchainer sur
| > des considerations plus philosophiques.
|
| GNU Common Lisp n'est pas l'implémentation de Common Lisp la plus
| importante, loin de là.

Granted.

| clisp, sbcl, cmucl, openmcl en libre sont bien plus utilisées et bien
| plus à jour.

CLisp est a donf basé sur du C.

| De celles là, clisp contient des couches basses implémentées en D, un
| C fortement pré-processé spécifique. (Mais par exemple, le compilateur
| de clisp est implémenté en lisp).
|
| sbcl et cmucl contiennet comme je disais un peu de code C pour le
| ramasse miette et l'interface avec le système, mais sinon sont
| quasiment entièrement implémentés en lisp.
|
| openmcl est presque à 100% implémenté en lisp.

Et openmcl est de mon point de vue pire (an terme de qualité) que GCL,
alors si tu ne comptes pas GCL on devrait ignorer openmcl.

| > Ne prend pas tes interlocuteurs pour des cons, pas mal d'entre nous ont
| > quand meme deja foutu les doigts (aille) dans un compilateur/interpreteur
| > d'autre chose que du C/C++...
|
| Maintenant, va voir le source de gcc et va me dire qu'il est
| implémenté à 100% en C.

Le point étant ?

-- Gaby
Avatar
Gabriel Dos Reis
koollman+ (Thomas (koollman) Samson) writes:

[...]

| Info. Et c'est compilateur C écrit en C, tout comme un compilateur
| common lisp peut etre ecrit en common lisp. (ou un compilateur
| python etre ecrit en python, ou autre).

J'aime bien le « peut ».

La compraison avec GCC est intéressante -- l'un est une réalité
quotidienne largement de facto dans l'industrie, l'autre est une
potentialité qui voudrait devenir réalité, depuis plus d'un demi-siècle.

-- Gaby
Avatar
Gabriel Dos Reis
(Marc Espie) writes:

| In article ,
| Pascal J. Bourguignon wrote:
| >Maintenant, va voir le source de gcc et va me dire qu'il est
| >implémenté à 100% en C.
|
| Non, effectivement, et c'est d'ailleurs la source de la plupart de ces
| problemes d'efficacite et de maintainabilite. Son bout de code pseudo-lisp
| pue franchement.


100% d'accord.

-- Gaby
Avatar
pjb
koollman+ (Thomas (koollman) Samson) writes:

Michael DOUBEZ writes:

Pascal J. Bourguignon a écrit :
(Marc Espie) writes:
Ne prend pas tes interlocuteurs pour des cons, pas mal d'entre nous ont
quand meme deja foutu les doigts (aille) dans un compilateur/interpreteur
d'autre chose que du C/C++...


Maintenant, va voir le source de gcc et va me dire qu'il est
implémenté à 100% en C.



D'après wikipedia
Nearly all of GCC is written in C with the exception of the Ada
frontend; much of the Ada frontend is written in Ada.

Info ou intox ? :)




Info. Et c'est compilateur C écrit en C, tout comme un compilateur
common lisp peut etre ecrit en common lisp. (ou un compilateur
python etre ecrit en python, ou autre).



Mais peut on dire que gcc est implémenté à 100% en C?

Par exemple:


(define_insn "stack_tls_protect_test_di"
[(set (match_operand:CCZ 0 "flags_reg_operand" "")
(unspec:CCZ [(match_operand:DI 1 "memory_operand" "m")
(match_operand:DI 2 "const_int_operand" "i")]
UNSPEC_SP_TLS_TEST))
(clobber (match_scratch:DI 3 "=r"))]
"TARGET_64BIT"
"mov{q}t{%1, %3|%3, %1};xor{q}t{%%fs:%P2, %3|%3, QWORD PTR %%fs:%P2}"
[(set_attr "type" "multi")])


est ce que c'est du C ça?


[ gcc]$ pwd
/data/src/languages/gcc/gcc-4.1.0/gcc
[ gcc]$ find . ( ( -name ada -o -name fortran -o -name java -name treelang -o -name testsuite ) -prune ) -o -type f -name *.[hc] -exec cat {} ; | wc -l
1078286
[ gcc]$ find . ( ( -name ada -o -name fortran -o -name java -name treelang -o -name testsuite ) -prune ) -o -type f -name *.md -exec cat {} ; | wc -l
223798
[ gcc]$

(/ 223798.0 1078286) --> 0.2075497595257659
soit quand même 20% de 'lisp' dans gcc, bien plus que la quantité de C
dans sbcl ou openmcl...


--
__Pascal Bourguignon__ http://www.informatimago.com/
Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we. -- Georges W. Bush
Avatar
Gabriel Dos Reis
(Pascal J. Bourguignon) writes:

| koollman+ (Thomas (koollman) Samson) writes:
|
| > Michael DOUBEZ writes:
| >
| >> Pascal J. Bourguignon a écrit :
| >>> (Marc Espie) writes:
| >>>> Ne prend pas tes interlocuteurs pour des cons, pas mal d'entre nous ont
| >>>> quand meme deja foutu les doigts (aille) dans un compilateur/interpreteur
| >>>> d'autre chose que du C/C++...
| >>> Maintenant, va voir le source de gcc et va me dire qu'il est
| >>> implémenté à 100% en C.
| >>
| >> D'après wikipedia
| >> Nearly all of GCC is written in C with the exception of the Ada
| >> frontend; much of the Ada frontend is written in Ada.
| >>
| >> Info ou intox ? :)
| >>
| >
| > Info. Et c'est compilateur C écrit en C, tout comme un compilateur
| > common lisp peut etre ecrit en common lisp. (ou un compilateur
| > python etre ecrit en python, ou autre).
|
| Mais peut on dire que gcc est implémenté à 100% en C?
|
| Par exemple:
|
|
| (define_insn "stack_tls_protect_test_di"
| [(set (match_operand:CCZ 0 "flags_reg_operand" "")
| (unspec:CCZ [(match_operand:DI 1 "memory_operand" "m")
| (match_operand:DI 2 "const_int_operand" "i")]
| UNSPEC_SP_TLS_TEST))
| (clobber (match_scratch:DI 3 "=r"))]
| "TARGET_64BIT"
| "mov{q}t{%1, %3|%3, %1};xor{q}t{%%fs:%P2, %3|%3, QWORD PTR %%fs:%P2}"
| [(set_attr "type" "multi")])
|
|
| est ce que c'est du C ça?

C'est du RTL -- une structure de données interne que GCC utilise pour
décrire des passes, des machines, et des programmes à un niveau
relativement bas. Il a un RTL writer/reader -- imagine tu fais de la
persistence.

| [ gcc]$ pwd
| /data/src/languages/gcc/gcc-4.1.0/gcc
| [ gcc]$ find . ( ( -name ada -o -name fortran -o -name java -name treelang -o -name testsuite ) -prune ) -o -type f -name *.[hc] -exec cat {} ; | wc -l
| 1078286
| [ gcc]$ find . ( ( -name ada -o -name fortran -o -name java -name treelang -o -name testsuite ) -prune ) -o -type f -name *.md -exec cat {} ; | wc -l
| 223798
| [ gcc]$
|
| (/ 223798.0 1078286) --> 0.2075497595257659
| soit quand même 20% de 'lisp' dans gcc, bien plus que la quantité de C
| dans sbcl ou openmcl...

On peut appeler cette structure de données du Lisp si toute structure
de données avec suffisamment de parenthèses insipides est du Lisp.
Mais je ne suis pas certains que les implémentations Lisp
l'accepteront. Je ne sais pas non plus si le RTL reader/writer
évaluera correctement mes programmes Lisp.

-- Gaby
Avatar
espie
In article <g7p1qs$566$,
Marc Espie wrote:
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.



Finalement, une nouvelle version d'ecl est sorti, une nouvelle version
de maxima egalement.

Les deux s'entendent bien ensemble finalement, et je crois que Gaby planche
sur open-axiom pour que ca compile avec ecl.

De tres bonnes raisons de jeter GNU common-lisp aux orties, finalement:

- c'est du GNU officiel
- c'est chiant a porter sur quasiment n'importe quelle archi
- ca reclame ce putain de mmap a des adresses fixes.

Donc tant qu'a faire, je fais de la pub: si vous etes assez fou pour vouloir
faire du lisp aujourd'hui (ou si vous n'avez pas le choix, que vous devez
utiliser un machin qui n'existe qu'en lisp), poussez a fond sur ecl, au
moins il marche sur autre chose que gnu-linux-i386...
4 5 6 7 8