LupusMic a écrit 1481 commentaires

Et encore, la première fois que je l'ai lu, il y a 15 ans, j'était en Math Sup TPC, avec donc masse de chimie : ben je ne voulais pas croire qu'il parlait de l'eau, je ne pouvais pas imaginer qu'une personne puisse soutenir ce genre de discours. Ce n'est que lorsque j'ai découvert le pot-aux-roses que je me suis détendu :)

Et oui je pense que la consommation de tous les gras est mauvaise et doit être déconseillé…

Tu dois profondément manquer d'acide (gras) linoléique pour clamer ce genre d'ineptie.

C'est parce qu'il n'a pas 5 ans qu'il n'a pas à se justifier.

Et dire qu'on m'a toujours vendu GNOME comme étant un Desktop Environment, plutôt qu'un Laptop Environment.

Quand je pense que l'eau est un composé chimique.

"Voulez-vous manger ces produits composés avec de la chimie ?"

Tu es au courant que mariner, cuire et fermenter c'est de la chimie ?

En même temps les machines avec lecteur optique sont plus l'exception que la règle de nos jours.

Tu as une statistique ou c'est une affirmation fumeuse ?

Ce n'est pas ce que Michel critique. L'huile, c'est du gras, le gras c'est de l'huile. Le sucre c'est les glucides, les glucides sont le sucre. Ce sont des synonymes. C'est pour ça que c'est idiot de spécifier que du sucre contient du sucre.

Par contre, la radioactivité et la toxicité de l'Uranium ne sont pas spécifique à ce métal. C'est une propriété partagée par d'autres produits. Du coup, avoir un symbole pour désigner ces propriétés physique (la radioactivité du matériau) n'est pas absurde. C'est pareil avec les produits corrosifs : les acides et bases fortes ne sont pas de même nature, mais ont une action équivalente sur les tissus humains : on peut leur associé un symbole commun alors que leur nature est antagoniste.

Libres !!! Non de Droite, enfin de Gauche, enfin, ça dépend comment tu les regardes. Un peu comme comme un fumeux chatton.

Bon, voilà bien le problème de ce genre de projets : raconter des conneries.

Le E510d est un colorant produit à l'aide de sulfite d'aluminium, mais le sulfite d'aluminium n'entre pas dans la composition du caramel.
Quand à son aspect cancérigène, il est plus que spécieux.

Alors qu'on ferait mieux de s'attaquer à un produit toxique, mortel, qui tue chaque années des millions de gens, et qu'on retrouve dans les cellules cancéreuse. Hein, personne n'interdit la DHMO http://dhmo.org/facts.html !!!!1111

On sait que le Coca c'est toxique, comme l'alcool : c'est pour ça qu'on les boit (et parce que la drogue, c'est difficile d'en sortir).

