LupusMic a écrit 1481 commentaires

Via les serveurs de clé ?

Non, MySQL peut être compilé directement.

Le format de stockage de la base de données n'a rien à voir avec la portabilité. On parle de portabilité pour un logiciel. Pour le format de fichier, ce serait plutôt de l'interopérabilité.

Merci pour l'info. J'ai fini par me rendre compte que Launchpad utilise un n-ième SCM :) J'ai essayé de cloner. On verra ce que j'arrive à en tirer.

Je n'ai jamsi utilisé Lauchpad, mais ça m'a l'air bien obscur. Sur GitHub tu as directement une URL git qui te permet de récupérer l'arbre de versionement. N'y a-t-il pas la même chose sur Launchpad ?

Certains parlent du barbu :)

Qu'on parle d'huile, ou d'huile de roche, le problème reste le même. Les longues chaînes carbonées ne sont pas miscibles dans l'eau du fait de leurs propriétés physique.

Prouver le contraire signifierait que l'ensemble des chimiste, les biochimistes, les ingénieurs, etc considèrent pour vrai un fait qu'ils observent quotidiennement alors qu'il est faut.

La seule grande différence entre l'huile de roche et l'huile végétale ou animale, c'est que cette dernière a une tête hydrophile (c'est la partie acide de la molécule, c'est aussi pour ça qu'on les appelle des acides gras). Du coup, ces corps ont une propriété stupéfiante : pouvoir entrer en émulsion avec l'eau. C'est ce qu'on réalise pour obtenir une vinaigrette.

Dans un récipient, verser moitié huile (de plante, hein), moitié vinaigre (acide acétique). On constate que deux phases perdurent. Selon la densité de l'huile, elle sera sous l'eau, ou plus généralement, sur l'eau. L'émulsion s'obtient en frappant violemment les deux liquides pour que les phases s'entre-choquent. Les têtes hydrophiles vont avoir tendance à s'ioniser (se dissoudre dans l'eau. Les queues à se réfugier entre-elle, loin de cette eau répulsive (là, vous pensez à la métaphore sexuelle que vous voulez).

Au bout de quelques minutes, ce traitement aura pour conséquence de rendre difficilement perceptibles les phases car elles seront entre-mêlées, sous la forme de bulles millimétrique (ou microscopiques si vous êtes un sauvage).

Mais ceci de marche pas avec les pétroles. Ces substances sont composées d'une grande variété d'alcanes, d'alcènes et de molécules aromatiques (benzènes), qui eux ne peuvent absolument pas se dissoudre dans la flotte, car ce sont des hydrocarbures (pas de tête ionisable).

Finalement, l'étude mise en lumière par le prix IgNobel n'est pas fausse : elle est malhonnête en détournant le vocabulaire, ce qui est encore bien pire.

La barbe est juste un ensemble de poils localisés particulièrement.

Ce que tout le monde semble oublier, c'est que l'émission de monnaie est un monopole d'État, même aux ÉUA. Du coup, c'est illégal dans la plupart des pays.

http://www.open-std.org/JTC1/SC22/WG14/www/standards (c'est un draft de C99, mais ils ne sont jamais loin du contenu qui tien lieu de standard, et c'est compatible avec les C précédents).

Paragraphe 6.5

Je cite:
“71) This paragraph renders undefined statement expressions such as
i = ++i + 1;
a[i++] = i;
”

Les règles de priorité s'est bien beau, mais elles sont là pour indiquer à l'implémenteur le comportement souhaitable. C'est comme l'évaluation fainéante : elle est courante, mais n'est absolument pas garantie par les normes du C.

En C++ on n e devrait utiliser que rarement l'incrémentation des entiers.

Le boulot du compilateur n'est pas d'optimiser. Le travail du compilateur c'est de traduire du code source en code machine. L'optimisation, c'est du bonus. Compter sur les optimisations du compilateur, c'est s'assurer d'écrire du code qui n'est pas portable pour un sous.

Le standard C ne garanti pas que l'incrémentation soit effectuée avant ou après l'affectation. C'est un détail d'implémentation laissé au concepteur du compilateur. C'est du code qui n'est pas portable.

Une des règles de base en programmation, c'est quand même d'éviter de faire plus d'une chose par ligne. Surtout en C.

