tanguy_k a écrit 766 commentaires

J'ai également le Sansa Clip+. Je l'utilise surtout pour lire le format FLAC.
Dans l'ensemble il est bien (écran lisible, petit et léger, 8h d'autonomie, micro-SD, USB standard, bon son...) mais malheureusement le volume sonore est faible. De plus il plante régulièrement (apparemment à cause des tags dans mes fichiers FLAC).
Je compte utiliser Rockbox http://www.rockbox.org/ , as tu déjà essayé sur ce modèle ?

Je comprends pas pourquoi tu veux absolument que l'on te mentionne ? A priori ça ne t'apporte rien.

iOS, Android ? on parle de PC desktops pas de smartphones...

http://en.wikipedia.org/wiki/Usage_share_of_operating_systems#Web_clients

GNU/Linux :  1.58% sur Wikipedia/Wikimedia    1.02% en prenant d'autres sources
Mac OS X  :  7.60%                            7.25%
Windows   : 80.08%                           85.54%

J'imagine que la discussion a eu lieu via mailing-list

Par IRC apparemment, ca tempere quand meme les propos : en general sur une mailing-list les gens sont plus "raisonnes" et surtout pas seulement toi peux juger/interpreter ce qui s'y dit.

En discutant un peu avec des devs GTK (enfin GNOME) [...]

J'imagine que la discussion a eu lieu via mailing-list, est-il possible d'avoir les liens vers les mails en question ?

les fichiers aux formats Ogg, MP3 et FLAC (ces deux derniers seront convertis en Ogg par le logiciel)

Si c'est exact c'est une connerie sans nom !

Je viens de passer hier soir a bidouiller un peu Mono sous Windows et il y a pas mal de trucs qui me déplaisent...

• Ils utilisent encore les autotools pour compiler !
• L'organisation du repository fait que pour compiler un petit composant (dans mon cas XSP, un petit serveur web) et non l’intégralité de Mono, il faut bidouiller les scripts
• MonoDevelop et autres applications utilisent Gtk+ et sous Windows c'est vraiment horrible : thème qui s’intègre mal et surtout la boite de dialogue pour les fichiers anti-ergonomique
• Le package Mono pour Windows dans la page de téléchargement contient tout, vraiment tout ! Gtk, XulRunner, IKVM... plus de modularité n'aurait pas fait de mal
• ASP.NET MVC 3 sous Windows est censé être corrigé dans la 2.10.1, en fait non :/

et c'est pas les quelques dev' Mono qui vont pouvoir continuer le support et l'évolution

et c'est pas les quelques dev' de Linux qui vont pouvoir développer un OS

Pour info les devs de Mono ont implémenté tout .NET + ajouté pas mal de librairies et applications dont Gtk#, MonoDevelop (IDE), Moonlight, MonoDroid, MonoTouch, MonoMac, Gecko#, WebKit#...

ECMA couvre bien plus

Effectivement, il y a 2 normes ECMA (334 et 335).
ECMA 335 couvre la CLI et apparemment tout System.* (notamment XML, HTTP, IO...)
http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-335.pdf et la dernière mise a jour date de décembre 2010 !

La question se serait effectivement posée différement si MonoDroid était réalisé par un tiers.

Même pas, la licence MIT (concerne les librairies et le compilo) est quasi-identique a la BSD donc tu fais ce que tu veux.

c'est les mêmes auteurs qui font Mono et MonoDroid

Oui et non, il y a des contributeurs externe a Novell sur Mono...
Mais Novell demande l'assignement du copyright pour certaines parties de Mono (de plus en plus désuet j'imagine avec le basculement vers la licence MIT).

Seule la couche de compatibilité pourrait [...] poser problème [...] sous Linux elle n'est pas nécessaire et n'a pas vraiment d'utilité.

LINQ, ADO.Net, WCF, WF, XML, HTTP... Si tu fais du C# t'es pratiquement obligé d'utiliser des composants de .NET (même sous Linux) qui donc ne font pas partie des normes ECMA (sauf a re-inventer la roue évidemment).
ECMA couvre seulement le langage lui même, pire C# 3 et 4 ne sont pas couvert, la dernière norme date de 2006 -> une éternité !

Il a un risque plus important que pour d'autres logiciels libres. Mais Microsoft ne peut pas non plus 10 ans après les faits se plaindre de la violation d'un brevet. Il me semble qu'il est du devoir du détenteur d'un brevet de le faire valoir dans un délais "raisonnable".
Mon avis est donc qu'il ne se passera rien ou au pire des représailles anecdotiques.

Les développeurs de Mono ne sont pas idiots, ils ont bien conscience des risques de brevets. Cf Icaza en 2006 http://tirania.org/blog/archive/2006/Nov-04.html

I do not know of any patents which Mono infringes.

Et s'ils en rencontraient :

[...] (1) work around the patent by using a different implementation [...] if that is not possible, we would (2) remove the pieces of code that were covered by those patents, and also (3) find prior art that would render the patent useless.

La FAQ de Mono est également assez clair sur le sujet http://www.mono-project.com/FAQ:_Licensing#Patents

