et le compilateur (g++) me donne l'erreur que j'ai mise en sujet.
Est-ce que le code suivant, qui compile sans erreur, est équivalent à ce
que je veux faire ?
Les vrais mecs ne programment pas en C++. Ils programment en assembleur.
"I write all of my software in 100% pure assembly language -- the raw native language of the Intel microprocessor. I use it because, as the actual language of the system, it requires no inefficient translation from an easier-to-use "high level" language." https://www.grc.com/unpnp/unpnp.htm
Il reste un peu de microcode pour certaines instructions...
Fabien LE LEZ wrote:
Les vrais mecs ne programment pas en C++. Ils programment en
assembleur.
"I write all of my software in 100% pure assembly language -- the raw
native language of the Intel microprocessor. I use it because, as the
actual language of the system, it requires no inefficient translation
from an easier-to-use "high level" language."
https://www.grc.com/unpnp/unpnp.htm
Il reste un peu de microcode pour certaines instructions...
Les vrais mecs ne programment pas en C++. Ils programment en assembleur.
"I write all of my software in 100% pure assembly language -- the raw native language of the Intel microprocessor. I use it because, as the actual language of the system, it requires no inefficient translation from an easier-to-use "high level" language." https://www.grc.com/unpnp/unpnp.htm
Il reste un peu de microcode pour certaines instructions...
Lucas Levrel
Le 24 juillet 2009, James Kanze a écrit :
Les doubles sont bien contigus, mais il n'y a aucune garantie en ce qui concerne leur représentation. J'ai déjà vu la représentation d'un long change d'une version du compilateur à l'autre, et pour les types plus complex, la représentation pourrait changer même selon les options de la compilation.
Merci, c'est bon à savoir ! Et que penser d'un type comme double ? N'a-t-il pas une correspondance directe en assembleur (ce qui le rendrait plus « fiable ») ?
-- LL
Le 24 juillet 2009, James Kanze a écrit :
Les doubles sont bien contigus, mais il n'y a aucune garantie en
ce qui concerne leur représentation. J'ai déjà vu la
représentation d'un long change d'une version du compilateur à
l'autre, et pour les types plus complex, la représentation
pourrait changer même selon les options de la compilation.
Merci, c'est bon à savoir ! Et que penser d'un type comme double ?
N'a-t-il pas une correspondance directe en assembleur (ce qui le rendrait
plus « fiable ») ?
Les doubles sont bien contigus, mais il n'y a aucune garantie en ce qui concerne leur représentation. J'ai déjà vu la représentation d'un long change d'une version du compilateur à l'autre, et pour les types plus complex, la représentation pourrait changer même selon les options de la compilation.
Merci, c'est bon à savoir ! Et que penser d'un type comme double ? N'a-t-il pas une correspondance directe en assembleur (ce qui le rendrait plus « fiable ») ?
-- LL
pjb
James Kanze writes:
On Jul 23, 3:28 pm, Gabriel Dos Reis wrote:
James Kanze writes:
> On Jul 22, 5:19 pm, (Pascal J. > Bourguignon)> wrote:
> > Fabien LE LEZ writes:
> > En fait, rien n'empêche de définir une classe (template) > > specifique pour des tableaux multidimentionnel. C'est > > juste une question d'imagination, mais il semble bien que > > les programmeurs C++ n'en soit pas capables, et se > > ramênent toujours à des vecteurs de vecteurs qu'ils ont > > appris à faire en C...
> C'est plutôt une question de ne pas réinventer la roue. > C'est un peu stupide de réécrire un tas de code, quand j'ai > une implémentation tout faite qui marche.
ah mais, tu montres que tu es homme quand tu le fais tout seul avec tes petites mains :-p
Et puis, réécrire une classe de vecteur pour l'n-ième fois, c'est bien plus simple de s'attaquer aux problèmes réels qu'a le client. Et peut-être plus rentable, aussi, parce que par la suite, il n'y a que moi qui comprendrai le code -- il faut donc que le client s'adresse à moi pour tout modification, que je pourrais facturer assez cher.
Si cette objection était réelle, celà signifierait que les programmeurs C++ sont incapable de comprendre la moindre abtraction. Bon, je ne suis pas loin de le croire, mais c'est toi qui le dis tout haut.
-- __Pascal Bourguignon__
James Kanze <james.kanze@gmail.com> writes:
On Jul 23, 3:28 pm, Gabriel Dos Reis <g...@cs.tamu.edu> wrote:
James Kanze <james.ka...@gmail.com> writes:
> On Jul 22, 5:19 pm, p...@informatimago.com (Pascal J.
> Bourguignon)> wrote:
> > Fabien LE LEZ <grams...@gramster.com> writes:
> > En fait, rien n'empêche de définir une classe (template)
> > specifique pour des tableaux multidimentionnel. C'est
> > juste une question d'imagination, mais il semble bien que
> > les programmeurs C++ n'en soit pas capables, et se
> > ramênent toujours à des vecteurs de vecteurs qu'ils ont
> > appris à faire en C...
> C'est plutôt une question de ne pas réinventer la roue.
> C'est un peu stupide de réécrire un tas de code, quand j'ai
> une implémentation tout faite qui marche.
ah mais, tu montres que tu es homme quand tu le fais tout seul
avec tes petites mains :-p
Et puis, réécrire une classe de vecteur pour l'n-ième fois,
c'est bien plus simple de s'attaquer aux problèmes réels qu'a le
client. Et peut-être plus rentable, aussi, parce que par la
suite, il n'y a que moi qui comprendrai le code -- il faut donc
que le client s'adresse à moi pour tout modification, que je
pourrais facturer assez cher.
Si cette objection était réelle, celà signifierait que les
programmeurs C++ sont incapable de comprendre la moindre abtraction.
Bon, je ne suis pas loin de le croire, mais c'est toi qui le dis tout
haut.
> On Jul 22, 5:19 pm, (Pascal J. > Bourguignon)> wrote:
> > Fabien LE LEZ writes:
> > En fait, rien n'empêche de définir une classe (template) > > specifique pour des tableaux multidimentionnel. C'est > > juste une question d'imagination, mais il semble bien que > > les programmeurs C++ n'en soit pas capables, et se > > ramênent toujours à des vecteurs de vecteurs qu'ils ont > > appris à faire en C...
> C'est plutôt une question de ne pas réinventer la roue. > C'est un peu stupide de réécrire un tas de code, quand j'ai > une implémentation tout faite qui marche.
ah mais, tu montres que tu es homme quand tu le fais tout seul avec tes petites mains :-p
Et puis, réécrire une classe de vecteur pour l'n-ième fois, c'est bien plus simple de s'attaquer aux problèmes réels qu'a le client. Et peut-être plus rentable, aussi, parce que par la suite, il n'y a que moi qui comprendrai le code -- il faut donc que le client s'adresse à moi pour tout modification, que je pourrais facturer assez cher.
Si cette objection était réelle, celà signifierait que les programmeurs C++ sont incapable de comprendre la moindre abtraction. Bon, je ne suis pas loin de le croire, mais c'est toi qui le dis tout haut.
Merci, c'est bon à savoir ! Et que penser d'un type comme double ? N'a-t-il pas une correspondance directe en assembleur (ce qui le rendrait plus « fiable ») ?
Non, pas forcement. Ca depend des plateformes. Meme sur intel, ou on differencie le type stocke en memoire (64 bits) des valeurs dans les registres (80 bits), ce qui donne des choses tres droles selon l'optimisation (difference de precision selon que tout tient dans les registres ou pas).
Et c'est sans parler de certaines archis ou un gros bout, voire la totalite du support virgule flottante est emule et tres lent (arm/intel xscale, par exemple).
In article <Pine.LNX.4.64.0907271052350.4512@coulomb.univ-paris12.fr>,
Lucas Levrel <lucas.levrel@univ-paris12.fr> wrote:
Merci, c'est bon à savoir ! Et que penser d'un type comme double ?
N'a-t-il pas une correspondance directe en assembleur (ce qui le rendrait
plus « fiable ») ?
Non, pas forcement. Ca depend des plateformes. Meme sur intel, ou on
differencie le type stocke en memoire (64 bits) des valeurs dans les registres
(80 bits), ce qui donne des choses tres droles selon l'optimisation
(difference de precision selon que tout tient dans les registres ou pas).
Et c'est sans parler de certaines archis ou un gros bout, voire la totalite
du support virgule flottante est emule et tres lent (arm/intel xscale, par
exemple).
Merci, c'est bon à savoir ! Et que penser d'un type comme double ? N'a-t-il pas une correspondance directe en assembleur (ce qui le rendrait plus « fiable ») ?
Non, pas forcement. Ca depend des plateformes. Meme sur intel, ou on differencie le type stocke en memoire (64 bits) des valeurs dans les registres (80 bits), ce qui donne des choses tres droles selon l'optimisation (difference de precision selon que tout tient dans les registres ou pas).
Et c'est sans parler de certaines archis ou un gros bout, voire la totalite du support virgule flottante est emule et tres lent (arm/intel xscale, par exemple).
James Kanze
On Jul 27, 11:42 am, (Pascal J. Bourguignon) wrote:
James Kanze writes: > On Jul 23, 3:28 pm, Gabriel Dos Reis wrote: >> James Kanze writes:
>> > On Jul 22, 5:19 pm, (Pascal J. >> > Bourguignon)> wrote:
>> > > Fabien LE LEZ writes:
>> > > En fait, rien n'empêche de définir une classe (template) >> > > specifique pour des tableaux multidimentionnel. C'est >> > > juste une question d'imagination, mais il semble bien que >> > > les programmeurs C++ n'en soit pas capables, et se >> > > ramênent toujours à des vecteurs de vecteurs qu'ils ont >> > > appris à faire en C...
>> > C'est plutôt une question de ne pas réinventer la roue. >> > C'est un peu stupide de réécrire un tas de code, quand j'ai >> > une implémentation tout faite qui marche.
>> ah mais, tu montres que tu es homme quand tu le fais tout seul >> avec tes petites mains :-p
> Et puis, réécrire une classe de vecteur pour l'n-ième fois, > c'est bien plus simple de s'attaquer aux problèmes réels qu'a le > client. Et peut-être plus rentable, aussi, parce que par la > suite, il n'y a que moi qui comprendrai le code -- il faut donc > que le client s'adresse à moi pour tout modification, que je > pourrais facturer assez cher.
Si cette objection était réelle, celà signifierait que les programmeurs C++ sont incapable de comprendre la moindre abtraction. Bon, je ne suis pas loin de le croire, mais c'est toi qui le dis tout haut.
N'importe quoi. Apparamment, c'est toi qui ne comprends pas ce que signifie abstraction, puisque tu te sens obligé à réécrire tout, même s'il existe déjà.
-- 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
On Jul 27, 11:42 am, p...@informatimago.com (Pascal J. Bourguignon)
wrote:
James Kanze <james.ka...@gmail.com> writes:
> On Jul 23, 3:28 pm, Gabriel Dos Reis <g...@cs.tamu.edu> wrote:
>> James Kanze <james.ka...@gmail.com> writes:
>> > On Jul 22, 5:19 pm, p...@informatimago.com (Pascal J.
>> > Bourguignon)> wrote:
>> > > Fabien LE LEZ <grams...@gramster.com> writes:
>> > > En fait, rien n'empêche de définir une classe (template)
>> > > specifique pour des tableaux multidimentionnel. C'est
>> > > juste une question d'imagination, mais il semble bien que
>> > > les programmeurs C++ n'en soit pas capables, et se
>> > > ramênent toujours à des vecteurs de vecteurs qu'ils ont
>> > > appris à faire en C...
>> > C'est plutôt une question de ne pas réinventer la roue.
>> > C'est un peu stupide de réécrire un tas de code, quand j'ai
>> > une implémentation tout faite qui marche.
>> ah mais, tu montres que tu es homme quand tu le fais tout seul
>> avec tes petites mains :-p
> Et puis, réécrire une classe de vecteur pour l'n-ième fois,
> c'est bien plus simple de s'attaquer aux problèmes réels qu'a le
> client. Et peut-être plus rentable, aussi, parce que par la
> suite, il n'y a que moi qui comprendrai le code -- il faut donc
> que le client s'adresse à moi pour tout modification, que je
> pourrais facturer assez cher.
Si cette objection était réelle, celà signifierait que les
programmeurs C++ sont incapable de comprendre la moindre
abtraction. Bon, je ne suis pas loin de le croire, mais c'est
toi qui le dis tout haut.
N'importe quoi. Apparamment, c'est toi qui ne comprends pas ce
que signifie abstraction, puisque tu te sens obligé à réécrire
tout, même s'il existe déjà.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
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
On Jul 27, 11:42 am, (Pascal J. Bourguignon) wrote:
James Kanze writes: > On Jul 23, 3:28 pm, Gabriel Dos Reis wrote: >> James Kanze writes:
>> > On Jul 22, 5:19 pm, (Pascal J. >> > Bourguignon)> wrote:
>> > > Fabien LE LEZ writes:
>> > > En fait, rien n'empêche de définir une classe (template) >> > > specifique pour des tableaux multidimentionnel. C'est >> > > juste une question d'imagination, mais il semble bien que >> > > les programmeurs C++ n'en soit pas capables, et se >> > > ramênent toujours à des vecteurs de vecteurs qu'ils ont >> > > appris à faire en C...
>> > C'est plutôt une question de ne pas réinventer la roue. >> > C'est un peu stupide de réécrire un tas de code, quand j'ai >> > une implémentation tout faite qui marche.
>> ah mais, tu montres que tu es homme quand tu le fais tout seul >> avec tes petites mains :-p
> Et puis, réécrire une classe de vecteur pour l'n-ième fois, > c'est bien plus simple de s'attaquer aux problèmes réels qu'a le > client. Et peut-être plus rentable, aussi, parce que par la > suite, il n'y a que moi qui comprendrai le code -- il faut donc > que le client s'adresse à moi pour tout modification, que je > pourrais facturer assez cher.
Si cette objection était réelle, celà signifierait que les programmeurs C++ sont incapable de comprendre la moindre abtraction. Bon, je ne suis pas loin de le croire, mais c'est toi qui le dis tout haut.
N'importe quoi. Apparamment, c'est toi qui ne comprends pas ce que signifie abstraction, puisque tu te sens obligé à réécrire tout, même s'il existe déjà.
-- 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
espie
In article , Pascal J. Bourguignon wrote:
Si cette objection était réelle, celà signifierait que les programmeurs C++ sont incapable de comprendre la moindre abtraction. Bon, je ne suis pas loin de le croire, mais c'est toi qui le dis tout haut.
J'avoue que je comprend de moins en moins pourquoi tu traines encore sur ce groupe.
A part insulter regulierement la majorite des contributeurs a ce groupe (ce que tu viens de faire, si par hasard tu ne t'en es pas rendu compte), et faire du proselytisme mal place pour lisp, je ne sais pas ce que tu en tires.
Si on est globalement tous aussi mauvais en terme de qualite d'abstraction, et aussi mauvais au niveau ingenierie, au point de ne pas choisir le langage qui convient, qu'est-ce que tu viens foutre ici ? nous ecraser de ta superiorite naturelle ?
A part troller, je ne vois pas...
La, j'avoue que j'en ai franchement ma claque. Je ne passe pas ma vie sur fr.comp.lang.python a dire que perl c'est mieux, ou sur fr.comp.lang.linux a dire que bsd c'est mieux...
Bref, casse-toi, ca nous fera des vacances.
Autant te lire sur fr.comp.lang.general me semble approprie, autant j'en ai marre de te voir systematiquement denigrer les acquis du C++ et les developpeurs C++ dans ce newsgroup.
In article <7cab2qv4vb.fsf@pbourguignon.anevia.com>,
Pascal J. Bourguignon <pjb@informatimago.com> wrote:
Si cette objection était réelle, celà signifierait que les
programmeurs C++ sont incapable de comprendre la moindre abtraction.
Bon, je ne suis pas loin de le croire, mais c'est toi qui le dis tout
haut.
J'avoue que je comprend de moins en moins pourquoi tu traines encore
sur ce groupe.
A part insulter regulierement la majorite des contributeurs a ce groupe
(ce que tu viens de faire, si par hasard tu ne t'en es pas rendu compte),
et faire du proselytisme mal place pour lisp, je ne sais pas ce que tu
en tires.
Si on est globalement tous aussi mauvais en terme de qualite d'abstraction,
et aussi mauvais au niveau ingenierie, au point de ne pas choisir le langage
qui convient, qu'est-ce que tu viens foutre ici ? nous ecraser de ta
superiorite naturelle ?
A part troller, je ne vois pas...
La, j'avoue que j'en ai franchement ma claque. Je ne passe pas ma vie sur
fr.comp.lang.python a dire que perl c'est mieux, ou sur fr.comp.lang.linux
a dire que bsd c'est mieux...
Bref, casse-toi, ca nous fera des vacances.
Autant te lire sur fr.comp.lang.general me semble approprie, autant j'en ai
marre de te voir systematiquement denigrer les acquis du C++ et les
developpeurs C++ dans ce newsgroup.
Si cette objection était réelle, celà signifierait que les programmeurs C++ sont incapable de comprendre la moindre abtraction. Bon, je ne suis pas loin de le croire, mais c'est toi qui le dis tout haut.
J'avoue que je comprend de moins en moins pourquoi tu traines encore sur ce groupe.
A part insulter regulierement la majorite des contributeurs a ce groupe (ce que tu viens de faire, si par hasard tu ne t'en es pas rendu compte), et faire du proselytisme mal place pour lisp, je ne sais pas ce que tu en tires.
Si on est globalement tous aussi mauvais en terme de qualite d'abstraction, et aussi mauvais au niveau ingenierie, au point de ne pas choisir le langage qui convient, qu'est-ce que tu viens foutre ici ? nous ecraser de ta superiorite naturelle ?
A part troller, je ne vois pas...
La, j'avoue que j'en ai franchement ma claque. Je ne passe pas ma vie sur fr.comp.lang.python a dire que perl c'est mieux, ou sur fr.comp.lang.linux a dire que bsd c'est mieux...
Bref, casse-toi, ca nous fera des vacances.
Autant te lire sur fr.comp.lang.general me semble approprie, autant j'en ai marre de te voir systematiquement denigrer les acquis du C++ et les developpeurs C++ dans ce newsgroup.
