Pour paraphraser une autre personne, le français n'est visiblement pas la langue maternelle de l'auteur de cette entrée, c'est donc normal qu'il ait du mal à expliquer clairement son problème.
Surtout qu'ici, ce n'est pas trivial. Il s'agit bien de relier un port USB d'un côté et un port série de l'autre. Il a l'appareil idoine, il lui faut maintenant le piloter en particulier. Heureusement, ça fait partie des classes de périphériques standard, et ça se résout en deux lignes de shell.
Si tu branches sur ton décodeur un contrôleur série RS-232 USB, celui-ci va être reconnu comme tel par le noyau. Dès lors, tu n'as pas besoin d'aller piloter directement le bus USB (heureusement), mais simplement d'aller écrire dans le fichier spécial concerné, exactement comme pour un port série ordinaire :
Non, le halt, c'est justement ce qui va l'appeler. Ca ressemble plus à un SysRq+"e" ou "i", mais en fait c'est au-dessus. C'est écrit en clair, d'ailleurs : au moment de démonter les disques, il faut faire le ménage en virant tous les processus mais en faisant attention d'épargner les nettoyeurs eux-mêmes. Comme ce n'est (visiblement) pas trivial, il y a un outil dédié.
Pour ceux à qui la commande Linux killall manquerait sous Solaris, jetez un oeil du côté de pkill (et pgrep).
Un caractère à destination de quel périphérique ? Le port USB ressemble plus à une carte réseau qu'à un port série ...
Sous Linux, on utilise beaucoup la libusb. Si tu utilises une distribution basée sur RedHat, regarde si le package libusb-devel est installé. Il est livré avec toutes les documentations.
Oui, mais envoyer un e-mail ne coûte rien, envoyer un SMS, si.
Bon, je suis sûr que soit ils beneficient de tarifs de gros, soient ils passent par des pays où il est encore gratuit d'envoyer des SMS (à une époque, je m'envoyais mes logos persos en passant par la Suède).
Bon, je pense que ça ne va durer qu'un temps, parce que le téléphone mobile est beaucoup moins "anonyme" que ne l'est Internet, que ces petites bêtises ont un coût, et surtout parce qu'à terme, on pourra radiolocaliser ces géneurs (sauf plateformes téléinformatiques étrangères, bien sûr).
Tape runlevel pour voir si tu es bien resté en niveau cinq, mais à priori, il ne devrait pas y avoir de problème.
Si startx fonctionne, c'est que le pépin est plus subtil, mais la prochaine fois que tu démarres, loggue-toi et vérifie le contenu de /var/log/Xorg.0.log et vérifie les dernières lignes, spécialement celles qui commencent par (EE)<:B> (les erreurs).
Car dans ton cas de Camion+benne+arrimage, j'ai du mal à croire que Camion+benne se comporte toujours exactement comme un camion, comme une benne et comme l'arrimage.
Ah bon, et pourquoi ?
- Un camion-benne est un camion. Même chassis, même nécessité d'immatriculation, et il se conduit de la même façon par un conducteur de poids lourds (notion de compatibilité et d'interface, justement).
- Un camion-benne est une benne puisqu'il s'agit d'une benne traditionnelle fixée à un chassis. Un camion-benne qui reste au parking a toutes les propriétés d'une benne ordinaire.
Les quelques différences qui vont apparaître se gèrent alors avec la redéfinition des membres concernés. C'est tout l'intérêt de l'héritage objet, d'ailleurs : ne redéfinir que le diff. Dans l'exemple qui nous intéresse, "l'arrimage" était justement les modifications et ajouts nécessaires à la nouvelle classe (pas une troisième classe héritée).
D'une manière générale, si tu vois l'intérêt d'implémenter de plusieurs interfaces à la fois, alors il y a un intérêt à dériver de plusieurs classes à la fois également. Ca ne se voit pas beaucoup dans la Javadoc parce qu'il ont écrit cela de manière élégante, à l'aide de "*Model" et compagnie qui présentent toujours la chose comme si elle était complètement abstraite.
Génial. Si un logiciel plante, on ne peut même pas aller nettoyer la base de registre :-( Bon, en même temps, comme dirait pasBill, les utilisateurs normaux ne le font jamais ...
J'ai l'impression que tu mélanges deux choses. Il y a probablement des rewrites légitimes dans ta config', surtout si tu ne l'as pas rédigée seule, mais s'il y a trop d'URL Rewrite dans une configuration Apache, c'est souvent le signe que quelque chose n'est pas maîtrisée. Elles servent en général à contourner un problème sans le résoudre ...
Sinon, il faut faire la différence entre les virtual hosts ordinaires et les name-based virtual hosts. « ServerAlias » sert aux seconds.
Vérifie si ton serveur fonctionne bien en mode name-based pour les adresses IP concernées, en regardant s'il existe une directive NameVirtualHost dans ton fichier de conf'.
Ajouter « fr.projet.local » à ton /etc/hosts n'a aucun effet si tu le fais sur ton serveur. Sur ta machine cliente, ça lui permettra effectivement d'appeler la bonne adresse, et cela doit fonctionner si, encore une fois, ton site utilise les NBVH.
Le concept des interfaces existaient avant Java... C'est très utilisé en SystemC par exemple.
Je n'ai pas dit le contraire.
C'est la seul utilisation "propre" que j'ai vu de l'héritage multiple. Le problème des diamants devient énorme
Là, je ne suis pas d'accord. Personne n'oblige un programmeur C++ à coder en diamant et réciproquement, personne ne devrait en être empeché. Ce n'est pas parce que c'est difficile que ce n'est pas propre. Ce qui l'est, c'est la manière de contourner le problème sans le résoudre.
La seule raison, à mon avis, pour laquelle Java ne propose pas l'héritage multiple à ses programmeurs est l'obligation de dériver de Object, parce que là, on aurait systématiquement un diamant à la moindre classe dérivée multiple.
Il n'empêche qu'il y a réellement des classes qui dérivent de plusieurs objets de même importance (genre : Camion-Benne = Camion + Benne + dispositif d'arrimage prope) et que c'est très chiant de devoir faire le choix d'une classe "majeure" dont héritera l'objet quand les autres ne seront que réimplémentés. Et trancher en faveur du tout-interface (autrement dit, renoncer à l'héritage) ne m'amuse pas plus.
Si les ambigüités du diamant posent problème, alors il suffit de toutes les redéfinir dans la classe héritante en une seule fois, ce qui est en substance ce qu'une interface oblige à faire. Mais se repalucher le même code 15 fois de suite, ça va bien cinq minutes ...
Update après relecture : ce n'est pas un troll Java/C++, même si ça en a l'air. Je voulais dire dans ma dernière phrase qu'il valait mieux essayer de vaincre dès le départ les difficultés d'un langage plutôt que d'appliquer les modèles d'un autre. Ce n'est pas un plaidoyer en faveur d'un langage plus que de l'autre ...
En fait c'est logique, même si cette méthode est déclarée virtuelle et donc redéfinissable dans B, cela n'implique pas qu'elle doive nécessairement être redéfinie vu qu'elle n'est pas virtuelle pure.
Pas tout-à-fait : une méthode, quelle qu'elle soit, n'a pas besoin d'être virtuelle (pure ou non) pour pouvoir être redéfinie. En fait, tu n'as même pas besoin de la déclarer dans les classes dérivées dès lors que celles-ci en héritent de la classe supérieure. Ca veut dire notamment que tu n'as pas besoin de déclarer une méthode virtuelle (pure) à la racine de ton graphe simplement parce que tu comptes la faire apparaître un peu plus loin. C'est même fondamentalement le contraire : le procédé est fait pour t'éviter d'avoir à y penser à l'avance.
D'autre part, être confronté à des héritages en diamant est une chose relativement fréquente en C++, mais ils sont généralement dus à une erreur de conception dans le modèle et pas à une limitation technique. Au pire, ils traduisent un conflit, au mieux, ils mettent généralement en évidence des notions jusque là implicites.
Mais ton erreur d'analyse, dans ce cas précis, est de considérer chaque classe dérivée comme un sous-ensemble d'une classe plus générale (ce que N est à R, par exemple), alors qu'il s'agit au contraire d'une extension de la classe précédente (comme Z par rapport à N). Chaque classe contient implicitement la classe mère en entier, plus d'autres choses.
Il est humainement facile de trancher entre une classe qui définit property1() et une autre qui ne se prononce pas, mais c'est plus dur de le faire si elles ont des opinions antagonistes : tu pourrais très bien définir une classe D qui, héritant de deux classes, soit à la fois un anneau intègre et un anneau non-intègre, ce qui n'a pas de sens.
Si ce problème se résout parce qu'on sait qu'il y a prédominance ou récessivité, alors celles-ci doivent être définies. Mais ici, on voit que c'est le modèle objet même qui doit être revu. Le Java ne permettant pas d'hériter de plusieurs classes à la fois, c'est un problème qui est automatiquement contourné (donc jamais rencontré), mais pas résolu.
, auriez-vous des conseils pour l'exemple que je donnais à la fin ?
J'en ai un : Contrairement à Java, le C++ n'impose pas que tu définisses tes méthodes à l'intérieur de ta classe. C'est même mieux si tu sépares tes déclarations et définitions dans des fichiers .h et .c distincts. Ainsi, le .h peut être directement utilisé par les programmes sources externes qui utiliseront ta classe.
D'autre part, toute fonction membre définie dans la déclaration de la classe est automatiquement considérée inline, et c'est rarement souhaitable.
# Regexps ...
Posté par Obsidian . En réponse au message Extraire un bout de chaîne. Évalué à 4.
Pour extraire une date formée d'exactement huit chiffres consécutifs, tu peux utiliser un truc du style :
date=`echo $fic | sed -e "s/^.*\/\([0-9]\{8\}\)\/.*$/\1/g`Mais vérifie d'abord que tu n'as jamais plus de sept chiffres consécutifs autre part dans le chemin.
A bientôt.
[^] # Re: Whaou!
Posté par Obsidian . En réponse au journal Microsoft->mode=MODE_OPENSOURCE;. Évalué à 2.
Rien de nouveau sous le soleil, quoi.
On ne change pas un busness model qui marche, aussi immoral soit-il, d'ailleurs.
[^] # Re: Un peu d'exagération ne fait pas de mal
Posté par Obsidian . En réponse au message envoyer un caractère sur le port USB. Évalué à 2.
Surtout qu'ici, ce n'est pas trivial. Il s'agit bien de relier un port USB d'un côté et un port série de l'autre. Il a l'appareil idoine, il lui faut maintenant le piloter en particulier. Heureusement, ça fait partie des classes de périphériques standard, et ça se résout en deux lignes de shell.
[^] # Re: Point de depart
Posté par Obsidian . En réponse au message envoyer un caractère sur le port USB. Évalué à 2.
/dev/ttyUSB0
$ stty litout 9600 /dev/ttyUSB0
$ echo "Bonjour" > /dev/ttyUSB0
[^] # Re: un conseil
Posté par Obsidian . En réponse au journal Solaris pour les newbz'. Évalué à 3.
Non, le halt, c'est justement ce qui va l'appeler. Ca ressemble plus à un SysRq+"e" ou "i", mais en fait c'est au-dessus. C'est écrit en clair, d'ailleurs : au moment de démonter les disques, il faut faire le ménage en virant tous les processus mais en faisant attention d'épargner les nettoyeurs eux-mêmes. Comme ce n'est (visiblement) pas trivial, il y a un outil dédié.
Pour ceux à qui la commande Linux killall manquerait sous Solaris, jetez un oeil du côté de pkill (et pgrep).
[^] # Re: Point de depart
Posté par Obsidian . En réponse au message envoyer un caractère sur le port USB. Évalué à 3.
# Un caractère ?
Posté par Obsidian . En réponse au message envoyer un caractère sur le port USB. Évalué à 4.
Sous Linux, on utilise beaucoup la libusb. Si tu utilises une distribution basée sur RedHat, regarde si le package libusb-devel est installé. Il est livré avec toutes les documentations.
/usr/share/doc/libusb-devel-0.1.12/html/examples.html
/usr/share/doc/libusb-devel-0.1.12/html/api.html
[^] # Re: CONTACT !
Posté par Obsidian . En réponse au journal Au secours! Rendez moi ma tranquilité !. Évalué à 2.
[^] # Re: black list
Posté par Obsidian . En réponse au journal Au secours! Rendez moi ma tranquilité !. Évalué à 3.
Bon, je suis sûr que soit ils beneficient de tarifs de gros, soient ils passent par des pays où il est encore gratuit d'envoyer des SMS (à une époque, je m'envoyais mes logos persos en passant par la Suède).
Bon, je pense que ça ne va durer qu'un temps, parce que le téléphone mobile est beaucoup moins "anonyme" que ne l'est Internet, que ces petites bêtises ont un coût, et surtout parce qu'à terme, on pourra radiolocaliser ces géneurs (sauf plateformes téléinformatiques étrangères, bien sûr).
# Xorg plante
Posté par Obsidian . En réponse au message Demarrage en mode console. Évalué à 4.
Si startx fonctionne, c'est que le pépin est plus subtil, mais la prochaine fois que tu démarres, loggue-toi et vérifie le contenu de /var/log/Xorg.0.log et vérifie les dernières lignes, spécialement celles qui commencent par (EE)<:B> (les erreurs).
Bon courage.
[^] # Re: Ferme ton compte avant de partir...
Posté par Obsidian . En réponse au message Marre de linux pourri. Évalué à 2.
[^] # Re: héritage multiple en diamant
Posté par Obsidian . En réponse au message Autour de l'héritage multiple et des méthodes virtuelles.. Évalué à 2.
Ah bon, et pourquoi ?
- Un camion-benne est un camion. Même chassis, même nécessité d'immatriculation, et il se conduit de la même façon par un conducteur de poids lourds (notion de compatibilité et d'interface, justement).
- Un camion-benne est une benne puisqu'il s'agit d'une benne traditionnelle fixée à un chassis. Un camion-benne qui reste au parking a toutes les propriétés d'une benne ordinaire.
Les quelques différences qui vont apparaître se gèrent alors avec la redéfinition des membres concernés. C'est tout l'intérêt de l'héritage objet, d'ailleurs : ne redéfinir que le diff. Dans l'exemple qui nous intéresse, "l'arrimage" était justement les modifications et ajouts nécessaires à la nouvelle classe (pas une troisième classe héritée).
D'une manière générale, si tu vois l'intérêt d'implémenter de plusieurs interfaces à la fois, alors il y a un intérêt à dériver de plusieurs classes à la fois également. Ca ne se voit pas beaucoup dans la Javadoc parce qu'il ont écrit cela de manière élégante, à l'aide de "*Model" et compagnie qui présentent toujours la chose comme si elle était complètement abstraite.
[^] # Re: Ferme ton compte avant de partir...
Posté par Obsidian . En réponse au message Marre de linux pourri. Évalué à 3.
N'oublie pas de fermer ton compte avant de partir ! :-)
(attends-moi, j'arrive ->[]).
[^] # Re: Ouch !
Posté par Obsidian . En réponse au message Marre de linux pourri. Évalué à 2.
$ regedit
bash: regedit: command not found
Génial. Si un logiciel plante, on ne peut même pas aller nettoyer la base de registre :-( Bon, en même temps, comme dirait pasBill, les utilisateurs normaux ne le font jamais ...
[^] # Re: Ferme ton compte avant de partir...
Posté par Obsidian . En réponse au message Marre de linux pourri. Évalué à 6.
Des canadiens, sans doute ...
[^] # Re: Ouch !
Posté par Obsidian . En réponse au message Marre de linux pourri. Évalué à 2.
# Ouch !
Posté par Obsidian . En réponse au message Marre de linux pourri. Évalué à 4.
Tiens, ça existe encore, AOL ? :-)
Bon, sinon, trop gros, passera pas.
Et puis, dès le lundi matin (14h00), c'est quand même costaud à avaler ...
[^] # Re: L'un de nous deux n'as pas bien compris quelque chose.
Posté par Obsidian . En réponse à la dépêche Le président français propose aux écoliers d'adopter un projet libre mort sur SourceForge. Évalué à 9.
[^] # Re: DNS...
Posté par Obsidian . En réponse au message VirtualHost : ServerAlias ne fonctionne pas. Évalué à 3.
Sinon, il faut faire la différence entre les virtual hosts ordinaires et les name-based virtual hosts. « ServerAlias » sert aux seconds.
Vérifie si ton serveur fonctionne bien en mode name-based pour les adresses IP concernées, en regardant s'il existe une directive NameVirtualHost dans ton fichier de conf'.
Ajouter « fr.projet.local » à ton /etc/hosts n'a aucun effet si tu le fais sur ton serveur. Sur ta machine cliente, ça lui permettra effectivement d'appeler la bonne adresse, et cela doit fonctionner si, encore une fois, ton site utilise les NBVH.
[^] # Re: Consistent
Posté par Obsidian . En réponse au message who affiche des utilisateurs déconnectés. Évalué à 2.
[^] # Re: héritage multiple en diamant
Posté par Obsidian . En réponse au message Autour de l'héritage multiple et des méthodes virtuelles.. Évalué à 4.
Je n'ai pas dit le contraire.
Là, je ne suis pas d'accord. Personne n'oblige un programmeur C++ à coder en diamant et réciproquement, personne ne devrait en être empeché. Ce n'est pas parce que c'est difficile que ce n'est pas propre. Ce qui l'est, c'est la manière de contourner le problème sans le résoudre.
La seule raison, à mon avis, pour laquelle Java ne propose pas l'héritage multiple à ses programmeurs est l'obligation de dériver de Object, parce que là, on aurait systématiquement un diamant à la moindre classe dérivée multiple.
Il n'empêche qu'il y a réellement des classes qui dérivent de plusieurs objets de même importance (genre : Camion-Benne = Camion + Benne + dispositif d'arrimage prope) et que c'est très chiant de devoir faire le choix d'une classe "majeure" dont héritera l'objet quand les autres ne seront que réimplémentés. Et trancher en faveur du tout-interface (autrement dit, renoncer à l'héritage) ne m'amuse pas plus.
Si les ambigüités du diamant posent problème, alors il suffit de toutes les redéfinir dans la classe héritante en une seule fois, ce qui est en substance ce qu'une interface oblige à faire. Mais se repalucher le même code 15 fois de suite, ça va bien cinq minutes ...
# Consistent
Posté par Obsidian . En réponse au message who affiche des utilisateurs déconnectés. Évalué à 2.
inconsistent -> cohérent, en français.
Sinon, j'ai le même problème ...
[^] # Re: Only two remote holes in the default install, in more than 10 years!
Posté par Obsidian . En réponse au journal Microsoft pire qu'ubuntu dans ses updates. Évalué à 6.
Subtil ! :-)
[^] # Re: héritage multiple en diamant
Posté par Obsidian . En réponse au message Autour de l'héritage multiple et des méthodes virtuelles.. Évalué à 3.
[^] # Re: Tes "virtual" sont mals placés
Posté par Obsidian . En réponse au message Autour de l'héritage multiple et des méthodes virtuelles.. Évalué à 3.
Pas tout-à-fait : une méthode, quelle qu'elle soit, n'a pas besoin d'être virtuelle (pure ou non) pour pouvoir être redéfinie. En fait, tu n'as même pas besoin de la déclarer dans les classes dérivées dès lors que celles-ci en héritent de la classe supérieure. Ca veut dire notamment que tu n'as pas besoin de déclarer une méthode virtuelle (pure) à la racine de ton graphe simplement parce que tu comptes la faire apparaître un peu plus loin. C'est même fondamentalement le contraire : le procédé est fait pour t'éviter d'avoir à y penser à l'avance.
D'autre part, être confronté à des héritages en diamant est une chose relativement fréquente en C++, mais ils sont généralement dus à une erreur de conception dans le modèle et pas à une limitation technique. Au pire, ils traduisent un conflit, au mieux, ils mettent généralement en évidence des notions jusque là implicites.
Mais ton erreur d'analyse, dans ce cas précis, est de considérer chaque classe dérivée comme un sous-ensemble d'une classe plus générale (ce que N est à R, par exemple), alors qu'il s'agit au contraire d'une extension de la classe précédente (comme Z par rapport à N). Chaque classe contient implicitement la classe mère en entier, plus d'autres choses.
Il est humainement facile de trancher entre une classe qui définit property1() et une autre qui ne se prononce pas, mais c'est plus dur de le faire si elles ont des opinions antagonistes : tu pourrais très bien définir une classe D qui, héritant de deux classes, soit à la fois un anneau intègre et un anneau non-intègre, ce qui n'a pas de sens.
Si ce problème se résout parce qu'on sait qu'il y a prédominance ou récessivité, alors celles-ci doivent être définies. Mais ici, on voit que c'est le modèle objet même qui doit être revu. Le Java ne permettant pas d'hériter de plusieurs classes à la fois, c'est un problème qui est automatiquement contourné (donc jamais rencontré), mais pas résolu.
J'en ai un : Contrairement à Java, le C++ n'impose pas que tu définisses tes méthodes à l'intérieur de ta classe. C'est même mieux si tu sépares tes déclarations et définitions dans des fichiers .h et .c distincts. Ainsi, le .h peut être directement utilisé par les programmes sources externes qui utiliseront ta classe.
D'autre part, toute fonction membre définie dans la déclaration de la classe est automatiquement considérée inline, et c'est rarement souhaitable.