Bon y a un un développeur de gnome qui a fait une présentation du nouvel "indexeur" de fichiers de Gnome. Je sais pas si ça s'appelle comme ça.
Concrètement ce programme répertorie les emails, les documents, les conversations IM/IRC (donc gaim/xchat) les images, musiques et enfin films.
Il se met a jour dynamiquement via des appels au noyau (inotify noyau > 2.6.9). L'indexation permet d'avoir le résultat de la recherche de manière instantannée.Ce projet est écrit en C# à l'aide de Mono et de GTK#.
Les demos ; http://nat.org/demos/(...) (en flash)
Le site du projet : http://www.gnome.org/projects/beagle/(...)
Le blog des devs : http://www.planetbeagle.org/(...)
Journal Des nouvelles de Gnome
24
jan.
2005
# Wouach
Posté par Anonyme . Évalué à 4.
# retour d'expérience
Posté par Florent Zara (site web personnel, Mastodon) . Évalué à 3.
http://www.neokraft.net/blog/2005/01/21/570-en-vrac(...)
En bref, prometteur mais pas pu l'installer !
Il cite d'ailleurs un autre outil à surveiller de près: Dashboard
[^] # Re: retour d'expérience
Posté par el_mickey . Évalué à 2.
[^] # Re: retour d'expérience
Posté par MsK` . Évalué à 7.
[^] # Re: retour d'expérience
Posté par Erwan . Évalué à 2.
Et comme je n'utilise ni Evolution ni Gaim, ca limite un peu l'interet pour le moment...
# Bravo Gnome !
Posté par spongurex . Évalué à 5.
J'ai vraiment hâte d'utiliser ce petit utilitaire.
Mais je me pose deux questions :
1) Comment ça va tourner sur les ordinateurs. Il faudra bientôt un cluster de machines pour faire fonctionner Gnome ! Car même si c'est le kernel qui se charge de surveiller les modifications de fichiers, à chaque modification, Beagle doit analyser le fichier => consommation de ressources.
2) Ne serait-ce pas ça que voulait faire Microsoft avec WinFS ? Ou bien je n'ai rien compris...
[^] # Re: Bravo Gnome !
Posté par Nicolas Évrard (site web personnel, Mastodon) . Évalué à 4.
[^] # Re: Bravo Gnome !
Posté par grafit . Évalué à 3.
2) MS en a rêvé, GNOME l'a fait ?
On dirait que certains meneurs commencent à trainer la pate... et peinent à... suivre! :o)
Au suivant au suivant
Un jour je me ferai cul-de-jatte ou bonne s½ur ou pendu
Enfin un de ces machins où je ne serai jamais plus
Le suivant le suivant
[^] # Re: Bravo Gnome !
Posté par CrEv (site web personnel) . Évalué à 1.
je vais répondre aux deux 2)
Ce programme, aussi bon soit-il, n'a rien à voir avec WinFS
WinFS est sencé être un nouveau système de fichier (comme ext3, reiserfs, ...) mais intégrant une couche base de donnée. Alors que dans ce cas, c'est une appli qui doit créer l'équivalent d'une bdd à partir des fichiers
Une différence est également le fait que (d'après ce que j'ai compris) cette appli répertorie certains fichiers, alors que winfs étant un système de fichier pourra répertorier tous les fichiers.
Enfin, Winfs n'étant pas annoné avant 2007 dans le meilleur des cas, on peut toujours attendre...
Enfin, il serait pas mal d'avoir la même chose en QT et gérant les applis KDe ;-)
[^] # Re: Bravo Gnome !
Posté par gnumdk (site web personnel) . Évalué à 3.
et non :)
http://linuxfr.org/~gnumdk/11511.html(...)
[^] # Re: Bravo Gnome !
Posté par CrEv (site web personnel) . Évalué à 2.
Merci de l'éclaircissement ;-)
[^] # Re: Bravo Gnome !
Posté par TImaniac (site web personnel) . Évalué à 2.
effectivemetn WinFS utilisera le système de fichier comme "support", mais du point de vue du programmeur MS souhaite que ce soit WinFS qui soit vu comme le FS (c'est pas pour rien que y'a FS dand WinFS)
WinFS est donc une couche d'abstraction orientée BDD qui tend à remplacer NTFS en l'ingérant (burp) :)
[^] # Re: Bravo Gnome !
Posté par Sasuke . Évalué à 2.
Il a lancé le truc, tapé "pokute" (mon pseudo pour ceux qui auraient pas remarqué) et il a trouvé une photo. Puis, tjrs la fenêtre ouverte, je lui dit "salut !" dans gaim, et instantannément une nouvelle entrée apparait sans qu'il ait eu rien à faire (!)
Par contre, c'est encore très chiant à installer et relativement instable (il a relancé le daemon plusieurs fois).
[^] # Re: Bravo Gnome !
Posté par Erwan . Évalué à 3.
Sur la version que j'ai teste (0.0.4), le demon Beagle tourne avec une priorite de 15 donc ca ne rame pas. Par contre, la requete n'etait pas mise a jour en temps reel comme sur la video de Nat.
2) Le but est le meme, mais la facon de faire est differente. Microsoft veut carrement indexer directement les fichiers dans une BD, en gros le filesystem serait une BD. Avec Beagle, on a un filesystem classique et une BD a cote.
Pour les concurrents de Beagle, il s'agit du "desktop search", un sujet tres a la mode depuis que Google a sorti sa proposition (sous les OS proprios) :
http://desktop.google.com/(...)
http://desktop.yahoo.com/(...)
http://www.x1.com/products/xds.html(...)
http://www.apple.com/macosx/tiger/spotlight.html(...)
# bloat
Posté par mickabouille . Évalué à 3.
Je suis un peu déçu par l'orientation prise.
J'espère juste qu'on pourra continuer à utiliser les applis du genre gimp, gnumeric, rox... sans avoir gnome.
Allez, va falloir que je me mette à xfce, moi!
[^] # Re: bloat
Posté par Jérôme (site web personnel) . Évalué à 1.
Xfce se porte comme un charme, avec les même appli lancées, et de gdesklets en plus.
J'utilise rox-filer par contre, mais c'est un peu penible car par defaut il n'associe aucune application au extention /mime-type
[^] # Re: bloat
Posté par dawar (site web personnel) . Évalué à 2.
Par contre je reste sur gnome pour ma machine, plus puissante, par habitude (et aussi pour le vu-meter en applet dont j'ai besoin)
Mais beagle, ca donne envie, vivement que ca sorte du stade experimental (d'ailleur si j'ai compris, ce n'est pas tant que ca lié a gnome)
[^] # Re: bloat
Posté par Yusei (Mastodon) . Évalué à 2.
Tu es déçu de l'existence de ce logiciel, ou bien tu es déçu qu'on te force à l'utiliser ?
[^] # Re: bloat
Posté par gyhelle . Évalué à 3.
Hmmm, a la lecture de ta phrase, et en supposant que tu n'est pas de la pire mauvaise fois possible, je te conseille une consultation chez un ophtalmologue.
Quand le posteur précédent dit être "un peu déçu par l'orientation prise", on peu supposer qu'il a soupesé ses mots.
Etudions ensemble cette phrase :
"je suis" : Cela concerne son avis personnel.
"un peu" : par opposition a beaucoup il n'est que légèrement affecteé par ce qui va suivre. Ca ne le traumatise pas outre mesure et considère que rien n'est remis fondamentalement en cause.
"déçu" : C'est une déception pas l'incarnation de ses pires cauchemars.
"orientation prise" : présente une caractéristique d'évolution. Le sujet avait certaines caractèristiques qui on changés depuis.
Une fois mis bout à bout, on peu déduire que l'auteur de la phrase précédentee pense (à tord ou a raison) que Gnome avait certaines caracteristiques (ici de légéreté et de simplicité, mais ce n'est pas important) qui disparaissent ou ont disparue depuis.
Comme tu peut le voir nulle remise en cause de l'exitence de Gnome ou évocation d'une obligation d'utilisation.
[^] # Re: bloat
Posté par Yusei (Mastodon) . Évalué à 5.
- Beagle est lourd
- Beagle est conçu pour Gnome
- donc Beagle sera inclus dans Gnome
- donc s'il utilise Gnome il sera obligé d'utiliser Beagle
- donc s'il utilise Gnome il sera obligé d'utiliser un logiciel lourd
Que Beagle soit lourd, peut-être, je ne sais pas.
Qu'il soit inclus dans Gnome, je n'en sais rien non plus, mais admettons.
Même dans ce cas, je suis persuadé qu'il sera toujours possible d'utiliser Gnome sans Beagle, et que donc je ne vois pas ce qui, dans l'existence de Beagle, remet en question la possibilité qu'a le monsieur d'utiliser Gnome "aussi léger qu'avant".
De la même manière, OOo est lourd, OOo est inclus de base dans plein de distributions, et si quelqu'un me disait qu'il est déçu de la tendance qu'ont les distributions à inclure des logiciels lourds, je lui demanderais aussi si ce qui le déçoit c'est l'existence d'OOo, ou le fait qu'on le force à l'utiliser. Si la réponse est "ni l'un ni l'autre", je ne vois pas de quoi il est déçu.
Un logiciel n'est lourd que pour ceux qui l'utilisent, et s'ils l'utilisent c'est qu'ils ont une raison. Si on interdit aux gens de développer des logiciels lourds, on prive ceux qui en ont besoin de ces logiciels, et ça n'apporte rien aux autres, qui de toutes façons n'en auraient pas eu l'usage.
Quant au reste, je me demande où, dans mon unique phrase, tu as été pêcher que j'avais pris sa remarque pour autre chose qu'un avis personnel, ou bien pour quelque chose de dramatique.
[^] # Re: bloat
Posté par gyhelle . Évalué à 0.
Le message originel parlait de gnome en général, donc sans plus de précision de ta part, j'ai considéré que ta remarque concernait gnome aussi.
>je ne vois pas ce qui, dans l'existence de Beagle, remet en question la >possibilité qu'a le monsieur d'utiliser Gnome "aussi léger qu'avant".
Encore une fois, il fait une remarque sur l'environnement Gnome, pas sur un logiciel donné.
>De la même manière, OOo est lourd, OOo est inclus de base dans plein
>distributions, et si quelqu'un me disait qu'il est déçu de la tendance qu'ont >distributions à inclure des logiciels lourds, je lui demanderais aussi si ce
>déçoit c'est l'existence d'OOo, ou le fait qu'on le force à l'utiliser. Si la
>réponse est "ni l'un ni l'autre", je ne vois pas de quoi il est déçu.
Il faudrait plutot faire l'analogie suivante : On utilise OOo qui est s'alourdit au fil des mois/années. Est on deçu par son existence ? non. Et on forcé de l'utiliser ? non. Ce qui deçoit, c'est l'allourdissement d'OOo.
Tu as d'ailleurs fait un bon choix en prenant cet exemple : dans petit cas personnel, la première fois que j'ai fait tourner OOo sur ma machine, j'était déçu : c'était inutilisable. Je ne suis pourtant ni deçu qu'il existe et personne ne me force à l'utiliser, comme quoi il y a plusieurs causes possibles à la déception.
>Si on interdit aux gens de développer des logiciels lourds, on prive ceux >qui en ont besoin de ces logiciels, et ça n'apporte rien aux autres, qui de >toutes façons n'en auraient pas eu l'usage.
Qu'elle est l'adresse du MIDML (Mouvement pour l'Interdiction du Developpement de logiciels Monstruerusement lourd) ? J'ai bien envie d'y militer.
Mauvaise blague à part, je ne vois pas trop pourquoi tu dit ça. Personne n'a rien interdit à personne.
>qui de toutes façons n'en auraient pas eu l'usage.
On parle toujours de l'utilisation de logiciels lourds ? Sur quoi te base tu pour affirmer que ceux qui ne les utilisent pas n'en auraient pas eu l'usage ? Si on a pas de machine de dernière génération, on a pas besoin des softs qui tournent dessus ? Ca marche aussi avec des objets matériels ?
[^] # Re: bloat
Posté par Yusei (Mastodon) . Évalué à 3.
Si un logiciel est trop lourd pour que je l'utilise, je ne l'utilise pas. Je me base là dessus pour dire que le fait que ce logiciel existe ou non ne m'affecte pas, et que donc, autant qu'il existe. Autrement dit, qu'OOo existe ou pas, je ne m'en servirais pas, et ça ne me viendrait pas à l'idée de dire que je regrette l'intégration d'OOo dans Gnome, tant que personne ne m'oblige à l'utiliser.
M'enfin, tu as l'air convaincu que je suis un vilain monsieur très bête, alors je ne vois pas pourquoi j'insiste.
«Il faudrait plutot faire l'analogie suivante : On utilise OOo qui est s'alourdit au fil des mois/années. Est on deçu par son existence ? non. Et on forcé de l'utiliser ? non. Ce qui deçoit, c'est l'allourdissement d'OOo.»
C'est une mauvaise analogie dans le cas présent. On parle de l'ajout de Beagle dans Gnome, et pour autant que je sache il sera toujours possible d'utiliser Gnome sans Beagle, de même que l'on peut utiliser Gnome sans nautilus. Par conséquent, même si le bureau "de base" de Gnome s'alourdit, personne n'est obligé de subir cet alourdissement.
Je vois Beagle comme un apport de fonctionnalités pour ceux qui choisiront d'en payer le prix, et qui ne coûte absolument rien aux autres.
«je ne vois pas trop pourquoi tu dit ça. Personne n'a rien interdit à personne.»
Err, pff, c'est fatiguant... C'est un raccourci, à la place de dire "si on interdit", j'aurais pu dire "si à chaque fois que quelqu'un sort un logiciel qui est lourd, on lui fait le reproche de sa lourdeur jusqu'à le dégoûter de continuer", mais ça aurait été plus long, et pas plus clair. Si jamais, un jour, je dis que je meurs de soif, merci de ne pas me corriger pour m'expliquer que je peux survivre quelques jours sans boire ;-)
(C'est fou, quand même, on va finir par croire que le post auquel je répondais est une affaire d'état, avec ce genre de capilotractage)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: bloat
Posté par Aurélien Bompard (site web personnel) . Évalué à 4.
Je passerai sur le troll QT, mais personnellement j'aime pas l'orientation dans le sens "On va faire simple : on va enlever des fonctionnalités et des options de configuration". Personnellement, je fais partie de ceux qui aiment bien avoir un bureau adapté exactement à leurs goûts, quitte à y passer un peu de temps au début.
Alors voilà, personnellement je n'aime pas l'orientation prise par GNOME, donc je ne l'utilise pas. Mais je suis très content qu'ils aient choisi une voie, qu'ils s'y tiennent, et que ça plaise aux gens. C'est juste pas pour moi.
C'est d'autant mieux que comme ça la différence entre GNOME et KDE est encore plus tracée, c'est pas juste une question d'apparence ou de GTK/QT. Il y a encore moins "double-emploi" qu'avant, bref, tout va bien :)
[^] # Re: bloat
Posté par Gilles Gagniard (site web personnel) . Évalué à 3.
Peux tu expliciter s'il te plait les problèmes de license de Qt ? Aux dernières nouvelles, la GPL est une license considérée comme étant libre ...
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: bloat
Posté par gnumdk (site web personnel) . Évalué à 2.
http://kde-cygwin.sourceforge.net/qt3-win32/(...)
[^] # Re: bloat
Posté par Infernal Quack (site web personnel) . Évalué à 4.
Trop gros. Passera pas
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: bloat
Posté par MsK` . Évalué à 0.
[^] # Re: bloat
Posté par gnumdk (site web personnel) . Évalué à 1.
>comparé à KDE.
Exactement, C'est un peu comme COMMAND.COM et bash, y'a un truc qui offre aucune fonctionnalité et un truc puissant, apres, à chacun de faire son choix ;)
[^] # Re: bloat
Posté par ploum (site web personnel, Mastodon) . Évalué à 7.
Disons que KDE c'est un peu Emacs et Gnome c'est vim : Le premier sert surtout à faire bien sur les screenshots, mais au final tout le monde utilise le second.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: bloat
Posté par thecat . Évalué à 1.
Kde c'est comme Java : super puissant mais développé par une boite qui fait du proprio
Gnome c'est comme mono : toujours a la traine et recopiant les trucs des concurant sans apporter d'innovation ...
... quelqu'un pour me suivre ?
[^] # Re: bloat
Posté par ploum (site web personnel, Mastodon) . Évalué à 4.
KDE, c'est peut-être super puissant mais bon sang que c'est chiant à utiliser. En plus c'est lourd, c'est ultra lent, ça fait chier tout le monde. (bref comme java)
Gnome, c'est au départ un truc repompé mais avec des idées originales et finalement, ça enfonce complètement le modèle dont ça s'inspirait (bref comme gnome).
Mouais, pas mal...
Mais quoiqu'il en soit, Vim rox et Emacs sux, ça c'est sûr.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: bloat
Posté par Erwan . Évalué à 2.
Novell aimerait beaucoup que mono et gtk# soient integre a Gnome, mais ce n'est pas l'avis de tous les gens de la Gnome Foundation.
[^] # Re: bloat
Posté par TImaniac (site web personnel) . Évalué à 2.
# On va encore dire que je suis un raleur mais...
Posté par Jerome Herman . Évalué à -3.
public static void main
Et là d'un coup beurk...
Voilà. C'est tout.
[^] # Re: On va encore dire que je suis un raleur mais...
Posté par Stephane Wirtel (site web personnel) . Évalué à 1.
[^] # Re: On va encore dire que je suis un raleur mais...
Posté par Franck . Évalué à 2.
C# Programmer's Reference
Main
The Main method is the entry point of your program, where the program control starts and ends. It is declared inside a class or struct. It must be static. It can either have a void or int return type.
[^] # Re: On va encore dire que je suis un raleur mais...
Posté par Jerome Herman . Évalué à 4.
Tout d'abord commençons par un petit résumé des épisodes précédents :
Jusqu'à ce que Borland décide de créer un compilateur C tous les compilateurs du monde sortait une erreur ou au moins un warning grave quand on avait le malheur d'oublier de mettre le type de retour de la fonction main.
Les compilateurs UNIX créés à des époques ou la mémoire valait une telle fortune que toutes les instructions de base étaient codées sur deux caractères (ls, vi, ed, df etc.) refusaient tout bonnement de compiler votre code si vous déclariez "main" de la façon suivante :
void main(void) ou void main(int argc, char **argv)
Les raisons sont multiples. On peut en trouver un certain nombre par ici : http://users.aber.ac.uk/auj/voidmain.shtml(...)
http://www.delorie.com/djgpp/v2faq/faq22_25.html(...)
Les principales raisons sont :
- Parceque c'est pas standard en C
- Parcequ'un script ou un autre programme n'a aucun moyen de savoir si le programme s'est bien terminé.
- Parceque le système aime bien qu'on lui renvoit un message quand on s'arrète de fonctionner parceque sinon il ne peut pas savoir si c'est le controlleur de processus qui ne se met pas à jour ou si c'est le processus qui ne répond plus.
- En C++ ISO le void main est tout simplement rejeté par le compilo.
Depuis Borland a créé un compilateur C pour dos (le fameux bc1.0). Et sous DOS il y a pas de langage de script à proprement parler, il y a un seul programme et un seul utilisateur à un instant donné et si le programme crashe il y a 99.9% de schance pour qu'il entrainne DOS avec lui.
Dans cette optique Borland c'est dit que void main c'était valable. Et des générations de développeur squi ont découvert la programmation sur le Dos de papa ont utilisé la syntaxe void main. Et certains ont même écrit des livres, en utilisant le void main dans tous les sens.
Seulement voilà, les OS monocouche/monoutilisateur/monoapplication on (heureusement) disparus et les autres ont besoin d'un retour de la fonction main. Windows y compris, en fait avec le nombre de callback et les possibilités d'interactions COM+ windows a absolument besoin d'un retour.
Alors pourquoi déclarer la syntaxe void main comme valide avec tous els dangers que celà représente pour le système ? La réponse est là : http://www.awprofessional.com/articles/article.asp?p=25322&seqN(...)
Tout à la fin de l'article vous verrez :
A void return type, paradoxically, internally results in a return status of 0; that is, the execution environment always interprets the program as having succeeded.
Et oui, si vous déclarer void main le compilo transformera celà en int main et renverra toujours 0 (success). Donc :
- Si votre programme crash le système n'en sera jamais informé, toute les protections qui évitent qu'un programme qui crashe soit relancé en boucle indéfiniment deviennent inutiles
- La signature de votre fonction main() est fausse
- Les appels a des objets COM/COM+ ou autres bibliothèques depuis votre programme deviennent indébuggables (difficile de remonter une erreur jusqu'à sa source quand aucune erreur n'est levée) etc.
On peut trouver des excuses totu à fait valable aux gotos aux indirections multiples et enchevétrées, à la reccursivité non terminale cassée à coup de Break et à d'autres sagouineries qui peuvent s'avérer necessaires dans des cas très particuliers. Mais il n'y a aucune excuse pour utiliser void comme type de retour de main. Même dans les langages ou l'utilité d'un int en type de retour est plus discutable (java par exemple) on ne perd pas grand chose à le faire quand même.
[^] # Re: On va encore dire que je suis un raleur mais...
Posté par TImaniac (site web personnel) . Évalué à 3.
On parle de C#, y'a un système d'exception qui peut être intercepté par la VM : et un message d'exception est autrement plus complet, précis et enrichi qu'un simple numéro de retour .
La signature de votre fonction main() est fausse
Dans le cas où le programme généré est un exécutable Windows ou Unix oui, mais le code C# ou Java est censé être indépendant de ces considérations de "bootstrapping" visant à intégrer l'exécutable dans son environnement.
Les appels a des objets COM/COM+ ou autres bibliothèques depuis votre programme deviennent indébuggables (difficile de remonter une erreur jusqu'à sa source quand aucune erreur n'est levée) etc.
Pareil, C# a été conçu pour intégrer et utiliser facilement un composant COM/COM+, et réciproquement : alors tu penses bien que si celà avait posé un problème... Suffit de bien penser le passage d'un monde à l'autre, et de convertir les valeurs de retour d'erreur en exception.
Bref, même si à l'époque de bc1.0 pour DOS ce choix était vraiment discutable, cette argumentation ne tient plus du tout aujourd'hui puisque d'autres systèmes de message d'erreurs (exception) sont utilisées pour communiquer entre les applications.
Evidemment il y a des cas où celà peut être utile, notamment pour s'intégrer dans un environnement Unix, mais reste que ce cas de figure est de plus en plus rare, et il est normal que le langage n'impose plus ce genre de contrainte, tout en laissant le choix au programmeur d'utiliser cette possibilité s'il en a envie.
[^] # Re: On va encore dire que je suis un raleur mais...
Posté par Jerome Herman . Évalué à 2.
Une terminaison anormale d'un rpogramme ne veut pas forcément dire qu'une exception a été retournée et remontée jusqu'à la VM. En Java celà s'apelle un code rouge. Un exemple simple est quand suite à une destruction un peu trop hative de certains objets on se retrouve à "perdre" des objets fondamentaux à l'execution du programme. Dans 99,99% des ca son va remonte rune erreur, mais j'ai eu le cas d'un programe qui donait toute les apparences de s'executer proprement mais qui en fait se vautrait à un moment, perdait la procédure de boucle et se fermait (nettoyage par le garbage collector des objets inateignable) en apparence proprement.
Je pense qu'un cas similaire peut être codé en .Net pour peu que l'on se penche un peu sur le problème.
mais le code C# ou Java est censé être indépendant de ces considérations de "bootstrapping" visant à intégrer l'exécutable dans son environnement.
En théorie c'est vrai pour Java, en pratique quand on veut faire dialoguer deux threads ou deux processus il y a des fois on a des surprises d'une VM X sur un système x86 à la même VM X sur un système Solaris (vécu inside) . La plupart de ces problèmes ont étés plus ou moins résolus aujorud'hui. Mais de temps en temps ca ressurgit.
Par contre C# est indépendant de la plateforme, mais surement pas du "COM WRAPPER". Comme tu le dis si bien C# a été conçu pour s'intégré très bien avec les objets COM, pour peu que l'on utilise le wrapper par défaut de Microsoft.
Mais même si l'on utilise le wrapper Microsoft on peut avori des surprises. J'ai eu deux collègue squi se sont arrachés les cheveux pendant des semaines sur un programme qui appelait un objet COM en call-back pour les tests d'appoints, mais qui était appelé en natif par l'objet COM lors du fonctionnement normal. Dans ces cas là la déclaration des fonctions compte ennormément, or une des fonctions (pas main, le connecteur base de données) avait deux signatures différentes suivant que l'objet COM appelait le programme ou l'inverse.
Au final il leur a fallu un bon moment pour comprendre pourquoi quand ils utilisaient les fonctions pour tests d'appoints le wrapper finissait par partir en vrille au bout d'un moment.
Je ne connais pas avec précision leur qualité en tant que devoleppeur, et donc je ne peux pas dire si ils ont commis une erreur de débutant ou non. Mais je sais que les objets COM 1.5 ont des procédures d'appels et de référencement très bas niveau, et que si on arrive à gruger le wrapper, on finira par avoir un chouette bazar parceque si le wrapper dit oui, dérrière on attaque le système direct.
Personellement même en Java je fais des "public static int main" ca ne coute rien et c'est utile plus souvent qu'on pourrait le penser.
[^] # Re: On va encore dire que je suis un raleur mais...
Posté par TImaniac (site web personnel) . Évalué à 3.
Le fait est que quasiment plus personne n'utilise ce code d'erreur dans le main, notamment les débutants : alors autant laisser le compilo mettre la BONNE valeur par défaut, plutôt que de forcer le noobs à renvoyer une valeur, noobs qui pourrait très bien s'amuser à mettre return 1 (c'est vrai pourquoi return 0 ?) sans forcement comprendre la portée de ses actes.
Celui qui sait ce que ca fait met une valeur de retour s'il en a envie, je vois vraiment pas où est le problème.
[^] # Re: On va encore dire que je suis un raleur mais...
Posté par Jerome Herman . Évalué à 2.
Oui mais le fait est qu'encore moins de personnes prennent le temps de trapper toutes les erreurs, ou de renvoyer une erreur explicitement, dans ce cas le code erreur du main est toujours bon à prendre.
alors autant laisser le compilo mettre la BONNE valeur par défaut, plutôt que de forcer le noobs à renvoyer une valeur,
Le compilateur ne fera pas un programme à ta place. Il forcera une sortie système à 0, ce qui ne veut rien dire d'autre que 'le programme s'est executé correctement' . Maintenant uen fois de plus ce n'est pas parceque le programme ne génère pas d'exceptions qu'il s'est executé correctement, mais là il n'y a que le programmeur qui peut savoir que quelque chose c'est mal passé. Charge à lui soit de créer et de lever une exception pour chaque erreur, soit de passer un paramêtre pour que le programme se termine correctement et renvoit un entier.
Créer des exceptions pour chaque cas est la solution la plus propre, mais trapper toutes les erreurs possibles peut être fastidieux et particulièrement lent.
... pourrait très bien s'amuser à mettre return 1 (c'est vrai pourquoi return 0 ?)
Le 0 est horriblement pratique ca permet de faire le test d'erreur, le renvoit d'erreur et le numéro d'erreur dans une seule instruction.
par exemple
if (!erreur) traiteerreur(erreur);
On utilise le 0 comme un false et hop le tour est joué.
Celui qui sait ce que ca fait met une valeur de retour s'il en a envie, je vois vraiment pas où est le problème.
Manifestement il doit quand même y en avoir un, sinon pourquoi le compilateur s'amuserait-il a transformer la signature de la fonction pour renvoyer un entier quand même. Et quitte à avoir un entier renvoyé quoi qu'il arrive autant
a) ecrire le code de façon à se que ce renvoit d'entier soit visible
b) utiliser ce renvoit d'entier pour transporter une info (autant en profiter) plutôt que de renvoyer 0 à chaque fois.
c) Il n'est pas improbable (surtout vu l'intégration de C# avec COM+) que votre programme C# soit un jour utilisé via un script WSH sous windows. Dans ce cas là, retourner un entier est une très bonne chose.
[^] # Re: On va encore dire que je suis un raleur mais...
Posté par TImaniac (site web personnel) . Évalué à 2.
Tu n'a pas compris ce que j'ai voulu dire : le débutant renverra peut être autre chose que 0 puisqu'il n'a aucune idée de la signification de cette valeur. D'où l'idée de laisser le compilo mettre un return 0 plutôt que de prendre le risque que le noobs renvoie n'importe quoi. Celui qui connaît la sémantique de la valeur de retour mettra int main s'il en a envie, mais il en sera conscient.
Pour moi on fait :
static int Main(string args[])
si on veut gérer l'interfaçage avec l'environnement (arguments console, valeurs de retour pour le système, etc)
soit on fait :
static void Main()
dans le cas d'une application graphique par exemple, auquel cas les arguments et valeur de retour n'ont plus beaucoup de signification, notamment pour le noobs.
Manifestement il doit quand même y en avoir un, sinon pourquoi le compilateur s'amuserait-il a transformer la signature de la fonction pour renvoyer un entier quand même.
Ouuuuuuiiiiiiinnnnnnnnnnnnnn !!
Je dis que celà ne pose aucun problème, ni pour le programmeur, ni pour le compilo : le compilo se débrouille très bien comme un grand !
Sinon si on suit ton raisonnement, faudrait continuer comme ça pour tous les points du langage :
class truc : object
bah oui, faut expliciter que celà dérive de object, même si le compilateur le met par défaut !
à la fin de toutes les méthodes ne pas oublier de mettre un return : bah oui dans la pratique le compilo il mettra bien return vide !
bref partout quoi.
Le compilo te permet dans le cas du main de t'empêcher de faire une connerie si tu sais pas quelle est la signification de cette valeur de retour, et te laisse la possibilité de spécifier toi même la valeur.
Bref ca gène personne sauf toi.
# Spotlight
Posté par Adrien BUSTANY (site web personnel) . Évalué à 4.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.