C'est surtout que je ne connais pas tout les prototype de surcharge par cœur. Vu que c'est à utiliser avec parcimonie. Il n'y a vraiment que dans l'implémentation d'un itérateur que la surcharge des opérateurs d'incrémentations et de décrémentation (qui sont de toute façon particuliers) où ils sont utiles. Et puis bon, j'en écrit pas tout les jours des itérateurs :)

Il fallait lire
// Post incrémentation
T const operator ++()
{
T tmp(*this) ;
++*this ;
return tmp ;
}

// Pré incrementation
T const & T::operator ++(int)
{
// On fait l'incrémentation ici
return *this
}

Quel boulet, j'ai oublié de virer le deuxième paramètre entièrement. Au temps pour moi.

J'ai dit, à titre d'illustration. Parce que c'est plus simple de montrer une implémentation de operator++ que de parler d'assembleur.

Ça ne change effectivement pas grand chose, mais c'est quand même une mauvaise habitude (se reposer sur le compilateur pour compenser une mauvaise habitude).

Utiliser des noms de variables obscures ou ne pas documenter son code ne change non plus pas grand chose à l'exécution du code compilé. Ceci dit, ce ne sont pas de bonnes pratiques.

Quand au code du noyau, je n'y touche pas. Je n'ai pas le matériel ni l'expérience pour le modifier.

J'ai surtout oublié de remplacer entièrement mon typename T par T. Par contre, le deuxième const dans quel sens ?

La variable locale statique n'a aucun intérêt, si ce n'est d'introduire des bogues avec des variables globales cachées.

En C, une bonne pratique consiste à demander au client (le code qui utilise la fonction) d'initialiser une zone mémoire et de fournir un pointeur sur cette zone avec la taille. Ça évite de prendre la responsabilité d'allouer de la mémoire, ou d'utiliser ce genre de bricolage.

Ne pas prendre la responsabilité d'allouer de l'espace mémoire permet de laisser au client le choix de l'allocateur, du type de mémoire (automatique ou dynamique), etc.

Et effectivement, en passant, si à chaque invocation l'application doit initialiser de la mémoire automatique statique pour une centaine de fonctions, ça va commencer à faire cher l'optimisation précoce.

Le segfault n'est pas assuré, bien au contraire.

C'est pire lorsque la variable est statique pour une simple raison : l'exécution du code aura encore plus l'aspect d'un code fonctionnel. Or, ici on voit très bien que la fonction est un piège à con, comme je l'ai déjà expliqué plus haut.

En quoi est-ce risible ?

Mon commentaire est uniquement destiné à mettre en perspective le prétendu focus sur la sécurité mis en avant dans la dépêche. Je suis persuadé qu'un audit approfondi apporterait de l'eau à mon moulin.

C'est vrai que j'ai tendance à plus faire du C++ que du C, et donc la pré-incrémentation a du sens. Ceci dit, le compilateur n'est pas contraint d'optimiser, et une variable temporaire peut donc être générée lors de la post-incrémentation pour récupérer le résultat de la post-incrémentation.

À titre d'illustration, en C++, on surcharge classiquement l'opérateur de post-incrémentation ainsi (T étant un type quelconque) :

// Post incrémentation
T const operator ++(typename const & target)
{
T tmp(target) ;
++target ;
return tmp ;
}

// Pré incrementation
T const & T::operator ++(int)
{
// On fait l'incrémentation ici
return *this
}

On voit bien que la post-incrémentation devrait créer une copie temporaire à retourner (même si c'est un objet anonyme qui est créé, ça dépend des options d'optimisation).

L'incrémentation ne devrait pas être faire en même temps qu'une autre opération : le C ne garanti pas forcément un ordre d'exécution des instruction dans une même expression. Le choix est laissé à l'implémentation. Par exemple, dans l'expression suivante, le résultat est indéterminé par le standard C.
f(i++, i -=2) ;

Donc non, la post-incrémentation est à proscrire sauf cas particuliers.

Fichier ashd/src/sendfile.c (je suis tombé sur ce fichier en tentant de compiler le bousin)

