Batchyx a écrit 1261 commentaires

Sauf que les applis android en ce moment ce sont des gros bloatwares qui font le café, te propose de télécharger des nouvelles recettes de café, et te propose de parler de cette appli en envoyant des SMS à tout tes amis. Résultat, tu te retrouve avec des gros bloatwares qui nécessitent plein d'autorisations pour des fonctionnalités légitimes dont tu ne te sert jamais. Et comme on ne peut pas dire qu'Android soit un OS 100% libre et transparent, tu peux te brosser pour vouloir réduire les autorisations à la main, contrairement à nos Linux chéris.

C'est pas bien compliqué pourtant :

• tout ce qui est *_ptr utilise delete, *_array utilise delete[]
• scoped_* : son destructeur détruit l'objet. ne peut pas être copié.
• shared_* : utilise un compteur de référence (sans gc) et détruit quand la dernière référence est détruite. peut être copié, et est donc le seul type à pouvoir être stocké dans un conteneur STL.
• weak_ptr : c'est une référence faible vers un shared_ptr. Comme un shared_ptr qui ne contribue pas au compteur de référence (en gros)
• auto_ptr : (c'est dans la STL au cas ou) : son destructeur détruit l'objet, mais le pointeur peut être transféré d'un auto_ptr à un autre.
• unique_ptr : la même chose que auto_ptr, en version boost prévu pour le prochain standart.

Personnellement, j'ajouterai les vector_ptr/set_ptr/list_ptr/...._ptr qui sont comme des vector/set/list/...<T*> sauf que le T* est détruit automatiquement. Ça évite de devoir faire des vector<shared_ptr<T*> > et ainsi d'avoir des milliers de compteurs de références qui seront toujours à 1.

Sauf qu'ici on est en C++ et pas en C. En C pour découper une fonction, s'il n'y à pas de fil directeur, on se retrouve avec des sous-fonctions avec 20 arguments ou des structures avec autant. En C++ (ou dans les autres langages objets), on peut mettre cette fonction dans une classe et stocker l'état dans les variables membres.

Sinon, oui, reinterpret_cast<int>(NULL) = 0; compile. valgrind gueulera peut être dans ce cas la, mais pour l'encodage, Qt ou pas, STL ou pas, il faudra toujours que le programmeur fasse gaffe.

Sinon je n'ai jamais dit qu'on ne peut se passer de l'allocation dynamique. tant mieux, puisqu'il faudrai alors se passer de tout les conteneurs STL. Par contre, se passer de delete, c'est possible et même recommandé. voir un delete en dehors d'un destructeur c'est généralement le signe d'un code qui n'est pas exception-safe, et voir un delete dans un destructeur c'est généralement un gachi de lignes puis-qu'utiliser un pointeur intelligent (ou un conteneur intelligent de pointeur) économisera des lignes et des erreurs. de base en C++ il y a déjà un pointeur intelligent (std::auto_ptr) même si tout seul il n'est pas très utile.

En même temps, utiliser delete à la main dans un code C++/boost, c'est un peu comme utiliser un goto. Tu peux t'en passer dans 99% des cas, ça t'évitera de faire des erreurs et ça rendra ton code plus court et plus lisible.

Windows utilise le codepage Windows-1252, dérivé propriétaire de iso8859-1, et non pas iso8859-15.

Oh la jolie fuite de mémoire ;) Dommage que la solution correcte dans ce cas est de virer le pointeur, sinon ça aurai pu faire de la pub pour les pointeurs intelligents de boost.

pas besoin de boost pour joindre des strings :

T container;
std::ostringstream oss;
std::copy(container.begin(), container.end(), std::ostream_iterator<T::value_type>(oss, " "));
std::string result = oss.str();

avantage : ça marche pareil si T contient des nombres ou des classes. Va donc dire la même chose avec Qt.

std::string ne fait pas de partage implicite de la mémoire ? Alors change d'implémentation.

Et sinon, le principe des templates, c'est que quand le compilateur voit un template, il peut dérouler tout le code, voir tout le code inutile qu'il exécute et le foutre à la poubelle si on active les optimisations. C'est comme ça par exemple que les itérateurs de conteneurs comme std::vector ou std::string sont inlinés et souvent remplacés par des pointeurs dès qu'on passe en -O1.

Il ne faut pas exagérer, il faudrai plus de consommation en RAM que ça pour que les développeurs java se sentent comme chez eux.

(oui je sais, vendredi c'est demain.)

le logarithme complexe

Le problème, c'est qu'il n'y à pas qu'une seule définition du logarithme complexe, il y en a plutôt une infinité. Par exemple, log(-1) pourrait être égal à πⅈ, -πⅈ ou être une expression indéfinie.

Oh non tu ne les connais pas par cœurs les commandes. Tu connais peut être par cœur les commandes utilisées par un client IRC, mais je doute que tu connaisses par cœur les codes numériques de réponses. Et si tu ne connais pas les codes de réponses à envoyer à un client qui se connecte avec une paire NICK, USER, ton client ne se sentira jamais "connécté". Causer l'IRC coté client c'est très simple (ça peut même se faire à la main avec un client telnet), mais coté serveur c'est une autre paire de manche.

On parle d'un serveur IRC la. Si tu veux qu'un client IRC (ce que aujourd'hui peu de monde n'a sur sa machine) quelconque puisse se connecter et rejoindre un salon, c'est pas une centaine de ligne qui vont suffire. Si tu veux gérer les modes en respectant un peu la norme pour que les clients pas tolérants ne soient pas perdus, tu va morfler pour le nombre de lignes. Sachant que la première chose que les clients font, c'est te mettre un +i, et certains clients ne vont pas rejoindre de salon avant d'avoir eu ce +i.

Les clients IRC aujourd'hui sont assez sophistiqués, entre ceux qui vont spammer ton serveur de 'who', 'userhost', de 'away' et autres ... ils vont t'en faire baver sur les cas d'erreurs et sur tes écarts à la norme. Tu peut même faire crasher certain clients avec des assert errors si tu ne gère pas correctement le case-insensitive version scandinave. Il n'y a plus beaucoup de place pour des serveurs fait à l'arrache. J'avais commencé un serveur irc qui fait 1000 lignes et qui est tout juste capable de supporter les salon avec la plupart des clients.

Et puis même si tu fait un serveur qui supporte tout ou que tu récupère un serveur existant, si personne n'a de clients IRC, ça ne servira strictement à rien. C'est bien plus utile par exemple de faire un serveur de chat auquel les utilisateurs se connectent en telnet, ça prend moins de lignes, et c'est plus universel.

Euh, faire des scripts externes est très certainement aussi buggé que cette méthode. Surtout si tes scripts externes doivent réagir à un événement qui n'est pas fiable ou difficile à détecter sans faire du polling.

Pour avoir une floppée de scripts externes pour gérer ma config réseau compliquée, je parle en connaissance de cause.

Personnellement, j'aimerai bien pouvoir modifier par exemple les serveurs SMTP et les proxies à utiliser avec ce genre de méthode. Ça serait certainement plus fiable et plus automatisé que ce que je fais déjà.

Si t'est un power user qui s'y connaît, alors ne télécharge pas une netinstall, mais une businesscard. De toute façon tu n'a pas la patience de télécharger une netinstall en entier, surtout qu'en plus il va falloir mettre à jour le système de base de la netinstall une fois installé, et en tant que power user, ça te broute d'attendre encore plus.

Le fait d'être complètement compatible IPv6 faisait parti des but de Squeeze. Les utilisateurs de sid ont pas mal souffert pour avoir ce support out of the box ;)

Ouais, sauf que la libc d'android n'est absolument pas posix ni même c99, et on ne peut même pas émuler ce support tellement elle manque de fonctionnalité. Rajoute à cela que android n'a pas de serveur X avec sortie sur l'écran du gadget et que le framebuffer est déjà utilisé par les bidules java. si t'essaye d'écrire directement dans ton fb, ça va clignoter (pour l'avoir vu, c'est moche).

et pas besoin de Qt, la compilation échoue avec bien plus simple que ça. screen par exemple, vu que la libc android possède une api bâtarde pour gérer les pty.

La résolution n'a rien à voir avec la taille de l'écran, mais seulement dans le sens croissant. Ou alors il faudra me trouver une police lisible avec une taille de 3 ou 4 points. Ça risque déjà d'être difficile de faire un E (il faut au moins 5 points). alors que dire du É, £, & ou § qui doivent en nécessiter bien plus.

Mais je voulais surtout prouver que l'argument "tu ne sais pas gérer l'espace de ton écran" ne justifie pas le fait que la "plainte ridicule est totalement irrecevable".

Et si moi je m'amène avec un écran en 800x600, est ce que la plainte sera tout autant ridicule et irrecevable que Marc ? Même si je suis sous wmii avec midori ?

Moi qui croyait que le principe de base d'un site web accessible, c'est qu'il doit marcher avec toutes les résolutions et tailles de textes.

Ai-je dit le contraire ? Je n'ai même pas parlé d'utilisateurs qui n'ont rien à faire de l'informatique.

Faut arrêter avec les Linuxiens "moins doués et moins curieux", ça fait très Michu qui parle de "dieu en informatique" alors que ça n'existe pas.

L'informatique c'est vaste. La curiosité informatique est vaste aussi, tout comme les compétences. Tout le monde ne sais pas tout et n'a pas envie de tester toutes les alpha et les bétas de logiciels.

Personnellement, mon browser je m'en balance. Ça ne veut pas dire que je ne sais pas télécharger et tester une version beta de Firefox, mais juste parce que je n'ai pas envie de le faire, parce que pour Firefox ça m'intéresse pas, ça ne va pas révolutionner mon usage du web.

Ça ne veut pas dire que je n'aime pas les bétas. J'en ai des logiciels en béta/svn/git, simplement parce que ces logiciels m'intéressent.

Et la diversité de ces "curiosités" et de ces points de vues sont quand même un peu proportionnels au nombre d'utilisateurs d'OS, Surtout pour un browser : on navigue pas mieux en étant sous Linux qu'en étant sous Windows.

Le problème, surtout, c'est que la plupart de ces algorithmes de systèmes distribués, lorsqu'ils répondent au besoin, sont bien plus lents qu'une communication directe, et ils sont donc complètement impraticables pour une utilisation dans un jeu en ligne temps réel à cause de la latence trop importante.

Et surtout, un aimshot, par exemple, respecte parfaitement le protocole et les postconditions, puisqu'un humain doit de toute façon être autorisé à viser correctement.

C'est triste ton point de vue sur ceux qui codent avec Vi.

Je ne suis pas sûr qu'un transfert des droits patrimoniaux compte comme une "distribution". Mais je ne suis pas juriste ;)

Pas sûr, à mon avis ils pourraient toujours fournir un logiciel qui fait des mélanges hasardeux de licences (exemple : GPL + une licence incompatible avec la GPL) qui au final t'empêche de distribuer le logiciel.

Je compile toujours en -Os, sauf pour les machines récentes.

Sinon oui le gain en cycles CPU est souvent négligeable, mais dans les vielles machines c'est souvent la RAM qui limite. La vitesse ça limite moins, suffit juste d'attendre plus longtemps. Y a que dans certains cas que la vitesse limite, comme par exemple, la lecture de vidéo (avec mplayer bien sûr ;) ).