c'est le default du switch. Par ailleurs toutes les valeurs de errno
forment partie du standard POSIX, donc c'est assez peu sujet à
changement. Sinon c'est "erreur inconnue".
c'est le default du switch. Par ailleurs toutes les valeurs de errno
forment partie du standard POSIX, donc c'est assez peu sujet à
changement. Sinon c'est "erreur inconnue".
c'est le default du switch. Par ailleurs toutes les valeurs de errno
forment partie du standard POSIX, donc c'est assez peu sujet à
changement. Sinon c'est "erreur inconnue".
Tu sais, ce serait beaucoup mieux si tu citais le contribruiteur à
qui tu réponds.
Son nom, tu veux dire ?
Tu sais, ce serait beaucoup mieux si tu citais le contribruiteur à
qui tu réponds.
Son nom, tu veux dire ?
Tu sais, ce serait beaucoup mieux si tu citais le contribruiteur à
qui tu réponds.
Son nom, tu veux dire ?
On 22 juin, 17:35, "Mihamina Rakotomandimby (R12y)"
wrote:
> On Mon, 20 Jun 2011 22:42:16 +0200, Aéris wrote:
> > Il y en a surtout une qui avantage énormément les GC : les mecs d e chez
> > Sun, Oracle ou IBM sont bien plus compétents que nous pour savoir
> > comment gérer (proprement si possible) la mémoire.
> Et merde, tu viens de baisser le niveau de l'équipe qui est ici.
> Prends le temps de faire des recherches sur tes correspondants.
> C'est pratique quand on poste avec son vrai nom. Pas comme toi.
Comprendre le « nous » au sens « le commun des développeurs ».
J'ai jamais dis qu'il n'y avait pas d'exception à la règle, mais une
discussion est centrée autour du « développeur moyen », pas « d e la
dreamteam de dev »
On 22 juin, 17:35, "Mihamina Rakotomandimby (R12y)"
<miham...@rktmb.org> wrote:
> On Mon, 20 Jun 2011 22:42:16 +0200, Aéris wrote:
> > Il y en a surtout une qui avantage énormément les GC : les mecs d e chez
> > Sun, Oracle ou IBM sont bien plus compétents que nous pour savoir
> > comment gérer (proprement si possible) la mémoire.
> Et merde, tu viens de baisser le niveau de l'équipe qui est ici.
> Prends le temps de faire des recherches sur tes correspondants.
> C'est pratique quand on poste avec son vrai nom. Pas comme toi.
Comprendre le « nous » au sens « le commun des développeurs ».
J'ai jamais dis qu'il n'y avait pas d'exception à la règle, mais une
discussion est centrée autour du « développeur moyen », pas « d e la
dreamteam de dev »
On 22 juin, 17:35, "Mihamina Rakotomandimby (R12y)"
wrote:
> On Mon, 20 Jun 2011 22:42:16 +0200, Aéris wrote:
> > Il y en a surtout une qui avantage énormément les GC : les mecs d e chez
> > Sun, Oracle ou IBM sont bien plus compétents que nous pour savoir
> > comment gérer (proprement si possible) la mémoire.
> Et merde, tu viens de baisser le niveau de l'équipe qui est ici.
> Prends le temps de faire des recherches sur tes correspondants.
> C'est pratique quand on poste avec son vrai nom. Pas comme toi.
Comprendre le « nous » au sens « le commun des développeurs ».
J'ai jamais dis qu'il n'y avait pas d'exception à la règle, mais une
discussion est centrée autour du « développeur moyen », pas « d e la
dreamteam de dev »
On 22 juin, 17:35, "Mihamina Rakotomandimby (R12y)"
wrote:
> On Mon, 20 Jun 2011 22:42:16 +0200, Aéris wrote:
> > Il y en a surtout une qui avantage énormément les GC : les mecs de chez
> > Sun, Oracle ou IBM sont bien plus compétents que nous pour savoir
> > comment gérer (proprement si possible) la mémoire.
>
> Et merde, tu viens de baisser le niveau de l'équipe qui est ici.
> Prends le temps de faire des recherches sur tes correspondants.
> C'est pratique quand on poste avec son vrai nom. Pas comme toi.
J'ajouterais que même si je ne vous connais pas particulièrement ni
vos niveaux de compétence, quelque soit mon niveau, je n'oserais
jamais prétendre être meilleurs que IBM, Oracle ou Sun...
On 22 juin, 17:35, "Mihamina Rakotomandimby (R12y)"
<miham...@rktmb.org> wrote:
> On Mon, 20 Jun 2011 22:42:16 +0200, Aéris wrote:
> > Il y en a surtout une qui avantage énormément les GC : les mecs de chez
> > Sun, Oracle ou IBM sont bien plus compétents que nous pour savoir
> > comment gérer (proprement si possible) la mémoire.
>
> Et merde, tu viens de baisser le niveau de l'équipe qui est ici.
> Prends le temps de faire des recherches sur tes correspondants.
> C'est pratique quand on poste avec son vrai nom. Pas comme toi.
J'ajouterais que même si je ne vous connais pas particulièrement ni
vos niveaux de compétence, quelque soit mon niveau, je n'oserais
jamais prétendre être meilleurs que IBM, Oracle ou Sun...
On 22 juin, 17:35, "Mihamina Rakotomandimby (R12y)"
wrote:
> On Mon, 20 Jun 2011 22:42:16 +0200, Aéris wrote:
> > Il y en a surtout une qui avantage énormément les GC : les mecs de chez
> > Sun, Oracle ou IBM sont bien plus compétents que nous pour savoir
> > comment gérer (proprement si possible) la mémoire.
>
> Et merde, tu viens de baisser le niveau de l'équipe qui est ici.
> Prends le temps de faire des recherches sur tes correspondants.
> C'est pratique quand on poste avec son vrai nom. Pas comme toi.
J'ajouterais que même si je ne vous connais pas particulièrement ni
vos niveaux de compétence, quelque soit mon niveau, je n'oserais
jamais prétendre être meilleurs que IBM, Oracle ou Sun...
On 22 juin, 17:19, Toxico Nimbus wrote:
> > Qui, en faisant l'hypoth se que le d veloppeur est mauvais, pue tr s
> > fortement.
> Moi je ne fais pas ce genre d'hypoth se, c'est assez st rile.
Je ne la fait pas non plus, je fais justement l'hypothèse que mon code
ne doit faire aucune hypothèse sur ce qui se trouve en dessous.
> Une API mal document e est rarement bien crite. Un dev qui b cle sa doc
> aura sons doute d j b cl ses comment , son code, sa conception.
Je parle du moment où tu es encore en développement et où tu intè gres
des morceaux de code d'autres développeurs de ton équipe.
Tu as rarement de la doc fiable à ce moment du projet, au mieux la
Javadoc dans le code.
> 1. Ce qu'on attend d'elle ne peut se trouver ailleurs que dans la doc.
Dans la spécification oui, mais celle-ci n'est pas orientée technique
ni développement.
Dans la doc finale, elle y sera sûrement, mais elle n'est souvent pas
disponible au moment où on en a besoin (en cours de dev).
> 2. Je ne vois pas ce qu'est un cas hors limite, part peut- tre une
> m thode/classe utilis e en dehors de son domaine de validit ?
Voila.
Dans le domaine sécuritaire, même si l'utilisateur saisie n'importe
quoi, le soft ne doit pas faire n'importe quoi et se comporter
correctement.
Dans l'exemple de la fraiseuse, même si l'utilisateur saisit « toto »
ou « -1 » en vitesse de rotation, le soft doit arrêter l'avance de
coupe dès que le moteur de rotation s'arrête (certes le contrôle de s
données sera fait avant, mais cela est un exemple). Si tu as un bug
dans ton code, tu pourrais très bien envoyé -1 au moteur de commande,
qui va te bouffer une grosse « exception » ou un code d'erreur. S i
cette « exception » n'a pas été vue (uniquement possible en C et pas
en Java), ta machine va continuer à exécuter son programme, au lieu d e
partir en arrêt d'urgence pour couper tous les moteurs. Et tu vas
usiner moteur de coupe arrêté
> Gn ? Tu sors ta boule de cristal, ou tu d cide la place du concepteur
> ce que doit faire telle ou telle fonction ?
La doc me sert à savoir ce qu'elle fait dans le cas nominal.
Pour la gestion des cas hors limite, je ne me fie qu'à moi-même et ne
fait aucune hypothèse : si la fonction lève une exception, je la
traite, même si je ne comprend pas (encore) ce qu'elle fait. Question
de sécurité. Le développeur a très bien pu oublier de mettre sa d oc ou
javadoc à jour.
> > Je ne sais peut- tre pas quoi en faire, mais je sais au moins prot ge r
> > mon programme contre elle.
> Pas forc ment si tu ne sais pas dans quel tat est le syst me quand elle
> est lev e. Il n'y a que le concepteur qui peut te le dire, ou alors il
> faut relire les sources de ta lib.
J'ai au moins la possibilité de partir en mode « alerte rouge » .
Et je suis au moins averti qu'il manque un truc dans la doc et je peux
faire le nécessaire pour me renseigné.
Le but est d'au moins être averti du problème au plus tôt, alors qu e
l'erreur va sûrement passer aux oubliettes en C, faute de détection.
On 22 juin, 17:19, Toxico Nimbus <T...@free.fr> wrote:
> > Qui, en faisant l'hypoth se que le d veloppeur est mauvais, pue tr s
> > fortement.
> Moi je ne fais pas ce genre d'hypoth se, c'est assez st rile.
Je ne la fait pas non plus, je fais justement l'hypothèse que mon code
ne doit faire aucune hypothèse sur ce qui se trouve en dessous.
> Une API mal document e est rarement bien crite. Un dev qui b cle sa doc
> aura sons doute d j b cl ses comment , son code, sa conception.
Je parle du moment où tu es encore en développement et où tu intè gres
des morceaux de code d'autres développeurs de ton équipe.
Tu as rarement de la doc fiable à ce moment du projet, au mieux la
Javadoc dans le code.
> 1. Ce qu'on attend d'elle ne peut se trouver ailleurs que dans la doc.
Dans la spécification oui, mais celle-ci n'est pas orientée technique
ni développement.
Dans la doc finale, elle y sera sûrement, mais elle n'est souvent pas
disponible au moment où on en a besoin (en cours de dev).
> 2. Je ne vois pas ce qu'est un cas hors limite, part peut- tre une
> m thode/classe utilis e en dehors de son domaine de validit ?
Voila.
Dans le domaine sécuritaire, même si l'utilisateur saisie n'importe
quoi, le soft ne doit pas faire n'importe quoi et se comporter
correctement.
Dans l'exemple de la fraiseuse, même si l'utilisateur saisit « toto »
ou « -1 » en vitesse de rotation, le soft doit arrêter l'avance de
coupe dès que le moteur de rotation s'arrête (certes le contrôle de s
données sera fait avant, mais cela est un exemple). Si tu as un bug
dans ton code, tu pourrais très bien envoyé -1 au moteur de commande,
qui va te bouffer une grosse « exception » ou un code d'erreur. S i
cette « exception » n'a pas été vue (uniquement possible en C et pas
en Java), ta machine va continuer à exécuter son programme, au lieu d e
partir en arrêt d'urgence pour couper tous les moteurs. Et tu vas
usiner moteur de coupe arrêté
> Gn ? Tu sors ta boule de cristal, ou tu d cide la place du concepteur
> ce que doit faire telle ou telle fonction ?
La doc me sert à savoir ce qu'elle fait dans le cas nominal.
Pour la gestion des cas hors limite, je ne me fie qu'à moi-même et ne
fait aucune hypothèse : si la fonction lève une exception, je la
traite, même si je ne comprend pas (encore) ce qu'elle fait. Question
de sécurité. Le développeur a très bien pu oublier de mettre sa d oc ou
javadoc à jour.
> > Je ne sais peut- tre pas quoi en faire, mais je sais au moins prot ge r
> > mon programme contre elle.
> Pas forc ment si tu ne sais pas dans quel tat est le syst me quand elle
> est lev e. Il n'y a que le concepteur qui peut te le dire, ou alors il
> faut relire les sources de ta lib.
J'ai au moins la possibilité de partir en mode « alerte rouge » .
Et je suis au moins averti qu'il manque un truc dans la doc et je peux
faire le nécessaire pour me renseigné.
Le but est d'au moins être averti du problème au plus tôt, alors qu e
l'erreur va sûrement passer aux oubliettes en C, faute de détection.
On 22 juin, 17:19, Toxico Nimbus wrote:
> > Qui, en faisant l'hypoth se que le d veloppeur est mauvais, pue tr s
> > fortement.
> Moi je ne fais pas ce genre d'hypoth se, c'est assez st rile.
Je ne la fait pas non plus, je fais justement l'hypothèse que mon code
ne doit faire aucune hypothèse sur ce qui se trouve en dessous.
> Une API mal document e est rarement bien crite. Un dev qui b cle sa doc
> aura sons doute d j b cl ses comment , son code, sa conception.
Je parle du moment où tu es encore en développement et où tu intè gres
des morceaux de code d'autres développeurs de ton équipe.
Tu as rarement de la doc fiable à ce moment du projet, au mieux la
Javadoc dans le code.
> 1. Ce qu'on attend d'elle ne peut se trouver ailleurs que dans la doc.
Dans la spécification oui, mais celle-ci n'est pas orientée technique
ni développement.
Dans la doc finale, elle y sera sûrement, mais elle n'est souvent pas
disponible au moment où on en a besoin (en cours de dev).
> 2. Je ne vois pas ce qu'est un cas hors limite, part peut- tre une
> m thode/classe utilis e en dehors de son domaine de validit ?
Voila.
Dans le domaine sécuritaire, même si l'utilisateur saisie n'importe
quoi, le soft ne doit pas faire n'importe quoi et se comporter
correctement.
Dans l'exemple de la fraiseuse, même si l'utilisateur saisit « toto »
ou « -1 » en vitesse de rotation, le soft doit arrêter l'avance de
coupe dès que le moteur de rotation s'arrête (certes le contrôle de s
données sera fait avant, mais cela est un exemple). Si tu as un bug
dans ton code, tu pourrais très bien envoyé -1 au moteur de commande,
qui va te bouffer une grosse « exception » ou un code d'erreur. S i
cette « exception » n'a pas été vue (uniquement possible en C et pas
en Java), ta machine va continuer à exécuter son programme, au lieu d e
partir en arrêt d'urgence pour couper tous les moteurs. Et tu vas
usiner moteur de coupe arrêté
> Gn ? Tu sors ta boule de cristal, ou tu d cide la place du concepteur
> ce que doit faire telle ou telle fonction ?
La doc me sert à savoir ce qu'elle fait dans le cas nominal.
Pour la gestion des cas hors limite, je ne me fie qu'à moi-même et ne
fait aucune hypothèse : si la fonction lève une exception, je la
traite, même si je ne comprend pas (encore) ce qu'elle fait. Question
de sécurité. Le développeur a très bien pu oublier de mettre sa d oc ou
javadoc à jour.
> > Je ne sais peut- tre pas quoi en faire, mais je sais au moins prot ge r
> > mon programme contre elle.
> Pas forc ment si tu ne sais pas dans quel tat est le syst me quand elle
> est lev e. Il n'y a que le concepteur qui peut te le dire, ou alors il
> faut relire les sources de ta lib.
J'ai au moins la possibilité de partir en mode « alerte rouge » .
Et je suis au moins averti qu'il manque un truc dans la doc et je peux
faire le nécessaire pour me renseigné.
Le but est d'au moins être averti du problème au plus tôt, alors qu e
l'erreur va sûrement passer aux oubliettes en C, faute de détection.
Dans le même ordre d'idée il y a le typage automatique et
dynamique des variables, comme en python, et qui n'existe pas en Java,
ce pour quoi je pense que Java est un langage considérablement
inférieur
Dans le même ordre d'idée il y a le typage automatique et
dynamique des variables, comme en python, et qui n'existe pas en Java,
ce pour quoi je pense que Java est un langage considérablement
inférieur
Dans le même ordre d'idée il y a le typage automatique et
dynamique des variables, comme en python, et qui n'existe pas en Java,
ce pour quoi je pense que Java est un langage considérablement
inférieur
>> Cette pratique antédiluvienne consistant à obliger le
>> lecteur à se taper un fil interminable pour suivre la conversation
>> est vraiment d'un autre âge.
>
> ?
> Je ne vois pas bien le rapport avec la première demande. Parce que
> c'est difficile de voir à quel message ma réponse est rattachée ?
Honnêtement ? Oui, parce que tu ne coupes que ce qui
t'intéresse histoire de dénaturer les propros.
>> Cette pratique antédiluvienne consistant à obliger le
>> lecteur à se taper un fil interminable pour suivre la conversation
>> est vraiment d'un autre âge.
>
> ?
> Je ne vois pas bien le rapport avec la première demande. Parce que
> c'est difficile de voir à quel message ma réponse est rattachée ?
Honnêtement ? Oui, parce que tu ne coupes que ce qui
t'intéresse histoire de dénaturer les propros.
>> Cette pratique antédiluvienne consistant à obliger le
>> lecteur à se taper un fil interminable pour suivre la conversation
>> est vraiment d'un autre âge.
>
> ?
> Je ne vois pas bien le rapport avec la première demande. Parce que
> c'est difficile de voir à quel message ma réponse est rattachée ?
Honnêtement ? Oui, parce que tu ne coupes que ce qui
t'intéresse histoire de dénaturer les propros.
Rassure-toi, tu n'es pas le seul !-)
Rassure-toi, tu n'es pas le seul !-)
Rassure-toi, tu n'es pas le seul !-)
Ya pas de "ccommun des développeurs" en C : il n'y a que des bons.
Ya pas de "ccommun des développeurs" en C : il n'y a que des bons.
Ya pas de "ccommun des développeurs" en C : il n'y a que des bons.
Ya pas de "ccommun des développeurs" en C : il n'y a que des bons.
Ya pas de "ccommun des développeurs" en C : il n'y a que des bons.
Ya pas de "ccommun des développeurs" en C : il n'y a que des bons.