Supprimer "private"

On Mon, 19 Sep 2005 11:50:10 +0200, Bertrand Lenoir-Welter
<bertrand.2004@galaad.net>:

Vous codez souvent deux fonctions de même label dont une est privée et
l'autre publique ?

Volontairement : des constructeurs.



Involontairement : des fonctions au nom bateau, dans des classes un
peu "riches".



Malgré moi : avec les jolis #define de l'API Win32 par exemple.

#include <windows.h>

class C
{
public:
void SetForm (double);

private:
void SetFormA (int);
};

int main()
{
C c;
c.SetForm (42); // Error: 'C::SetFormA(int)' is not accessible
}

Bertrand Lenoir-Welter <bertrand.2004@galaad.net> a écrit :

Marc Boyer :

Tu ne fais des erreurs d'inattention qu'après des nuits en boites
sans café après ? Heureux homme.

Oui mais, comme je suis modeste en plus d'être intelligent, je me dois
de préciser que je triche : tenez-vous bien, je n'appelle JAMAIS une
fonction "f" tout court. Ca vous épate, hein ?

De mes cours de génie log, j'ai retenu qu'une mission spaciale
(un satellite je crois) avait planté à cause d'un
FORI=1,4 // Déclaration d'une var 'FORI', intitialisée à 1,4
en lieu et place du
FOR I=1,4 // Début de boucle d'indice I allant de 1 à 4

Une partie de la leçon, c'est que l'erreur d'inattention stupide,
ça arrive aussi dans la vraie vie.
Et que tout ce que le compilateur peut vérifier, c'est ça de gagné.

Plus sérieusement, on a pas mal caricaturé ce que j'ai dit dans ce
thread - pardon ce troll.

C'est à dire que tu avais commencé fort: "Pour un développeur seul
sur un projet, je trouve leur intérêt limité sinon nul".

Si l'argumentaire consiste à trouver des
exemples bien tordus qui n'arrivent jamais en pratique ou dont on peut
se passer facilement et avec avantage, ou encore des cas d'écriture de
code qui vaudraient illico à leur auteur un avertissement avec mise à
pied, je concède tout en bloc et vous avez raison. Je n'ai jamais dit
qu'un private ne servait à rien dans le C++, mais seulement que je ne
m'en servais pas en projet solo

Non, ce n'est pas *exactement* ce que tu as dit, même si c'est
peut-être ce que tu pensais.

Ensuite, Gaby t'a montré un cas dont je ne dirais pas qu'il vaut
mise à pied illico.

Si, a contrario, nous sommes
entre gens d'expérience qui avons acquis quelques bonnes - ou mauvaises
- habitudes au cours d'années de pratique, je vous prie de concéder que
mon style d'écriture, s'il n'est pas dans le Dogme, ne me vaudra pas les
Assises pour autant, mais tout juste les gros yeux, et encore.

Les assises surement pas. Après, tout dépend de pour qui tu codes.
Formellement, je pense qu'on peut accuser de faute professionnelle le
fait de refuser de mettre les public/private si c'est ce qui est
exigé par le responsable hiérarchique. Dans la pratique...

Marc Boyer
--
À vélo, prendre une rue à contre-sens est moins dangeureux
que prendre un boulevard dans le sens légal. À qui la faute ?

Marc Boyer :

De mes cours de génie log, j'ai retenu qu'une mission spaciale
(un satellite je crois) avait planté à cause d'un
FORI=1,4 // Déclaration d'une var 'FORI', intitialisée à 1,4
en lieu et place du
FOR I=1,4 // Début de boucle d'indice I allant de 1 à 4

Certes. Il y a eu aussi Mars Orbiter en 1997 où l'équipe de
développement basée en Angleterre et chargée de l'injection
intraorbitale de la sonde croyait que la NASA travaillait au système
impérial et non au système métrique. 720 M$ convertis en chaleur et en
lumière, et un chef de (gros) projet remercié. Même à ce niveau, ça
reste des hommes...

Tout ça me conforte dans l'idée qu'il faut faire attention aux labels
d'identificateurs trop peu explicites. Au demeurant, votre exemple ne
s'applique pas au C.

Une partie de la leçon, c'est que l'erreur d'inattention stupide,
ça arrive aussi dans la vraie vie.
Et que tout ce que le compilateur peut vérifier, c'est ça de gagné.

Ok, vous avez gagné. Je me permets quand même de signaler qu'en 13 ans
de C++, j'ai eu des tas de bugs, y compris du compilo, mais jamais ce
genre de truc. Donc, quand je code en solo, c'est pour tout public.

