Bon, les gars, vous qui êtes linuxiens comme moi, est-il normal que je
n'arrive pas à dénicher de linuxien compétent depuis presque 6 mois ? Je
ne sais pas, il me semble que c'est la crise, tout ça, et qu'il devrait y
avoir des gens qui cherchent du boulot. Au lieu de quoi, je ne reçois que
des CV de "Java drones" (pour les développeurs) et "certification
MCSE" (pour les administrateurs). Comment se fait-ce?
Il y a deux/trois ans j'ai l'impression qu'il y avait plein monde et là,
pfuit....
--
The fact that a believer is happier than a sceptic is no more to the
point than the fact that a drunken man is happier than a sober one.
The happiness of credulity is a cheap and dangerous quality.
George Bernard Shaw
je n'ai jamais eu de fuite mémoire ,je mets régulièrement mes obj à null après utilisation,
C'est de la gestion de mémoire déguisée, ça. Tricheur!
JKB
Le 21-10-2009, ? propos de Re: De la difficulté à trouver? des linuxiens professionnels, remy ?crivait dans fr.comp.os.linux.debats :
JKB a écrit :
Le 21-10-2009, ? propos de Re: De la difficulté à trouver? des linuxiens professionnels, remy ?crivait dans fr.comp.os.linux.debats :
JKB a écrit :
Le 21-10-2009, ? propos de Re: De la difficulté à trouver? des linuxiens professionnels, Nicolas George ?crivait dans fr.comp.os.linux.debats :
JKB , dans le message , a écrit :
Ce qui est encore plus emmerdant, c'est que dans la plupart des formations, on apprend directement un truc comme Java, C++, C#, .NET parce que c'est à la mode sans passer par la case 'je maîtrise le C ou le Fortran, ou tout autre langage impératif ou fonctionnel évolué'.
le C est pratiquement aussi indispensable que le basic de mon enfance en dehors de la programmation système qui ne représente que 0,000001 % du code créé dans une boite cela ne sert à rien
On ne doit pas travailler dans le même genre de boîtes. Chez moi, c'est C, FORTRAN et langage maison.
tiens justement il faudrait que le noyau s'y mette un peu au c++ histoire de ne pas avoir à se trainer des interfaces à la con
Surtout pas, et il y a des raisons à ça. Écrire un noyau en C++, c'est se tirer une balle dans les pieds à brève échéance. Sur ce point, Linus a parfaitement raison. Et je ne vois pas en quoi le fait d'utiliser un langage plus qu'un autre permettra d'avoir des interfaces stables.
MonDriver::Driver { .....
}
Ce n'est pas parce que tu as écrit ce truc que ton interface est stable. Ça masque juste le problème.
qui changent tous les 6 mois bon bref
un bout de code se doit d'être lisible et maintenable tout le reste c'est du pipo
qui a besoin de faire des apple système posix en dehors de quelques vieux barbus
Je suis globalement d'accord avec ce que tu dis, mais je mitigerais un peu ce que tu dis dans ce paragraphes : les formations qui commencent directement par java le font en général en commençant par du java qui interagit avec l'utilisateur uniquement par println et sans objets.
C'est sûr. Maintenant, Java masque un tas de trucs qui ne devraient pas être masqués ne serait-ce que pour la bonne compréhension des choses. Je pense en particulier à la gestion de la mémoire.
la programmation se doit d'être lisible et maintenable java est lisible, simple, portable et maintenable
Mouarf. Toi, tu n'as _jamais_ été confronté aux problèmes javanais comme la soi-disante portabilité. Déjà, lorsque tu passes d'une JVM d'origine Sun sous Windows à la même sous Solaris ou sous Linux, voire à une J9 sous ppc (linux ou AIX), tu peux avoir des surprises assez amusantes, mais lorsque tu passes sur des JVM vraiment spéciales tournant sur du matériel plus exotique comme des PDA, c'est la fête au village. Java n'est _pas_ portable, en tout cas pas de façon simple, pas de façon fiable, et ça demande un boulot de caractérisation et de contournement des bugs assez conséquent. La cerise sur le gâteau, c'est lorsque tu dois faire tourner un bout de java sous OpenVMS avec la gestion des chemins de fichier !
Ça, c'est pour le côté fiable du truc.
Du côté maintenabilité, Java ne l'est ni plus ni moins qu'un autre langage (en fait plutôt moins si tu regardes le code avec tous les 'workarounds' nécessaires au contournement des bugs des JVM).
Maintenant, dire que c'est lisible et simple, ça n'engage que toi. Pour ma part, je ne trouve ce truc ni simple ni lisible. Il a la rigidité d'ADA sans en avoir aucun des avantages.
donc java le reste ...
Malheureusement.
je pisse du java depuis le jdk 1.0, de moins en moins souvent certes, mais si ton code est correctement écrit il est portable .
Non. Tu as plein de trucs qui ne le sont pas dès que tu attaques des JVM pour du matériel exotique. J'en ai une sur un PDA qui est très tatillone. Et je puis t'assurer que le code java est propre.
je n'ai jamais eu de fuite mémoire ,je mets régulièrement mes obj à null après utilisation, et je ne m'occupe que très rarement du gc elle se débrouille
voila ma recette pour ne pas être emmerdé
Quand tu as 2 Go de mémoire, ça roule. Lorsque tu as la mémoire embarquée dans un PDA et la vitesse du processeur ARM, tu commences déjà à voir les choses différemment.
ps: je ne code pas d'appli web remy
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 21-10-2009, ? propos de
Re: De la difficulté à trouver? des linuxiens professionnels,
remy ?crivait dans fr.comp.os.linux.debats :
JKB a écrit :
Le 21-10-2009, ? propos de
Re: De la difficulté à trouver? des linuxiens professionnels,
remy ?crivait dans fr.comp.os.linux.debats :
JKB a écrit :
Le 21-10-2009, ? propos de
Re: De la difficulté à trouver? des linuxiens professionnels,
Nicolas George ?crivait dans fr.comp.os.linux.debats :
JKB , dans le message <slrnhdtd21.5ai.knatschke@rayleigh.systella.fr>, a
écrit :
Ce qui est encore plus emmerdant, c'est que dans la plupart des
formations, on apprend directement un truc comme Java, C++, C#, .NET
parce que c'est à la mode sans passer par la case 'je maîtrise le C
ou le Fortran, ou tout autre langage impératif ou fonctionnel
évolué'.
le C est pratiquement aussi indispensable que le basic de mon enfance
en dehors de la programmation système qui ne représente que 0,000001 %
du code créé dans une boite cela ne sert à rien
On ne doit pas travailler dans le même genre de boîtes. Chez moi,
c'est C, FORTRAN et langage maison.
tiens justement il faudrait que le noyau s'y mette un peu au c++
histoire de ne pas avoir à se trainer des interfaces à la con
Surtout pas, et il y a des raisons à ça. Écrire un noyau en C++,
c'est se tirer une balle dans les pieds à brève échéance. Sur ce
point, Linus a parfaitement raison. Et je ne vois pas en quoi le
fait d'utiliser un langage plus qu'un autre permettra d'avoir des
interfaces stables.
MonDriver::Driver
{
.....
}
Ce n'est pas parce que tu as écrit ce truc que ton interface est
stable. Ça masque juste le problème.
qui changent tous les 6 mois
bon bref
un bout de code se doit d'être lisible et maintenable
tout le reste c'est du pipo
qui a besoin de faire des apple système posix en dehors de quelques
vieux barbus
Je suis globalement d'accord avec ce que tu dis, mais je mitigerais un peu
ce que tu dis dans ce paragraphes : les formations qui commencent
directement par java le font en général en commençant par du java qui
interagit avec l'utilisateur uniquement par println et sans objets.
C'est sûr. Maintenant, Java masque un tas de trucs qui ne devraient
pas être masqués ne serait-ce que pour la bonne compréhension des
choses. Je pense en particulier à la gestion de la mémoire.
la programmation se doit d'être lisible et maintenable
java est lisible, simple, portable et maintenable
Mouarf. Toi, tu n'as _jamais_ été confronté aux problèmes javanais
comme la soi-disante portabilité. Déjà, lorsque tu passes d'une JVM
d'origine Sun sous Windows à la même sous Solaris ou sous Linux,
voire à une J9 sous ppc (linux ou AIX), tu peux avoir des surprises
assez amusantes, mais lorsque tu passes sur des JVM vraiment
spéciales tournant sur du matériel plus exotique comme des PDA,
c'est la fête au village. Java n'est _pas_ portable, en tout cas pas
de façon simple, pas de façon fiable, et ça demande un boulot de
caractérisation et de contournement des bugs assez conséquent.
La cerise sur le gâteau, c'est lorsque tu dois faire tourner un bout
de java sous OpenVMS avec la gestion des chemins de fichier !
Ça, c'est pour le côté fiable du truc.
Du côté maintenabilité, Java ne l'est ni plus ni moins qu'un autre
langage (en fait plutôt moins si tu regardes le code avec tous les
'workarounds' nécessaires au contournement des bugs des JVM).
Maintenant, dire que c'est lisible et simple, ça n'engage que toi.
Pour ma part, je ne trouve ce truc ni simple ni lisible. Il a la
rigidité d'ADA sans en avoir aucun des avantages.
donc java le reste ...
Malheureusement.
je pisse du java depuis le jdk 1.0, de moins en moins souvent certes,
mais si ton code est correctement écrit il est portable .
Non. Tu as plein de trucs qui ne le sont pas dès que tu attaques des
JVM pour du matériel exotique. J'en ai une sur un PDA qui est très
tatillone. Et je puis t'assurer que le code java est propre.
je n'ai jamais eu de fuite mémoire ,je mets régulièrement mes obj à
null après utilisation, et je ne m'occupe que très rarement du gc elle
se débrouille
voila ma recette pour ne pas être emmerdé
Quand tu as 2 Go de mémoire, ça roule. Lorsque tu as la mémoire
embarquée dans un PDA et la vitesse du processeur ARM, tu commences
déjà à voir les choses différemment.
ps: je ne code pas d'appli web
remy
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 21-10-2009, ? propos de Re: De la difficulté à trouver? des linuxiens professionnels, remy ?crivait dans fr.comp.os.linux.debats :
JKB a écrit :
Le 21-10-2009, ? propos de Re: De la difficulté à trouver? des linuxiens professionnels, remy ?crivait dans fr.comp.os.linux.debats :
JKB a écrit :
Le 21-10-2009, ? propos de Re: De la difficulté à trouver? des linuxiens professionnels, Nicolas George ?crivait dans fr.comp.os.linux.debats :
JKB , dans le message , a écrit :
Ce qui est encore plus emmerdant, c'est que dans la plupart des formations, on apprend directement un truc comme Java, C++, C#, .NET parce que c'est à la mode sans passer par la case 'je maîtrise le C ou le Fortran, ou tout autre langage impératif ou fonctionnel évolué'.
le C est pratiquement aussi indispensable que le basic de mon enfance en dehors de la programmation système qui ne représente que 0,000001 % du code créé dans une boite cela ne sert à rien
On ne doit pas travailler dans le même genre de boîtes. Chez moi, c'est C, FORTRAN et langage maison.
tiens justement il faudrait que le noyau s'y mette un peu au c++ histoire de ne pas avoir à se trainer des interfaces à la con
Surtout pas, et il y a des raisons à ça. Écrire un noyau en C++, c'est se tirer une balle dans les pieds à brève échéance. Sur ce point, Linus a parfaitement raison. Et je ne vois pas en quoi le fait d'utiliser un langage plus qu'un autre permettra d'avoir des interfaces stables.
MonDriver::Driver { .....
}
Ce n'est pas parce que tu as écrit ce truc que ton interface est stable. Ça masque juste le problème.
qui changent tous les 6 mois bon bref
un bout de code se doit d'être lisible et maintenable tout le reste c'est du pipo
qui a besoin de faire des apple système posix en dehors de quelques vieux barbus
Je suis globalement d'accord avec ce que tu dis, mais je mitigerais un peu ce que tu dis dans ce paragraphes : les formations qui commencent directement par java le font en général en commençant par du java qui interagit avec l'utilisateur uniquement par println et sans objets.
C'est sûr. Maintenant, Java masque un tas de trucs qui ne devraient pas être masqués ne serait-ce que pour la bonne compréhension des choses. Je pense en particulier à la gestion de la mémoire.
la programmation se doit d'être lisible et maintenable java est lisible, simple, portable et maintenable
Mouarf. Toi, tu n'as _jamais_ été confronté aux problèmes javanais comme la soi-disante portabilité. Déjà, lorsque tu passes d'une JVM d'origine Sun sous Windows à la même sous Solaris ou sous Linux, voire à une J9 sous ppc (linux ou AIX), tu peux avoir des surprises assez amusantes, mais lorsque tu passes sur des JVM vraiment spéciales tournant sur du matériel plus exotique comme des PDA, c'est la fête au village. Java n'est _pas_ portable, en tout cas pas de façon simple, pas de façon fiable, et ça demande un boulot de caractérisation et de contournement des bugs assez conséquent. La cerise sur le gâteau, c'est lorsque tu dois faire tourner un bout de java sous OpenVMS avec la gestion des chemins de fichier !
Ça, c'est pour le côté fiable du truc.
Du côté maintenabilité, Java ne l'est ni plus ni moins qu'un autre langage (en fait plutôt moins si tu regardes le code avec tous les 'workarounds' nécessaires au contournement des bugs des JVM).
Maintenant, dire que c'est lisible et simple, ça n'engage que toi. Pour ma part, je ne trouve ce truc ni simple ni lisible. Il a la rigidité d'ADA sans en avoir aucun des avantages.
donc java le reste ...
Malheureusement.
je pisse du java depuis le jdk 1.0, de moins en moins souvent certes, mais si ton code est correctement écrit il est portable .
Non. Tu as plein de trucs qui ne le sont pas dès que tu attaques des JVM pour du matériel exotique. J'en ai une sur un PDA qui est très tatillone. Et je puis t'assurer que le code java est propre.
je n'ai jamais eu de fuite mémoire ,je mets régulièrement mes obj à null après utilisation, et je ne m'occupe que très rarement du gc elle se débrouille
voila ma recette pour ne pas être emmerdé
Quand tu as 2 Go de mémoire, ça roule. Lorsque tu as la mémoire embarquée dans un PDA et la vitesse du processeur ARM, tu commences déjà à voir les choses différemment.
ps: je ne code pas d'appli web remy
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Patrice Karatchentzeff
JKB a écrit :
[...]
Oui, je sais, je hais les langages objet. Ça c'est vu ?
Non. De toute façon, il faut être un peu maso pour être d'un avis contraire.
tiens justement il faudrait que le noyau s'y mette un peu au c++
histoire de ne pas avoir à se trainer des interfaces à la con qui changent tous les 6 mois
il dit qu'il voit pas le rapport
en java tiens juste pour le sport
public class Driver extend Driver0 { driver (int a ,int b) { module_param(a,b); InitMemoire(); mydriver_init();
} public void InitMemoire() { ... } public void mydriver_init() { ... } public void mydriver_exit() { ... } public void module_param(a int b,int) { ... } }
public class MyDriver extend Driver { MyDriver() { super(minor,major); } }
j'ai besoin de savoir utiliser que le constructeur, tout le reste comme par exemple mydriver_exit() j'ai pas besoin de l'implémenter j'ai un objet générique Driver qui se démerde avec
sauf si j'ai besoin de modifier son comportement ou de le spécialiser dans ce cas
public class MyDriver extend Driver { MyDriver() { super(minor,major); } public void mydriver_exit() { //je fais ce que je veux ou je l'adapte à mes besoins super.mydriver_exit() } }
bon bref si je suis en C je suis pratiquement obligé de modifier le prototype histoire d'éviter les confusions entre chaque version si je suis en objet je surcharge et pas forcément "par dessus" je peux très bien modifier "par dessous" dans cet exemple Driver0
mon code Mydriver qui utilise Driver qui lui ne change pas
en gros l'idée générale du bousin
remy
-- http://remyaumeunier.chez-alice.fr/
debug this fifo a écrit :
remy wrote:
tiens justement il faudrait que le noyau s'y mette un peu au c++
histoire de ne pas avoir à se trainer des interfaces à la con
qui changent tous les 6 mois
il dit qu'il voit pas le rapport
en java tiens juste pour le sport
public class Driver extend Driver0
{
driver (int a ,int b)
{
module_param(a,b);
InitMemoire();
mydriver_init();
}
public void InitMemoire()
{
...
}
public void mydriver_init()
{
...
}
public void mydriver_exit()
{
...
}
public void module_param(a int b,int)
{
...
}
}
public class MyDriver extend Driver
{
MyDriver()
{
super(minor,major);
}
}
j'ai besoin de savoir utiliser que le constructeur, tout le
reste comme par exemple mydriver_exit() j'ai pas besoin de
l'implémenter j'ai un objet générique Driver qui se démerde avec
sauf si j'ai besoin de modifier son comportement ou de le
spécialiser dans ce cas
public class MyDriver extend Driver
{
MyDriver()
{
super(minor,major);
}
public void mydriver_exit()
{
//je fais ce que je veux ou je l'adapte à mes besoins
super.mydriver_exit()
}
}
bon bref si je suis en C je suis pratiquement obligé de modifier
le prototype histoire d'éviter les confusions entre chaque version si
je suis en objet je surcharge
et pas forcément "par dessus" je peux très bien modifier "par dessous"
dans cet exemple Driver0
mon code Mydriver qui utilise Driver qui lui ne change pas
tiens justement il faudrait que le noyau s'y mette un peu au c++
histoire de ne pas avoir à se trainer des interfaces à la con qui changent tous les 6 mois
il dit qu'il voit pas le rapport
en java tiens juste pour le sport
public class Driver extend Driver0 { driver (int a ,int b) { module_param(a,b); InitMemoire(); mydriver_init();
} public void InitMemoire() { ... } public void mydriver_init() { ... } public void mydriver_exit() { ... } public void module_param(a int b,int) { ... } }
public class MyDriver extend Driver { MyDriver() { super(minor,major); } }
j'ai besoin de savoir utiliser que le constructeur, tout le reste comme par exemple mydriver_exit() j'ai pas besoin de l'implémenter j'ai un objet générique Driver qui se démerde avec
sauf si j'ai besoin de modifier son comportement ou de le spécialiser dans ce cas
public class MyDriver extend Driver { MyDriver() { super(minor,major); } public void mydriver_exit() { //je fais ce que je veux ou je l'adapte à mes besoins super.mydriver_exit() } }
bon bref si je suis en C je suis pratiquement obligé de modifier le prototype histoire d'éviter les confusions entre chaque version si je suis en objet je surcharge et pas forcément "par dessus" je peux très bien modifier "par dessous" dans cet exemple Driver0
mon code Mydriver qui utilise Driver qui lui ne change pas
en gros l'idée générale du bousin
remy
-- http://remyaumeunier.chez-alice.fr/
remy
JKB a écrit :
{ .....
}
Ce n'est pas parce que tu as écrit ce truc que ton interface est stable. Ça masque juste le problème.
le but ce n'est pas de ne plus faire évoluer le noyau mais de simplifier la vie de ceux qui codent 5 lignes de C pour un driver par exemple
Quand tu as 2 Go de mémoire, ça roule. Lorsque tu as la mémoire embarquée dans un PDA et la vitesse du processeur ARM, tu commences déjà à voir les choses différemment.
j'ai aussi développé ,mais là de manière informelle juste histoire de voir, un sokoban en j2me je n'ai pas eu de problème et c'était pour un téléphone portable pas un pda
ps: je ne code pas d'appli web remy
JKB
-- http://remyaumeunier.chez-alice.fr/
JKB a écrit :
{
.....
}
Ce n'est pas parce que tu as écrit ce truc que ton interface est
stable. Ça masque juste le problème.
le but ce n'est pas de ne plus faire évoluer le noyau mais de simplifier
la vie de ceux qui codent 5 lignes de C pour un driver par exemple
Quand tu as 2 Go de mémoire, ça roule. Lorsque tu as la mémoire
embarquée dans un PDA et la vitesse du processeur ARM, tu commences
déjà à voir les choses différemment.
j'ai aussi développé ,mais là de manière informelle juste histoire de
voir, un sokoban en j2me je n'ai pas eu de problème et c'était pour
un téléphone portable pas un pda
Ce n'est pas parce que tu as écrit ce truc que ton interface est stable. Ça masque juste le problème.
le but ce n'est pas de ne plus faire évoluer le noyau mais de simplifier la vie de ceux qui codent 5 lignes de C pour un driver par exemple
Quand tu as 2 Go de mémoire, ça roule. Lorsque tu as la mémoire embarquée dans un PDA et la vitesse du processeur ARM, tu commences déjà à voir les choses différemment.
j'ai aussi développé ,mais là de manière informelle juste histoire de voir, un sokoban en j2me je n'ai pas eu de problème et c'était pour un téléphone portable pas un pda
ps: je ne code pas d'appli web remy
JKB
-- http://remyaumeunier.chez-alice.fr/
remy
Mihamina Rakotomandimby a écrit :
10/21/2009 01:15 PM, remy:
je n'ai jamais eu de fuite mémoire ,je mets régulièrement mes obj à null après utilisation,
C'est de la gestion de mémoire déguisée, ça. Tricheur!
chut !!!
-- http://remyaumeunier.chez-alice.fr/
Mihamina Rakotomandimby a écrit :
10/21/2009 01:15 PM, remy:
je n'ai jamais eu de fuite mémoire ,je mets régulièrement mes obj à
null après utilisation,
C'est de la gestion de mémoire déguisée, ça.
Tricheur!
je n'ai jamais eu de fuite mémoire ,je mets régulièrement mes obj à null après utilisation,
C'est de la gestion de mémoire déguisée, ça. Tricheur!
chut !!!
-- http://remyaumeunier.chez-alice.fr/
JKB
Le 21-10-2009, ? propos de Re: De la difficulté à trouver? des linuxiens professionnels, remy ?crivait dans fr.comp.os.linux.debats :
debug this fifo a écrit :
remy wrote:
tiens justement il faudrait que le noyau s'y mette un peu au c++
histoire de ne pas avoir à se trainer des interfaces à la con qui changent tous les 6 mois
il dit qu'il voit pas le rapport
en java tiens juste pour le sport
public class Driver extend Driver0 { driver (int a ,int b) { module_param(a,b); InitMemoire(); mydriver_init();
} public void InitMemoire() { ... } public void mydriver_init() { ... } public void mydriver_exit() { ... } public void module_param(a int b,int) { ... } }
public class MyDriver extend Driver { MyDriver() { super(minor,major); } }
j'ai besoin de savoir utiliser que le constructeur, tout le reste comme par exemple mydriver_exit() j'ai pas besoin de l'implémenter j'ai un objet générique Driver qui se démerde avec
sauf si j'ai besoin de modifier son comportement ou de le spécialiser dans ce cas
public class MyDriver extend Driver { MyDriver() { super(minor,major); } public void mydriver_exit() { //je fais ce que je veux ou je l'adapte à mes besoins super.mydriver_exit() } }
bon bref si je suis en C je suis pratiquement obligé de modifier le prototype histoire d'éviter les confusions entre chaque version si je suis en objet je surcharge et pas forcément "par dessus" je peux très bien modifier "par dessous" dans cet exemple Driver0
mon code Mydriver qui utilise Driver qui lui ne change pas
en gros l'idée générale du bousin
On voit surtout que tu n'as jamais développé un module pour le noyau Linux.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 21-10-2009, ? propos de
Re: De la difficulté à trouver? des linuxiens professionnels,
remy ?crivait dans fr.comp.os.linux.debats :
debug this fifo a écrit :
remy wrote:
tiens justement il faudrait que le noyau s'y mette un peu au c++
histoire de ne pas avoir à se trainer des interfaces à la con
qui changent tous les 6 mois
il dit qu'il voit pas le rapport
en java tiens juste pour le sport
public class Driver extend Driver0
{
driver (int a ,int b)
{
module_param(a,b);
InitMemoire();
mydriver_init();
}
public void InitMemoire()
{
...
}
public void mydriver_init()
{
...
}
public void mydriver_exit()
{
...
}
public void module_param(a int b,int)
{
...
}
}
public class MyDriver extend Driver
{
MyDriver()
{
super(minor,major);
}
}
j'ai besoin de savoir utiliser que le constructeur, tout le
reste comme par exemple mydriver_exit() j'ai pas besoin de
l'implémenter j'ai un objet générique Driver qui se démerde avec
sauf si j'ai besoin de modifier son comportement ou de le
spécialiser dans ce cas
public class MyDriver extend Driver
{
MyDriver()
{
super(minor,major);
}
public void mydriver_exit()
{
//je fais ce que je veux ou je l'adapte à mes besoins
super.mydriver_exit()
}
}
bon bref si je suis en C je suis pratiquement obligé de modifier
le prototype histoire d'éviter les confusions entre chaque version si
je suis en objet je surcharge
et pas forcément "par dessus" je peux très bien modifier "par dessous"
dans cet exemple Driver0
mon code Mydriver qui utilise Driver qui lui ne change pas
en gros l'idée générale du bousin
On voit surtout que tu n'as jamais développé un module pour le noyau
Linux.
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 21-10-2009, ? propos de Re: De la difficulté à trouver? des linuxiens professionnels, remy ?crivait dans fr.comp.os.linux.debats :
debug this fifo a écrit :
remy wrote:
tiens justement il faudrait que le noyau s'y mette un peu au c++
histoire de ne pas avoir à se trainer des interfaces à la con qui changent tous les 6 mois
il dit qu'il voit pas le rapport
en java tiens juste pour le sport
public class Driver extend Driver0 { driver (int a ,int b) { module_param(a,b); InitMemoire(); mydriver_init();
} public void InitMemoire() { ... } public void mydriver_init() { ... } public void mydriver_exit() { ... } public void module_param(a int b,int) { ... } }
public class MyDriver extend Driver { MyDriver() { super(minor,major); } }
j'ai besoin de savoir utiliser que le constructeur, tout le reste comme par exemple mydriver_exit() j'ai pas besoin de l'implémenter j'ai un objet générique Driver qui se démerde avec
sauf si j'ai besoin de modifier son comportement ou de le spécialiser dans ce cas
public class MyDriver extend Driver { MyDriver() { super(minor,major); } public void mydriver_exit() { //je fais ce que je veux ou je l'adapte à mes besoins super.mydriver_exit() } }
bon bref si je suis en C je suis pratiquement obligé de modifier le prototype histoire d'éviter les confusions entre chaque version si je suis en objet je surcharge et pas forcément "par dessus" je peux très bien modifier "par dessous" dans cet exemple Driver0
mon code Mydriver qui utilise Driver qui lui ne change pas
en gros l'idée générale du bousin
On voit surtout que tu n'as jamais développé un module pour le noyau Linux.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
