Non, c'est au makefile de te le dire, pas à l'éditeur de liens.
Va regarder pkgsrc.
Non, c'est au makefile de te le dire, pas à l'éditeur de liens.
Va regarder pkgsrc.
Non, c'est au makefile de te le dire, pas à l'éditeur de liens.
Va regarder pkgsrc.
Tous les projets n'ont pas les mêmes spécificités, c'est normal d'avoir des
pratiques différentes.
C'est bien l'esprit java que tu défends : on a un trou carré, et on fait à
toute force entrer tous les projets dans ce trou carré, même s'ils sont
naturellement ronds ou en forme d'étoile.
Tous les projets n'ont pas les mêmes spécificités, c'est normal d'avoir des
pratiques différentes.
C'est bien l'esprit java que tu défends : on a un trou carré, et on fait à
toute force entrer tous les projets dans ce trou carré, même s'ils sont
naturellement ronds ou en forme d'étoile.
Tous les projets n'ont pas les mêmes spécificités, c'est normal d'avoir des
pratiques différentes.
C'est bien l'esprit java que tu défends : on a un trou carré, et on fait à
toute force entrer tous les projets dans ce trou carré, même s'ils sont
naturellement ronds ou en forme d'étoile.
Si, tu le sais parfaitement. Les fonctions de la libc (et de la
plupart des bibliothèques) te renvoient une erreur et un code
d'erreur dans errno.
Tu sais donc parfaitement pourquoi ça a planté
lorsque tu peux avoir une ambiguité. On n'a vraiment pas dû
apprendre le C au même endroit...
Et alors ? La récupération peut être aussi bête que ne pas faire
planter le programme sur une erreur de segmentation.
Si, tu le sais parfaitement. Les fonctions de la libc (et de la
plupart des bibliothèques) te renvoient une erreur et un code
d'erreur dans errno.
Tu sais donc parfaitement pourquoi ça a planté
lorsque tu peux avoir une ambiguité. On n'a vraiment pas dû
apprendre le C au même endroit...
Et alors ? La récupération peut être aussi bête que ne pas faire
planter le programme sur une erreur de segmentation.
Si, tu le sais parfaitement. Les fonctions de la libc (et de la
plupart des bibliothèques) te renvoient une erreur et un code
d'erreur dans errno.
Tu sais donc parfaitement pourquoi ça a planté
lorsque tu peux avoir une ambiguité. On n'a vraiment pas dû
apprendre le C au même endroit...
Et alors ? La récupération peut être aussi bête que ne pas faire
planter le programme sur une erreur de segmentation.
Et donc, merci d'apporter encore un peu plus d'eau, cela revient
même à utiliser une hérésie comme Java à des endroit où d'autres
outils seraient largement plus efficaces (style calcul scientifique
avec Fortran). Merci de ton soutien.
Et donc, merci d'apporter encore un peu plus d'eau, cela revient
même à utiliser une hérésie comme Java à des endroit où d'autres
outils seraient largement plus efficaces (style calcul scientifique
avec Fortran). Merci de ton soutien.
Et donc, merci d'apporter encore un peu plus d'eau, cela revient
même à utiliser une hérésie comme Java à des endroit où d'autres
outils seraient largement plus efficaces (style calcul scientifique
avec Fortran). Merci de ton soutien.
... et le mauvais programmeur rajoutera un catch-all autour, en masquant non
seulement la condition d'erreur qu'il était censé traiter mais aussi les
autres conditions d'erreur qui peuvent survenir.
... et le mauvais programmeur rajoutera un catch-all autour, en masquant non
seulement la condition d'erreur qu'il était censé traiter mais aussi les
autres conditions d'erreur qui peuvent survenir.
... et le mauvais programmeur rajoutera un catch-all autour, en masquant non
seulement la condition d'erreur qu'il était censé traiter mais aussi les
autres conditions d'erreur qui peuvent survenir.
Le 18/06/2011 18:25, JKB a écrit :Si, tu le sais parfaitement. Les fonctions de la libc (et de la
plupart des bibliothèques) te renvoient une erreur et un code
d'erreur dans errno.
Donc je vais blinder mon code de errno (théoriquement 1 ligne sur 2)
pour ensuite le farcir de if ( error == MaLib.SEG_FAULT ) … else if (
error == MaLib.FOO_ERROR ) ?
Pire encore, ma propre fonction va devoir propager cette erreur à
l'appelant, donc aussi devoir gérer errno, la valeur de retour, avec
encore plus de if/else et de return partout, et l'appelant devrait aussi
faire un if -1, un appel à errno, une platré de if/else pour se
rattraper et une platré de gestion de errno en cas de non récupération
pour ensuite propager à l'appellant qui devra…………
T'appelles ça du code propre toi ?
Tu sais donc parfaitement pourquoi ça a planté
lorsque tu peux avoir une ambiguité. On n'a vraiment pas dû
apprendre le C au même endroit...
Euh pas exactement au même endroit je pense =)
Mais on a donc bien vu les mêmes codes tout bloated de gestion et de
propagation d'erreurs avec des chiés de #define dans les .h, des platrés
de if/elif, de return dans tous les coins, de tricks à la con pour
pouvoir à la fois faire un return « métier » et un return « erreur »
(ben oui, si ma méthode devait déjà retourner quelque chose, je fais
comment pour retourner -1 ou le code d'erreur ?)
Et alors ? La récupération peut être aussi bête que ne pas faire
planter le programme sur une erreur de segmentation.
Utilité ?
« Votre programme a planté. Mais ceci n'est pas un segfault »
Je préfère de loin le « Segmentation fault : null pointer dereference in
toto.so:38 », au moins j'ai de quoi tracker l'erreur…
Le 18/06/2011 18:25, JKB a écrit :
Si, tu le sais parfaitement. Les fonctions de la libc (et de la
plupart des bibliothèques) te renvoient une erreur et un code
d'erreur dans errno.
Donc je vais blinder mon code de errno (théoriquement 1 ligne sur 2)
pour ensuite le farcir de if ( error == MaLib.SEG_FAULT ) … else if (
error == MaLib.FOO_ERROR ) ?
Pire encore, ma propre fonction va devoir propager cette erreur à
l'appelant, donc aussi devoir gérer errno, la valeur de retour, avec
encore plus de if/else et de return partout, et l'appelant devrait aussi
faire un if -1, un appel à errno, une platré de if/else pour se
rattraper et une platré de gestion de errno en cas de non récupération
pour ensuite propager à l'appellant qui devra…………
T'appelles ça du code propre toi ?
Tu sais donc parfaitement pourquoi ça a planté
lorsque tu peux avoir une ambiguité. On n'a vraiment pas dû
apprendre le C au même endroit...
Euh pas exactement au même endroit je pense =)
Mais on a donc bien vu les mêmes codes tout bloated de gestion et de
propagation d'erreurs avec des chiés de #define dans les .h, des platrés
de if/elif, de return dans tous les coins, de tricks à la con pour
pouvoir à la fois faire un return « métier » et un return « erreur »
(ben oui, si ma méthode devait déjà retourner quelque chose, je fais
comment pour retourner -1 ou le code d'erreur ?)
Et alors ? La récupération peut être aussi bête que ne pas faire
planter le programme sur une erreur de segmentation.
Utilité ?
« Votre programme a planté. Mais ceci n'est pas un segfault »
Je préfère de loin le « Segmentation fault : null pointer dereference in
toto.so:38 », au moins j'ai de quoi tracker l'erreur…
Le 18/06/2011 18:25, JKB a écrit :Si, tu le sais parfaitement. Les fonctions de la libc (et de la
plupart des bibliothèques) te renvoient une erreur et un code
d'erreur dans errno.
Donc je vais blinder mon code de errno (théoriquement 1 ligne sur 2)
pour ensuite le farcir de if ( error == MaLib.SEG_FAULT ) … else if (
error == MaLib.FOO_ERROR ) ?
Pire encore, ma propre fonction va devoir propager cette erreur à
l'appelant, donc aussi devoir gérer errno, la valeur de retour, avec
encore plus de if/else et de return partout, et l'appelant devrait aussi
faire un if -1, un appel à errno, une platré de if/else pour se
rattraper et une platré de gestion de errno en cas de non récupération
pour ensuite propager à l'appellant qui devra…………
T'appelles ça du code propre toi ?
Tu sais donc parfaitement pourquoi ça a planté
lorsque tu peux avoir une ambiguité. On n'a vraiment pas dû
apprendre le C au même endroit...
Euh pas exactement au même endroit je pense =)
Mais on a donc bien vu les mêmes codes tout bloated de gestion et de
propagation d'erreurs avec des chiés de #define dans les .h, des platrés
de if/elif, de return dans tous les coins, de tricks à la con pour
pouvoir à la fois faire un return « métier » et un return « erreur »
(ben oui, si ma méthode devait déjà retourner quelque chose, je fais
comment pour retourner -1 ou le code d'erreur ?)
Et alors ? La récupération peut être aussi bête que ne pas faire
planter le programme sur une erreur de segmentation.
Utilité ?
« Votre programme a planté. Mais ceci n'est pas un segfault »
Je préfère de loin le « Segmentation fault : null pointer dereference in
toto.so:38 », au moins j'ai de quoi tracker l'erreur…
Le 18/06/2011 18:33, Nicolas George a écrit :... et le mauvais programmeur rajoutera un catch-all autour, en masquant non
seulement la condition d'erreur qu'il était censé traiter mais aussi les
autres conditions d'erreur qui peuvent survenir.
Et le chef de projet ira lui taper dessus à la prochaine revue de code
ou la prochaine analyse de la couverture de code des tests U.
Le 18/06/2011 18:33, Nicolas George a écrit :
... et le mauvais programmeur rajoutera un catch-all autour, en masquant non
seulement la condition d'erreur qu'il était censé traiter mais aussi les
autres conditions d'erreur qui peuvent survenir.
Et le chef de projet ira lui taper dessus à la prochaine revue de code
ou la prochaine analyse de la couverture de code des tests U.
Le 18/06/2011 18:33, Nicolas George a écrit :... et le mauvais programmeur rajoutera un catch-all autour, en masquant non
seulement la condition d'erreur qu'il était censé traiter mais aussi les
autres conditions d'erreur qui peuvent survenir.
Et le chef de projet ira lui taper dessus à la prochaine revue de code
ou la prochaine analyse de la couverture de code des tests U.
Le 18/06/2011 18:27, JKB a écrit :Et donc, merci d'apporter encore un peu plus d'eau, cela revient
même à utiliser une hérésie comme Java à des endroit où d'autres
outils seraient largement plus efficaces (style calcul scientifique
avec Fortran). Merci de ton soutien.
La discussion n'est pas de savoir quel langage choisir en fonction du
contexte mais lequel permet de faire les choses plus proprement.
Certes je ne ferais pas un OS ou du temps réel en Java.
Mais je ne serais pas assez fou pour aller faire de la bdd
ou du web en
C/C⁺⁺ !
Le 18/06/2011 18:27, JKB a écrit :
Et donc, merci d'apporter encore un peu plus d'eau, cela revient
même à utiliser une hérésie comme Java à des endroit où d'autres
outils seraient largement plus efficaces (style calcul scientifique
avec Fortran). Merci de ton soutien.
La discussion n'est pas de savoir quel langage choisir en fonction du
contexte mais lequel permet de faire les choses plus proprement.
Certes je ne ferais pas un OS ou du temps réel en Java.
Mais je ne serais pas assez fou pour aller faire de la bdd
ou du web en
C/C⁺⁺ !
Le 18/06/2011 18:27, JKB a écrit :Et donc, merci d'apporter encore un peu plus d'eau, cela revient
même à utiliser une hérésie comme Java à des endroit où d'autres
outils seraient largement plus efficaces (style calcul scientifique
avec Fortran). Merci de ton soutien.
La discussion n'est pas de savoir quel langage choisir en fonction du
contexte mais lequel permet de faire les choses plus proprement.
Certes je ne ferais pas un OS ou du temps réel en Java.
Mais je ne serais pas assez fou pour aller faire de la bdd
ou du web en
C/C⁺⁺ !
Et le chef de projet ira lui taper dessus à la prochaine revue de code
ou la prochaine analyse de la couverture de code des tests U.
Et le chef de projet ira lui taper dessus à la prochaine revue de code
ou la prochaine analyse de la couverture de code des tests U.
Et le chef de projet ira lui taper dessus à la prochaine revue de code
ou la prochaine analyse de la couverture de code des tests U.
Globalement parlant, tous les projets ont globalement les mêmes besoins.
Intégrer des librairies et des dépendances, compiler, générer la sortie?
Mais globalement parlant, le moule est suffisamment générique et propre
pour être utilisé en l'état sur une énorme proportion de projets.
Personnellement, je n'ai encore jamais trouvé de justification valable
pour sortir du socle Maven, du n-tiers, du MVC ou de l'IoC.
Globalement parlant, tous les projets ont globalement les mêmes besoins.
Intégrer des librairies et des dépendances, compiler, générer la sortie?
Mais globalement parlant, le moule est suffisamment générique et propre
pour être utilisé en l'état sur une énorme proportion de projets.
Personnellement, je n'ai encore jamais trouvé de justification valable
pour sortir du socle Maven, du n-tiers, du MVC ou de l'IoC.
Globalement parlant, tous les projets ont globalement les mêmes besoins.
Intégrer des librairies et des dépendances, compiler, générer la sortie?
Mais globalement parlant, le moule est suffisamment générique et propre
pour être utilisé en l'état sur une énorme proportion de projets.
Personnellement, je n'ai encore jamais trouvé de justification valable
pour sortir du socle Maven, du n-tiers, du MVC ou de l'IoC.
