La je dois comprendre les 10 arguments de CreateProcess() dans une partie d'un soft, je crois que je vais vite changer pour un execl() tout con qui date dit y'a 15 ans. Et le probleme c'est que tout est comme ca dans l'API windows et si encore il n'y avait que ca... genre quand je dois utiliser cette putain de base de registre de merde ou le dll war...
Mozilla et OpenOffice sont developpes en C++. Apres il y a peut etre des bouts de C.
Pour ma part je pense que le C en dehors de quelques applications specifiques a vecu. Faire des malloc de char * c'est franchement d'une autre epoque et ca ne devrait plus exister de nos jours.
D'ailleurs au sujet de: Support "propre" des erreurs
les languages recents proposent tous ce genre de chose.
Pour developper de grosses applications, maintenant on a des outils bien plus performants que le couple vi/C: UML, OCL (on commence a y venir cf http://www.key-project.org/(...) ), programmation object... Il suffit de voir des outils comme Borland Together pour comprendre.
Perso j'ai commence a programmer en C et en GTK+, ba j'ai vite compris qu'en utilisant Java ou meme C++/KDE/Qt (d'autres proposerons Python, Ruby...) j'etais beaucoup plus productif, que j'obtenais un code plus propre, plus clair, plus simple, moins de bugs ect...
Pour s'en convaincre c'est d'ailleurs assez simple, GTK reprend le principe de la programmation object malgre etre programme en C. Autant donc utiliser directement un language object et ne pas re-inventer la roue.
Pour les logiciels proprio c'est parfait comme systeme ! (savoir ensuite si c'est bon d'avoir des logiciels proprios sous linux est un autre debat).
Comme les libs sont incluses avec le logiciel, l'entreprise qui commercialise son logiciel sous Linux n'a pas a se soucier de la compatibilite de son logiciel avec tel ou tel distrib. Dans l'etat actuel des choses, les entreprises ne supportent qu'une seule distribution et meme qu'une seule version de celle-ci, avec ce systeme ca ne serait plus le cas.
Mais c'est clair que ca serait pas cool que toutes les applications libres sous linux embarquent leurs propres libs C/C++ et le reste.
> Ca veut dire qu'on est pas prêt d'avoir une wenbox qui marche sous linux ça.
Ca veut surtout dire que la dll ne fonctionne que sous Windows actuellement. Ca ne veut aucunement dire que la wenbox ne fonctionnera pas sous Linux ou Mac (il suffit de changer le code correspondant a la gestion du port USB qui est specifique a l'OS).
dll proprietaire ca veut dire que c'est un partenaire qui developpe la dll pour nous mais nous n'avons pas acces au code source pour le moment.
> Mais pour les sources, rien pour le moment ? A moins que je ne sois vraiment vraiment nul ?
On est en train de monter une infrastructure pour diffuser le logiciel sous GNU GPL. Pour l'instant seulement les couches bas niveau sont sous GNU GPL et LGPL comme tu as pu le lire. On en a deja parle ici : http://linuxfr.org/~beck/16467.html(...)
On a encore des zones d'ombre car Qt sous Windows necessite une exception a la GNU GPL. De plus la wenbox (un boitier USB) utilise une dll proprietaire. Pour l'instant on est en version beta donc un peu de patience !
Autres precisions, pour faire fonctionner Wengo avec un autre SIP phone, il suffit de fermer la fenetre de login ou de cliquer sur File/advanced/unregister et ensuite d'indiquer une addresse IP du type sip:192.168.0.1 Par contre en utilisant ce mode on ne passe pas par la plateforme Wengo et donc les firewalls/NAT ne sont pas pris en compte.
La plateforme Wengo a ete testee avec d'autres SIP phones comme sjphone sous Windows.
Autre precision, les contacts que l'on cree dans le logiciel sont au format VCard (via la lib vcard de KDE).
Tout est stocke dans le repertoire wengo de l'utilisateur (C:/Documents and Settings/$USER/wengo et /home/$USER/.wengo sous Linux) au format XML.
Je suis un des developpeurs du logiciel Wengo.
Je developpe la partie graphique.
Pour la partie graphique, tout est developpe sous Linux en C++/Qt.
Pour l'instant on ne livre qu'une version Windows, mais il y aura une version MacOS egalement.
La partie reseau s'appuie sur libosip, exosip et libortp et donc cette partie est sous licence GNU GPL.
Pour la partie graphique sous GPL ce n'est qu'une question de temps. Actuellement le logiciel dialogue avec la couche SIP via RPC (il y a 2 executables: softphone.exe et phapiserver.exe) d'ou aucun probleme de licence.
Le produit est encore jeune mais fonctionne deja a travers les NAT/Firewall.
> cervisia fait ca tres bien
Je ne comprends pas comment tu fais, voila ce que je viens de lire [1]:
by Marko on: 07/09/2004, 5:16
When is subversion support scheduled ?
by cloose on: 07/09/2004, 5:58
We tried to get it into KDE 3.3 but my time was just too limited and the release cycle too short.
The support for subversion has top priority for me when the release cycle for KDE 4 starts which should be around end of Q4/2004. There are also other developers who offered to help me out with the subversion part when the basic plugin framework is done. So you just have to be patient. :-)
Et dans Kdevelop, j'ai trouve aucune doc pour faire fonctionner le plugin subversion, je ne sais pas comment il faut faire.
> Vachement mieux pour qui ? Pour ceux qui font du logiciel propriétaire ?
> Effectivement, dans ce cas, c'est mieux adapté.
Ca permettrait a beaucoup plus de devs d'utiliser ta lib, de repandre la philosophie du libre, d'avoir plus de rapport de bugs (puisque plus d'utilisateurs), une reconnaissance plus importante et pourquoi pas meme plus de contributeurs. Perso je prefere que les devs utilisent VMIME que un MSMIME meme dans des softs proprios, pas toi ?
Et pour le code source lui meme ca change quoi ? ba rien du tout: c'est libre et personne ne peut reprendre ton code pour en faire une lib proprio (cf licenses BSD, MIT...).
Bref pour resume, avec la LGPL ta lib gagne en nombre d'utilisateurs et cela n'est jamais mauvais. Surtout qu'il n'y a aucune contre partie.
C'est pas super adapte la GPL pour les libs. La LGPL c'est quand meme vachement mieux, enfin de mon point de vue. Libre a toi de faire ce que tu veux :)
Au passage, pas besoin de faire des const string &, std::string dans la STL contient un compteur de reference. Et puis c'est dommage y'a aucun commentaire.
On est bien d'accord sur la partie commentaire de code source, par contre un truc me choque dans ce que tu dis:
> [...] Une approche orientée objet extrêmement bien faite.
J'ai l'impression que tout le monde est d'accord pour dire que l'approche objet est meilleure dans la majorite des cas sur l'approche fonctionnelle.
Or il se trouve que C++ implemente la premiere et la derniere mais C que l'approche fonctionnelle.
Alors pourquoi diable re-inventer la roue et utiliser le C pour utiliser l'approche objet et pas le C++ qui a ete fait et etudie expres pour ?
Il me parait logique et evident qu'un outil qui a ete fait dans un but est souvent meilleure pour atteindre ce but qu'un outil qui n'a pas ete cree et pense pour.
Pour prendre un exemple simple, j'utilise ma Peugeot 205 pour faire des petits trajets en ville parcequ'elle a ete concu pour. En revanche une Renault Espace sera clairement moins a l'aise dans ce meme environnement meme si c'est possible.
Pour moi c'est evident qu'il faut utiliser des outils adaptes a la problematique. Et dans ce cas C++ est plus adapte pour faire de l'OO que le C parceque ca a ete concu et pense pour contrairement au C. J'ai fait 5 mois de GTK 8h/jour il y a 2 ans et maintenant je fais du Qt 8h/jour -> ba y'a pas photo l'un est clairement plus sympa et moins casse gueule a utiliser que l'autre. Avec GTK ils ont re-invente le modele objet en moins bien que le C++.
> j'ai du mal à comprendre le choix du C.. [...]
> Je vous invite à lire le blog de l'auteur de Kompose, très instructif à
> propos du C vs. le C++...
> http://waidlafragger.de/~blog/oisch/(...)
Alléluia !
Moi aussi j'ai jamais compris pourquoi les gens programmaient encore en C, et pourtant j'ai commence a programmer en C.
Par contre pour le C++ je sais pas comment tu fais pour ne pratiquement pas avoir de pointeurs. J'essaye le plus possible d'utiliser les references mais deja Qt ca aide pas dans ce domaine. Si tu as des liens, docs sur le sujet ca m'interesse.
Mais le C++ c'est quand meme vachement complique pour rien, les refs, pointeurs, copy constructor, le manque de consistance et tout le bordel... C'est pour ca que d'un point de vue developpeur je prefere 100x plus Java, en plus MVC c'est pas encore supporte par Qt (par contre nivo utilisateur je prefere clairement le C++)
Dans le doc de Debian, 2 notions bien differentes sont melanges:
- la licence des logiciels appartenant a Sun
Ca je m'en fou, c'est le business de Sun.
- l'utilisation des noms de packages java et sun
[You] may not create, or authorize your licensees to create additional classes, interfaces, or subpackages that are
contained in the "java" or "sun" packages or similar as specified by
Sun in any class file naming convention;
Pourquoi ils ont fait ca ? simplement pour se premunir d'entreprises (Microsoft au hasard) qui pourraient ajouter des classes java.bidule et laisser penser qu'elles font partie de Java. Sun a peur que des versions incompatibles de Java apparaissent et le passé leur donne raison. Quant a la restriction sur les packages en utilisant le mot sun, ca me semble evident.
Rien n'empeche de faire des packages gnu.org.swing c'est techniquement pas un gros probleme de faire un script qui renomment les noms automatiquement.
De plus je ne suis pas persuade qu'implementer swing dans son coin en utilisant comme nom de package javax.swing soit un gros probleme vu que le paragraphe s'applique aux ajouts. Le mieux c'est encore de demander a Sun parceque la remarque de Debian [1] ne clarifie rien.
[1] it is unclear whether or not the word 'additional' includes reimplementations of existing classes, or whether it applies only to classes with new names.
Enfin pour la remarque toujours sur le site web de Debian: Sun has made public statements in connection with their legal strategy in the Sun-Microsoft lawsuit that indicate that the company considers the published specifications of Java2 to be intellectual property that can not legally be used by persons involved in efforts to create Java2 clean-room implementations.
J'attend de voir des ecrits de Sun a ce sujet parceque j'ai pas trouve. Le seul truc que j'ai trouve indique justement le contraire: http://lists.debian.org/debian-java/2002/02/msg00156.html(...)
Les multiples re-implementations de J2EE dont une a ete certifiee [2] ne posent pas de probleme alors pourquoi J2SE poserait un probleme ? Et sur le CVS de Kaffe on peut voir des classes Java2 je me pose donc des questions sur la justesse des propos sur le page web de Debian.
> du fait de la licence imposée par Sun, il est impossible de proposer une mise en ouvre alternative de Swing (que cette alternative soit libre ou non).
C'est impressionant, a chaque news sur Java toujours les memes ragots qui sont ecrits et re-ecrits. Vous en avez pas marre de raconter des conneries a longueur d'annees ?
Expliques moi en quoi Sun rends impossible une implementation de JVM/Swing en libre ? rien, la preuve ils l'ont deja fait:
Si la communaute ne s'investie pas aussi dynamiquement dans l'implementation d'une JVM libre, c'est pas de la faute de Sun. C'est aussi probablement parceque les JVM existantes suffisent. De meme que ce n'est pas de la faute a Microsoft si Mono avance tres vite. De toute facon si Mono ne le fait pas, c'est pas Microsoft qui va fournir .NET sous Linux/*BSD contrairement a Sun avec Java. Mon avis est que le monde Java est infiniment plus ouvert a tous les niveaux que celui de .NET par exemple.
> sauf qu'avec Mono, on a une implémentation complète, libre, multiplateforme, performante et on ne dépend pas du bon vouloir de Sun
Et quelque chose empeche d'avoir la meme chose pour Java ?
Non, rien et d'ailleurs c'est meme en train de se faire.
De facon generale je rappelle que Java n'est pas moins libre que C++, C, C# ou meme UNIX.
Java c'est des specifications et un ensemble d'API, libre ensuite a chacun de programmer une implementation. Linus Torvalds a cree Linux il l'a voulu compatible avec UNIX, tout comme GCC implemente C++ et le C. Bref s'il n'y a pas d'implementation libre correcte de Java c'est pas de la faute de Sun mais c'est de la faute des developpeurs de logiciels libres. Apres il est vrai que si Sun pouvait mettre Java sous LGPL ca serait "sympa".
Au moins ce qui est clair c'est que Sun ne mettra pas de batons dans les roues de projets libres Java contrairement a Microsoft. Je suis persuade que si une implementation de .NET est trop presente, Microsoft se donnera les moyens de renverser la tendance.
> Glib c'est une bibliothèque qui implémente les listes chaînées et autres
Et la STL ca fait pas ca justement ?
> pouvoir accéder à toute une panoplie de bibliothèques programmées
> en C et de lui donner une API agréable en C++ [...]
> Gstreamer rentre donc parfaitement dans la philosophie QT/KDE
S'il existe deja des projets qui ont directement une API agreable en C++ je pense que c'est encore plus dans la philosophie Qt/KDE d'y regarder de plus pres avant de faire un choix qui aura beaucoup de poids.
Noatun... mouais le peu de fois ou je l'ai utilise ca plantait.
Le truc c'est qu'il ne faudrait pas un lecteur video qui en option peut lire les fichiers audio, mais plutot l'inverse car un lecteur audio a systematiquement un systeme de playlist vachement avance ce qui n'est souvent pas le cas d'un lecteur video. On imagine l'interet de winamp pour lire les videos mais tres peu celui de winDVD pour lire les mp3 de tout les jours.
Le truc qui m'a toujours etonne sous KDE (le reste je sais pas) c'est qu'il n'y a pas vraiment d'equivalent a Windows Media Player dans le sens ou il y a des outils pour gerer les mp3, ogg ect... avec une jolie playlist et des outils pour gerer les videos, DVD...
Mais les 2 outils sont separes alors que l'on y gagnerait a avoir un seul lecteur audio qui pourrait lire les DVD et videos via des plugins. Mine de rien il y a enormement de trucs en commun entre lecteur audio et video. Ca permettrait de ne pas avoir a "apprendre" deux logiciels differents, ca simplifierait les choses.
Si Amarok pouvait piloter xine ou mplayer ca serait tip top.
> Il faudrait pouvoir choisir l'image du film que l on veut mettre en guise d'appercu
Konqueror et Nautilus ne le font pas ? genre prendre la 10e frame de chaque video et l'afficher ? le probleme c'est la gestion de format exotique genre les .mov sinon c'est toujours du mpeg1 sur les appareils photo numeriques.
Chapeau pour avoir realiser cet outil !
J'ai juste une question a formuler, les videos sont-elles geres ?
C'est con a dire mais avec les appareils photos numeriques, on peut maintenant prendre des videos mais malheureusement j'ai pas trouve de gallerie photo qui les gerent.
> bref rien de neuf sous le soleil et je vois vraiment pas l'interet de la chose.
> Ben si, montrer que question productivité on peut faire un truc en 4
> jours au lieu de tout recoder en 6 mois.
Je crois qu'aucune demonstration est utile pour comprendre que recoder un soft dans un autre language c'est plus long que de recompiler le soft sous un autre environnement. C'est super evident.
Si ca les amusent de perdre 4j pour arriver a cette conclusion...
> D'où l'intérêt de supporter plusieurs langages sur une même plateforme.
Je suis d'accord que ca peut etre interessant d'avoir plusieurs languages supportes. Ici c'est le cas: on prend un "vieux" soft en C, on le porte sous un framework moderne et on peut ajouter des nouvelles fonctionnalites plus facilement grace aux outils modernes du framework.
> Si tu compares vraiment avec l'original, Quake2.NET en C est plus
> rapide que l'original, parceque l'original n'avait pas les optimisations P4.
Tu le sors d'ou ca ? sur le site web de Quake.NET il y a ecrit: Running Quake II.NET in the timedemo test indicates the managed version performs about 85% as fast as the native version. Native version pour moi ca veux dire qu'ils ont telecharge la demo de IdSoftware, fait un timedemo et compare avec leur version .NET
[^] # Re: Peur...
Posté par tanguy_k (site web personnel) . En réponse au journal Qt 4.0 en GPL sous Windows. Évalué à 4.
Oui enfin il y a equivalent et equivalent
Juste un exemple d'un truc normalement tout con a faire, creer un processus:
http://doc.trolltech.com/3.3/qprocess.html(...)
proc = new QProcess( this );
proc->addArgument( "monprogramme" );
proc->addArgument( "param1" );
proc->addArgument( "param2" );
proc->addArgument( "param3" );
proc->start()
et ca http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dl(...)
BOOL CreateProcess(
LPCTSTR lpApplicationName,
LPTSTR lpCommandLine,
LPSECURITY_ATTRIBUTES lpProcessAttributes,
LPSECURITY_ATTRIBUTES lpThreadAttributes,
BOOL bInheritHandles,
DWORD dwCreationFlags,
LPVOID lpEnvironment,
LPCTSTR lpCurrentDirectory,
LPSTARTUPINFO lpStartupInfo,
LPPROCESS_INFORMATION lpProcessInformation
);
La je dois comprendre les 10 arguments de CreateProcess() dans une partie d'un soft, je crois que je vais vite changer pour un execl() tout con qui date dit y'a 15 ans. Et le probleme c'est que tout est comme ca dans l'API windows et si encore il n'y avait que ca... genre quand je dois utiliser cette putain de base de registre de merde ou le dll war...
# Mauvais exemples
Posté par tanguy_k (site web personnel) . En réponse au message Conception de gros projets en C. Évalué à 5.
Pour ma part je pense que le C en dehors de quelques applications specifiques a vecu. Faire des malloc de char * c'est franchement d'une autre epoque et ca ne devrait plus exister de nos jours.
D'ailleurs au sujet de: Support "propre" des erreurs
les languages recents proposent tous ce genre de chose.
Pour developper de grosses applications, maintenant on a des outils bien plus performants que le couple vi/C: UML, OCL (on commence a y venir cf http://www.key-project.org/(...) ), programmation object... Il suffit de voir des outils comme Borland Together pour comprendre.
Perso j'ai commence a programmer en C et en GTK+, ba j'ai vite compris qu'en utilisant Java ou meme C++/KDE/Qt (d'autres proposerons Python, Ruby...) j'etais beaucoup plus productif, que j'obtenais un code plus propre, plus clair, plus simple, moins de bugs ect...
Pour s'en convaincre c'est d'ailleurs assez simple, GTK reprend le principe de la programmation object malgre etre programme en C. Autant donc utiliser directement un language object et ne pas re-inventer la roue.
# Parfait pour les logiciels proprio
Posté par tanguy_k (site web personnel) . En réponse au journal Autopackage. Évalué à 1.
Comme les libs sont incluses avec le logiciel, l'entreprise qui commercialise son logiciel sous Linux n'a pas a se soucier de la compatibilite de son logiciel avec tel ou tel distrib. Dans l'etat actuel des choses, les entreprises ne supportent qu'une seule distribution et meme qu'une seule version de celle-ci, avec ce systeme ca ne serait plus le cas.
Mais c'est clair que ca serait pas cool que toutes les applications libres sous linux embarquent leurs propres libs C/C++ et le reste.
[^] # Re: QT sous windows
Posté par tanguy_k (site web personnel) . En réponse au journal Cherche stagiaires pour faire du python, qt et C++. Évalué à 1.
[^] # Re: J'aurais du chercher plus longtemps
Posté par tanguy_k (site web personnel) . En réponse au journal Wengo : du pipo ?. Évalué à 1.
Ca veut surtout dire que la dll ne fonctionne que sous Windows actuellement. Ca ne veut aucunement dire que la wenbox ne fonctionnera pas sous Linux ou Mac (il suffit de changer le code correspondant a la gestion du port USB qui est specifique a l'OS).
dll proprietaire ca veut dire que c'est un partenaire qui developpe la dll pour nous mais nous n'avons pas acces au code source pour le moment.
[^] # Re: J'aurais du chercher plus longtemps
Posté par tanguy_k (site web personnel) . En réponse au journal Wengo : du pipo ?. Évalué à 1.
On est en train de monter une infrastructure pour diffuser le logiciel sous GNU GPL. Pour l'instant seulement les couches bas niveau sont sous GNU GPL et LGPL comme tu as pu le lire. On en a deja parle ici : http://linuxfr.org/~beck/16467.html(...)
On a encore des zones d'ombre car Qt sous Windows necessite une exception a la GNU GPL. De plus la wenbox (un boitier USB) utilise une dll proprietaire. Pour l'instant on est en version beta donc un peu de patience !
[^] # Re: Quelques precisions
Posté par tanguy_k (site web personnel) . En réponse au journal N9uf Telecom lance Wengo. Évalué à 1.
La plateforme Wengo a ete testee avec d'autres SIP phones comme sjphone sous Windows.
Autre precision, les contacts que l'on cree dans le logiciel sont au format VCard (via la lib vcard de KDE).
Tout est stocke dans le repertoire wengo de l'utilisateur (C:/Documents and Settings/$USER/wengo et /home/$USER/.wengo sous Linux) au format XML.
Bref que du standard de A a Z.
# Quelques precisions
Posté par tanguy_k (site web personnel) . En réponse au journal N9uf Telecom lance Wengo. Évalué à 1.
Je developpe la partie graphique.
Pour la partie graphique, tout est developpe sous Linux en C++/Qt.
Pour l'instant on ne livre qu'une version Windows, mais il y aura une version MacOS egalement.
La partie reseau s'appuie sur libosip, exosip et libortp et donc cette partie est sous licence GNU GPL.
Pour la partie graphique sous GPL ce n'est qu'une question de temps. Actuellement le logiciel dialogue avec la couche SIP via RPC (il y a 2 executables: softphone.exe et phapiserver.exe) d'ou aucun probleme de licence.
Le produit est encore jeune mais fonctionne deja a travers les NAT/Firewall.
[^] # Re: XMMS2
Posté par tanguy_k (site web personnel) . En réponse au journal Nullsoft, c'est fini. Évalué à 2.
C'est confidentiel ou on peut avoir un apercu de ces killer features ?
> [...] xmms2, c'est la mort assuré des autres lecteurs audio
Pourquoi ca serait la mort des autres lecteurs audio ?
Le site web de XMMS2 est pas super bavard non plus...
[^] # Re: Expérience similaire.
Posté par tanguy_k (site web personnel) . En réponse au journal Gestion de version. Évalué à 1.
Je ne comprends pas comment tu fais, voila ce que je viens de lire [1]:
by Marko on: 07/09/2004, 5:16
When is subversion support scheduled ?
by cloose on: 07/09/2004, 5:58
We tried to get it into KDE 3.3 but my time was just too limited and the release cycle too short.
The support for subversion has top priority for me when the release cycle for KDE 4 starts which should be around end of Q4/2004. There are also other developers who offered to help me out with the subversion part when the basic plugin framework is done. So you just have to be patient. :-)
Et dans Kdevelop, j'ai trouve aucune doc pour faire fonctionner le plugin subversion, je ne sais pas comment il faut faire.
[1] http://kde-apps.org/content/show.php?content=10181(...)
# Juste comme ca
Posté par tanguy_k (site web personnel) . En réponse au journal Mr Nicolas Appert. Évalué à 0.
En francais l'abréviation de Monsieur c'est M. (avec le point a la fin)
[^] # Re: Expérience similaire.
Posté par tanguy_k (site web personnel) . En réponse au journal Gestion de version. Évalué à 1.
Je confirme, il est super bien foutu. D'ailleurs il y a quoi comme client sous Linux qui pourrait etre semblable (integre a Konqueror par exemple) ?
[^] # Re: VMime !
Posté par tanguy_k (site web personnel) . En réponse au journal Et vous que développez vous?. Évalué à 1.
> Effectivement, dans ce cas, c'est mieux adapté.
Ca permettrait a beaucoup plus de devs d'utiliser ta lib, de repandre la philosophie du libre, d'avoir plus de rapport de bugs (puisque plus d'utilisateurs), une reconnaissance plus importante et pourquoi pas meme plus de contributeurs. Perso je prefere que les devs utilisent VMIME que un MSMIME meme dans des softs proprios, pas toi ?
Et pour le code source lui meme ca change quoi ? ba rien du tout: c'est libre et personne ne peut reprendre ton code pour en faire une lib proprio (cf licenses BSD, MIT...).
Bref pour resume, avec la LGPL ta lib gagne en nombre d'utilisateurs et cela n'est jamais mauvais. Surtout qu'il n'y a aucune contre partie.
[^] # Re: VMime !
Posté par tanguy_k (site web personnel) . En réponse au journal Et vous que développez vous?. Évalué à 2.
C'est pas super adapte la GPL pour les libs. La LGPL c'est quand meme vachement mieux, enfin de mon point de vue. Libre a toi de faire ce que tu veux :)
Au passage, pas besoin de faire des const string &, std::string dans la STL contient un compteur de reference. Et puis c'est dommage y'a aucun commentaire.
[^] # Re: Heu le C ?
Posté par tanguy_k (site web personnel) . En réponse au message Bien s'entourer en c, et plus si affinités. Évalué à 2.
> [...] Une approche orientée objet extrêmement bien faite.
J'ai l'impression que tout le monde est d'accord pour dire que l'approche objet est meilleure dans la majorite des cas sur l'approche fonctionnelle.
Or il se trouve que C++ implemente la premiere et la derniere mais C que l'approche fonctionnelle.
Alors pourquoi diable re-inventer la roue et utiliser le C pour utiliser l'approche objet et pas le C++ qui a ete fait et etudie expres pour ?
Il me parait logique et evident qu'un outil qui a ete fait dans un but est souvent meilleure pour atteindre ce but qu'un outil qui n'a pas ete cree et pense pour.
Pour prendre un exemple simple, j'utilise ma Peugeot 205 pour faire des petits trajets en ville parcequ'elle a ete concu pour. En revanche une Renault Espace sera clairement moins a l'aise dans ce meme environnement meme si c'est possible.
Pour moi c'est evident qu'il faut utiliser des outils adaptes a la problematique. Et dans ce cas C++ est plus adapte pour faire de l'OO que le C parceque ca a ete concu et pense pour contrairement au C. J'ai fait 5 mois de GTK 8h/jour il y a 2 ans et maintenant je fais du Qt 8h/jour -> ba y'a pas photo l'un est clairement plus sympa et moins casse gueule a utiliser que l'autre. Avec GTK ils ont re-invente le modele objet en moins bien que le C++.
[^] # Re: Heu le C ?
Posté par tanguy_k (site web personnel) . En réponse au message Bien s'entourer en c, et plus si affinités. Évalué à 0.
> Je vous invite à lire le blog de l'auteur de Kompose, très instructif à
> propos du C vs. le C++...
> http://waidlafragger.de/~blog/oisch/(...)
Alléluia !
Moi aussi j'ai jamais compris pourquoi les gens programmaient encore en C, et pourtant j'ai commence a programmer en C.
Par contre pour le C++ je sais pas comment tu fais pour ne pratiquement pas avoir de pointeurs. J'essaye le plus possible d'utiliser les references mais deja Qt ca aide pas dans ce domaine. Si tu as des liens, docs sur le sujet ca m'interesse.
Mais le C++ c'est quand meme vachement complique pour rien, les refs, pointeurs, copy constructor, le manque de consistance et tout le bordel... C'est pour ca que d'un point de vue developpeur je prefere 100x plus Java, en plus MVC c'est pas encore supporte par Qt (par contre nivo utilisateur je prefere clairement le C++)
[^] # Re: A comparer plutot au C#
Posté par tanguy_k (site web personnel) . En réponse à la dépêche Java 2 Standard Edition version 5.0. Évalué à 3.
- la licence des logiciels appartenant a Sun
Ca je m'en fou, c'est le business de Sun.
- l'utilisation des noms de packages java et sun
[You] may not create, or authorize your licensees to create
additional classes, interfaces, or subpackages that are
contained in the "java" or "sun" packages or similar as specified by
Sun in any class file naming convention;
Pourquoi ils ont fait ca ? simplement pour se premunir d'entreprises (Microsoft au hasard) qui pourraient ajouter des classes java.bidule et laisser penser qu'elles font partie de Java. Sun a peur que des versions incompatibles de Java apparaissent et le passé leur donne raison. Quant a la restriction sur les packages en utilisant le mot sun, ca me semble evident.
Rien n'empeche de faire des packages gnu.org.swing c'est techniquement pas un gros probleme de faire un script qui renomment les noms automatiquement.
De plus je ne suis pas persuade qu'implementer swing dans son coin en utilisant comme nom de package javax.swing soit un gros probleme vu que le paragraphe s'applique aux ajouts. Le mieux c'est encore de demander a Sun parceque la remarque de Debian [1] ne clarifie rien.
[1] it is unclear whether or not the word 'additional' includes reimplementations of existing classes, or whether it applies only to classes with new names.
Enfin pour la remarque toujours sur le site web de Debian:
Sun has made public statements in connection with their legal strategy in the Sun-Microsoft lawsuit that indicate that the company considers the published specifications of Java2 to be intellectual property that can not legally be used by persons involved in efforts to create Java2 clean-room implementations.
J'attend de voir des ecrits de Sun a ce sujet parceque j'ai pas trouve. Le seul truc que j'ai trouve indique justement le contraire: http://lists.debian.org/debian-java/2002/02/msg00156.html(...)
Les multiples re-implementations de J2EE dont une a ete certifiee [2] ne posent pas de probleme alors pourquoi J2SE poserait un probleme ? Et sur le CVS de Kaffe on peut voir des classes Java2 je me pose donc des questions sur la justesse des propos sur le page web de Debian.
[2] http://linuxfr.org/2004/07/19/16847.html(...)
De toute facon dans le pire des cas tous ces problemes s'appliquent aussi a .Net/Mono
[^] # Re: A comparer plutot au C#
Posté par tanguy_k (site web personnel) . En réponse à la dépêche Java 2 Standard Edition version 5.0. Évalué à 6.
C'est impressionant, a chaque news sur Java toujours les memes ragots qui sont ecrits et re-ecrits. Vous en avez pas marre de raconter des conneries a longueur d'annees ?
Expliques moi en quoi Sun rends impossible une implementation de JVM/Swing en libre ? rien, la preuve ils l'ont deja fait:
http://forum.hardware.fr/forum2.php?config=hardwarefr.inc&post=(...)
http://gcc.gnu.org/java/(...)
http://www.gnu.org/software/classpath/(...)
http://www-124.ibm.com/developerworks/oss/jikes/(...)
ect...
Si la communaute ne s'investie pas aussi dynamiquement dans l'implementation d'une JVM libre, c'est pas de la faute de Sun. C'est aussi probablement parceque les JVM existantes suffisent. De meme que ce n'est pas de la faute a Microsoft si Mono avance tres vite. De toute facon si Mono ne le fait pas, c'est pas Microsoft qui va fournir .NET sous Linux/*BSD contrairement a Sun avec Java. Mon avis est que le monde Java est infiniment plus ouvert a tous les niveaux que celui de .NET par exemple.
[^] # Re: A comparer plutot au C#
Posté par tanguy_k (site web personnel) . En réponse à la dépêche Java 2 Standard Edition version 5.0. Évalué à 5.
Et quelque chose empeche d'avoir la meme chose pour Java ?
Non, rien et d'ailleurs c'est meme en train de se faire.
De facon generale je rappelle que Java n'est pas moins libre que C++, C, C# ou meme UNIX.
Java c'est des specifications et un ensemble d'API, libre ensuite a chacun de programmer une implementation. Linus Torvalds a cree Linux il l'a voulu compatible avec UNIX, tout comme GCC implemente C++ et le C. Bref s'il n'y a pas d'implementation libre correcte de Java c'est pas de la faute de Sun mais c'est de la faute des developpeurs de logiciels libres. Apres il est vrai que si Sun pouvait mettre Java sous LGPL ca serait "sympa".
Au moins ce qui est clair c'est que Sun ne mettra pas de batons dans les roues de projets libres Java contrairement a Microsoft. Je suis persuade que si une implementation de .NET est trop presente, Microsoft se donnera les moyens de renverser la tendance.
[^] # Re: Le son dans 3.4
Posté par tanguy_k (site web personnel) . En réponse au journal Le son sous KDE (3.)4. Évalué à 2.
Et la STL ca fait pas ca justement ?
> pouvoir accéder à toute une panoplie de bibliothèques programmées
> en C et de lui donner une API agréable en C++ [...]
> Gstreamer rentre donc parfaitement dans la philosophie QT/KDE
S'il existe deja des projets qui ont directement une API agreable en C++ je pense que c'est encore plus dans la philosophie Qt/KDE d'y regarder de plus pres avant de faire un choix qui aura beaucoup de poids.
[^] # Re: lecteur multimedia = video + audio
Posté par tanguy_k (site web personnel) . En réponse au journal Kaffeine not dead!. Évalué à 2.
Le truc c'est qu'il ne faudrait pas un lecteur video qui en option peut lire les fichiers audio, mais plutot l'inverse car un lecteur audio a systematiquement un systeme de playlist vachement avance ce qui n'est souvent pas le cas d'un lecteur video. On imagine l'interet de winamp pour lire les videos mais tres peu celui de winDVD pour lire les mp3 de tout les jours.
# lecteur multimedia = video + audio
Posté par tanguy_k (site web personnel) . En réponse au journal Kaffeine not dead!. Évalué à 4.
Mais les 2 outils sont separes alors que l'on y gagnerait a avoir un seul lecteur audio qui pourrait lire les DVD et videos via des plugins. Mine de rien il y a enormement de trucs en commun entre lecteur audio et video. Ca permettrait de ne pas avoir a "apprendre" deux logiciels differents, ca simplifierait les choses.
Si Amarok pouvait piloter xine ou mplayer ca serait tip top.
[^] # Re: Ca fait les videos ?
Posté par tanguy_k (site web personnel) . En réponse au journal album web. Évalué à 2.
Konqueror et Nautilus ne le font pas ? genre prendre la 10e frame de chaque video et l'afficher ? le probleme c'est la gestion de format exotique genre les .mov sinon c'est toujours du mpeg1 sur les appareils photo numeriques.
# Ca fait les videos ?
Posté par tanguy_k (site web personnel) . En réponse au journal album web. Évalué à 4.
J'ai juste une question a formuler, les videos sont-elles geres ?
C'est con a dire mais avec les appareils photos numeriques, on peut maintenant prendre des videos mais malheureusement j'ai pas trouve de gallerie photo qui les gerent.
[^] # Re: allez hop
Posté par tanguy_k (site web personnel) . En réponse au journal Jake2 - port Quake2 en Java. Évalué à 2.
> Ben si, montrer que question productivité on peut faire un truc en 4
> jours au lieu de tout recoder en 6 mois.
Je crois qu'aucune demonstration est utile pour comprendre que recoder un soft dans un autre language c'est plus long que de recompiler le soft sous un autre environnement. C'est super evident.
Si ca les amusent de perdre 4j pour arriver a cette conclusion...
> D'où l'intérêt de supporter plusieurs langages sur une même plateforme.
Je suis d'accord que ca peut etre interessant d'avoir plusieurs languages supportes. Ici c'est le cas: on prend un "vieux" soft en C, on le porte sous un framework moderne et on peut ajouter des nouvelles fonctionnalites plus facilement grace aux outils modernes du framework.
> Si tu compares vraiment avec l'original, Quake2.NET en C est plus
> rapide que l'original, parceque l'original n'avait pas les optimisations P4.
Tu le sors d'ou ca ? sur le site web de Quake.NET il y a ecrit:
Running Quake II.NET in the timedemo test indicates the managed version performs about 85% as fast as the native version. Native version pour moi ca veux dire qu'ils ont telecharge la demo de IdSoftware, fait un timedemo et compare avec leur version .NET