Vu que le sucre représente juste 11 % de la masse, je me demande quelle couleur ces couillons vont utiliser pour un quatre-quart.
D'ailleurs, dans la fiche du Bounty, la proportion en sucre est plus élevée, et pourtant n'apparait pas en vert. Il y a même un ingrédient qui est en vert, alors qu'il est certain qu'il y a des OGM dedans (au moins à l'état de traces). Ce qui ne me pose aucun problème, mais les « clients » de ce genre de rumeurs sur la toxicité des aliments ont une peur irrationnelle qui leur fait croire que les OGM vont pousser dans leur intestin.

D'ailleurs : http://fr.openfoodfacts.org/additif/e322-lecithines

Aucun ordinateur ne peut garantir une exécution dans un temps donné, parce que tout simplement il ne le peut pas physiquement. La seule chose qu'un processeur peut éventuellement garantir, c'est le nombre de ticks processeurs qui seront alloués à une instruction. Et c'est en comptant ces ticks par instruction qu'on peut déterminer en combien de ticks un programme peut s'exécuter. Cela permet de calculer un temps statistique d'exécution, mais il ne pourra pas être garanti avec précision.

Ce que tu appelle du RT mou, ce n'est pas du RT. C'est une exécution sous contrainte de temps, mais ça n'a rien à voir avec une quelconque garantie.

C'est gentil de dire que je raconte n'importe quoi pour ensuite me paraphraser. Quand je dis « Il sait simplement qu'un .C va être compilé en .o », ça veut bien dire qu'il va vérifier le ctime du .C et lui appliquer une commande pour le transformer en .o. Je n'excluait pas d'autres suffixes.

J'aime la fiabilité. C'est énervant quand un programme est lent, mais c'est la panique quand il tombe en marche pour aller plus vite. En l'occurrence, j'ai bien déjà tenté d'utiliser les mécanismes de génération de dépendance, mais il faut bien avouer que ça ne fonctionne pas toujours. Je préfère quand ça ne marche jamais, ou quand ça marche tout le temps, je déteste l'entre-deux plein de terreur, plein de sombritude. Mais si tu as une ressource qui peut m'aider, tu es le bienvenue (et non, je ne replongerais pas dans autoshit, je tiens à conserver ma santé mental :D ).

Un jeu vidéo, ce n'est pas du temps réel (TR). Le TR, c'est garantir qu'une opération peut être effectuée en un nombre de cycle déterminé, et ce de manière déterministe. Sous architecture Intel, c'est le genre de chose impossible, par exemple. Tu trouveras des tas d'articles qui vont prétendre qu'on peut faire du TR sous Intel, mais dans l'absolu, la moindre instruction (sauf div) peut être victime d'une interuption matérielle, ce qui rend impossible à la plate-forme de garantir un nombre de cycles précis pour une instruction assembleur.

Je parlais de make. Make ne sait pas ce qu'est un fichier C++. Il sait simplement qu'un .C va être compilé en .o par gcc suivant une règle par défaut. Mais il ne peut pas deviner quels en-têtes un module inclus. Alors certes, il est possible de contourner avec l'option -MM de gcc, en créant un fichier de dépendance. Mais je n'ai jamais réussi à le mettre en place de manière fiable.

En pratique, je fais dans l'orthogonalité, et j'applique le pimpl idiom, histoire de me blinder contre les mauvaises surprises.

On ne parle pas ici de temps réel, mais de jeux vidéos. C'est bien ce que je reproche un peu à ton propos. Si je voulais faire mon chaint, j'aurais pu commencer à parler des problèmes d'orthogonalité d'un code défini dans le header, inliné dans tous les modules ; des problèmes de compilation qui verrons le jour quand la structure d'une classe sera changée, et que tous les modules l'utilisant ne sont pas recompilé (le problème classique de make qui ne prend pas en compte les en-têtes, car il ne peut pas), etc.

L'overcommit memory est une optimisation acceptable quand la fiabilité n'est pas priomordiale, mais que la vitesse d'exécution l'est. C'est le cas typique d'un jeu vidéo. Je suis cependant moins enchanté lorsque c'est une base de données qui est trompée par l'OS. Sur ce genre de machines, j'aurais tendance à désactiver l'overcommit (en plus de la swap).

Cyrus ? Dovecot ?

Bah, exec, cow, c'est du pareil au même :p

Notes bien que ce n'est pas grave, pour moi, que ça prenne une place monstre en mémoire. Tant que ça permet d'améliorer les performances, l'usage du matériel doit être total.

Ceci est valable pour la mémoire dynamique. Les sections statiques du programme sont directement mappées dans la mémoire du processus. Ensuite, Linux fait du COW sur ces sections, certes, mais stricto sensus, la mémoire est allouée.

Oui, on appelle ça une optimisation.

Ça tombe bien, il n'y a pas d'interruptions, mais une exception. Et les exception ne sont pas lourdes.

J'ai attrapé l'exception parce que je voulais respecter l'interface initialement proposée. Mais très franchement, l'exception devrait être propagée, car tenter d'accéder au-delà de l'identifiant d'entité maxiamal est une erreur de programmation, qui doit être géré par l'appelant.

Quand à l'argument foireux de l'inline, tu me fais doucement rire. On parle d'une fonction qui est définie dans un module. Elle ne sera donc pas inlinée dans les modules appelant.

C'st une plaisanterie ? Tu ne consommes pas de mémoire parce que tu la réserves à l'invocation du programme ? Il y aura forcément une perte d'espace mémoire pour le gain de performance, c'est un compromis classique.

Je ne comprends pas ta phrase dans ce contexte.

Au fait, j'ai oublié un * dans le type de retour de la fonction, my bad.

Lorsque tu créé un tableau d'objets, tous les objets sont alloués et initialisés (constructeur par défaut appelé).
Ce n'est pas le cas si tu alloue un std::vector suivi d'un std::vector::reserve, où seule l'allocation sera effectuée.

Mais oui, il y aura de la mémoire perdue, forcément.

En effet, l'usage d'un std::array pourrait être envisagé, puisque les composants sont stockés par type.

std::array<Component, N> composantPool;
std::array<Component *, N> composantAddress;

Component getComponent(int entity)
{
    Component * comp = std::nullptr_t;
    try
    {
        comp = composantAddress.at(entity);
    }
    catch(std::out_of_range & e)
    {
        comp = std::nullptr_t;
    }

    return comp;
}

Non, tu as tout à fait raison.

Quel MVC ?

http://addyosmani.com/resources/essentialjsdesignpatterns/book/#detailmvcmvp

Donc tu voudrais que tous les sites, en plus de réinventer dix-mil fois l'UI, doivent fournir des outils de gestion de ton matériel ? C'est fun.