ld a écrit :
> On 30 oct, 10:37, James Kanze wrote:
>> On Oct 30, 8:41 am, ld wrote:
>>> On 28 oct, 19:13, David Fleury wrote:
>> [...]
>>> En particulier avec C++, la capacite a faire un bon design est
>>> essentielle dans un "vrai" projet.
>> Ce n'est pas particulier avec C++ ; une bonne conception est
>> essentielle, quelque soit le langage.
> Je considère que c'est encore plus critique sur les langages
> statiquement typés avec peu/pas de fonctionnalités dynamiques comme C
> et C++ et où le manque de flexibilité du design se paye au prix for t.
C'est d'autant plus vrai pour les langages dynamiques où il est
nécessaire d'avoir une bonne couverture de test et où l'architecture est
pressurés par la testabilité.
> Le minimum étant les interfaces à-la-Java que malheureusement C++ n 'a
> pas (mais pourrait).
Quel est le problème avec les classes virtuelles pures ?
struct IConnectable
{
virtual connect()=0;
virtual disconnect()=0;
};
Je dirai plutôt que c'est Java qui n'a pas voulu des héritages multip les.
>> Mais la question reste :
>> quelle est la poste à pourvoir ? Dans des grandes équipes, il y
>> a beaucoup de programmeurs qui n'ont qu'à implémenter des
>> éléments d'une conception qui leur est donnée. (Dans un projet,
>> au moins, environ 80% des développeurs n'avaient même pas le
>> droit de toucher aux fichiers d'en-tête. Qui était de toute
>> façon générée à partir du modèle par Rational Rose.)
> Tout à fait d'accord. Mais comme je n'ai jamais travaillé dans une
> "grande" équipe (>20) et comme je crois que c'est somme toute assez
> rare, je n'avais pas considéré ce cas de figure. Autant pour moi. C eci-
> dit, je n'aime les projets où on considère les programmeurs comme d es
> générateurs de code et où leur rôle est ultra spécialisé. M on coté
> créatif sans doute ;-)
Ça dépends de la taille du projet. Typiquement, il y a un groupe de
développeur qui est là du début à la fin (core team) et d'autres qui
viennent en renfort à certains points clés de la vie du projet (en
général au milieu). Ceux qui viennent aider ne sont pas moins créat ifs
même si il est peut probable qu'ils prennent une décision qui va
influencer le cours du projet.
ld a écrit :
> On 30 oct, 10:37, James Kanze <james.ka...@gmail.com> wrote:
>> On Oct 30, 8:41 am, ld <Laurent.Den...@gmail.com> wrote:
>>> On 28 oct, 19:13, David Fleury <dfleu...@libertysurf.fr> wrote:
>> [...]
>>> En particulier avec C++, la capacite a faire un bon design est
>>> essentielle dans un "vrai" projet.
>> Ce n'est pas particulier avec C++ ; une bonne conception est
>> essentielle, quelque soit le langage.
> Je considère que c'est encore plus critique sur les langages
> statiquement typés avec peu/pas de fonctionnalités dynamiques comme C
> et C++ et où le manque de flexibilité du design se paye au prix for t.
C'est d'autant plus vrai pour les langages dynamiques où il est
nécessaire d'avoir une bonne couverture de test et où l'architecture est
pressurés par la testabilité.
> Le minimum étant les interfaces à-la-Java que malheureusement C++ n 'a
> pas (mais pourrait).
Quel est le problème avec les classes virtuelles pures ?
struct IConnectable
{
virtual connect()=0;
virtual disconnect()=0;
};
Je dirai plutôt que c'est Java qui n'a pas voulu des héritages multip les.
>> Mais la question reste :
>> quelle est la poste à pourvoir ? Dans des grandes équipes, il y
>> a beaucoup de programmeurs qui n'ont qu'à implémenter des
>> éléments d'une conception qui leur est donnée. (Dans un projet,
>> au moins, environ 80% des développeurs n'avaient même pas le
>> droit de toucher aux fichiers d'en-tête. Qui était de toute
>> façon générée à partir du modèle par Rational Rose.)
> Tout à fait d'accord. Mais comme je n'ai jamais travaillé dans une
> "grande" équipe (>20) et comme je crois que c'est somme toute assez
> rare, je n'avais pas considéré ce cas de figure. Autant pour moi. C eci-
> dit, je n'aime les projets où on considère les programmeurs comme d es
> générateurs de code et où leur rôle est ultra spécialisé. M on coté
> créatif sans doute ;-)
Ça dépends de la taille du projet. Typiquement, il y a un groupe de
développeur qui est là du début à la fin (core team) et d'autres qui
viennent en renfort à certains points clés de la vie du projet (en
général au milieu). Ceux qui viennent aider ne sont pas moins créat ifs
même si il est peut probable qu'ils prennent une décision qui va
influencer le cours du projet.
ld a écrit :
> On 30 oct, 10:37, James Kanze wrote:
>> On Oct 30, 8:41 am, ld wrote:
>>> On 28 oct, 19:13, David Fleury wrote:
>> [...]
>>> En particulier avec C++, la capacite a faire un bon design est
>>> essentielle dans un "vrai" projet.
>> Ce n'est pas particulier avec C++ ; une bonne conception est
>> essentielle, quelque soit le langage.
> Je considère que c'est encore plus critique sur les langages
> statiquement typés avec peu/pas de fonctionnalités dynamiques comme C
> et C++ et où le manque de flexibilité du design se paye au prix for t.
C'est d'autant plus vrai pour les langages dynamiques où il est
nécessaire d'avoir une bonne couverture de test et où l'architecture est
pressurés par la testabilité.
> Le minimum étant les interfaces à-la-Java que malheureusement C++ n 'a
> pas (mais pourrait).
Quel est le problème avec les classes virtuelles pures ?
struct IConnectable
{
virtual connect()=0;
virtual disconnect()=0;
};
Je dirai plutôt que c'est Java qui n'a pas voulu des héritages multip les.
>> Mais la question reste :
>> quelle est la poste à pourvoir ? Dans des grandes équipes, il y
>> a beaucoup de programmeurs qui n'ont qu'à implémenter des
>> éléments d'une conception qui leur est donnée. (Dans un projet,
>> au moins, environ 80% des développeurs n'avaient même pas le
>> droit de toucher aux fichiers d'en-tête. Qui était de toute
>> façon générée à partir du modèle par Rational Rose.)
> Tout à fait d'accord. Mais comme je n'ai jamais travaillé dans une
> "grande" équipe (>20) et comme je crois que c'est somme toute assez
> rare, je n'avais pas considéré ce cas de figure. Autant pour moi. C eci-
> dit, je n'aime les projets où on considère les programmeurs comme d es
> générateurs de code et où leur rôle est ultra spécialisé. M on coté
> créatif sans doute ;-)
Ça dépends de la taille du projet. Typiquement, il y a un groupe de
développeur qui est là du début à la fin (core team) et d'autres qui
viennent en renfort à certains points clés de la vie du projet (en
général au milieu). Ceux qui viennent aider ne sont pas moins créat ifs
même si il est peut probable qu'ils prennent une décision qui va
influencer le cours du projet.
Et c'est bien plus difficile d'évaluer sa capacité de travailler
en équipe ou de communiquer qu'il ne l'est d'évaluer ses
compétences C++. Alors qu'à la rigueur, le C++ s'apprend, tandis
que la capacité de travailler en équipe et de communiquer
clairement ses idées, plus difficilement.
Je ne sais pas. La dernière fois que j'avais à valider les
compétences des candidats, je trouveais que 9 sur 10 s'heurter
sur des questions aussi simple que « Pourquoi est-ce qu'on
déclarerait un destructeur virtuel ? ».
Un (avec soi-disant 2
ans d'expérience avec C++ dans un projet OO) m'a même démandé ce
que j'entendais par « virtuel ».
Et c'est bien plus difficile d'évaluer sa capacité de travailler
en équipe ou de communiquer qu'il ne l'est d'évaluer ses
compétences C++. Alors qu'à la rigueur, le C++ s'apprend, tandis
que la capacité de travailler en équipe et de communiquer
clairement ses idées, plus difficilement.
Je ne sais pas. La dernière fois que j'avais à valider les
compétences des candidats, je trouveais que 9 sur 10 s'heurter
sur des questions aussi simple que « Pourquoi est-ce qu'on
déclarerait un destructeur virtuel ? ».
Un (avec soi-disant 2
ans d'expérience avec C++ dans un projet OO) m'a même démandé ce
que j'entendais par « virtuel ».
Et c'est bien plus difficile d'évaluer sa capacité de travailler
en équipe ou de communiquer qu'il ne l'est d'évaluer ses
compétences C++. Alors qu'à la rigueur, le C++ s'apprend, tandis
que la capacité de travailler en équipe et de communiquer
clairement ses idées, plus difficilement.
Je ne sais pas. La dernière fois que j'avais à valider les
compétences des candidats, je trouveais que 9 sur 10 s'heurter
sur des questions aussi simple que « Pourquoi est-ce qu'on
déclarerait un destructeur virtuel ? ».
Un (avec soi-disant 2
ans d'expérience avec C++ dans un projet OO) m'a même démandé ce
que j'entendais par « virtuel ».
ld a écrit :On 30 oct, 10:37, James Kanze wrote:On Oct 30, 8:41 am, ld wrote:On 28 oct, 19:13, David Fleury wrote:
[...]En particulier avec C++, la capacite a faire un bon design est
essentielle dans un "vrai" projet.
Ce n'est pas particulier avec C++ ; une bonne conception est
essentielle, quelque soit le langage.
Je considère que c'est encore plus critique sur les langages
statiquement typés avec peu/pas de fonctionnalités dynamiques comme C
et C++ et où le manque de flexibilité du design se paye au prix fort.
C'est d'autant plus vrai pour les langages dynamiques où il est
nécessaire d'avoir une bonne couverture de test et où l'architecture est
pressurés par la testabilité.
Le minimum étant les interfaces à-la-Java que malheureusement C++ n'a
pas (mais pourrait).
Quel est le problème avec les classes virtuelles pures ?
struct IConnectable
{
virtual connect()=0;
virtual disconnect()=0;
};
Je dirai plutôt que c'est Java qui n'a pas voulu des héritages multiples.
Mais la question reste :
quelle est la poste à pourvoir ? Dans des grandes équipes, il y
a beaucoup de programmeurs qui n'ont qu'à implémenter des
éléments d'une conception qui leur est donnée. (Dans un projet,
au moins, environ 80% des développeurs n'avaient même pas le
droit de toucher aux fichiers d'en-tête. Qui était de toute
façon générée à partir du modèle par Rational Rose.)
Tout à fait d'accord. Mais comme je n'ai jamais travaillé dans une
"grande" équipe (>20) et comme je crois que c'est somme toute assez
rare, je n'avais pas considéré ce cas de figure. Autant pour moi. Ceci-
dit, je n'aime les projets où on considère les programmeurs comme des
générateurs de code et où leur rôle est ultra spécialisé. Mon coté
créatif sans doute ;-)
Ça dépends de la taille du projet. Typiquement, il y a un groupe de
développeur qui est là du début à la fin (core team) et d'autres qui
viennent en renfort à certains points clés de la vie du projet (en
général au milieu). Ceux qui viennent aider ne sont pas moins créatifs
même si il est peut probable qu'ils prennent une décision qui va
influencer le cours du projet.
ld a écrit :
On 30 oct, 10:37, James Kanze <james.ka...@gmail.com> wrote:
On Oct 30, 8:41 am, ld <Laurent.Den...@gmail.com> wrote:
On 28 oct, 19:13, David Fleury <dfleu...@libertysurf.fr> wrote:
[...]
En particulier avec C++, la capacite a faire un bon design est
essentielle dans un "vrai" projet.
Ce n'est pas particulier avec C++ ; une bonne conception est
essentielle, quelque soit le langage.
Je considère que c'est encore plus critique sur les langages
statiquement typés avec peu/pas de fonctionnalités dynamiques comme C
et C++ et où le manque de flexibilité du design se paye au prix fort.
C'est d'autant plus vrai pour les langages dynamiques où il est
nécessaire d'avoir une bonne couverture de test et où l'architecture est
pressurés par la testabilité.
Le minimum étant les interfaces à-la-Java que malheureusement C++ n'a
pas (mais pourrait).
Quel est le problème avec les classes virtuelles pures ?
struct IConnectable
{
virtual connect()=0;
virtual disconnect()=0;
};
Je dirai plutôt que c'est Java qui n'a pas voulu des héritages multiples.
Mais la question reste :
quelle est la poste à pourvoir ? Dans des grandes équipes, il y
a beaucoup de programmeurs qui n'ont qu'à implémenter des
éléments d'une conception qui leur est donnée. (Dans un projet,
au moins, environ 80% des développeurs n'avaient même pas le
droit de toucher aux fichiers d'en-tête. Qui était de toute
façon générée à partir du modèle par Rational Rose.)
Tout à fait d'accord. Mais comme je n'ai jamais travaillé dans une
"grande" équipe (>20) et comme je crois que c'est somme toute assez
rare, je n'avais pas considéré ce cas de figure. Autant pour moi. Ceci-
dit, je n'aime les projets où on considère les programmeurs comme des
générateurs de code et où leur rôle est ultra spécialisé. Mon coté
créatif sans doute ;-)
Ça dépends de la taille du projet. Typiquement, il y a un groupe de
développeur qui est là du début à la fin (core team) et d'autres qui
viennent en renfort à certains points clés de la vie du projet (en
général au milieu). Ceux qui viennent aider ne sont pas moins créatifs
même si il est peut probable qu'ils prennent une décision qui va
influencer le cours du projet.
ld a écrit :On 30 oct, 10:37, James Kanze wrote:On Oct 30, 8:41 am, ld wrote:On 28 oct, 19:13, David Fleury wrote:
[...]En particulier avec C++, la capacite a faire un bon design est
essentielle dans un "vrai" projet.
Ce n'est pas particulier avec C++ ; une bonne conception est
essentielle, quelque soit le langage.
Je considère que c'est encore plus critique sur les langages
statiquement typés avec peu/pas de fonctionnalités dynamiques comme C
et C++ et où le manque de flexibilité du design se paye au prix fort.
C'est d'autant plus vrai pour les langages dynamiques où il est
nécessaire d'avoir une bonne couverture de test et où l'architecture est
pressurés par la testabilité.
Le minimum étant les interfaces à-la-Java que malheureusement C++ n'a
pas (mais pourrait).
Quel est le problème avec les classes virtuelles pures ?
struct IConnectable
{
virtual connect()=0;
virtual disconnect()=0;
};
Je dirai plutôt que c'est Java qui n'a pas voulu des héritages multiples.
Mais la question reste :
quelle est la poste à pourvoir ? Dans des grandes équipes, il y
a beaucoup de programmeurs qui n'ont qu'à implémenter des
éléments d'une conception qui leur est donnée. (Dans un projet,
au moins, environ 80% des développeurs n'avaient même pas le
droit de toucher aux fichiers d'en-tête. Qui était de toute
façon générée à partir du modèle par Rational Rose.)
Tout à fait d'accord. Mais comme je n'ai jamais travaillé dans une
"grande" équipe (>20) et comme je crois que c'est somme toute assez
rare, je n'avais pas considéré ce cas de figure. Autant pour moi. Ceci-
dit, je n'aime les projets où on considère les programmeurs comme des
générateurs de code et où leur rôle est ultra spécialisé. Mon coté
créatif sans doute ;-)
Ça dépends de la taille du projet. Typiquement, il y a un groupe de
développeur qui est là du début à la fin (core team) et d'autres qui
viennent en renfort à certains points clés de la vie du projet (en
général au milieu). Ceux qui viennent aider ne sont pas moins créatifs
même si il est peut probable qu'ils prennent une décision qui va
influencer le cours du projet.
Wykaaa a écrit :[snip]
Je voulais dire, en fait :
pt étant un nom de tableau peut-on écrire pt++ ?
La réponse est évidemment non puisqu'un nom de tableau est un pointeur
constant sur le premier élément du tableau.
Comme d'autre l'ont signalé, le om d'un tableau est de type tableau et
non pas de type pointer. Pour des raisons historiques (K&R C), le
tableau se converti implicitement en pointeur mais il reste un tableau.
D'ailleur:
int * const ptr;
const int tab[42];
int * const ptr=tab;
sizeoff(ptr)!=sizeof(tab)
Wykaaa a écrit :
[snip]
Je voulais dire, en fait :
pt étant un nom de tableau peut-on écrire pt++ ?
La réponse est évidemment non puisqu'un nom de tableau est un pointeur
constant sur le premier élément du tableau.
Comme d'autre l'ont signalé, le om d'un tableau est de type tableau et
non pas de type pointer. Pour des raisons historiques (K&R C), le
tableau se converti implicitement en pointeur mais il reste un tableau.
D'ailleur:
int * const ptr;
const int tab[42];
int * const ptr=tab;
sizeoff(ptr)!=sizeof(tab)
Wykaaa a écrit :[snip]
Je voulais dire, en fait :
pt étant un nom de tableau peut-on écrire pt++ ?
La réponse est évidemment non puisqu'un nom de tableau est un pointeur
constant sur le premier élément du tableau.
Comme d'autre l'ont signalé, le om d'un tableau est de type tableau et
non pas de type pointer. Pour des raisons historiques (K&R C), le
tableau se converti implicitement en pointeur mais il reste un tableau.
D'ailleur:
int * const ptr;
const int tab[42];
int * const ptr=tab;
sizeoff(ptr)!=sizeof(tab)
On 30 oct, 10:04, James Kanze wrote:
> Et c'est bien plus difficile d'évaluer sa capacité de
> travailler en équipe ou de communiquer qu'il ne l'est
> d'évaluer ses compétences C++. Alors qu'à la rigueur, le C++
> s'apprend, tandis que la capacité de travailler en équipe et
> de communiquer clairement ses idées, plus difficilement.
"ce qui se conçoit bien s?énonce clairement et les mots pour
le dire viennent aisément" donc pour ce qui est des questions
relative au C++, cela peu poser des problèmes de communication
de ne pas le comprendre.
Imagine toi assister à une réunion en Mandarin (à moins que tu
ne le parles?), il te sera difficile de participer...
> Je ne sais pas. La dernière fois que j'avais à valider les
> compétences des candidats, je trouveais que 9 sur 10
> s'heurter sur des questions aussi simple que « Pourquoi
> est-ce qu'on déclarerait un destructeur virtuel ? ».
Parce que le compilateur le demande ;-)
> Un (avec soi-disant 2 ans d'expérience avec C++ dans un
> projet OO) m'a même démandé ce que j'entendais par
> « virtuel ».
Arf, recalé.
On 30 oct, 10:04, James Kanze <james.ka...@gmail.com> wrote:
> Et c'est bien plus difficile d'évaluer sa capacité de
> travailler en équipe ou de communiquer qu'il ne l'est
> d'évaluer ses compétences C++. Alors qu'à la rigueur, le C++
> s'apprend, tandis que la capacité de travailler en équipe et
> de communiquer clairement ses idées, plus difficilement.
"ce qui se conçoit bien s?énonce clairement et les mots pour
le dire viennent aisément" donc pour ce qui est des questions
relative au C++, cela peu poser des problèmes de communication
de ne pas le comprendre.
Imagine toi assister à une réunion en Mandarin (à moins que tu
ne le parles?), il te sera difficile de participer...
> Je ne sais pas. La dernière fois que j'avais à valider les
> compétences des candidats, je trouveais que 9 sur 10
> s'heurter sur des questions aussi simple que « Pourquoi
> est-ce qu'on déclarerait un destructeur virtuel ? ».
Parce que le compilateur le demande ;-)
> Un (avec soi-disant 2 ans d'expérience avec C++ dans un
> projet OO) m'a même démandé ce que j'entendais par
> « virtuel ».
Arf, recalé.
On 30 oct, 10:04, James Kanze wrote:
> Et c'est bien plus difficile d'évaluer sa capacité de
> travailler en équipe ou de communiquer qu'il ne l'est
> d'évaluer ses compétences C++. Alors qu'à la rigueur, le C++
> s'apprend, tandis que la capacité de travailler en équipe et
> de communiquer clairement ses idées, plus difficilement.
"ce qui se conçoit bien s?énonce clairement et les mots pour
le dire viennent aisément" donc pour ce qui est des questions
relative au C++, cela peu poser des problèmes de communication
de ne pas le comprendre.
Imagine toi assister à une réunion en Mandarin (à moins que tu
ne le parles?), il te sera difficile de participer...
> Je ne sais pas. La dernière fois que j'avais à valider les
> compétences des candidats, je trouveais que 9 sur 10
> s'heurter sur des questions aussi simple que « Pourquoi
> est-ce qu'on déclarerait un destructeur virtuel ? ».
Parce que le compilateur le demande ;-)
> Un (avec soi-disant 2 ans d'expérience avec C++ dans un
> projet OO) m'a même démandé ce que j'entendais par
> « virtuel ».
Arf, recalé.
On 30 oct, 10:37, James Kanze wrote:
> On Oct 30, 8:41 am, ld wrote:
> > On 28 oct, 19:13, David Fleury wrote:
> [...]
> > En particulier avec C++, la capacite a faire un bon design
> > est essentielle dans un "vrai" projet.
> Ce n'est pas particulier avec C++ ; une bonne conception est
> essentielle, quelque soit le langage.
Je considère que c'est encore plus critique sur les langages
statiquement typés avec peu/pas de fonctionnalités dynamiques
comme C et C++ et où le manque de flexibilité du design se
paye au prix fort.
Le minimum étant les interfaces à-la-Java que malheureusement
C++ n'a pas (mais pourrait).
> Mais la question reste :
> quelle est la poste à pourvoir ? Dans des grandes équipes,
> il y a beaucoup de programmeurs qui n'ont qu'à implémenter
> des éléments d'une conception qui leur est donnée. (Dans un
> projet, au moins, environ 80% des développeurs n'avaient
> même pas le droit de toucher aux fichiers d'en-tête. Qui
> était de toute façon générée à partir du modèle par Ratio nal
> Rose.)
Tout à fait d'accord. Mais comme je n'ai jamais travaillé dans
une "grande" équipe (>20) et comme je crois que c'est somme
toute assez rare,
je n'avais pas considéré ce cas de figure. Autant pour moi.
Ceci- dit, je n'aime les projets où on considère les
programmeurs comme des générateurs de code et où leur rôle est
ultra spécialisé. Mon coté créatif sans doute ;-)
On 30 oct, 10:37, James Kanze <james.ka...@gmail.com> wrote:
> On Oct 30, 8:41 am, ld <Laurent.Den...@gmail.com> wrote:
> > On 28 oct, 19:13, David Fleury <dfleu...@libertysurf.fr> wrote:
> [...]
> > En particulier avec C++, la capacite a faire un bon design
> > est essentielle dans un "vrai" projet.
> Ce n'est pas particulier avec C++ ; une bonne conception est
> essentielle, quelque soit le langage.
Je considère que c'est encore plus critique sur les langages
statiquement typés avec peu/pas de fonctionnalités dynamiques
comme C et C++ et où le manque de flexibilité du design se
paye au prix fort.
Le minimum étant les interfaces à-la-Java que malheureusement
C++ n'a pas (mais pourrait).
> Mais la question reste :
> quelle est la poste à pourvoir ? Dans des grandes équipes,
> il y a beaucoup de programmeurs qui n'ont qu'à implémenter
> des éléments d'une conception qui leur est donnée. (Dans un
> projet, au moins, environ 80% des développeurs n'avaient
> même pas le droit de toucher aux fichiers d'en-tête. Qui
> était de toute façon générée à partir du modèle par Ratio nal
> Rose.)
Tout à fait d'accord. Mais comme je n'ai jamais travaillé dans
une "grande" équipe (>20) et comme je crois que c'est somme
toute assez rare,
je n'avais pas considéré ce cas de figure. Autant pour moi.
Ceci- dit, je n'aime les projets où on considère les
programmeurs comme des générateurs de code et où leur rôle est
ultra spécialisé. Mon coté créatif sans doute ;-)
On 30 oct, 10:37, James Kanze wrote:
> On Oct 30, 8:41 am, ld wrote:
> > On 28 oct, 19:13, David Fleury wrote:
> [...]
> > En particulier avec C++, la capacite a faire un bon design
> > est essentielle dans un "vrai" projet.
> Ce n'est pas particulier avec C++ ; une bonne conception est
> essentielle, quelque soit le langage.
Je considère que c'est encore plus critique sur les langages
statiquement typés avec peu/pas de fonctionnalités dynamiques
comme C et C++ et où le manque de flexibilité du design se
paye au prix fort.
Le minimum étant les interfaces à-la-Java que malheureusement
C++ n'a pas (mais pourrait).
> Mais la question reste :
> quelle est la poste à pourvoir ? Dans des grandes équipes,
> il y a beaucoup de programmeurs qui n'ont qu'à implémenter
> des éléments d'une conception qui leur est donnée. (Dans un
> projet, au moins, environ 80% des développeurs n'avaient
> même pas le droit de toucher aux fichiers d'en-tête. Qui
> était de toute façon générée à partir du modèle par Ratio nal
> Rose.)
Tout à fait d'accord. Mais comme je n'ai jamais travaillé dans
une "grande" équipe (>20) et comme je crois que c'est somme
toute assez rare,
je n'avais pas considéré ce cas de figure. Autant pour moi.
Ceci- dit, je n'aime les projets où on considère les
programmeurs comme des générateurs de code et où leur rôle est
ultra spécialisé. Mon coté créatif sans doute ;-)
ld a écrit :
> On 30 oct, 10:37, James Kanze wrote:
>> On Oct 30, 8:41 am, ld wrote:
>>> On 28 oct, 19:13, David Fleury wrote:
>> [...]
>>> En particulier avec C++, la capacite a faire un bon design
>>> est essentielle dans un "vrai" projet.
>> Ce n'est pas particulier avec C++ ; une bonne conception
>> est essentielle, quelque soit le langage.
> Je considère que c'est encore plus critique sur les langages
> statiquement typés avec peu/pas de fonctionnalités
> dynamiques comme C et C++ et où le manque de flexibilité du
> design se paye au prix fort.
C'est d'autant plus vrai pour les langages dynamiques où il
est nécessaire d'avoir une bonne couverture de test et où
l'architecture est pressurés par la testabilité.
> Le minimum étant les interfaces à-la-Java que
> malheureusement C++ n'a pas (mais pourrait).
Quel est le problème avec les classes virtuelles pures ?
struct IConnectable
{
virtual connect()=0;
virtual disconnect()=0;
};
Je dirai plutôt que c'est Java qui n'a pas voulu des héritages
multiples.
ld a écrit :
> On 30 oct, 10:37, James Kanze <james.ka...@gmail.com> wrote:
>> On Oct 30, 8:41 am, ld <Laurent.Den...@gmail.com> wrote:
>>> On 28 oct, 19:13, David Fleury <dfleu...@libertysurf.fr> wrote:
>> [...]
>>> En particulier avec C++, la capacite a faire un bon design
>>> est essentielle dans un "vrai" projet.
>> Ce n'est pas particulier avec C++ ; une bonne conception
>> est essentielle, quelque soit le langage.
> Je considère que c'est encore plus critique sur les langages
> statiquement typés avec peu/pas de fonctionnalités
> dynamiques comme C et C++ et où le manque de flexibilité du
> design se paye au prix fort.
C'est d'autant plus vrai pour les langages dynamiques où il
est nécessaire d'avoir une bonne couverture de test et où
l'architecture est pressurés par la testabilité.
> Le minimum étant les interfaces à-la-Java que
> malheureusement C++ n'a pas (mais pourrait).
Quel est le problème avec les classes virtuelles pures ?
struct IConnectable
{
virtual connect()=0;
virtual disconnect()=0;
};
Je dirai plutôt que c'est Java qui n'a pas voulu des héritages
multiples.
ld a écrit :
> On 30 oct, 10:37, James Kanze wrote:
>> On Oct 30, 8:41 am, ld wrote:
>>> On 28 oct, 19:13, David Fleury wrote:
>> [...]
>>> En particulier avec C++, la capacite a faire un bon design
>>> est essentielle dans un "vrai" projet.
>> Ce n'est pas particulier avec C++ ; une bonne conception
>> est essentielle, quelque soit le langage.
> Je considère que c'est encore plus critique sur les langages
> statiquement typés avec peu/pas de fonctionnalités
> dynamiques comme C et C++ et où le manque de flexibilité du
> design se paye au prix fort.
C'est d'autant plus vrai pour les langages dynamiques où il
est nécessaire d'avoir une bonne couverture de test et où
l'architecture est pressurés par la testabilité.
> Le minimum étant les interfaces à-la-Java que
> malheureusement C++ n'a pas (mais pourrait).
Quel est le problème avec les classes virtuelles pures ?
struct IConnectable
{
virtual connect()=0;
virtual disconnect()=0;
};
Je dirai plutôt que c'est Java qui n'a pas voulu des héritages
multiples.
> "ce qui se conçoit bien s?énonce clairement et les mots pour
> le dire viennent aisément" donc pour ce qui est des questions
> relative au C++, cela peu poser des problèmes de communication
> de ne pas le comprendre.
Il y a effectivement un rapport. Ceux qui conçoivent bien
peuvent toujours s'exprimer clairement et avec précision ; ceux
qui conçoivent mal rarement.
Maintenant, je ne suis pas sûr d'avoir bien compris. Est-ce qui
tu veux suggérer que la conception du C++ n'est pas très bien,
et que donc, c'est difficile à en parler de façon claire et avec
précision ? :-)
> Imagine toi assister à une réunion en Mandarin (à moins que tu
> ne le parles?), il te sera difficile de participer...
Certes, mais pour une poste en France, je m'attendrais qu'on
discute soit en français, soit en anglais (dans le contexte d'un
projet international). Ou sinon qu'une connaissance de Mandarin
soit exigée d'avance, dans quel cas, je ne me postulerais même
pas. Mais je ne vois pas trop le rapport avec des compétences
C++.
> > Je ne sais pas. La dernière fois que j'avais à valider les
> > compétences des candidats, je trouveais que 9 sur 10
> > s'heurter sur des questions aussi simple que « Pourquoi
> > est-ce qu'on déclarerait un destructeur virtuel ? ».
> Parce que le compilateur le demande ;-)
Justement non. Le compilateur ne le démande pas.
La réponse
exacte comportera obligatoirement des mots « comportement
indéfin ». Mais j'acceptais aussi des réponses à peu près
correctes.
> > Un (avec soi-disant 2 ans d'expérience avec C++ dans un
> > projet OO) m'a même démandé ce que j'entendais par
> > « virtuel ».
> Arf, recalé.
Justement, non. J'ai bien signalé mon avis (que le candidat
était complétement incompétant, et qu'il mentait sur le CV),
mais on m'a répondu qu'il nous fallait quand même quelques uns,
et que vu le marché à l'époque, on n'en trouverait pas d'autres.
J'ai commencé peu après à chercher un autre projet:-).
> "ce qui se conçoit bien s?énonce clairement et les mots pour
> le dire viennent aisément" donc pour ce qui est des questions
> relative au C++, cela peu poser des problèmes de communication
> de ne pas le comprendre.
Il y a effectivement un rapport. Ceux qui conçoivent bien
peuvent toujours s'exprimer clairement et avec précision ; ceux
qui conçoivent mal rarement.
Maintenant, je ne suis pas sûr d'avoir bien compris. Est-ce qui
tu veux suggérer que la conception du C++ n'est pas très bien,
et que donc, c'est difficile à en parler de façon claire et avec
précision ? :-)
> Imagine toi assister à une réunion en Mandarin (à moins que tu
> ne le parles?), il te sera difficile de participer...
Certes, mais pour une poste en France, je m'attendrais qu'on
discute soit en français, soit en anglais (dans le contexte d'un
projet international). Ou sinon qu'une connaissance de Mandarin
soit exigée d'avance, dans quel cas, je ne me postulerais même
pas. Mais je ne vois pas trop le rapport avec des compétences
C++.
> > Je ne sais pas. La dernière fois que j'avais à valider les
> > compétences des candidats, je trouveais que 9 sur 10
> > s'heurter sur des questions aussi simple que « Pourquoi
> > est-ce qu'on déclarerait un destructeur virtuel ? ».
> Parce que le compilateur le demande ;-)
Justement non. Le compilateur ne le démande pas.
La réponse
exacte comportera obligatoirement des mots « comportement
indéfin ». Mais j'acceptais aussi des réponses à peu près
correctes.
> > Un (avec soi-disant 2 ans d'expérience avec C++ dans un
> > projet OO) m'a même démandé ce que j'entendais par
> > « virtuel ».
> Arf, recalé.
Justement, non. J'ai bien signalé mon avis (que le candidat
était complétement incompétant, et qu'il mentait sur le CV),
mais on m'a répondu qu'il nous fallait quand même quelques uns,
et que vu le marché à l'époque, on n'en trouverait pas d'autres.
J'ai commencé peu après à chercher un autre projet:-).
> "ce qui se conçoit bien s?énonce clairement et les mots pour
> le dire viennent aisément" donc pour ce qui est des questions
> relative au C++, cela peu poser des problèmes de communication
> de ne pas le comprendre.
Il y a effectivement un rapport. Ceux qui conçoivent bien
peuvent toujours s'exprimer clairement et avec précision ; ceux
qui conçoivent mal rarement.
Maintenant, je ne suis pas sûr d'avoir bien compris. Est-ce qui
tu veux suggérer que la conception du C++ n'est pas très bien,
et que donc, c'est difficile à en parler de façon claire et avec
précision ? :-)
> Imagine toi assister à une réunion en Mandarin (à moins que tu
> ne le parles?), il te sera difficile de participer...
Certes, mais pour une poste en France, je m'attendrais qu'on
discute soit en français, soit en anglais (dans le contexte d'un
projet international). Ou sinon qu'une connaissance de Mandarin
soit exigée d'avance, dans quel cas, je ne me postulerais même
pas. Mais je ne vois pas trop le rapport avec des compétences
C++.
> > Je ne sais pas. La dernière fois que j'avais à valider les
> > compétences des candidats, je trouveais que 9 sur 10
> > s'heurter sur des questions aussi simple que « Pourquoi
> > est-ce qu'on déclarerait un destructeur virtuel ? ».
> Parce que le compilateur le demande ;-)
Justement non. Le compilateur ne le démande pas.
La réponse
exacte comportera obligatoirement des mots « comportement
indéfin ». Mais j'acceptais aussi des réponses à peu près
correctes.
> > Un (avec soi-disant 2 ans d'expérience avec C++ dans un
> > projet OO) m'a même démandé ce que j'entendais par
> > « virtuel ».
> Arf, recalé.
Justement, non. J'ai bien signalé mon avis (que le candidat
était complétement incompétant, et qu'il mentait sur le CV),
mais on m'a répondu qu'il nous fallait quand même quelques uns,
et que vu le marché à l'époque, on n'en trouverait pas d'autres.
J'ai commencé peu après à chercher un autre projet:-).
C'est bien ce qui trouble nombre de débutants en C/C++ (et même quelques
fois, des non débutants, ces espèces d'équivalences pointeurs/tableau.
D'ailleurs on peut écrire : "0123456789ABCDEF"[i].
Je peux te garantir que ceci trouble même certains programmeurs C très
expérimentés.
C'est bien ce qui trouble nombre de débutants en C/C++ (et même quelques
fois, des non débutants, ces espèces d'équivalences pointeurs/tableau.
D'ailleurs on peut écrire : "0123456789ABCDEF"[i].
Je peux te garantir que ceci trouble même certains programmeurs C très
expérimentés.
C'est bien ce qui trouble nombre de débutants en C/C++ (et même quelques
fois, des non débutants, ces espèces d'équivalences pointeurs/tableau.
D'ailleurs on peut écrire : "0123456789ABCDEF"[i].
Je peux te garantir que ceci trouble même certains programmeurs C très
expérimentés.
On 30 oct, 15:02, Michael DOUBEZ wrote:
> ld a écrit :
> > Le minimum étant les interfaces à-la-Java que
> > malheureusement C++ n'a pas (mais pourrait).
> Quel est le problème avec les classes virtuelles pures ?
> struct IConnectable
> {
> virtual connect()=0;
> virtual disconnect()=0;
> };
> Je dirai plutôt que c'est Java qui n'a pas voulu des
> héritages multiples.
Il y en a plusieurs:
Les instances contiendront (n+1) pointeurs vers les multiples
vtbls pour n heritage multiples, meme si ses classes
abstraites de base n'ont pas de donnees membres (interfaces).
Le modele objet de C++ pourrait optimiser ca, mais c'est assez
complique a cause d'une part du "vrai" heritage multiple et
d'autre part des contraintes dans les ctors/dtors. En tout cas
gcc ne le fait pas. Donc si la classe implemente ± 10
interfaces, un cas assez courant pour un design "flexible", on
se retrouve avec 5 a 10 pointeurs dans les instances (je
suppose quelques heritages simples dans le tas). Ces pointeurs
necessitent des ajustements d'offsets dans l'instance a chaque
fois que l'on utilise l'instance a travers une de ses
interfaces (ce qui est le but pour la flexibilite), et ce qui
demande de generer du code et des calculs en plus.
De plus il faut utiliser au maximum les retours contravariant
pour garder un maximum de visibilite statique,
Enfin, en theorie, il faudrait deriver virtuellement *par
defaut* pour un design flexible sans "bombe a retardement",
mais cela rajoute encore des pointeurs des des ajustements
d'offset. Au final tous ces calculs intermediaires
ralentissent la resolution des appels virtuels de facon non
negligeable. Mes mesures sur gcc 4.2 montrent que par rapport
a un appel virtuel avec heritage simple, l'heritage multiple
de 4 interfaces ralentit d'un facteur ±2 l'appel, et
l'heritage virtuel d'un facteur ±4. Soit ±8 au total si on
mixe les deux, ce qui serait l'approche correcte. Je ne pense
pas que les autres compilateur font mieux et je trouve deja
pas mal compte tenu de tout ce que le compilateur doit
generer.
La faute au "vrai" heritage multiple.
Maintenant de mon point de vue, qui n'engage que moi, je
trouverais beaucoup plus utile une implementation tres
efficace des interfaces a- la-Java en C++ (space & time) a la
place de l'heritage multiple rarement utile et facilement
simulable quand on a vraiment besoin.
On 30 oct, 15:02, Michael DOUBEZ <michael.dou...@free.fr> wrote:
> ld a écrit :
> > Le minimum étant les interfaces à-la-Java que
> > malheureusement C++ n'a pas (mais pourrait).
> Quel est le problème avec les classes virtuelles pures ?
> struct IConnectable
> {
> virtual connect()=0;
> virtual disconnect()=0;
> };
> Je dirai plutôt que c'est Java qui n'a pas voulu des
> héritages multiples.
Il y en a plusieurs:
Les instances contiendront (n+1) pointeurs vers les multiples
vtbls pour n heritage multiples, meme si ses classes
abstraites de base n'ont pas de donnees membres (interfaces).
Le modele objet de C++ pourrait optimiser ca, mais c'est assez
complique a cause d'une part du "vrai" heritage multiple et
d'autre part des contraintes dans les ctors/dtors. En tout cas
gcc ne le fait pas. Donc si la classe implemente ± 10
interfaces, un cas assez courant pour un design "flexible", on
se retrouve avec 5 a 10 pointeurs dans les instances (je
suppose quelques heritages simples dans le tas). Ces pointeurs
necessitent des ajustements d'offsets dans l'instance a chaque
fois que l'on utilise l'instance a travers une de ses
interfaces (ce qui est le but pour la flexibilite), et ce qui
demande de generer du code et des calculs en plus.
De plus il faut utiliser au maximum les retours contravariant
pour garder un maximum de visibilite statique,
Enfin, en theorie, il faudrait deriver virtuellement *par
defaut* pour un design flexible sans "bombe a retardement",
mais cela rajoute encore des pointeurs des des ajustements
d'offset. Au final tous ces calculs intermediaires
ralentissent la resolution des appels virtuels de facon non
negligeable. Mes mesures sur gcc 4.2 montrent que par rapport
a un appel virtuel avec heritage simple, l'heritage multiple
de 4 interfaces ralentit d'un facteur ±2 l'appel, et
l'heritage virtuel d'un facteur ±4. Soit ±8 au total si on
mixe les deux, ce qui serait l'approche correcte. Je ne pense
pas que les autres compilateur font mieux et je trouve deja
pas mal compte tenu de tout ce que le compilateur doit
generer.
La faute au "vrai" heritage multiple.
Maintenant de mon point de vue, qui n'engage que moi, je
trouverais beaucoup plus utile une implementation tres
efficace des interfaces a- la-Java en C++ (space & time) a la
place de l'heritage multiple rarement utile et facilement
simulable quand on a vraiment besoin.
On 30 oct, 15:02, Michael DOUBEZ wrote:
> ld a écrit :
> > Le minimum étant les interfaces à-la-Java que
> > malheureusement C++ n'a pas (mais pourrait).
> Quel est le problème avec les classes virtuelles pures ?
> struct IConnectable
> {
> virtual connect()=0;
> virtual disconnect()=0;
> };
> Je dirai plutôt que c'est Java qui n'a pas voulu des
> héritages multiples.
Il y en a plusieurs:
Les instances contiendront (n+1) pointeurs vers les multiples
vtbls pour n heritage multiples, meme si ses classes
abstraites de base n'ont pas de donnees membres (interfaces).
Le modele objet de C++ pourrait optimiser ca, mais c'est assez
complique a cause d'une part du "vrai" heritage multiple et
d'autre part des contraintes dans les ctors/dtors. En tout cas
gcc ne le fait pas. Donc si la classe implemente ± 10
interfaces, un cas assez courant pour un design "flexible", on
se retrouve avec 5 a 10 pointeurs dans les instances (je
suppose quelques heritages simples dans le tas). Ces pointeurs
necessitent des ajustements d'offsets dans l'instance a chaque
fois que l'on utilise l'instance a travers une de ses
interfaces (ce qui est le but pour la flexibilite), et ce qui
demande de generer du code et des calculs en plus.
De plus il faut utiliser au maximum les retours contravariant
pour garder un maximum de visibilite statique,
Enfin, en theorie, il faudrait deriver virtuellement *par
defaut* pour un design flexible sans "bombe a retardement",
mais cela rajoute encore des pointeurs des des ajustements
d'offset. Au final tous ces calculs intermediaires
ralentissent la resolution des appels virtuels de facon non
negligeable. Mes mesures sur gcc 4.2 montrent que par rapport
a un appel virtuel avec heritage simple, l'heritage multiple
de 4 interfaces ralentit d'un facteur ±2 l'appel, et
l'heritage virtuel d'un facteur ±4. Soit ±8 au total si on
mixe les deux, ce qui serait l'approche correcte. Je ne pense
pas que les autres compilateur font mieux et je trouve deja
pas mal compte tenu de tout ce que le compilateur doit
generer.
La faute au "vrai" heritage multiple.
Maintenant de mon point de vue, qui n'engage que moi, je
trouverais beaucoup plus utile une implementation tres
efficace des interfaces a- la-Java en C++ (space & time) a la
place de l'heritage multiple rarement utile et facilement
simulable quand on a vraiment besoin.