C'est à dire que tu avais commencé fort: "Pour un développeur seul
sur un projet, je trouve leur intérêt limité sinon nul".

Je maintiens. Mais j'accepte d'ajouter "sauf dans des cas grotesques"
rien que pour vous faire plaisir. Ca vous fait plaisir, au moins ?

Non, ce n'est pas *exactement* ce que tu as dit, même si c'est
peut-être ce que tu pensais.

Une mouche vient de prendre le vent par l'arrière...

Ensuite, Gaby t'a montré un cas dont je ne dirais pas qu'il vaut
mise à pied illico.

Gaby m'a montré un cas que je n'utiliserai jamais, tout simplement parce
que je le trouve limite caricatural pour le genre d'appli dont je me
contente depuis 20 ans. Je lui donnerai peut-être raison avant ma
retraite, si Dieu me prête vie.

Les assises surement pas. Après, tout dépend de pour qui tu codes.

Pour mes clients. Lesquels se fichent un peu de savoir si mes fonctions
sont toutes publiques ou en partie privées, et plus généralement avec
quoi et comment je code, du moment que ça marche bien chez eux.

Si j'étais prof de C++, certes je m'engueulerais. Mais je suis pas prof
de C++ (comme vous l'aviez deviné, j'en suis presque sûr).

Formellement, je pense qu'on peut accuser de faute professionnelle le
fait de refuser de mettre les public/private si c'est ce qui est
exigé par le responsable hiérarchique. Dans la pratique...

Je suis d'accord. Mais le responsable hiérarchique, c'est moi. Je code
en solo (bis repetita) et ai dit dès le début que je ne ferais pas
pareil si je travaillais en équipe.

Il faut dire que je suis un peu schizophrène et moi aussi.

Bertrand Lenoir-Welter <bertrand.2004@galaad.net> writes:

[...]

| > Ensuite, Gaby t'a montré un cas dont je ne dirais pas qu'il vaut
| > mise à pied illico.
|
| Gaby m'a montré un cas que je n'utiliserai jamais, tout simplement
| parce que je le trouve limite caricatural

Caricatural comme dans std::ios_base, std::fstream, etc.?

| pour le genre d'appli dont
| je me contente depuis 20 ans. Je lui donnerai peut-être raison avant
| ma retraite, si Dieu me prête vie.

Je ne te demande pas de me donner raison. Tu as sufffisamment montré
la hauteur de ton arrogance et la profondeur de ton ignorance pour que
je puisse me passer de ta magnanimité. Merci beaucoup.

-- Gaby

Gabriel Dos Reis <gdr@integrable-solutions.net> writes:

Bertrand Lenoir-Welter <bertrand.2004@galaad.net> writes:

[...]

| > Ensuite, Gaby t'a montré un cas dont je ne dirais pas qu'il vaut
| > mise à pied illico.
|
| Gaby m'a montré un cas que je n'utiliserai jamais, tout simplement
| parce que je le trouve limite caricatural

Caricatural comme dans std::ios_base, std::fstream, etc.?

| pour le genre d'appli dont
| je me contente depuis 20 ans. Je lui donnerai peut-être raison avant
| ma retraite, si Dieu me prête vie.

Je ne te demande pas de me donner raison. Tu as sufffisamment montré
la hauteur de ton arrogance et la profondeur de ton ignorance pour que
je puisse me passer de ta magnanimité. Merci beaucoup.

C'est simplement un tres bon troll, lire fr.comp.algorithmes le
prouve. Fabien n'est pas mal, mais on voit mieux que c'est un role.

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

"Jean-Marc Bourguet" <jm@bourguet.org> a écrit dans le message de news:
pxbhdch2o2w.fsf@news.bourguet.org...

C'est simplement un tres bon troll, lire fr.comp.algorithmes le
prouve. Fabien n'est pas mal, mais on voit mieux que c'est un role.

je prone

qu'un rôle
dans un troll
c'est pas drôle.

--
-Stan

Bertrand Lenoir-Welter <bertrand.2004@galaad.net> a écrit :

Marc Boyer :
[SNIP FORI]

Au demeurant, votre exemple ne s'applique pas au C.

Oui. Je n'ai pas connaissance d'un exemple C/C++ dans
lequel une erreur de typage ait fait sauter un gros projet.

Une partie de la leçon, c'est que l'erreur d'inattention stupide,
ça arrive aussi dans la vraie vie.
Et que tout ce que le compilateur peut vérifier, c'est ça de gagné.

Ok, vous avez gagné. Je me permets quand même de signaler qu'en 13 ans
de C++, j'ai eu des tas de bugs, y compris du compilo, mais jamais ce
genre de truc.

