Changer de thème Blork Blork of Mana - par Orugari Earthblork - par Yohmgaï Lag - par Chann
Mots clés (3 caractères minimum) :
*Froum :
Tous les froums Copa BlorkanaLes jeux vidéoLecture / ÉcritureFilms, animes et sériesLiens vidéos / Créations et annonces personnellesLes parties en réseauLe Temple du Blam!
Auteur (3 caractères minimum) :
Les champs marqués d'un * sont obligatoires.
Connectez vous pour voir qui est la !
Connectez vous pour accéder à votre messagerie privée !
Tous les blogs
Inscription
Connexion : Retenir | Oubli ?
Destinataire : *
Message : *
Si vous avez oublié votre mot de passe, merci de nous indiquer les renseignements suivants :
Votre pseudo : *
Adresse email de votre profil : *
Page [ 1 2 3 ]
Bas de page
Message laissé le 23/08/12 à 12:19
Bravo, il faut se donner des projets, et partir à l'aventure pour apprendre de nouvelles choses. Si tu fais du C++ (et que tu veux faire de la POO), je te conseille plutôt la SFML pour faire un moteur graphique 2D. En gros y'a trois bibliothèques pour faire des applis multimédias 2D : - SDL - Allegro - SFML SDL et Allegro sont les plus connus, mais SFML est réellement POO et bien mieux foutu en terme d'API que la SDL (la SDL, c'est assez caca quand même). Cependant l'API est moins mature que la SDL. Mais pour te donner une idée de la viabilité, j'utilise personnellement toujours la SFML par rapport à la SDL. De plus, lors des projets C++ qu'on proposait aux étudiants d'école d'ingénieur, on leur conseillait systématiquement la SFML. Cependant, des moteurs de jeux 2D, il y en a pléthore, là où AGS fait la différence, c'est son IDE et son langage de script (ce qui est finalement décorélé du noyau en C++). Pour moi l'intérêt d'un moteur de jeux d'aventure, c'est qu'il soit facilement utilisable pour créer des jeux d'aventure. Soit il fournit une API C++ très haut niveau, ce qui est assez rebutant pour beaucoup de monde. Soit il fournit un langage de script. Ce langage de script, il peut-être ad-hoc (je déconseille, car c'est beaucoup de boulot), où alors c'est un langage de script existant. Le problème de cette dernière approche, c'est que le C++ c'est chiant à binder . Pourquoi tu ne profites pas de ce nouveau projet pour utiliser d'autres technos ? Comme D ou Go qui palient beaucoup de problèmes inhérent à C++.
Message laissé le 23/08/12 à 13:30
Merci Jonath pour tes précisons. Je vais répondre un peu dans le désordres Le coup de SDL / SFML c'est juste une question de gout. j'ai décider SDL car c'est la seul que je connaisse. Si bcq de monde prefere SFML alors je m'y mettrai. Bien que j'ai deja plus ou moins fini la classe SDL/CPP pour le graphisme. les nouveaux langages c'est bien gentil mais je préfère rester sur du "barbu". Car au final on ne sais pas si le langage va continuer a vivre ou non. Puis les tutoriaux sont plus nombreux en c(pp) qu'en D ou go. Certes ca serrai l'occasion mais je pense que je m'y perdrai car on dois déjà connaitre tellement de langage alors en rajouter 1... Sinon pour le langage de script. Ca ne serra pas du script. Ca serra une API C++ mais simplifier justement... genre des classes hero, item, map etc... a moi/nous de faire en sorte que ca colle. mais je suis ouvert a toutes propositions
Message laissé le 23/08/12 à 15:26
C'est une question de goût, oui et non. SDL est en C, SFML en C++, le design est vraiment OO avec héritage malin et tout. Avec SFML tu fais du C++, avec SDL, tu fais un wrapper pour que ce soit pas trop horrible et que ça ressemble à du C++. Mais bon si t'as déjà écrit une partie avec la SDL, t'embêtes pas Et puis sinon, je ne suis pas d'accord, certes C++ est le plus mature, mais bon D a 11 ans, Go est écrit par Google, tu peux y aller ton code va pas mourir dans les 10 ans. Et ce qui pour est après 10 ans, tu auras le temps d'y repenser lors de la réécriture de ton soft (oui ton soft sera réécrit dans 10 ans, c'est un cycle de vie normal d'un logiciel ). De manière générale, faut pas avoir peur de se lancer sur les technos qu'on connaît pas : en ce moment (enfin depuis ces 15 dernières années) ce qui monte c'est l'approche fonctionnel : type safety, inférence de type, quasi tout non mutable, évaluation paresseuse, facilité pour paralléliser (clojure, haskell, scala sont sur les feux de la rampe). Quant à l'API haut niveau C++, c'est à mon avis un mauvais choix. C++ est un langage complexe, pas type-safe. où tu gères la mémoire avec tes mains et où tu peux bidouiller les références : cela fait un langage très difficile d'accès et très error-prone. C'est clairement pas pour les débutants. Enfin mon résumé c'est quand on peut éviter C++, faut le faire Mais bon c'est mon avis, et si t'as une bonne expertise C++ et que c'en est de même pour tes collaborateurs, faut partir sur du C++ .
Message laissé le 23/08/12 à 15:58
ça donne pas envie de se mettre a la progra mon tout petit niveau en C me suffit amplement .
Message laissé le 23/08/12 à 16:21
Citation :
maekring a écrit : ça donne pas envie de se mettre a la progra mon tout petit niveau en C me suffit amplement .
Pourtant, si tu savais tout ce qu' on peut faire grâce a elle...
Message laissé le 23/08/12 à 19:45
Oui non... Le C faut oublier. Ca commence à prendre de la bouteille. Je sais que y'aura toujours des défenseurs de bon et vieux langages comme celui-ci, mais faut savoir passer à autres choses. Mon côté extreme commencerait à me faire penser ça aussi du C++ mais je risque me faire engueuler sévère là Trop vieille ergonomie à mon gout, les prémices de l'objet... Un langage super puissant et super complet, je dis pas le contraire, mais toutes ces histoires de pointeurs et les segmentation fault dans tout les sens, c'est plus ma tasse de thé
Message laissé le 23/08/12 à 19:59
moi je sais pas le C je l'ai après en cours j'avais pas le choix on m'a foutu du python une fois j'ai trouvé ça tellement nul que j'ai laissé filer et oui on peut faire plein de chose mais je passes assez de temps sur le pc pour ne pas en faire encor plus .
Message laissé le 24/08/12 à 09:52
Mais tu as raison Freytaw ... le c/cpp c'est vieux. Énormément de problèmes. Mais toujours bcq utilisé. Par contre le seg fault... c'est que tu ne sais pas codé proprement @maekring => je n'ai pas du tout aimé python non plus. Je suis un fervent développeur de java par contre.
Message laissé le 24/08/12 à 11:07
On peut aussi tout coder en assembleur, les segfaults, ça arrive que pour ceux qui savent pas programmer Et bon, vieux veut pas dire mauvais Regardez Lisp et Scheme, deux superbes langages, toujours tendance, et qui sont aussi vieux voir plus que C. Personnellement je préfère C à C++, sa sémantique est beaucoup plus simple. C++ est bloaté de << nouvelles >> fonctionalités. Le problème, c'est que par soucis de rétro-compatibilité, ça a été introduit de manière complètement ad-hoc... Quant à java, bon je veux pas dire trop de mal de java, mais c'est une catastrophe. Déjà, c'est OO, la POO, ça fait 15 ans qu'on s'est rendu compte que c'était la plus grosse fausse bonne idée de tous les temps. D'ailleurs, pour palier les problèmes énormes de la POO, on a créé les design pattern, un espèce de pansement pour prévenir les dégâts. Ensuite, non seulement c'est OO, mais c'est pas complètement OO, donc faut faire du boxing... De plus, sa gestion du polymorphisme est catastrophique, sa gestion des encodages une misère mais le pire de tout, c'est son énorme retard : - pas de closures - pas de tuples - pas d'arguments nommés - pas d'inférence de types Bordel on est en 201*, pourquoi ce langage s'est arrêté en 1990 ?? Coder en java, c'est un real pain in the ass Par contre la JVM, ça c'est pas trop mal Je ne suis pas fan de python non plus pour plusieurs raisons, mais c'est difficile de comparer avec java, java est un langage compilé, python non, je suppose que c'est plus l'argumentaire "langage compilé"/"langage de scripts" qui vous fait ne pas aimer python ?
Message laissé le 24/08/12 à 11:40
Pour les seg fault, oui, c'est des erreurs de codage. Ca veut pas dire que t'es mauvais, ça veut juste dire que le langage est pas user friendly pour moi. Et vous allez pas me faire croire que vous avez jamais eu de seg-fault ? Puis en même temps, j'ai pas fait de C++ depuis 5 ans donc bon Pour le JAVA, je sais pas si tu t'es essayé à la version 7 Jonath, mais elle corrige bon nombre de problème. Et la version 8 arrive bientôt. Dans tout les cas, et quoi qu'on en dises, le JAVA est plus facile à prendre en main que le C++. Je dis pas que c'est mieux, je préfère juste la syntaxe.
hep je n'ai jamais dis que "seg fault" = "tu ne sais pas prog." on ai pas a epitech ici... (j'ai étudier chez eux.. shame on me) et oui on peux tous faire en asm... mais la c'est du suicide intellectuel C'est vrai que le Cpp et ces nouvelles fonctionnalités sont pénibles. Après on n'est pas obligé de les utilisés. Mais bon ca fais comme une sorte de régression... Si c'est la c'est qu'il y avait un besoin a la base... mais Bon / Pas Bon besoin ca c'est une autre histoire. Pour java, tout les problèmes que tu cite moi je trouve que c'est une bonne chose que ca ne soit pas implémenté (sauf les arguments nommés). Car je trouve que ca fait du code beaucoup plus lisible (choix perso je l'assume). Mais sur l'encodage la on ai bien d'accord... qu'est ce je peux lutter avec cette merde... Et pourquoi tu dis que son polymorphisme et catastrophique je comprend pas ? Pourquoi la POO est une fausse bonne idee ? Je ne vois pas en quoi... Ce qui me déplait dans le pyhton c'est ca syntaxe... j'accroche pas... je n'ai pas essayre le version 7. me suis arreter a la 6 (pour le moment) Et oui la syntaxe java et bien plus simple que cpp !
Message laissé le 24/08/12 à 11:44
Micky a écrit : hep je n'ai jamais dis que "seg fault" = "tu ne sais pas prog." on ai pas a epitech ici... (j'ai étudier chez eux.. shame on me)
Toi non, mais Jonath s'y croit lui à Epitech on dirait Je vais splitter le sujet en deux, parce qu'au final, on va plus disserté sur les langages de programmation que de faire avancer ton projet !
Message laissé le 24/08/12 à 11:51
j'adore le sujet prise de tete lol... mais c'est plus débattre quand même... non ?
Message laissé le 24/08/12 à 13:08
Bah ouais mais moi j'ai un défaut, c'est que quand je programme je fais jamais de bugs C'est pour ça que j'ai pas besoin de debugger, je code, je compile, j'envois direct en prod sans tester : c'est ça la testostérone du programmeur Pourquoi vous faites pas pareil ? Pour la POO, y'a un grave problème d'expression. Que se passe-t-il quand tu veux rajouter une méthode à un type de données ? Tu dois la réécrire pour toutes les classes qui en héritent (bien sûr, avec un peu de chance tu peux un peu factoriser), mais le problème est là : tu dispatches une même fonctionnalité dans plusieurs classes. C'est le problème de la POO c'est données-centrique (l'objet), mais chaque fonctionnalité est défini à moultes endroits différents. Enfin, comment on peut être << contre >> les closures : Code :
list = [1, 3 ,4] new_list = filter(list, (\x -> x > 2)) print(new_list) -> [3, 4]
Et encore, c'est un exemple extrêmement naïf, mais ca permet de faire des fonctions d'ordre supérieur tout en étant type-safe. De même, les tuples c'est pas sale, et ca permet de gérer facilement les fonctions multivaluées. Pareil l'inférence de type, au moins local ça ferait pas de mal : Code :
List<Int> list_int = new List<Int> <-- you don't say ! list_int = new List<Int> <-- ca suffit largement, on connaît le type list_int
Enfin, je vais faire la tête de con, non la syntaxe n'est pas un argument pour dire tel ou tel langage est bien . Ce qui compte c'est ses fonctionnalités et l'expressivité qu'il nous apporte. Ouais java 7 est meilleur que java 6, et java 8 sera meilleur que java 7, je ne fais que constater l'énorme retard. Les closures dans java, on en parle depuis la 1.3 (plus de 10 ans !), et ça arrivera que dans la 1.8 (enfin on espère tous). Et je suis d'accord, java est plus facile à prendre en main que C++, tu ne gères pas la mémoire . Gérer la mémoire, c'est bien un truc qu'on a pas envie de faire (surtout que les GC ça marche plutôt bien).
Message laissé le 24/08/12 à 13:36
je ne comprend pas ton exemple de closure... la c'est juste une fonction qui filtre suivant un pattern... Concernant le typage le faite de l'enlevé (meme qu'en local) je ne suis pas d'accord. ca enleve de la visibilité (ca dépends des méthodes bien sur). mais c'est surtout histoire de moins taper au clavier... la je dis c'est de la feignantise... Je préfère le Typage fort. Mais le vrai pourquoi... j'avoue je n'ai pas vraiment d'argument... c'est un peu comme si on me posais la question "pourquoi tu aime tel couleur ?..." Trop d'emmerde avec le faible. (meme si la c'est pas faible au sens javascript (par exemple)) je préfère en mettre plus que pas assez. Mais tu ne fais pas ta tete de con... j'ai juste parler pour moi. j'ai pas accroché... j'ai pas compris la "philosophie" Mais pardonne moi mais j'ai pas compris en quoi c'était un problème la POO. si ta un bout de code pour illustrer... j'ai pas bien pigé pour le coup...
Message laissé le 24/08/12 à 14:32
Je te rejoins là dessus Micky, le typage fort, y'a que ça de vrai. Et là Jonath, c'est moi qui vais te paraitre condescendant, mais je trouve que ce genre de fonctionnalité, c'est de la branlette intellectuelle. C'est formidable et ça ouvre effectivement de belle possibilité, mais en pratique, dans l'industrie professionnelle, celle que je vis au jour le jour là, ça ne sert à rien. On a pas besoin d'un tel niveau d'abstraction pour coder de vrais applis. Alors c'est sûr, la "vrai" industrie aurait effectivement beaucoup à apprendre sur les méthode de codage du monde libre, mais à un moment donné, je pense que c'est vouloir un peu trop en faire. C'est pousser le perfectionnisme à son paroxysme, si je puis dire. Clairement, les closures, on peut s'en passer. C'est pas pour ça qu'on fera des trucs pourris à coté ! Et puis excuse moi du peu, mais ton premier exemple est franchement illisible pour un non initié à ce type de déclaration. Et d'ailleurs, le problème d'accessibilité du C++ est un des arguments qui font que évidemment, le monde professionnel le boude un peu. Maintenant, je suis bien d'accord que le monde professionnel devrait parfois apprendre à se remettre en question, surtout quand on voit que des trucs super pourris comme Windev existent encore et toujours et envers et contre tout. Mais, du coup, que tu veuilles l'entendre ou non, la syntaxe reste aussi un argument de poids. NB : le nom du sujet, c'est juste une blague. Puis parler boulot sur un forum de décompression, c'est prise de tête pour moi !
Message laissé le 24/08/12 à 14:52
@Micky Non non ce n'est pas un pattern, c'est une fonction (dans mon exemple c'est une fonction anonyme), mais ça peut-être écrit avec une fonction nommée -> Code 1 Et l'inférence de types, c'est du typage fort (et aussi statique), d'ailleurs ce n'est possible qu'avec du typage fort et statique. Ce qu'il se passe c'est que le type est inféré. Dans mon exemple on a en partie droite a List<Int>, on peut inférer que la partie gauche est aussi un List<Int>, donc pas besoin de le réécrire ! Et ça c'est de l'inférence locale, mais l'inférence de types, ça permet d'écrire du code polymorphique très facilement. D'ailleurs, le C++, c'est du typage statique, mais c'est du typage faible (surtout à cause de C), on peut pas faire facilement de l'inférence de types (en java, c'est un typage plus fort, on pourrait plus facilement). Dans les langages de script en général, y'a vérification du type qu'au runtime (typage dynamique). Par contre, peut très bien y avoir du typage fort, et c'est même souvent le cas (Python, Ruby, Prolog, Scheme ... sauf javascript qui est à peu près comme C). Pour un exemple du problème d'expressivité, voilà une modélisation simplifiée pour modéliser une expression mathématique -> Code 2. Je veux ajouter une fonction d'affichage -> Code 3 J'ai mis ma fonction d'affichage dans toutes mes classes héritées, j'ai dispatché et modifier plusieurs fichiers pour une fonction. Maintenant tu prends un projet de taille plus conséquente, comment tu fais pour raisonner sur ta fonction (plus complexe qu'une bête fonction d'affichage) si elle est dispatchée dans 30 classes différentes ? C'est un des gros problèmes du OO. @Freytaw Et je le prends pas mal, mais les closures, c'est loin d'être de la branlette, c'est pour ça que ça arrive dans C++11 et dans java 8. D'ailleurs, le concept de closure est à la racine de quasiment toutes les nouveautés informatiques ces 15 dernière années. De même, il y a un peu d'inférence de type dans C++11 et il y en a aussi un peu dans java 7 (c'est grâce à ça que les génériques sont devenus moins verbeux) -> Code 4 Code1 Code :
is_more_than_2(int x) = return x > 2 list = [1, 3 ,4] new_list = filter(list, is_more_than_2) print(new_list) -> [3, 4]
Code 2 Code :
class Expr {} class Int : Expr { int info } class Plus : Expr { Expr left, right }
Code 3 Code :
class Expr { abstract string toString() } class Int : Expr { int info string toString() { return info.toString() } } class Plus : Expr { Expr left, right string print() { return left.toString() + " + " + right.toString; } }
Code 4 Code :
List<Int> list_int = new List <> (); <-- on répète pas en partie droite
Ah et j'ai trouvé un bug du forum blork, après la fermeture d'une balise code, les retours à la ligne ne sont plus pris en compte Du coup, j'ai mis toutes les balises code en bas, désolé pour la lisibilité.
Message laissé le 24/08/12 à 15:04
Merci pour tes exemples il sont plus parlant. j'ai compris ce que tu voulais dire. mais je rejoins freytow sur tout les points. Pour ce qui est de la faiblesse de la POO, pour moi ca n'en ai pas une. C'est ca force justement. Si tu cree une classe abstraite c'est que tu as besoin que cette méthode soit implémenter (je parle pour ton exemple). Sinon c'est qu'il y a une erreur de conception. et la c'est une autre histoire. L'héritage c'est génial. Mais faut pas en faire tout et n'importe quoi ! windev.. c'est vraiment pourris ce truc... "développer 10x plus vite" oui mais que quoi ? bande de boulay...
Message laissé le 24/08/12 à 15:18
Developper 10 x plus vite et débugger 20 x plus longtemps !
Message laissé le 24/08/12 à 15:19
grave XD
Haut de page