Citation:
Envoyé par
fcharton
Effectivement, sauf à partir du principe qu'on lie dynamiquement (c'est une lib système normalement présente sur tout système windows post 2000...). Mais d'accord là dessus...
Ce qu'il y a, c'est qu'il faut, au moment de l'édition des liens, que ld (car c'est lui qui s'en occupera) sache que "telle fonction" est fournie par gdiplus.dll.
Autrement, il te sortira un erreur "undefined reference to (function) ".
Citation:
Ca c'est facile, c'est du microsoft de base. Tu l'as avec Windows pour faire tourner des machines windows... Je pense qu'il faudrait que farfelue fonctionne avec les fichiers Microsoft natifs, c'est cela qui va être un rien compliqué, vu que notre logique est différente des principes de programmation Windows (enfin, je pense, hein?)
Je parlais de la licence des fichiers d'en-tête...
On ne peut pas "simplement" se contenter de les copier du dossier include de VS ou de Borland dans le dossier include de Gcc.
Il y a plusieurs raisons à cela:
Ils sont fournis sous la licence attachée au compilateur.
Tu peux donc créer une application (commerciale ou non) qui utilise les fichier d'en-tête, mais tu risque de ne peux pas pouvoir donner les fichiers d'en-tête à tout le monde et n'importe qui.
Par contre, tu peux écrire toute une documentation sur ces fichiers d'en-tête, et je peux, sur base de la lecture de celle-ci, créer un fichier d'en-tête adapté à mon compilateur, pour autant que je n'aie jamais regardé le fichier d'en-tête d'origine :D
Ensuite, il y a fatalement une série de symboles préprocesseur dans ces fichiers d'en-tête qui sont dépendants du compilateur lui-même.
Il faut donc veiller à "adapter" le fichier d'en-tête de manière à ce qu'il utilise les symboles équivalents du compilateur avec lequel on souhaite travailler et qui sont différents du compilateur "dont sont tirés" les fichiers d'en-tête.
Citation:
En gros, il va falloir inventer un système générique et transparent, qui permet d'appeler de l'API "à l'ancienne", sans pour autant pourrir les jolis paradigmes modernes dont farfelue se nourrira... (p... qu'est ce que je parle bien ce soir... ca doit être parce que je tape ceci au jardin, en contemplant un ciel vide d'avions...)
exactement :D
Citation:
Oui, maintenant, la question que je me pose est la suivante. Pour tout un tas de choses de base, on va "isoler" l'utilisateur de l'API et des trucs dégoutants qui se passent à bas niveau. Par exemple, il me parait logique que l'utilisateur n'ait pas besoin d'allouer des Device Context, ni qu'il ait besoin de gérer la palette d'un bitmap.
C'est bien l'idée, en effet
Citation:
Cependant, il restera toujours des choses que nous ne gérons pas. Soit parce que ces éléments, trop spécifiques Windows, n'ont pas été retenus dans notre facade, soit juste parce qu'on n'a pas voulu, pas eu le temps, etc...
C'est effectivement le risque... à nous de faire en sorte que cette partie manquante soit, a terme, aussi limitée que possible ;)
Citation:
Pour ces "parties manquantes", il me semble malin de permettre à l'utilisateur de pouvoir les utiliser s'il le souhaite. Même s'il faut pour cela ouvrir dans farfelue une porte sur quelque chose d'un peu crade... La vraie force de la librairie, ce sera de le permettre sans "casser" le reste.
Effectivement, mais, encore une fois, l'idéal sera réellement de faire en sorte que l'utilisateur de Farfelue n'aie "même pas besoin ni envie" d'aller "repêcher" une fonction non exposée par la facade ;)
Citation:
Envoyé par goten
Ne compte pas *exclusivement* là dessus en ce qui me concerne. Pour produire du code de production, je fais rarement confiance aux gens qui se forment sur l'instant... et comme ça va être mon cas, je me fait pas confiance =).
C'est une approche des plus sensées...
Le problème, c'est que, si on décide "d'attendre d'avoir trouvé" un type qui maitrise le sujet pour s'y mettre, autant se serrer la main, reconnaitre notre erreur et faire fermer l'hébergement, car les chances d'en trouver un rapidement sont pour le moins limitées.
Si c'est pour ne réellement commencer le dev que dans six mois ou un an, quand ont aura trouvé "la perle" qui sera suffisamment à l'aise en GDI+ ou en xorg, le projet sera "mort né" :aie:
Autrement dit, ton approche est très saine, mais "faute de grives on mange des merles" et, en attendant de trouver les perles qui nous font défaut, il faudra bien que nous fassions "contre mauvaise fortune bon coeur" ;)
Citation:
Plus sérieusement, j'ai peur que ça soit quelque chose d'assez complexe, et un *chaperon* maitrisant bien la chose serait peut être un plus.
Effectivement...
Mais encore une fois, il ne faut pas que cette recherche du "chaperon idéal" ne nous empêche d'avancer malgré tout et bloque le projet.
Autrement, nous n'avancerons pas, et, comme il n'y a encore rien de fait, le projet sera mort né :aie::cry: