LupusMic a écrit 1481 commentaires

Mais alors, quel est l'intérêt de chercher dans l'historique si ce n'est pour travailler dessus ?

Tu veux dire que tu utilises une WUI pour chercher un commit alors que git a tous les outils nécessaires pour ça ?

Chaque application susceptible de produire du son intègre déjà son propre réglage de volume

Il est où le réglage de son dans Mozilla Firefox ?

Pour moi, le réglage du son d'une application devrait être comme le réglage de la taille de la fenêtre : assiocié à la ressource.

Je me disais bien que j'aurais des réactions ;) C'est à cause de ce genre de subtilité que RMS préfère parler de logiciels privateurs, puisque des logiciels sont la propriété d'une entité au final : la FSF.

Du coup, une extension spécifique qui n'a pas de réalité standard est forcément propriétaire.

Non, extension propriétaire.

À priori il est possible, lors de la création d’un fichier anonyme, de s’assurer que personne n’a ouvert le fichier entre sa création et sa suppression, mais ça peut être délicat

Et n'élimine pas la race condition, puisque ce n'est pas un appel atomique. Sauf à compter le nombre de fd après avoir unlinké ?

Sauf que ce n'est pas simple, et qu'une solution unique n'est pas forcément souhaitable. Et que ce n'est pas la logique dans le monde du libre.

Ok, au temps pour moi, j'ai trouvé ça sur le site pourri de l'académie française :

\2. Conduire, transporter une chose en un lieu ou jusqu'à une personne. Amenez-moi ma voiture. Ces marchandises sont amenées aux entrepôts par bateau. Cette conduite amènera l'eau au village. Par ext. Fam. Apporter. Amenez vos livres, vos bagages.

Mais ça fait quand même mal aux yeux :p

il faut trouver une clef et l'amener à la porte de sortie

il faut trouver une clef et la rapporter (porter ?) à la porte de sortie

(on emporte les objets, on emmène les gens)

Parce que c'est drôle, vicieux, etc.

Au moment où j'écris se commentaire, seul 5 % des moules ont un Kinnect à la maison.

Disons qu'il est moins pire que les autres, parce que ces auteurs pratiquent une politique de sécurité raisonnable. Cependant, le problème des gestionnaires de paquets par dépôt reste ouvert, en ce sens qu'ils ne bénéficient pas des mises à jour de sécurité du système.

Un lien ? On peut trouver ce genre de blagues : https://bugzilla.redhat.com/show_bug.cgi?id=749378

Les comparaisons ne sont foireuses que pour ceux qui ne les comprennent pas.

Maven n'est pas pertinent parce qu'il ne va pas, au petit bonheur la chance, butiner sur des serveurs plus ou moins de confiance pour trouver comment satisfaire ses dépendances. Il faut spécifiquement indiquer à Maven quelles sources consulter pour étancher son désir de dépendance.
Alors qu'avec pip et compagnie, tu te retrouves souvent avec des scripts s'exécutant, provenant de serveurs dont tu n'as jamais entendu parler. Sans compter que ce sont généralement des serveurs où n'importe qui déposer une version d'un composant, sans qu'il n'y ait aucun contrôle. Tout ça parce que le comportement par défaut de PIP, c'est de jeter tout principe de sécurité de base et de se tremper joyeusement dans le premier paquet qui semble correspondre à ses désirs.

Oui, tu peux spécifier que tu ne veux pas installer, que tu ne veux que télécharger : mais ce n'est pas le comportement par défaut. Donc à la moindre erreur, s'il y a un ver qui traîne dans un paquet, tu le choppe à ton tour. Et évidement, il va se loger dans tes propres sources, que tu vas empaqueter dans un pip et uploadé (ou il va le faire tout seul, pour peut que ton trouseau de clés n'est pas protégé par une passphrase).

Pip, c'est comme la base de registre de MS Windows : une bonne idée à la base, une implémentation merdique à l'arrivée.

Je ne sais pas pourquoi tu es venu avec Maven dans la discussion. Cet outil n'a rien à voir avec Pip, Gem, et autres rustines mal-pensées.

C'est un peu comme si tu m'opposait Git dans une discussion autour des formats d'archives : ça n'a aucune pertinence.

Maintenant, Maven ne semble pas être un outil de diffusion automatique de vers, je n'ai donc pas d'opinion sur ce gestionnaire de build.

https://wiki.debian.org/SettingUpSignedAptRepositoryWithReprepro

Ah non, pitié, le pire du monde Python/PHP/Ruby en C++ ><

Est-ce qu'une appli SDL1.2 tourne avec SDL2 ?

Nop. En fait, l'architecture a été complètement revue, le bliting ne se fait plus de la même manière, ainsi que l'usage des inputs. Même SDL_Main a été viré, donc tout programme SDL 1.2 doit être porté.

En même temps, il y en a qui utilisent le cookie pour conserver les identifiants d'authentification. Chez l'un des premiers hébergeur que j'ai utilisé, il était ainsi possible de collecter tous les mots de passes de leurs clients connectés qui passaient par mon site. L'hébergement se faisait par sous-domaines, et le site de connexion était directement la racine du domaine.

Il me semble d'ailleurs que cet article a participé à ma compréhension de la programmation orientée objet et fonctionnelle, en plus des ouvrages ou conférences de Stroustrup, Meyers et Sutter.

Des serveurs RSS ? Ce ne serait pas des serveurs Web par hasard ?

La différence c'est qu'un navigateur, ça sert à naviguer. En calle-sèche, ça ne sert à rien. Et qu'on ne me parle pas de mode hors-ligne, ça n'a jamais fonctionné ce truc.

Le principe même d'un navigateur Web ? Qui est de contacter un serveur Web pour récupérer les documents HTML ?

Note qu'HTTPRack n'est pas un navigateur Web, pas plus que Wget.

Eh bien on parle aussi parfois de polymorphisme de méthode pour désigner la surcharge par opposition au polymorphisme de type que tu connais. Visiblement c'est un terme qui ne semble pas très répandu, j'ai trouvé peu de références sur le net, en tout cas il était utilisé dans les cours que j'ai eus sur les langages objets.

J'avais justement parcouru le Web pour tenter de trouver quelque chose, mais rien de bien intéressant. Ça a l'air d'être une lubie d'universitaires franco-français.

S'il faut avoir peur d'une simple délégation, où va le monde ? :-)
Je suis un fainéant, moins j'en fait et mieux je me porte :-D

J'ai pas compris l'exemple que tu as donné, pourquoi ne pas faire ça ? Le template ne fait pas bien son job ?

typedef std::vector<std::string> string_array;

Dans ce cas, string_array reste un std::vector. Je ne veux pas exposer l'interface de std::vector, et l'utilisateur n'a pas à savoir comment est implémenté string_array. Bref, dans ton cas, il est possible de confondre des type, puisque string_array est publiquement un std::vectorstd::string.
Ceci implique que n'importe quel std::vectorstd::string peut être fournit en lieu et place de string_array. Donc le jour où tu décide de remplacer std::vectorstd::string par std::vectorstd::string<MonAlloc, MonAlloc>, partout où le code utilisera std::vertorstd::string devront être mis à jour. Alors qu'en étant orthogonal dès le départ, on évite ses blagues.

De plus, il n'est pas possible de restreindre l'usage des méthodes de std::vector.

Pour le reste du commentaire, je n'ai pas envie d'être méchant, alors je n'y réponds pas…

Bah, plus personne ne nous regarde, on est entre nous, fais-moi mal.

Je pensais au "polymorphisme de méthode"…

Ben, c'est ce que permet une fonction membre virtuelle. Donc tu parles de la même chose. Personnellement, je ne connais que deux types de polymorphismes : statique, dynamique. Le premier est résolu à la compilation (en C++, il est obtenu à l'aide de templates) ; le second à l'aide de méthodes virtuelles.

Pour ce qui est de l'héritage autre que publique, je ne vois pas trop son intérêt par rapport à la composition…

L'héritage privé est l'héritage canonique. C'est pour ça que c'est sa visibilité par défaut en C++. L'intérêt de ce type d'héritage réside dans la dérivation de templates, du genre :

#include <string>
#include <vector>

class string_list
    : private std::vector<std::string>
{
    using std::vector<std::string>::cbegin;
    using std::vector<std::string>::cend;
} /* class string_list */;

Une composition, dans ce cas, pourrait introduire une indirection, et plus de code (donc statistiquement plus de bogues).

Pour moi le fait de devoir introduire des contraintes dans une définition est un inconvénient.

Et malheureusement, la plupart des développeurs pensent comme toi : à mort la rigueur ; personne ne va oser faire ça ; les mutex c'est pour les fillettes ; tout est publique, je n'ai rien à cacher.

Forcer un type permet d'assurer que le code n'échouera pas bêtement.
J'aime être certain que je ne créé pas de variable sans le savoir, en me trompant en tapant la variable.
J'aime savoir si la classe que j'utilise est copiable, clonable, si ces attributs sont en lecture seule ou non, si je peux la dériver, etc. J'aime la certitude, circonscrire les risques, là où tu semble te délecter du risque maximal.

Le polymorphisme permet de fournir une interface publique dynamique, qu'importe l'implémentation.

L'héritage complet permet d'encapsuler une hiérarchie. Par complet, j'entends celui de C++, qui permet des héritages privés ou protégés, encapsulant ainsi l'héritage.

Je suppose que par "méthodes virtuelles" tu veux parler des méthodes virtuelles pures (sinon tu te répètes :p ). Encore une fois, c'est un moyen d'indiquer une interface, et de déléguer aux implémentations l'encapsulation du problème.

Tu me trouveras certainement monomaniaque, mais au final, quand on réfléchi à tous les avantages de la programmation orientée objet, on en revient toujours à un dénominateur commun : l'encapsulation.

Justement, l'interface c'est ce qui est publique (ou protégé pour les héritiés). Ce qui est privé relève du détail d'implémentation. C'est ça l'encapsulation, c'est ça le principe fondateur de la programmation orientée objet. Sinon on aurait juste gardé les struct en C.