Plus d'excuse possible pour ne pas programmer de jeux sous Linux ! John R. Hall met à disposition (sur son site au format pdf et LaTeX) le livre "Programming Linux Games" qui couvre notament l'utilisation de SDL mais aussi
la gestion du son, du réseau, et l'utilisation d'outil de développement sous Linux. Un bon point de départ pour tout ceux qui veulent créer des jeux.
Huh ? Où as-tu vu que le bouquin parlait de programmation objet ?
Pour atténuer ton troll, deux remarques:
- ClanLib est en C++ (mais le bouquin n'en parle quasi pas)
- Tu peux mettre des morceaux de SDL dans du code C++
Les programmeurs C++ n'ont jamais été obligé par quiconque de faire de l'objet en C.. et s'ils "commencent à y etre habitués", j'en déduirais donc que Gtk est meilleur (oui, on a tous vu que ton troll visait Gtk vs Qt) !
AMHA ce n'était pas un troll. Pas mal de bibliothèques sont en C, et ceux qui font du C++ sont habitués à faire des parties orientées C ou utilisant des bibliothèques en C.
« Tu peux mettre des morceaux de SDL dans du code C++ »
Ce sera, dans ces passages là, un style de programmation plus proche du C que du C++. Mais il n'a pas dit que c'était mal. Ceux qui le veulent peuvent intégrer ça dans des objets, et n'utiliser plus que des objets dans le noyau de leur application.
« Les programmeurs C++ n'ont jamais été obligé par quiconque de faire de l'objet en C.. »
Mais il n'a dit ça nulle part ! Faire des objets autour d'API en C c'est se faire une petite bibliothèque orientée objet utilisant une API en C (mais l'API de la bibliothèque, elle, sera bien en C++), afin que dans le reste de son programme on n'ait pas à faire du C, mais du C++ en n'utilisant que des objets.
C'est vrai qu'il est toujours possible d'encapsuler du C pour en faire du C++. Mais c'est dommage qu'un bouquin qui parle des jeux ne soit pas en C++, langage devenu véritablement standard dans l'industrie du jeu vidéo.
Je dis ça comme ça, mais dans le monde des jeux commerciaux, un programmeur qui ne travaille pas en C++, je lui souhaite bon courage pour se faire embaucher ou que ce soit. (Surtout en ce moment.)
je ne crois pas qu'ils fassent de C++ sur game boy advance. Par contre si tu tates en C, c'est bon. Et puis de toute façon on peut faire de l'objet en C (ça craint un peu, mais bon...).
> de toute façon on peut faire de l'objet en C
Je suis meme tombe un jour sur un prof qui nous a fait faire de l'objet en Prolog. C'est de la perversion 8-)
> kes ke des objets peuvent bien avoir à foutre dans un langage logique comme prolog ??????
Absolument rien AMHA. Ceci dit c'est vrai que "techniquement" tu peux arriver a recreer les concepts d'instance et de classe a l'aide de predicats. Il semble me rappeler qu'on avait meme fait un peu d'heritage. En toute bonne foi, c'est un des trucs les plus louches que j'ai jamais vu en info, c'etait limite incomprehensible, je n'en ai jamais vu aucune application utile, et en toute sincerite vu la complexite du bidule je pense que ce genre de manip est reserve a une certaines categorie de chercheurs illumines -<8-P
« C'est vrai qu'il est toujours possible d'encapsuler du C pour en faire du C++. Mais c'est dommage qu'un bouquin qui parle des jeux ne soit pas en C++, langage devenu véritablement standard dans l'industrie du jeu vidéo. »
Quel est le problème ?... avoir des exemples en C alors qu'un programme sera plutot en C++ ? Mais ce dont il est question c'est souvent assez bas niveau, le C convient très bien. Le C++ sera surement mieux si tu parles de design. Beaucoup de bibliothèques utiles pour les jeux sont en C, ça n'empeche pas de les utiliser en C++. Ce qui compte c'est le contenu, pas le langage, surtout quand il ne s'agit que d'exemples et que la plupart des API utiles aux jeux sont en C.
C'est mal de tout programmer en C. Il faut programmer dans des langages de plus haut niveau pour accélerer le cycle de développement, avoir des programmes plus sûrs et plus maintenables (car plus courts). Et bien sûr les parties critiques du code peuvent être encore écrites en C (voire en assembleur, soyons fous).
Franchement, par exemple pour SDL, quand tu sais que tu as le choix entre une quinzaine de bindings différents, avec entre autre C++, Perl, Python, Ruby, ou OCaml c'est vraiment dommage d'utiliser du C pur.
Hint : choisir OCaml parmi les langages sus-cités (hail language troll).
À propos, j'aime beaucoup Ruby, et je me suis toujours demandé dans quelle mesure un script ruby était plus lent qu'un programme compilé. Dans le cas d'un jeu, ça doit commencer à se sentir (vu que pas mal de jeux codés en C/C++ rament sur ma machine). Bon je sais bien qu'il est facile d'incorporer du code C compilé dans un script ruby, mais ça perd un peu de son intérêt.
Ça te fait du bien de taper sur un logiciel toute la journée ?
C'est pour compenser le fait que tu n'as pas pu rencontrer les gens à qui tu voulais casser la gueule ?
Tiens c'est curieux moi c'est exactement l'inverse.. Je me fous aussi que ce soit du C ou du C++, (ie. du Gtk ou du Qt), tant pis pour le programmeur.. par contre, je vois bien quand l'un des deux me permets de détacher les menus, de changer mes raccourcis à la volée, ou de ne pas me faire chier avec des dockables windoze (faites moi penser à flinguer le mec qui a inventé ca)
A part ca, tu sais faire des critiques plus constructives et moins débile que de dire "ca sux", ou tu profites juste du fait que les XP ne sont plus là ? Parce que bon, j'aurai aimé pouvoir te dire que je suis *ravi* d'apprendre que tu trouves que Gnome sux.. mais non, je m'en contrefous
Euh, tu as l'air ironique, mais pouvoir détacher les menus et changer les raccourcis clavier à la volée, c'est aussi un de mes critères de choix pour un environnement. Et ce sont aussi des arguments bien plus concrets de dire que Gnome sux et KDE rulez sarace.
Yusei, qui utilise Window Maker avec des applications Gnome, KDE, ou autre, mais qui préfère vraiment les interfaces à base de Gtk.
Ahlala, l'art de prendre ses interlocuteurs pour des crétins décérébrés.
T'es gentil, on parlera de nuances quand ton argumentaire comportera autre chose que des "rox", "sux" et "c'est de la merde". Et quand tu auras appris à lire car je ne prenais pas position sur Gnome ni sur Gtk-en-tant-que-programmeur, je ne faisais que réagir à ton mépris envers quelque qui utilise des arguments.
(J'veux avoir le droit de mettre -1 quand je répond à un troll !)
Juste pour info, l'utilisateur lambda est *tres* concerné par l'interface de son PC.. c'est aussi pour ca que Linux a du mal à s'imposer (beaucoup d'entre eux croient que Linux ne fonctionne qu'en ligne de commande). Et un bon point de KDE: par défaut, cliquer sur un icone lance l'appli (pas comme Gnome ou faut le faire deux fois, c'est idiot et contre-intuitif - a peu pres aussi contre-intutif que de faire Alt-F4 pour "close")
Si on me dit "ce bureau ci est plus fatiguant que celui là" (parce que, par exemple, 30% des clicks ne sont pas réellement nécessaires, ainsi que 20 mètres de souris à parcourir(1)), et bien ca fait clairement pencher mon choix..
Et pour alimenter le débat Gnome/KDE-pour-les-lambdas-user, je trouve, non pardon, j'ai constaté que pour les newbies, Nautilus est beaucoup plus accessible que Konqueror.. ses "emblemes" et les "notes", que nous trouvons stupides, se sont révélés etre une tres bonne idée pour les newbies (j'ai meme vu des windozeurs demander à faire une telle chose dans MSExplorer (sans savoir que Nautilus le faisait)). Ce serait une bonne idée de rajouter ca dans Konqueror
(1): Au fait, je me suis toujours demandé l'interet de placer le panel en bas, alors que la plupart du temps, la souris passe son temps vers le haut des fenetres (là où sont les barres de titre)
Sauf que convertir un CD en .ogg, ca n'est pas du tout le boulot du gestionnaire de fichier, mais plutot d'un truc comme Grip. Avoir changé de gestionnaire de fichier pour quelque chose qui est particulièrement accessoire, c'est à peine crédible - Si encore, le CD pouvait se trouver dans des endroits très différents de l'arboressence, ou si encore on pouvait ripper autre chose que des CD, je comprendrais que ca figure dans le gestionnaire de fichier, mais là, que ce soit integré à Konqueror, ou que ce soit une appli externe, c'est strictement identique !
Peut-etre que (et vu tes délires anti-gnome, c'est particulièrement possible) que tu t'es bien gardé de lui montrer Grip, c'est ca ?
A tu deja compare en terme de vitesse GNOME et KDE ?
Tu as vite choisi :)
Meme sur une machine puissante KDE n'est d'une rapidite quasi instanne a la GNOME ou GnuStep+WindowMaker.
Et puis vouloir absolument que ca ressemble a windows, c'est plus pitoyable qu'autre chose.
Et pour finir, les applet dans le panel GNOME, c'est vraiment terrible. Il n'y a pas ca dans kde il me semble, mais je peux me tromper .....
Et puis vouloir absolument que ca ressemble a windows, c'est plus pitoyable qu'autre chose.
C'est aussi ce que je pensais, au début.. mais finalement, je trouve que c'est une bonne chose qu'on ait au moins un desktop cloné sur MSWin jusque dans ses raccourcis claviers.. Ca permet aux windozeurs de faire une transition plus facile, et d'attirer les lusers type slashdotteurs "c'est pas comme MSWin == c'est nul". L'important, c'est qu'on n'est pas obligé de l'utiliser, ou qu'on peut le configurer pour qu'il soit plus efficace et (ie. par exemple, changer le mode de focus) et plus beau (KDE 3.1 est horrible par défaut, on dirait du Playschool)...
mouuaarrrf A tu deja compare en terme de vitesse GNOME et KDE ?
et Il n'y a pas ca dans kde il me semble, mais je peux me tromper .....
il y a des applets dans kde , il est meme compatbile avec les dockapp windowmaker , bref qd on met ces 2 phrases l une a coté de l autre , on se demande si t as reelment testé kde...
>il y a des applets dans kde
Dans GNOME aussi. Et surement meme plus complexe.
>bref qd on met ces 2 phrases l une a coté de l autre , on se demande si t as reelment >testé kde...
Sisi, je l'ai tester et ca ne m'a vraiment pas convaincu. C'est d'une lenteur affligente.
> C' est marrant qd meme , precedement tu disais que y avait pas d applet dans kde et >maintenant tu dis que dans gnome elles sont plus complexes...
J'ai dis que je n'etait *pas sur de leur presence*, nuance (d'ou le "je peux me tromper" :) et qu'an tous cas ceux de GNOME etait terrible ! Tu as la facheuse habitude de tranforme ce que les gend dise .....
>Enfin bon juger un desktop sur ces applets c est un peu n importequoi n dans ce cas >windowmaker est forcement ce qu il y a de mieux.
Les applets c'est une chose parmis d'autre mais ca a son importance. Ceci dit je serais d'accord pour dire qu'il n'y a pas que ca.
>il y a des applets dans kde
Dans GNOME aussi. Et surement meme plus complexe.
>bref qd on met ces 2 phrases l une a coté de l autre , on se demande si t as reelment >testé kde...
Sisi, je l'ai tester et ca ne m'a vraiment pas convaincu. C'est d'une lenteur affligente.
Vivement que Linux soit programmé en Lisp ou en OCaml, que les utilisateurs aient enfin le système sûr qu'ils méritent. Les jeux qui seront alors programmés dans les mêmes langages auront une qualité incomparable avec ceux disponibles actuellement, programmés dans des langages aussi archaïques que le C ou le C++. De plus, grâce a l'instantanéité du développement en Lisp et en OCaml on aura la version 2 du hit du moment le lendemain, et la version 3 le surlendemain.
Je me réjouis qu'en ces sombres heures conservatrices, des gens audacieux osent enfin dire la vérité et s'élever contre la barbarie C et la dictature Kernighan et Ritchie. Ces deux sombres imbéciles, qui ont fait perdre 30 ans à l'informatique, meriteront tout le mal qu'on dira d'eux lorsque l'ensemble des programmeurs aura reconnu la supériorité d'OCaml.
Mais ca sera sans compter l'offensive des sorciers du clan PERL, qui se feront une joie sans limite de semer le chaos dans ton joli univers en technicolor !
Les plus beaux poemes sont ecrits en PERL, argument indiscutable pour programmer jeu comme Frozen Bobble !
> langages de plus haut niveau pour accélerer le cycle de développement,
Mouaif, bof. Developper en Python/Perl/Ruby je veux bien que ce soit plus rapide qu'en C standard. Mais concernant le C++, je suis pas sur.
J'ai personnellement developpe 2 projets de complexite equivalente, l'un en C, l'autre en C++. Celui en C est paradoxalement plus facile a maintenir; paradoxalement car il est vrai que tout le monde (ou presque) semble s'accorder pour dire que le C++ est plus maintenable.
Le probleme du C++, c'est que:
- il est moins standardise. Concretement, tu peux avoir des problemes de format de binaire (gcc 2.x vs gcc 3.x). Certains toolkits super utiles comme STL marchent bizarrement sur certaines plates-formes (Visual C++ pour ne pas le citer...), et d'une maniere generale il est plus facile de trouver un plus petit denominateur commun en C qu'en C++.
- les temps de compilation en C++ sont redhibitoires. Avec mon projet C++, je suis monte a 45 minutes de compilation sur un P200. Maintenant sur un Athlon 1.4GHz ca va un peu mieux, mais par rapport a du C c'est je jour et la nuit. Donc concretement, je passe la moitie du temps a compiler quand je programme en C++, alors qu'en C c'est quasi instantane.
- le C++ a tendance a pousser les gens vers la perfection. Et c'est pas toujours un bien. On se dit "Ah oui je pourrais peut-etre faire un truc conceptuellement plus beau en faisant ceci ou en faisant cela...". Et du coup on passe son temps a remodeler des trucs qui marchaient deja. En C je trouve que les criteres d'appreciation du code sont plus simples: ca fait ce qu'on veut, ca plante pas -> OK c'est bon.
- le C++ est AMHA beaucoup moins lisible/facile a comprendre que le C. En effet, le language aide le programmeur donc le programmeur n'hesite pas a mettre en place des mecanismes assez complexes. Pour prendre l'exemple de ClanLib, le code est assez dur a comprendre. Tu as des classes qui font Provider de ceci ou de cela, des trucs qui heritent de partout, du masquage de donnees, des concepts a tout va, des connecteurs en veux-tu en voila. Au final, c'est tres joli, mais beaucoup plus dur a comprendre qu'un code qui ferait la meme chose en C. Enfin c'est mon avis.
- en parlant de maintenabilite du C++, je rappelle que ClanLib, qui est en C++, a une API extremement instable qui bouge tout le temps, et est bien loin derriere SDL et Allegro ( http://www.talula.demon.co.uk/allegro/(...) ) en terme de stabilite (je parle ici de la stabilite au sens "ne pas faire de core dump"). Typiquement, les developpeurs de ClanLib ne cessent de faire du "redesign" de l'API parce que "ca sera plus beau comme ca", et la bibliotheque est pas mal victime de bugs lies au C++ (destructeurs appeles 2 fois, fuites memoire...). Prenons un exemple, la gestion des fichiers "a la .wad" a savoir stocker des donnees dans un seul fichier, et y acceder par mot-cle. Les developpeurs d'Allegro ont fait un truc super basique. Tu peux grosso-modo stocker les types "de base" de la lib (font, bitmap, sample...) et pour tes donnees "a toi" on t'offre la possibilite de manipuler le type de donnees "raw data" et tu recupere un pointeur "void *" sur tes donnees. Ca permet de tout faire. Mais c'est pas beau. Avec ClanLib en C++, c'est boOOOO! Par contre l'API a deja change au moins une fois en 2 ans (5 ans sans aucun changement pour Allegro). Tu dispose de supers classes de la mort pour enregistrer toi-meme ton propre type de donnees etc. Genial, mais en quoi cela fait-il gagner du temps? Moi je ne vois pas. Avec le bon vieux "void *" on en faisait autant... De plus, le C++ ne permet absolument pas de s'affranchir des problemes de faute memoire. Par contre, c'est vrai, c'est plus joli. Maintenant faut savoir si on veut faire du code joli ou du code qui marche.
Pour finir avec cette reflexion, je tiens a preciser que les developpeurs de ClanLib font un *excellent* boulot, sont tres competents, et mon propos n'est absolument pas de dire que leur projet est mediocre. Au contraire. Mais je ne vois pas en quoi C++ leur fait gagner du temps...
avec latex (j'ai pas regardé, mais a priori, les .tex sont surement des fichiers Latex), qui les compile et génère un dvi, que tu peux lire avec xdvi, ou transformer en postscript avec dvips
« le contenu des pdf ne semblent n'avoir aucun rapport avec le contenu des tex
Avec quel outil lit-on les .tex SVP ? »
Si tu ne connais pas LaTeX, ça n'a sans doute aucun intérêt pour toi de lire ces fichiers .tex. On les lit avec un éditeur de texte, rien d'autre, ce que tu y trouves ce sont des commandes en langage LaTeX, et une fois compilé ça donne le pdf. Les différentes étapes apparaissent dans le Makefile, si tu veux le détail des outils utilisés. Le .tex n'est vraiment utile ici que pour modifier. Ce qui n'est pas encore autorisé, l'auteur espère le passer en libre prochainement, mais ce n'est pas encore le cas, il est simplement gratuit et disponible en ligne.
# Re: Le livre
Posté par Samuel Pajilewski . Évalué à 1.
Il est pas mal, recouvre un peu tous les outils de dvlt de Linux, les methodes de Debuggages (comme quoi on avait pas besoin d'attendre IBM)
Ce serait un hommage a M. Hall d'acheter son livre plutot que de le pomper sur le Net.
C vrai quoi, des livres comme celui là il n'en existe pas tant !
Seul regret toutefois : Tout est en C, les fans de C++ seront deçus.
[^] # Re: Le livre
Posté par kruskal . Évalué à 1.
[^] # Re: Le livre
Posté par nodens . Évalué à 1.
--
mais ou est passée ma signature !!
[^] # Re: Le livre
Posté par Fabimaru (site web personnel) . Évalué à 1.
[^] # Re: Le livre
Posté par Benjamin . Évalué à 1.
Pour atténuer ton troll, deux remarques:
- ClanLib est en C++ (mais le bouquin n'en parle quasi pas)
- Tu peux mettre des morceaux de SDL dans du code C++
Les programmeurs C++ n'ont jamais été obligé par quiconque de faire de l'objet en C.. et s'ils "commencent à y etre habitués", j'en déduirais donc que Gtk est meilleur (oui, on a tous vu que ton troll visait Gtk vs Qt) !
[^] # Re: Le livre
Posté par #3588 . Évalué à 1.
« Tu peux mettre des morceaux de SDL dans du code C++ »
Ce sera, dans ces passages là, un style de programmation plus proche du C que du C++. Mais il n'a pas dit que c'était mal. Ceux qui le veulent peuvent intégrer ça dans des objets, et n'utiliser plus que des objets dans le noyau de leur application.
« Les programmeurs C++ n'ont jamais été obligé par quiconque de faire de l'objet en C.. »
Mais il n'a dit ça nulle part ! Faire des objets autour d'API en C c'est se faire une petite bibliothèque orientée objet utilisant une API en C (mais l'API de la bibliothèque, elle, sera bien en C++), afin que dans le reste de son programme on n'ait pas à faire du C, mais du C++ en n'utilisant que des objets.
[^] # Faire des jeux en C....
Posté par Nurbo . Évalué à 1.
Je dis ça comme ça, mais dans le monde des jeux commerciaux, un programmeur qui ne travaille pas en C++, je lui souhaite bon courage pour se faire embaucher ou que ce soit. (Surtout en ce moment.)
[^] # Re: Faire des jeux en C....
Posté par phq . Évalué à 1.
[^] # Re: Faire des jeux en C....
Posté par ufoot (site web personnel) . Évalué à 1.
Je suis meme tombe un jour sur un prof qui nous a fait faire de l'objet en Prolog. C'est de la perversion 8-)
[^] # Re: Faire des jeux en C....
Posté par phq . Évalué à 1.
[^] # Re: Faire des jeux en C....
Posté par ufoot (site web personnel) . Évalué à 1.
Absolument rien AMHA. Ceci dit c'est vrai que "techniquement" tu peux arriver a recreer les concepts d'instance et de classe a l'aide de predicats. Il semble me rappeler qu'on avait meme fait un peu d'heritage. En toute bonne foi, c'est un des trucs les plus louches que j'ai jamais vu en info, c'etait limite incomprehensible, je n'en ai jamais vu aucune application utile, et en toute sincerite vu la complexite du bidule je pense que ce genre de manip est reserve a une certaines categorie de chercheurs illumines -<8-P
[^] # Re: Faire des jeux en C....
Posté par LeMagicien Garcimore . Évalué à 1.
[^] # Re: Faire des jeux en C....
Posté par #3588 . Évalué à 1.
Quel est le problème ?... avoir des exemples en C alors qu'un programme sera plutot en C++ ? Mais ce dont il est question c'est souvent assez bas niveau, le C convient très bien. Le C++ sera surement mieux si tu parles de design. Beaucoup de bibliothèques utiles pour les jeux sont en C, ça n'empeche pas de les utiliser en C++. Ce qui compte c'est le contenu, pas le langage, surtout quand il ne s'agit que d'exemples et que la plupart des API utiles aux jeux sont en C.
# Le C c'est mal
Posté par gc (site web personnel) . Évalué à 1.
Franchement, par exemple pour SDL, quand tu sais que tu as le choix entre une quinzaine de bindings différents, avec entre autre C++, Perl, Python, Ruby, ou OCaml c'est vraiment dommage d'utiliser du C pur.
Hint : choisir OCaml parmi les langages sus-cités (hail language troll).
[^] # Re: Le C c'est mal
Posté par Yusei (Mastodon) . Évalué à 1.
[^] # Re: Le C c'est mal
Posté par Prosper . Évalué à 1.
oui mais si tu fais pas du C t es pas un pur et dur t es une tapaite , pour preuve , pour beaucoup kde sux parce que c est du c++
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Le C c'est mal
Posté par Jar Jar Binks (site web personnel) . Évalué à 1.
C'est pour compenser le fait que tu n'as pas pu rencontrer les gens à qui tu voulais casser la gueule ?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Le C c'est mal
Posté par Benjamin . Évalué à 1.
A part ca, tu sais faire des critiques plus constructives et moins débile que de dire "ca sux", ou tu profites juste du fait que les XP ne sont plus là ? Parce que bon, j'aurai aimé pouvoir te dire que je suis *ravi* d'apprendre que tu trouves que Gnome sux.. mais non, je m'en contrefous
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Le C c'est mal
Posté par Yusei (Mastodon) . Évalué à 1.
Yusei, qui utilise Window Maker avec des applications Gnome, KDE, ou autre, mais qui préfère vraiment les interfaces à base de Gtk.
[^] # Re: Le C c'est mal
Posté par Jar Jar Binks (site web personnel) . Évalué à 1.
Ne dis pas ça, tu vas te faire démolir.
GTK+ ça suXe, la preuve ils l'ont dit sur Internet, ça ne peut donc pas être faux.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Le C c'est mal
Posté par kadreg . Évalué à 1.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Le C c'est mal
Posté par Yusei (Mastodon) . Évalué à 1.
T'es gentil, on parlera de nuances quand ton argumentaire comportera autre chose que des "rox", "sux" et "c'est de la merde". Et quand tu auras appris à lire car je ne prenais pas position sur Gnome ni sur Gtk-en-tant-que-programmeur, je ne faisais que réagir à ton mépris envers quelque qui utilise des arguments.
(J'veux avoir le droit de mettre -1 quand je répond à un troll !)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Le C c'est mal
Posté par Sylvestre Ledru (site web personnel) . Évalué à 1.
[^] # Re: Le C c'est mal
Posté par Jar Jar Binks (site web personnel) . Évalué à 1.
[^] # Re: Le C c'est mal
Posté par Yusei (Mastodon) . Évalué à 1.
[^] # Re: Le C c'est mal
Posté par Benjamin . Évalué à 1.
Si on me dit "ce bureau ci est plus fatiguant que celui là" (parce que, par exemple, 30% des clicks ne sont pas réellement nécessaires, ainsi que 20 mètres de souris à parcourir(1)), et bien ca fait clairement pencher mon choix..
Et pour alimenter le débat Gnome/KDE-pour-les-lambdas-user, je trouve, non pardon, j'ai constaté que pour les newbies, Nautilus est beaucoup plus accessible que Konqueror.. ses "emblemes" et les "notes", que nous trouvons stupides, se sont révélés etre une tres bonne idée pour les newbies (j'ai meme vu des windozeurs demander à faire une telle chose dans MSExplorer (sans savoir que Nautilus le faisait)). Ce serait une bonne idée de rajouter ca dans Konqueror
(1): Au fait, je me suis toujours demandé l'interet de placer le panel en bas, alors que la plupart du temps, la souris passe son temps vers le haut des fenetres (là où sont les barres de titre)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Le C c'est mal
Posté par Benjamin . Évalué à 1.
Peut-etre que (et vu tes délires anti-gnome, c'est particulièrement possible) que tu t'es bien gardé de lui montrer Grip, c'est ca ?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Le C c'est BIEN
Posté par kb . Évalué à 1.
Tu as vite choisi :)
Meme sur une machine puissante KDE n'est d'une rapidite quasi instanne a la GNOME ou GnuStep+WindowMaker.
Et puis vouloir absolument que ca ressemble a windows, c'est plus pitoyable qu'autre chose.
Et pour finir, les applet dans le panel GNOME, c'est vraiment terrible. Il n'y a pas ca dans kde il me semble, mais je peux me tromper .....
[^] # Re: Le C c'est BIEN
Posté par Benjamin . Évalué à 1.
C'est aussi ce que je pensais, au début.. mais finalement, je trouve que c'est une bonne chose qu'on ait au moins un desktop cloné sur MSWin jusque dans ses raccourcis claviers.. Ca permet aux windozeurs de faire une transition plus facile, et d'attirer les lusers type slashdotteurs "c'est pas comme MSWin == c'est nul". L'important, c'est qu'on n'est pas obligé de l'utiliser, ou qu'on peut le configurer pour qu'il soit plus efficace et (ie. par exemple, changer le mode de focus) et plus beau (KDE 3.1 est horrible par défaut, on dirait du Playschool)...
[^] # Re: Le C c'est BIEN
Posté par Prosper . Évalué à 1.
et Il n'y a pas ca dans kde il me semble, mais je peux me tromper .....
il y a des applets dans kde , il est meme compatbile avec les dockapp windowmaker , bref qd on met ces 2 phrases l une a coté de l autre , on se demande si t as reelment testé kde...
[^] # Re: Le C c'est BIEN
Posté par kb . Évalué à 1.
Dans GNOME aussi. Et surement meme plus complexe.
>bref qd on met ces 2 phrases l une a coté de l autre , on se demande si t as reelment >testé kde...
Sisi, je l'ai tester et ca ne m'a vraiment pas convaincu. C'est d'une lenteur affligente.
[^] # Re: Le C c'est BIEN
Posté par Prosper . Évalué à 1.
Enfin bon juger un desktop sur ces applets c est un peu n importequoi n dans ce cas windowmaker est forcement ce qu il y a de mieux.
[^] # Re: Le C c'est BIEN
Posté par Yusei (Mastodon) . Évalué à 1.
Ben... oui, à croire que c'est pas un si mauvais critère ;-)
[^] # Re: Le C c'est BIEN
Posté par kb . Évalué à 1.
J'ai dis que je n'etait *pas sur de leur presence*, nuance (d'ou le "je peux me tromper" :) et qu'an tous cas ceux de GNOME etait terrible ! Tu as la facheuse habitude de tranforme ce que les gend dise .....
>Enfin bon juger un desktop sur ces applets c est un peu n importequoi n dans ce cas >windowmaker est forcement ce qu il y a de mieux.
Les applets c'est une chose parmis d'autre mais ca a son importance. Ceci dit je serais d'accord pour dire qu'il n'y a pas que ca.
[^] # Re: Le C c'est BIEN
Posté par kb . Évalué à 1.
Dans GNOME aussi. Et surement meme plus complexe.
>bref qd on met ces 2 phrases l une a coté de l autre , on se demande si t as reelment >testé kde...
Sisi, je l'ai tester et ca ne m'a vraiment pas convaincu. C'est d'une lenteur affligente.
[^] # Re: Le C c'est mal
Posté par Herrera Carlos . Évalué à 1.
Vivement que Linux soit programmé en Lisp ou en OCaml, que les utilisateurs aient enfin le système sûr qu'ils méritent. Les jeux qui seront alors programmés dans les mêmes langages auront une qualité incomparable avec ceux disponibles actuellement, programmés dans des langages aussi archaïques que le C ou le C++. De plus, grâce a l'instantanéité du développement en Lisp et en OCaml on aura la version 2 du hit du moment le lendemain, et la version 3 le surlendemain.
Je me réjouis qu'en ces sombres heures conservatrices, des gens audacieux osent enfin dire la vérité et s'élever contre la barbarie C et la dictature Kernighan et Ritchie. Ces deux sombres imbéciles, qui ont fait perdre 30 ans à l'informatique, meriteront tout le mal qu'on dira d'eux lorsque l'ensemble des programmeurs aura reconnu la supériorité d'OCaml.
[^] # Re: Le C c'est mal
Posté par Yohann (site web personnel) . Évalué à 1.
Les plus beaux poemes sont ecrits en PERL, argument indiscutable pour programmer jeu comme Frozen Bobble !
[^] # Re: Le C c'est mal
Posté par ufoot (site web personnel) . Évalué à 1.
Mouaif, bof. Developper en Python/Perl/Ruby je veux bien que ce soit plus rapide qu'en C standard. Mais concernant le C++, je suis pas sur.
J'ai personnellement developpe 2 projets de complexite equivalente, l'un en C, l'autre en C++. Celui en C est paradoxalement plus facile a maintenir; paradoxalement car il est vrai que tout le monde (ou presque) semble s'accorder pour dire que le C++ est plus maintenable.
Le probleme du C++, c'est que:
- il est moins standardise. Concretement, tu peux avoir des problemes de format de binaire (gcc 2.x vs gcc 3.x). Certains toolkits super utiles comme STL marchent bizarrement sur certaines plates-formes (Visual C++ pour ne pas le citer...), et d'une maniere generale il est plus facile de trouver un plus petit denominateur commun en C qu'en C++.
- les temps de compilation en C++ sont redhibitoires. Avec mon projet C++, je suis monte a 45 minutes de compilation sur un P200. Maintenant sur un Athlon 1.4GHz ca va un peu mieux, mais par rapport a du C c'est je jour et la nuit. Donc concretement, je passe la moitie du temps a compiler quand je programme en C++, alors qu'en C c'est quasi instantane.
- le C++ a tendance a pousser les gens vers la perfection. Et c'est pas toujours un bien. On se dit "Ah oui je pourrais peut-etre faire un truc conceptuellement plus beau en faisant ceci ou en faisant cela...". Et du coup on passe son temps a remodeler des trucs qui marchaient deja. En C je trouve que les criteres d'appreciation du code sont plus simples: ca fait ce qu'on veut, ca plante pas -> OK c'est bon.
- le C++ est AMHA beaucoup moins lisible/facile a comprendre que le C. En effet, le language aide le programmeur donc le programmeur n'hesite pas a mettre en place des mecanismes assez complexes. Pour prendre l'exemple de ClanLib, le code est assez dur a comprendre. Tu as des classes qui font Provider de ceci ou de cela, des trucs qui heritent de partout, du masquage de donnees, des concepts a tout va, des connecteurs en veux-tu en voila. Au final, c'est tres joli, mais beaucoup plus dur a comprendre qu'un code qui ferait la meme chose en C. Enfin c'est mon avis.
- en parlant de maintenabilite du C++, je rappelle que ClanLib, qui est en C++, a une API extremement instable qui bouge tout le temps, et est bien loin derriere SDL et Allegro ( http://www.talula.demon.co.uk/allegro/(...) ) en terme de stabilite (je parle ici de la stabilite au sens "ne pas faire de core dump"). Typiquement, les developpeurs de ClanLib ne cessent de faire du "redesign" de l'API parce que "ca sera plus beau comme ca", et la bibliotheque est pas mal victime de bugs lies au C++ (destructeurs appeles 2 fois, fuites memoire...). Prenons un exemple, la gestion des fichiers "a la .wad" a savoir stocker des donnees dans un seul fichier, et y acceder par mot-cle. Les developpeurs d'Allegro ont fait un truc super basique. Tu peux grosso-modo stocker les types "de base" de la lib (font, bitmap, sample...) et pour tes donnees "a toi" on t'offre la possibilite de manipuler le type de donnees "raw data" et tu recupere un pointeur "void *" sur tes donnees. Ca permet de tout faire. Mais c'est pas beau. Avec ClanLib en C++, c'est boOOOO! Par contre l'API a deja change au moins une fois en 2 ans (5 ans sans aucun changement pour Allegro). Tu dispose de supers classes de la mort pour enregistrer toi-meme ton propre type de donnees etc. Genial, mais en quoi cela fait-il gagner du temps? Moi je ne vois pas. Avec le bon vieux "void *" on en faisait autant... De plus, le C++ ne permet absolument pas de s'affranchir des problemes de faute memoire. Par contre, c'est vrai, c'est plus joli. Maintenant faut savoir si on veut faire du code joli ou du code qui marche.
Pour finir avec cette reflexion, je tiens a preciser que les developpeurs de ClanLib font un *excellent* boulot, sont tres competents, et mon propos n'est absolument pas de dire que leur projet est mediocre. Au contraire. Mais je ne vois pas en quoi C++ leur fait gagner du temps...
Sur ce, bonne fin de week-end.
# Re: Le livre
Posté par MeccaNo . Évalué à 1.
le contenu des pdf ne semblent n'avoir aucun rapport avec le contenu des tex
Avec quel outil lit-on les .tex SVP ?
bon week
[^] # Re: Le livre
Posté par Benjamin . Évalué à 1.
[^] # Re: Le livre
Posté par Aurelien . Évalué à 1.
Aprés il faut avoir Latex et les bon outils pour que la "compilation" du pdf se déroule bien.
[^] # Re: Le livre
Posté par Aurelien . Évalué à 1.
Il y a 2 options :
make pdf , pour obtenir le fichier pdf.
make clean , pour effacer les fichiers temporaires.
J'ai pas testé mais le Makefile semble correcte.
[^] # Re: Le livre
Posté par #3588 . Évalué à 1.
Avec quel outil lit-on les .tex SVP ? »
Si tu ne connais pas LaTeX, ça n'a sans doute aucun intérêt pour toi de lire ces fichiers .tex. On les lit avec un éditeur de texte, rien d'autre, ce que tu y trouves ce sont des commandes en langage LaTeX, et une fois compilé ça donne le pdf. Les différentes étapes apparaissent dans le Makefile, si tu veux le détail des outils utilisés. Le .tex n'est vraiment utile ici que pour modifier. Ce qui n'est pas encore autorisé, l'auteur espère le passer en libre prochainement, mais ce n'est pas encore le cas, il est simplement gratuit et disponible en ligne.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.