Conclusion : le risque n'est pas nul mais assez faible a mon avis

Pas mal la démonstration en 2 étapes :)
AHMA La menace des brevets sur Mono s'amenuise avec le temps

Pas rentable : la vente des licences ne couvrait pas la R&D

Je confirme, Windows 7 fonctionne sur un vieux P4 avec 512Mo RAM : navigation internet, Word ect... C'est lent certes mais ca marche et ca m'avait plutot bluffe.

20k lignes en C++ prends environ 10 secondes à compiler

Y'a que moi que ca choque ?

copie de T au return <------ génération de l'exception

Effectivement, je ne suis pas un specialiste de ce genre de truc.

C# et Java ne sont pas exception safe. Ce qui pose un gros problème de robustesse

Néanmoins je pense toujours que "parler d'erreurs de design est exagéré". J'imagine que les developpeurs de Qt, C# et Java ont fait un choix en connaissance de cause. Ca ne conviendra pas a toutes les utilisations certes.

Notons que quand on developpe en Qt, en general on n'utilise pas les exceptions car Qt ne les utilisent pas.

Effectivement je crois pas que l'on puisse faire ca avec Qt. Boost/STL est effectivement plus puissant.

Y'a que moi pour trouver ce code imbitable ?

Dire que Qt explose boost/STL parce qu'on gagne une ligne sur un split, c'est assez peu significatif.

Merci de ne pas me faire dire ce que je n'ai pas dit !

Je me cite moi-meme : "Je trouve la facon de faire plus logique, simple et lisible avec Qt"

Prototype : T QQueue::dequeue()

Au moment de dequeue() 2 étapes sont effectuées :

1. copie de T pour pouvoir le retourner
2. suppression de T de la queue

Lors de l'étape 1 il y a un appel à l'operateur = de T (T::operator=())

Si l'operateur = lance une exception alors la copie ne se fait pas et T retourné par dequeue() est foireux.

Effectivement std::queue ne fonctionne pas ainsi et pop() (l'equivalent de dequeue()) ne retourne rien cf http://www.sgi.com/tech/stl/queue.html#3 ou les concepteurs de la STL expliquent les raisons.

Es dramatique ?

• Une exception a eu lieu, ta valeur est donc non garantie, je trouve rien de choquant a ca, c'est meme plutôt commun.

• Tu peux toujours utiliser QQueue de la meme façon que std::queue.

• AHMA les concepteurs de la STL ne détiennent pas LA vérité. Par exemple en C# Queue.Dequeue fonctionne de la meme façon que QQueue, pareil en Java.

Parler d'"erreurs de design" est clairement exagéré.

si une exception est générer à l'appel de split t'auras des fuites mémoires

Et elle vient d'où cette exception ?

ça marche pareil si T contient des nombres ou des classes

Pas compris, ca t'arrive souvent de spliter des nombres et des classes ? tu peux donner un exemple

Le débat portait sur Qt vs STL :)

Donc comparons maintenant Qt vs Boost, split d'une string :

std::string str = "string to split"; std::vector<std::string> strs; boost::split(strs, str, boost::is_any_of(" "));

QString str = "string to split"; QStringList strs = str.split(" ");

"Joindre" des strings ensemble :

std::vector<std::string> list; list.push_back("Hello"); list.push_back("World!"); std::string joined = boost::algorithm::join(list, " ");

QStringList list; list << "Hello" << "World!"; QString joined = list.join(" ");

Je trouve la facon de faire plus logique, simple et lisible avec Qt.

Qt vs STL ? c'est même pas comparable tellement Qt est supérieur ! Exemple pour QString : partage implicite, UTF-8, UTF-16, utilisation des regexp, toLower(), toUpper(), split(), QStringList, startsWith(), endsWith(), contains(), replace(), append(), remove(), fromNumber(), toNumber(), trim()...

Avec std::string tu dois tout te palucher et perdre ton temps à re-inventer le n-ieme splitstring ou remplacement de chaîne de caractères.

Que Qt suive le modèle de Schwartz ou celui de Planck, que le constructeur ne prenne pas des iterateurs, la sémantique de at() et [] ect..., c'est du blabla et on s'en fou. Ce que je vois c'est le résultat au quotidien : avec Qt ça marche, c'est simple, c'est agréable, je développe plus vite et mieux parceque Qt est très bien foutu, bien mieux que la STL.

QString n'hérite pas de std::string

Heureusement que QString n’hérite pas de std::string ! Pareil pour QList, std::list et les autres. De toute facon la plupart des classes de la STL (dont std::string) n'ont même pas de destructeurs virtuels.

Pour passer de std::string a QString et vis versa il y a les méthodes suivantes :

std::string QString::toStdString() const std::wstring QString::toStdWString() const QString fromStdString(const std::string & str) QString fromStdWString(const std::wstring & str)

Pareil pour QList :

std::list<T> QList::toStdList() const QList<T> QList::fromStdList(const std::list<T> & list)

Si Qt est si bien (simple, facile, puissant, intuitif, performant...) c'est aussi parcequ'ils ne se basent pas sur la STL.