Quel "genre de truc" ? Jamais d'erreur d'inattention que le
compilo a détecté ? Moi, pleins avant de mettre -Wall -pedantic -W.

Donc, quand je code en solo, c'est pour tout public.

Pas compris le sens de cette phrase.

C'est à dire que tu avais commencé fort: "Pour un développeur seul
sur un projet, je trouve leur intérêt limité sinon nul".

Je maintiens. Mais j'accepte d'ajouter "sauf dans des cas grotesques"
rien que pour vous faire plaisir. Ca vous fait plaisir, au moins ?

Non.

Ensuite, Gaby t'a montré un cas dont je ne dirais pas qu'il vaut
mise à pied illico.

Gaby m'a montré un cas que je n'utiliserai jamais, tout simplement parce
que je le trouve limite caricatural pour le genre d'appli dont je me
contente depuis 20 ans. Je lui donnerai peut-être raison avant ma
retraite, si Dieu me prête vie.

Les assises surement pas. Après, tout dépend de pour qui tu codes.

Pour mes clients. Lesquels se fichent un peu de savoir si mes fonctions
sont toutes publiques ou en partie privées, et plus généralement avec
quoi et comment je code, du moment que ça marche bien chez eux.

Tout à fait.

Si j'étais prof de C++, certes je m'engueulerais. Mais je suis pas prof
de C++ (comme vous l'aviez deviné, j'en suis presque sûr).

Oui, tu es bien trop compétent.

Marc Boyer
--
À vélo, prendre une rue à contre-sens est moins dangeureux
que prendre un boulevard dans le sens légal. À qui la faute ?

Gabriel Dos Reis :

Caricatural comme dans std::ios_base, std::fstream, etc.?

Hé bé, faut tout bien peser avant d'envoyer, par ici...

Ai-je dit que c'était un cas impossible ? Non.
Est-ce pour autant un cas courant ? Non.
Est-ce un cas auquel je pourrais un jour me frotter ? Non.
Ai-je recommandé de NE PAS utiliser les private ? Non.
Avez-vous compris pourquoi je mets tout public ? Visiblement non.

Etes-vous du genre tolérant dans ce groupe ? Je vous laisse la réponse :

Je ne te demande pas de me donner raison. Tu as sufffisamment montré
la hauteur de ton arrogance et la profondeur de ton ignorance pour que
je puisse me passer de ta magnanimité. Merci beaucoup.

Bertrand Lenoir-Welter <bertrand.2004@galaad.net> writes:

| Gabriel Dos Reis :
|
| > Caricatural comme dans std::ios_base, std::fstream, etc.?
|
| Hé bé, faut tout bien peser avant d'envoyer, par ici...
|
| Ai-je dit que c'était un cas impossible ? Non.

Quelqu'un a dit « impossible » ? Non.

| Est-ce pour autant un cas courant ? Non.

c'est une construction idiomatique en C++. Si tu ne le savais pas,
maintenant tu le sais.

| Est-ce un cas auquel je pourrais un jour me frotter ? Non.

Je ne doute pas une seconde que dans tes applications tu ne t'en
serves pas. Mais, cela n'est fait pas moins une construction
idiomatique, documentée depuis des décennies.

| Ai-je recommandé de NE PAS utiliser les private ? Non.

Où est le rapport ?

| Avez-vous compris pourquoi je mets tout public ? Visiblement non.

tu fais ce que tu veux dans ton code, tu dois être majeur et vacciné.


-- Gaby

Marc Boyer wrote:

Marc Boyer :

Tu ne fais des erreurs d'inattention qu'après des nuits
en boites sans café après ? Heureux homme.

Oui mais, comme je suis modeste en plus d'être intelligent,
je me dois de préciser que je triche : tenez-vous bien, je
n'appelle JAMAIS une fonction "f" tout court. Ca vous épate,
hein ?

De mes cours de génie log, j'ai retenu qu'une mission
spaciale (un satellite je crois) avait planté à cause d'un
FORI=1,4 // Déclaration d'une var 'FORI', intitialisée à 1,4
en lieu et place du
FOR I=1,4 // Début de boucle d'indice I allant de 1 à 4

En quel langage ? (Je ne connais pas de langage de programmation
qui accept 1,4 comme valeur numérique.)

Ce que j'ai connu, c'est quelqu'un qui avait écrit en Fortran :
DO I = 1. 10
à la place de :
DO I = 1, 10
Parce que que blancs en Fortran n'ont aucune signification, le
premier a été interprété comme :
DOI = 1.10
-- une affectation, et non la tête d'une boucle.

