Je viens de tomber sur un message de Michel, d'il y a un mois, dont
voici un extrait :
> From: "Michel Michaud" <mm@gdzid.com>
> Subject: Re: buffer et std::vector<char> passage de l'un a l'autre
> Message-ID: <pQnHa.816$5d.225371@news20.bellglobal.com>
> Date: Mon, 16 Jun 2003 14:16:52 -0400
> Avec
> vector<char> v(taille);
> &v[0] est un char* qui peut être passé aux fonctions attendant un
> char[]/char*. La norme ne dit pas explicitement que les char sont
> contigus, mais c'est un fait et il y a une correction à la norme qui
> l'indique aussi.
J'avais toujours entendu dire que la contigüités des éléments d'un
vecteur était garantie. Apparemment non. Pour ce qui est de la
correction à la norme, je suppose que tu parlais d'un DR. En as-tu la
référence, stp ?
| Maintenant, dis-moi : cette impossibilité est-elle une intuition | de ta part, ou bien une induction basée sur un grand nombre | de tentatives (!), ou bien encore un théorème ?
Sur une constatation très simple : la sémantique, c'est la partie qui s'occupe de donner un sens aux mots, i.e à la syntaxe. Chaque fois que j'ai une notation, il faut que je lui donne un sens.
| Et dans ce | dernier cas, dans quel cadre conceptuel, mathématique | ou autre, ses hypothèses et sa démonstration peuvent-elles | être exprimées rigoureusement ?
Ben j'avoue que je ne comprends pas très bien où tu veux en venir.
Bon, je suppose que je n'utilise pas les mots corrects. De l'exemple de l'intervalle [1...8] du Pascal, remplacé en C++ par ta réponse avec template<typename T, int m, int M> je tire l'impression que ce qui est "cablé" dans un langage, et ce qui doit être écrit soi-même, est une limite qui peut bouger, selon le langage considéré. Ce qui est câblé, je l'appelais "syntaxe", à tort je pense, ce doit être là mon erreur... Il n'empêche, je suis frappé que la déclaration d'un sous-type d'entier puisse être exprimée à l'aide d'une simple déclaration en Pascal, alors même qu'elle contient un peu de sémantique (restriction entre deux bornes). En regard de cela, je constatais que la contiguïté, elle, semble plus résistante à une expression aussi immédiate. Ma question était donc : y aurait-il des propriétés dont on pourrait démontrer qu'elles ne sont "câblables" dans aucun langage, et la contiguïté serait-elle l'une d'entre elles ? Mais si tout cela est trop confus pour un autre cerveau que le mien, laissons tomber ;-)
--
Français *==> "Musique renaissance" <==* English midi - facsimiles - ligatures - mensuration http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/ Alain Naigeon - - Strasbourg, France
"Gabriel Dos Reis" <gdr@integrable-solutions.net> a écrit dans le message
news: m3znjcswq7.fsf@uniton.integrable-solutions.net...
"Alain Naigeon" <anaigeon@free.fr> writes:
| Maintenant, dis-moi : cette impossibilité est-elle une intuition
| de ta part, ou bien une induction basée sur un grand nombre
| de tentatives (!), ou bien encore un théorème ?
Sur une constatation très simple : la sémantique, c'est la partie qui
s'occupe de donner un sens aux mots, i.e à la syntaxe.
Chaque fois que j'ai une notation, il faut que je lui donne un sens.
| Et dans ce
| dernier cas, dans quel cadre conceptuel, mathématique
| ou autre, ses hypothèses et sa démonstration peuvent-elles
| être exprimées rigoureusement ?
Ben j'avoue que je ne comprends pas très bien où tu veux en venir.
Bon, je suppose que je n'utilise pas les mots corrects.
De l'exemple de l'intervalle [1...8] du Pascal, remplacé
en C++ par ta réponse avec template<typename T, int m, int M>
je tire l'impression que ce qui est "cablé" dans un langage, et
ce qui doit être écrit soi-même, est une limite qui peut bouger,
selon le langage considéré.
Ce qui est câblé, je l'appelais "syntaxe", à tort je pense, ce doit
être là mon erreur...
Il n'empêche, je suis frappé que la déclaration d'un sous-type
d'entier puisse être exprimée à l'aide d'une simple déclaration
en Pascal, alors même qu'elle contient un peu de sémantique
(restriction entre deux bornes).
En regard de cela, je constatais que la contiguïté, elle, semble
plus résistante à une expression aussi immédiate.
Ma question était donc : y aurait-il des propriétés dont on pourrait
démontrer qu'elles ne sont "câblables" dans aucun langage, et
la contiguïté serait-elle l'une d'entre elles ?
Mais si tout cela est trop confus pour un autre cerveau que le
mien, laissons tomber ;-)
--
Français *==> "Musique renaissance" <==* English
midi - facsimiles - ligatures - mensuration
http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/
Alain Naigeon - anaigeon@free.fr - Strasbourg, France
| Maintenant, dis-moi : cette impossibilité est-elle une intuition | de ta part, ou bien une induction basée sur un grand nombre | de tentatives (!), ou bien encore un théorème ?
Sur une constatation très simple : la sémantique, c'est la partie qui s'occupe de donner un sens aux mots, i.e à la syntaxe. Chaque fois que j'ai une notation, il faut que je lui donne un sens.
| Et dans ce | dernier cas, dans quel cadre conceptuel, mathématique | ou autre, ses hypothèses et sa démonstration peuvent-elles | être exprimées rigoureusement ?
Ben j'avoue que je ne comprends pas très bien où tu veux en venir.
Bon, je suppose que je n'utilise pas les mots corrects. De l'exemple de l'intervalle [1...8] du Pascal, remplacé en C++ par ta réponse avec template<typename T, int m, int M> je tire l'impression que ce qui est "cablé" dans un langage, et ce qui doit être écrit soi-même, est une limite qui peut bouger, selon le langage considéré. Ce qui est câblé, je l'appelais "syntaxe", à tort je pense, ce doit être là mon erreur... Il n'empêche, je suis frappé que la déclaration d'un sous-type d'entier puisse être exprimée à l'aide d'une simple déclaration en Pascal, alors même qu'elle contient un peu de sémantique (restriction entre deux bornes). En regard de cela, je constatais que la contiguïté, elle, semble plus résistante à une expression aussi immédiate. Ma question était donc : y aurait-il des propriétés dont on pourrait démontrer qu'elles ne sont "câblables" dans aucun langage, et la contiguïté serait-elle l'une d'entre elles ? Mais si tout cela est trop confus pour un autre cerveau que le mien, laissons tomber ;-)
--
Français *==> "Musique renaissance" <==* English midi - facsimiles - ligatures - mensuration http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/ Alain Naigeon - - Strasbourg, France
Alain Naigeon
"Christophe Lephay" a écrit dans le message news: bf776q$qgs$
Joli :)
Il ne reste plus qu'à intégrer un truc de ce genre dans la STL.
--
Français *==> "Musique renaissance" <==* English midi - facsimiles - ligatures - mensuration http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/ Alain Naigeon - - Strasbourg, France
"Christophe Lephay" <christophe-lephay@wanadoo.fr> a écrit dans le message
news: bf776q$qgs$1@news-reader2.wanadoo.fr...
Joli :)
Il ne reste plus qu'à intégrer un truc de ce genre dans la STL.
--
Français *==> "Musique renaissance" <==* English
midi - facsimiles - ligatures - mensuration
http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/
Alain Naigeon - anaigeon@free.fr - Strasbourg, France
"Christophe Lephay" a écrit dans le message news: bf776q$qgs$
Joli :)
Il ne reste plus qu'à intégrer un truc de ce genre dans la STL.
--
Français *==> "Musique renaissance" <==* English midi - facsimiles - ligatures - mensuration http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/ Alain Naigeon - - Strasbourg, France
Michel Michaud
Dans news:, Gabriel Dos
"Alain Naigeon" writes:
Je lis dans Stroustrup, 2ème édition française, page 10, une mise en garde contre les données membres publiques (mais dans certaines circonstances, j'ajoute, pour être honnête).
ce qui est important, c'est « dans certaines conditions ». Je mentionne encore l'exemple de std::pair<>.
Mais là, il faut avouer que certaines personnes disent justement que c'est une erreur d'avoir les données publiques. (ce qui ne prouve pas que les données publiques soient toujours des erreurs)
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Dans news:m3n0fchm9m.fsf@uniton.integrable-solutions.net, Gabriel Dos
"Alain Naigeon" <anaigeon@free.fr> writes:
Je lis dans Stroustrup, 2ème édition française, page 10, une mise
en garde contre les données membres publiques (mais dans certaines
circonstances, j'ajoute, pour être honnête).
ce qui est important, c'est « dans certaines conditions ».
Je mentionne encore l'exemple de std::pair<>.
Mais là, il faut avouer que certaines personnes disent justement que
c'est une erreur d'avoir les données publiques. (ce qui ne prouve pas
que les données publiques soient toujours des erreurs)
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Je lis dans Stroustrup, 2ème édition française, page 10, une mise en garde contre les données membres publiques (mais dans certaines circonstances, j'ajoute, pour être honnête).
ce qui est important, c'est « dans certaines conditions ». Je mentionne encore l'exemple de std::pair<>.
Mais là, il faut avouer que certaines personnes disent justement que c'est une erreur d'avoir les données publiques. (ce qui ne prouve pas que les données publiques soient toujours des erreurs)
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Christophe Lephay
"Michel Michaud" a écrit dans le message de news:1jHRa.7783$
Dans news:, Gabriel Dos
"Alain Naigeon" writes:
Je lis dans Stroustrup, 2ème édition française, page 10, une mise en garde contre les données membres publiques (mais dans certaines circonstances, j'ajoute, pour être honnête).
ce qui est important, c'est « dans certaines conditions ». Je mentionne encore l'exemple de std::pair<>.
Mais là, il faut avouer que certaines personnes disent justement que c'est une erreur d'avoir les données publiques. (ce qui ne prouve pas que les données publiques soient toujours des erreurs)
C'est vrai que ce serait bien plus robuste si on avait des fonctions membres du style get_the_first(), get_the_second(), set_the_first() et set_the_second() ;)
Plus sérieusement, quel argument as-tu(*) contre le fait que les données de pair soient publiques ?
Chris
(*) je dis "as-tu", mais c'est une figure de style En toute rigueur ce devrait être "ont-ils"...
"Michel Michaud" <mm@gdzid.com> a écrit dans le message de
news:1jHRa.7783$104.767215@news20.bellglobal.com...
Dans news:m3n0fchm9m.fsf@uniton.integrable-solutions.net, Gabriel Dos
"Alain Naigeon" <anaigeon@free.fr> writes:
Je lis dans Stroustrup, 2ème édition française, page 10, une mise
en garde contre les données membres publiques (mais dans certaines
circonstances, j'ajoute, pour être honnête).
ce qui est important, c'est « dans certaines conditions ».
Je mentionne encore l'exemple de std::pair<>.
Mais là, il faut avouer que certaines personnes disent justement que
c'est une erreur d'avoir les données publiques. (ce qui ne prouve pas
que les données publiques soient toujours des erreurs)
C'est vrai que ce serait bien plus robuste si on avait des fonctions membres
du style get_the_first(), get_the_second(), set_the_first() et
set_the_second() ;)
Plus sérieusement, quel argument as-tu(*) contre le fait que les données de
pair soient publiques ?
Chris
(*) je dis "as-tu", mais c'est une figure de style En toute rigueur ce
devrait être "ont-ils"...
"Michel Michaud" a écrit dans le message de news:1jHRa.7783$
Dans news:, Gabriel Dos
"Alain Naigeon" writes:
Je lis dans Stroustrup, 2ème édition française, page 10, une mise en garde contre les données membres publiques (mais dans certaines circonstances, j'ajoute, pour être honnête).
ce qui est important, c'est « dans certaines conditions ». Je mentionne encore l'exemple de std::pair<>.
Mais là, il faut avouer que certaines personnes disent justement que c'est une erreur d'avoir les données publiques. (ce qui ne prouve pas que les données publiques soient toujours des erreurs)
C'est vrai que ce serait bien plus robuste si on avait des fonctions membres du style get_the_first(), get_the_second(), set_the_first() et set_the_second() ;)
Plus sérieusement, quel argument as-tu(*) contre le fait que les données de pair soient publiques ?
Chris
(*) je dis "as-tu", mais c'est une figure de style En toute rigueur ce devrait être "ont-ils"...
Michel Michaud
Dans news:bf7gr1$58a$, Christophe
"Michel Michaud" a écrit dans le message de news:1jHRa.7783$
Dans news:, Gabriel
"Alain Naigeon" writes:
Je lis dans Stroustrup, 2ème édition française, page 10, une mise en garde contre les données membres publiques (mais dans certaines circonstances, j'ajoute, pour être honnête).
ce qui est important, c'est « dans certaines conditions ». Je mentionne encore l'exemple de std::pair<>.
Mais là, il faut avouer que certaines personnes disent justement que c'est une erreur d'avoir les données publiques. (ce qui ne prouve pas que les données publiques soient toujours des erreurs)
C'est vrai que ce serait bien plus robuste si on avait des fonctions membres du style get_the_first(), get_the_second(), set_the_first() et set_the_second() ;)
Non, mais x.first() vs x.first ? x.first(v) vs x.first=v;
Plus sérieusement, quel argument as-tu(*) contre le fait que les données de pair soient publiques ?
Chris
(*) je dis "as-tu", mais c'est une figure de style En toute rigueur ce devrait être "ont-ils"...
Je ne me rappelle plus exactement. Je n'ai pas d'opinion ferme là-dessus, alors je n'ai pas tellement le goût de chercher plus loin que « pair private » dans Google pour clc++m. J'ai trouvé ces deux bases si tu veux lire plus.
http://minilien.com/?NTwSo50hFJ
http://minilien.com/?flj2Rwz4iN
Je ne suis même pas certain que c'est à quoi je pensais...
Peut-être que Gabriel ou James se rappelle plus que moi s'il y a eu une discussion plus exacte sur des problèmes dûs à l'interface trop publique de std::pair...
(Personnellement je n'ai pas de problème avec le std::pair actuel, mon message tenait seulement à dire qu'il ne faut pas toujours se fier sur la bibliothèque pour des exemples de design qui semblent bons à tous. Si pair n'est pas un bon exemple de ça, il n'y a qu'à voir les critiques de James pour en trouver d'autres :-)
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Dans news:bf7gr1$58a$1@news-reader3.wanadoo.fr, Christophe
"Michel Michaud" <mm@gdzid.com> a écrit dans le message de
news:1jHRa.7783$104.767215@news20.bellglobal.com...
Dans news:m3n0fchm9m.fsf@uniton.integrable-solutions.net, Gabriel
"Alain Naigeon" <anaigeon@free.fr> writes:
Je lis dans Stroustrup, 2ème édition française, page 10, une mise
en garde contre les données membres publiques (mais dans
certaines circonstances, j'ajoute, pour être honnête).
ce qui est important, c'est « dans certaines conditions ».
Je mentionne encore l'exemple de std::pair<>.
Mais là, il faut avouer que certaines personnes disent justement
que c'est une erreur d'avoir les données publiques. (ce qui ne
prouve pas que les données publiques soient toujours des erreurs)
C'est vrai que ce serait bien plus robuste si on avait des
fonctions membres du style get_the_first(), get_the_second(),
set_the_first() et set_the_second() ;)
Non, mais x.first() vs x.first ? x.first(v) vs x.first=v;
Plus sérieusement, quel argument as-tu(*) contre le fait que les
données de pair soient publiques ?
Chris
(*) je dis "as-tu", mais c'est une figure de style En toute rigueur
ce devrait être "ont-ils"...
Je ne me rappelle plus exactement. Je n'ai pas d'opinion ferme
là-dessus, alors je n'ai pas tellement le goût de chercher plus
loin que « pair private » dans Google pour clc++m. J'ai trouvé ces
deux bases si tu veux lire plus.
http://minilien.com/?NTwSo50hFJ
http://minilien.com/?flj2Rwz4iN
Je ne suis même pas certain que c'est à quoi je pensais...
Peut-être que Gabriel ou James se rappelle plus que moi s'il y a
eu une discussion plus exacte sur des problèmes dûs à l'interface
trop publique de std::pair...
(Personnellement je n'ai pas de problème avec le std::pair actuel,
mon message tenait seulement à dire qu'il ne faut pas toujours se
fier sur la bibliothèque pour des exemples de design qui semblent
bons à tous. Si pair n'est pas un bon exemple de ça, il n'y a qu'à
voir les critiques de James pour en trouver d'autres :-)
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
"Michel Michaud" a écrit dans le message de news:1jHRa.7783$
Dans news:, Gabriel
"Alain Naigeon" writes:
Je lis dans Stroustrup, 2ème édition française, page 10, une mise en garde contre les données membres publiques (mais dans certaines circonstances, j'ajoute, pour être honnête).
ce qui est important, c'est « dans certaines conditions ». Je mentionne encore l'exemple de std::pair<>.
Mais là, il faut avouer que certaines personnes disent justement que c'est une erreur d'avoir les données publiques. (ce qui ne prouve pas que les données publiques soient toujours des erreurs)
C'est vrai que ce serait bien plus robuste si on avait des fonctions membres du style get_the_first(), get_the_second(), set_the_first() et set_the_second() ;)
Non, mais x.first() vs x.first ? x.first(v) vs x.first=v;
Plus sérieusement, quel argument as-tu(*) contre le fait que les données de pair soient publiques ?
Chris
(*) je dis "as-tu", mais c'est une figure de style En toute rigueur ce devrait être "ont-ils"...
Je ne me rappelle plus exactement. Je n'ai pas d'opinion ferme là-dessus, alors je n'ai pas tellement le goût de chercher plus loin que « pair private » dans Google pour clc++m. J'ai trouvé ces deux bases si tu veux lire plus.
http://minilien.com/?NTwSo50hFJ
http://minilien.com/?flj2Rwz4iN
Je ne suis même pas certain que c'est à quoi je pensais...
Peut-être que Gabriel ou James se rappelle plus que moi s'il y a eu une discussion plus exacte sur des problèmes dûs à l'interface trop publique de std::pair...
(Personnellement je n'ai pas de problème avec le std::pair actuel, mon message tenait seulement à dire qu'il ne faut pas toujours se fier sur la bibliothèque pour des exemples de design qui semblent bons à tous. Si pair n'est pas un bon exemple de ça, il n'y a qu'à voir les critiques de James pour en trouver d'autres :-)
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Arnaud Meurgues
Gabriel Dos Reis wrote:
Pour moi, le problème vient de ce que l'interface d'auto_ptr fait croire qu'on peut l'utiliser naïvement sans problème. Cela n'est pas du Murphy.
Ok. J'ai compris ton point de vue et l'approuve.
il y a eu beaucoup de versions d'auto_ptr<>, la seule « bonne » dont je me souviens bien est celle adoptée le 27 Novembre 1997 par le comité.
Ok. Je n'étais donc pas à jour.
Arnaud
Gabriel Dos Reis wrote:
Pour moi, le problème vient de ce que l'interface d'auto_ptr fait
croire qu'on peut l'utiliser naïvement sans problème. Cela n'est pas
du Murphy.
Ok. J'ai compris ton point de vue et l'approuve.
il y a eu beaucoup de versions d'auto_ptr<>, la seule « bonne »
dont je me souviens bien est celle adoptée le 27 Novembre 1997 par le
comité.
Pour moi, le problème vient de ce que l'interface d'auto_ptr fait croire qu'on peut l'utiliser naïvement sans problème. Cela n'est pas du Murphy.
Ok. J'ai compris ton point de vue et l'approuve.
il y a eu beaucoup de versions d'auto_ptr<>, la seule « bonne » dont je me souviens bien est celle adoptée le 27 Novembre 1997 par le comité.
Ok. Je n'étais donc pas à jour.
Arnaud
Arnaud Meurgues
wrote:
Sans vouloir offenser -- il y a dans la culture française une tendance à chercher trop dans des mots individuels, sans prendre en considération le tout.
Il n'y a pas d'offense. Je crois que le choix des mots est effectivement importants pour un français. Mais il me semblait que cela débordait la culture française. Après tout, le lapsus est un concept viennois.
Arnaud
kanze@gabi-soft.fr wrote:
Sans vouloir offenser -- il y a dans la culture française une tendance à
chercher trop dans des mots individuels, sans prendre en considération
le tout.
Il n'y a pas d'offense. Je crois que le choix des mots est effectivement
importants pour un français. Mais il me semblait que cela débordait la
culture française. Après tout, le lapsus est un concept viennois.
Sans vouloir offenser -- il y a dans la culture française une tendance à chercher trop dans des mots individuels, sans prendre en considération le tout.
Il n'y a pas d'offense. Je crois que le choix des mots est effectivement importants pour un français. Mais il me semblait que cela débordait la culture française. Après tout, le lapsus est un concept viennois.
Arnaud
Jean-Marc Bourguet
Arnaud Meurgues writes:
Après tout, le lapsus est un concept viennois.
Le fait que le lapsus revele quelque chose de l'inconscient est un concept viennois.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Le fait que le lapsus revele quelque chose de l'inconscient est un
concept viennois.
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Le fait que le lapsus revele quelque chose de l'inconscient est un concept viennois.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Arnaud Meurgues
Jean-Marc Bourguet wrote:
Après tout, le lapsus est un concept viennois. Le fait que le lapsus revele quelque chose de l'inconscient est un
concept viennois.
:-) Oui.
Arnaud
Jean-Marc Bourguet wrote:
Après tout, le lapsus est un concept viennois.
Le fait que le lapsus revele quelque chose de l'inconscient est un
Après tout, le lapsus est un concept viennois. Le fait que le lapsus revele quelque chose de l'inconscient est un
concept viennois.
:-) Oui.
Arnaud
kanze
"Alain Naigeon" wrote in message news:<3f16fabb$0$23700$...
a écrit dans le message news:
"Alain Naigeon" wrote in message news:<3f165f74$0$17266$...
Donc, le choix d'un langage s'effectue, en principe, sur des bases rationnelles.
Tout à fait. Un expert C++ touche entre 500 et 800 Euros par jour, sinon plus (selon le marché -- actuellement, les prix se tassent vers le bas de l'échelle). Un expert Modula-3 touche les indemnités de chomage -- peut-être 40 Euros par jour ? C'est une base très rationnelle, non ?
Après cette remarque, il ne reste plus qu'à se jetter du haut de la tour... "Eiffel" :-)
N'est-ce pas ? Il y a aussi le problème qu'une fois tu es un spécialiste en X, on te propose rarement des boulots avec Y. Parfois, quand le marché est en boom, et on ne trouve personne d'autre, mais même alors, c'est rare. Je suis fiché comme expert C++ sur Unix -- j'aurais du mal à trouver un boulot en Ada, ou sur PC.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
"Alain Naigeon" <anaigeon@free.fr> wrote in message
news:<3f16fabb$0$23700$626a54ce@news.free.fr>...
<kanze@gabi-soft.fr> a écrit dans le message news:
d6652001.0307170834.77c46c03@posting.google.com...
"Alain Naigeon" <anaigeon@free.fr> wrote in message
news:<3f165f74$0$17266$626a54ce@news.free.fr>...
Donc, le choix d'un langage s'effectue, en principe, sur des bases
rationnelles.
Tout à fait. Un expert C++ touche entre 500 et 800 Euros par jour,
sinon plus (selon le marché -- actuellement, les prix se tassent
vers le bas de l'échelle). Un expert Modula-3 touche les indemnités
de chomage -- peut-être 40 Euros par jour ? C'est une base très
rationnelle, non ?
Après cette remarque, il ne reste plus qu'à se jetter du haut de la
tour... "Eiffel" :-)
N'est-ce pas ? Il y a aussi le problème qu'une fois tu es un spécialiste
en X, on te propose rarement des boulots avec Y. Parfois, quand le
marché est en boom, et on ne trouve personne d'autre, mais même alors,
c'est rare. Je suis fiché comme expert C++ sur Unix -- j'aurais du mal à
trouver un boulot en Ada, ou sur PC.
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
"Alain Naigeon" wrote in message news:<3f16fabb$0$23700$...
a écrit dans le message news:
"Alain Naigeon" wrote in message news:<3f165f74$0$17266$...
Donc, le choix d'un langage s'effectue, en principe, sur des bases rationnelles.
Tout à fait. Un expert C++ touche entre 500 et 800 Euros par jour, sinon plus (selon le marché -- actuellement, les prix se tassent vers le bas de l'échelle). Un expert Modula-3 touche les indemnités de chomage -- peut-être 40 Euros par jour ? C'est une base très rationnelle, non ?
Après cette remarque, il ne reste plus qu'à se jetter du haut de la tour... "Eiffel" :-)
N'est-ce pas ? Il y a aussi le problème qu'une fois tu es un spécialiste en X, on te propose rarement des boulots avec Y. Parfois, quand le marché est en boom, et on ne trouve personne d'autre, mais même alors, c'est rare. Je suis fiché comme expert C++ sur Unix -- j'aurais du mal à trouver un boulot en Ada, ou sur PC.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