static char *attrmimetype(char *file)
{
#ifdef HAVE_XATTR
static char buf[1024];
int i;
ssize_t sz;

if((sz = getxattr(file, "user.ash-mime-type", buf, sizeof(buf) - 1)) > 0)
goto found;
if((sz = getxattr(file, "user.mime-type", buf, sizeof(buf) - 1)) > 0)
goto found;
if((sz = getxattr(file, "user.mime_type", buf, sizeof(buf) - 1)) > 0)
goto found;
if((sz = getxattr(file, "user.Content-Type", buf, sizeof(buf) - 1)) > 0)
goto found;
return(NULL);
found:
for(i = 0; i < sz; i++) {
if((buf[sz] < 32) || (buf[sz] >= 128))
return(NULL);
}
buf[sz] = 0;
return(buf);
#else
return(NULL);
#endif
}


Bon, goto bien utilisé ça peut être pratique.

Cependant, renvoyer l'adresse d'une variable locale c'est pas bien, et c'est encore pire quand elle est statique. Quid d'appels consécutifs, parallèles ?
Les débutants utilisent la post-incrémentation et ne comprennent pas que ni sizeof ni return ne sont des fonctions.
Le copier-coller c'est mal, DRY qu'il y'en a qui disent.

Tiens, c'est pas documenté, donc on ne sait même pas qu'il faut copier 1024 - 1 caractère depuis le pointeur retourné dans un nouvel emplacement. Une fonction difficile à utiliser manipulant des chaînes conduit inexorablement à des problèmes de sécurité.

Et je n'ai regardé qu'une fonciton.

Les dictionnaires ne contiennent pas l'ensembles des mots. Ce ne sont que des sous-ensembles des mots de la langue. Du coup, l'absence d'un mot du dictionnaire ne signifie pas qu'il n'existe pas.

L'intégration à FB ne signifie pas que FB aura un blanc seing pour pénétrer tes données. Une telle intégration peut signifier deux choses:
- récupérations de données depuis FB
- publication de données vers FB

Mais je suis bien curieux de voir comment ils vont s'intégrer à FB en isolant chaque utilisateurs sans que les développeurs de Diaspora n'ait accès aux données de toutes les instances de Diaspora. Parce que je vois mal chaque utilisateur créer une application Diaspora sur FB, rien que pour pouvoir interagir avec son compte.

Au delà du fait que ça rempli ma gamelle, FB me permet de rester en contact avec plus de personnes qu'à l'habitude. D'expérience, on perd le contact avec quelques amis, et beaucoup de connaissances. Ça m'est souvent arrivé de me demander « mais qu'est devenue cette personne », « C'est con que je n'ai jamais eu le temps de rappeler telle personne », etc. C'est à ça que sert FB : réduire sa mauvaise conscience en ce permettant de rester en contact (même partiel, superficiel) avec des personnes que j'apprécie un minimum.

Cela ne remplace pas mes véritables amis. Qu'ils soient IRL ou non. Mais étant handicapé du téléphone, peu prompt à sortir et à organiser des soirée, les réseaux sociaux me permettent de conserver un lien.

Et puis ça distrait dans la journée. Ça permet de virer l'instance de code pourri qu'on est en train de déboguer pour la remplacer par une vue plus propre. Avec souvent la solution à la clé. Mais pour ça, il y a d'autres distractions sur l'Internet, je te l'accorde.

C'est le minimum pour exister. Un projet de réseau social décentralisé qui ignorerait les réseaux existant est voué à l'échec.

Plutôt que d'imaginer tu devrais vérifier ;)

La mémoire, ce n'est pas la place du binaire sur le disque dur. Si tu embarque une bibliothèque dans le projet de ton logiciel, tu vas compiler cette bibliothèque. Cette version ne sera pas la même que celle fournit par la distribution. Le logiciel sera lié avec cette bibliothèque, le path de la bibliothèque étant décidé lors de la compilation. Donc oui, il y aura deux version de la bibliothèque dynamique chargées en mémoire. Au passage, ça n'a rien à voir avec les headers.

Dernier chapitre d'une norme longue et imbuvable, pas étonnant ;)
http://www.w3.org/TR/CSS21/ui.html#system-colors

Par contre ils le déconseille dans la CSS3, argh. C'est crétin ! J'espère qu'il y a un remplaçant..