Un autre problème que j'ai vu plusieurs fois dans le Fortran,
c'est qu'on insère du texte quelque part dans la ligne, en
faisant passer la fin de la ligne au delà du colonne 72 --
Fortran ignore tout ce qui se trouve au delà du colonne 72. Note
bien aussi que c'est très facile que le résultat soit encore
légal. Fortran n'exige pas la déclaration des variables non
plus, donc, si le nom d'une variable se trouve ainsi tronqué, tu
as simplement une nouvelle variable (que tu n'as pas
initialisée).

Une partie de la leçon, c'est que l'erreur d'inattention
stupide, ça arrive aussi dans la vraie vie.

Il faut dire qu'il y a des langages qui s'y prêtent plus que
d'autres:-).

Et que tout ce que le compilateur peut vérifier, c'est ça de
gagné.

Tout à fait. J'ai lu quelque part que le coût de rétrouver une
erreur se multiplie par dix à chaque étape qu'elle passe
inaperçue. C-à-d qu'une erreur trouvait dans les tests unitaires
coûte dix fois plus cher qu'une trouvait par le compilateur, une
trouvait lors de l'integration coûte dix fois plus cher qu'une
trouvée dans les tests unitaires, et une qui n'apparaît que dans
les betas coûte dix fois plus cher que si on l'avait trouvé dans
l'integration.

J'imagine que le chiffre n'est pas exactement dix dans tous les
cas. Mais le principe de base y est.

Plus sérieusement, on a pas mal caricaturé ce que j'ai dit
dans ce thread - pardon ce troll.

C'est à dire que tu avais commencé fort: "Pour un
développeur seul sur un projet, je trouve leur intérêt limité
sinon nul".

Si l'argumentaire consiste à trouver des exemples bien
tordus qui n'arrivent jamais en pratique ou dont on peut se
passer facilement et avec avantage, ou encore des cas
d'écriture de code qui vaudraient illico à leur auteur un
avertissement avec mise à pied, je concède tout en bloc et
vous avez raison. Je n'ai jamais dit qu'un private ne
servait à rien dans le C++, mais seulement que je ne m'en
servais pas en projet solo

Non, ce n'est pas *exactement* ce que tu as dit, même si
c'est peut-être ce que tu pensais.

Ensuite, Gaby t'a montré un cas dont je ne dirais pas qu'il
vaut mise à pied illico.

Si, a contrario, nous sommes entre gens d'expérience qui
avons acquis quelques bonnes - ou mauvaises

- habitudes au cours d'années de pratique, je vous prie de
concéder que mon style d'écriture, s'il n'est pas dans le
Dogme, ne me vaudra pas les Assises pour autant, mais tout
juste les gros yeux, et encore.

Les assises surement pas.

Ça dépend. Je crois bien qu'il y a un concepte de « négligence
criminelle » dans la jurisprudence française. S'il y a des
dégats à cause d'une erreur dans ton code, et que tu n'as pas
suivi les « règles de l'art », je crois que tu pourrais bien te
rétrouver aux assises. Et l'utilisation de « private » fait bien
partie des « règles de l'art » du C++.

Après, tout dépend de pour qui tu codes. Formellement, je
pense qu'on peut accuser de faute professionnelle le fait de
refuser de mettre les public/private si c'est ce qui est exigé
par le responsable hiérarchique. Dans la pratique...

Dans la pratique, je n'ai jamais entendu parler que quelqu'un
(un individu) qui a été inquiété à cause d'une erreur dans un
programme. Même des erreurs des plus grossières.

En ce qui concerne la législation de travail, je crois que le
réfus de suivre une consigne du responsable hiérarchique (sans
motif valable) peut être assimilé à une faute professionnelle
grave, donnant lieu à une licenciement sans préavis. Reste que
pour le faire valoir, l'hièrarchie doit pouvoir prouver et
l'existance de la consigne et ton réfus explicit de le suivre.

Mais on n'en est pas là, je crois. Même si je trouve l'assertion
initiale tellement ridicule qu'il ne valait même pas la peine
d'y répondre, l'auteur avait clairement dit qu'elle ne valait
que pour le code qu'on écrit pous soi-même. Quand on écirt du
code pour soi-même, pour le simple plaisir de coder, on a bien
droit de faire ce qu'on veut. Ce qui fait plaisir, en fin de
compte. Dans la mesure que je n'ai ni à maintenir ce code par la
suite, ni à me servir du programme qui en résulte, je n'ai rien
à dire.

--
James Kanze GABI Software
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