"mettre la race a google et facebook niveau scalabilite" c'est très difficile (d'ailleurs je doute que beaucoup de boites possèdent suffisamment de serveur pour pouvoir envisager une chose pareille) et comme tous les problèmes de recherche il est quasiment impossible à un "bac - 15" de sortir une solution miracle de sa tête. Les gens ont toujours tendance à penser qu'une fois que tu sais coder (après avoir lu "apprendre le C++ en trois jours", évidemment) tu as les compétences nécessaires pour résoudre n'importe quel problème en info...
Non, je ne parle pas de mon window manager, même s'il est très bien. Cette initiative, si elle aboutit à des enregistrements libres de qualité (et si l'orchestre et son chef ont bon goût) permettra à tous ceux qui n'ont pas les moyens de payer 30€ à la fnac pour une oeuvre de se cultiver quand même... et je serai le premier à en profiter :)
Voilà, commentaire totalement inutile mais me permettant d'exprimer bruyamment mon approbation sans limites.
Pour info, il existe plusieurs liseuses aux environs de 9" (asus DR900, kindle DX, par exemple). Après, c'est vrai qu'elles sont bien plus chères (et moins répandues).
Est-ce à dire que les sciences dures sont corrélées avec l'utilisation de LaTeX ? Ça ne e parait pas si aberrant si on se dit que LaTeX montre toute sa puissance pour exprimer des symboles (au sens d'expressions symboliques telles que les équations ou formules logiques) et non simplement des phrases, et que tout le monde (attention, appel au troll) sait que c'est le seul moyen d'être non-ambigu :>
Si j'ai bien compris, ils ont une base de code énorme en PHP (qui se chiffre en millions de lignes) parce qu'ils ont commencé avec (startup, quick and dirty, etc.). Réécrire tout ça dans un autre langage prendrait énormément de temps et d'efforts, du coup ils font ce qu'ils peuvent pour rendre PHP plus utilisable (pour les perfs, mais aussi pour la correction du programme avec de l'analyse statique tout ça).
Si les devs facebook devaient tout refaire de zéro, je doute qu'ils feraient les mêmes choix :)
Normalement, tu ne stockes qu'un seul type de données dans une map. La seule
contrainte, c'est que tu ne peux pas le vérifier à la compilation, c'est au
programmeur de faire attention.
Quand j'utilise une map donnée, elle a effectivement un type de clé et un type de valeur bien définis. Le problème reste que je n'ai pas envie d'écrire une structure de map pour chaque paire de types avec lesquels je compte l'utiliser, c'est bien mieux d'avoir une seule définition de map générique... Et avec du void*, à l'utilisation, pas moyen de savoir ce que contient réellement cette map, ce qui fait que C n'est pas très type-safe.
on oblige potentiellement à allouer quelque chose sur le tas
Si pour toi, pointeur == alloué sur le tas, je crois que tu n'as pas bien saisi ce
qu'est un pointeur.
Note le "potentiellement". Si je veux stocker un int dans un vecteur qui dure plus longtemps que mon scope actuel, avec la solution à base de void* je suis bien obligé d'allouer sur le tas de quoi stocker mon int, puisque les adresses sur la pile ne seront pas "valides" suffisamment longtemps. Allouer n'est pas gratuit, surtout dans un langage tel que C.
Effectivement, pour chaque élément ajouté à la map (implémenté avec un arbre
bicolore), tu as déjà 3 pointeurs (fils droit, fils gauche et parent) et
une couleur. Donc, ton économie de bout de chandelle, elle ne change pas grand chose...
Si j'implémente une liste générique et que je l'utilise pour stocker des int, il faut que j'alloue une cellule sur le tas par int ? Et un pointeur n'est pas gratuit, c'est une source possible de cache miss chaque fois que tu le déréférences (alors que si tu stockes l'int dans la cellule de liste, cette cellule est déjà dans le cache).
Sauf que si ta structure contient un pointeur vers une structure allouée
dynamiquement, tu ne sauras jamais quand tu dois la désallouer.
Ca je suis d'accord, mais en général dans une structure on déplace, on ne fait pas vraiment de copie. Si tu veux gérer le cas de la délétion de la structure, 1/ avec des void* le problème se pose aussi, 2/ tu peux donner une fonction "destructeur" au moment de détruire la structure (ou avant), qui se chargera (ou pas) de désallouer ce qu'il faut. Ce problème est inhérent aux langages à gestion manuelle de la mémoire, pas aux templates...
C'est justement le problème, en stockant un void* on perd à la fois l'information de type (donc de la sécurité), et on oblige potentiellement à allouer quelque chose sur le tas. Par exemple, si ma valeur est un uint32_t, il me faut l'allouer sur le tas pour qu'il persiste. Avec une map C++ j'aurais pu faire map et c'est plus efficace en stockage.
Les templates laissent le choix, je pense, si tu veux stocker un pointeur tu peux, si tu veux stocker une valeur (primordial quand tu écris un vector générique, par exemple, ou une matrice) c'est possible aussi. En C si tu veux stocker par valeur faut coder une structure de donnée par type (ou utiliser des macros immondes).
Après pour l'opérateur de copie, en C, je vois pas trop d'inconvénient à utiliser memcpy ^^
Certains ont parlé de surcharge des fonctions, mais une feature du C++ que je trouverais bien plus utile serait d'ajouter au C une forme simple (sans arguments optionnels ni variadiques) de templates. C'est vraiment ce qui me manque le plus, l'absence de types paramétrés interdit d'écrire des structures de données génériques (maps, vecteurs, etc.). Je ne dis pas qu'il faut quelque chose d'aussi compliqué que la STL, mais pouvoir écrire map simplifierait énormément la vie... et diminuerait le copier-coller de code.
[^] # Re: Mouarf !
Posté par c^3 . En réponse au journal Epitech: de la passion à l'expertise. Évalué à 2.
"mettre la race a google et facebook niveau scalabilite" c'est très difficile (d'ailleurs je doute que beaucoup de boites possèdent suffisamment de serveur pour pouvoir envisager une chose pareille) et comme tous les problèmes de recherche il est quasiment impossible à un "bac - 15" de sortir une solution miracle de sa tête. Les gens ont toujours tendance à penser qu'une fois que tu sais coder (après avoir lu "apprendre le C++ en trois jours", évidemment) tu as les compétences nécessaires pour résoudre n'importe quel problème en info...
The cake is a lie.
# Awesome!
Posté par c^3 . En réponse à la dépêche De la musique symphonique libre ? enfin ?. Évalué à 4.
Non, je ne parle pas de mon window manager, même s'il est très bien. Cette initiative, si elle aboutit à des enregistrements libres de qualité (et si l'orchestre et son chef ont bon goût) permettra à tous ceux qui n'ont pas les moyens de payer 30€ à la fnac pour une oeuvre de se cultiver quand même... et je serai le premier à en profiter :)
Voilà, commentaire totalement inutile mais me permettant d'exprimer bruyamment mon approbation sans limites.
The cake is a lie.
[^] # Re: LaTeX
Posté par c^3 . En réponse au journal Pour une disponibilité des articles de revues scientifiques au format Epub. Évalué à 2.
Pour info, il existe plusieurs liseuses aux environs de 9" (asus DR900, kindle DX, par exemple). Après, c'est vrai qu'elles sont bien plus chères (et moins répandues).
The cake is a lie.
[^] # Re: LaTeX
Posté par c^3 . En réponse au journal Pour une disponibilité des articles de revues scientifiques au format Epub. Évalué à 3.
Est-ce à dire que les sciences dures sont corrélées avec l'utilisation de LaTeX ? Ça ne e parait pas si aberrant si on se dit que LaTeX montre toute sa puissance pour exprimer des symboles (au sens d'expressions symboliques telles que les équations ou formules logiques) et non simplement des phrases, et que tout le monde (attention, appel au troll) sait que c'est le seul moyen d'être non-ambigu :>
The cake is a lie.
[^] # Re: si je resume
Posté par c^3 . En réponse à la dépêche Facebook libère son compilateur PHP just-in-time HipHop Virtual Machine (ou HHVM). Évalué à 1.
Si j'ai bien compris, ils ont une base de code énorme en PHP (qui se chiffre en millions de lignes) parce qu'ils ont commencé avec (startup, quick and dirty, etc.). Réécrire tout ça dans un autre langage prendrait énormément de temps et d'efforts, du coup ils font ce qu'ils peuvent pour rendre PHP plus utilisable (pour les perfs, mais aussi pour la correction du programme avec de l'analyse statique tout ça).
Si les devs facebook devaient tout refaire de zéro, je doute qu'ils feraient les mêmes choix :)
The cake is a lie.
[^] # Re: moar features
Posté par c^3 . En réponse à la dépêche C11 n'est pas encore mort. Évalué à 3.
Quand j'utilise une map donnée, elle a effectivement un type de clé et un type de valeur bien définis. Le problème reste que je n'ai pas envie d'écrire une structure de map pour chaque paire de types avec lesquels je compte l'utiliser, c'est bien mieux d'avoir une seule définition de map générique... Et avec du void*, à l'utilisation, pas moyen de savoir ce que contient réellement cette map, ce qui fait que C n'est pas très type-safe.
Note le "potentiellement". Si je veux stocker un int dans un vecteur qui dure plus longtemps que mon scope actuel, avec la solution à base de void* je suis bien obligé d'allouer sur le tas de quoi stocker mon int, puisque les adresses sur la pile ne seront pas "valides" suffisamment longtemps. Allouer n'est pas gratuit, surtout dans un langage tel que C.
Si j'implémente une liste générique et que je l'utilise pour stocker des int, il faut que j'alloue une cellule sur le tas par int ? Et un pointeur n'est pas gratuit, c'est une source possible de cache miss chaque fois que tu le déréférences (alors que si tu stockes l'int dans la cellule de liste, cette cellule est déjà dans le cache).
Ca je suis d'accord, mais en général dans une structure on déplace, on ne fait pas vraiment de copie. Si tu veux gérer le cas de la délétion de la structure, 1/ avec des void* le problème se pose aussi, 2/ tu peux donner une fonction "destructeur" au moment de détruire la structure (ou avant), qui se chargera (ou pas) de désallouer ce qu'il faut. Ce problème est inhérent aux langages à gestion manuelle de la mémoire, pas aux templates...
The cake is a lie.
[^] # Re: moar features
Posté par c^3 . En réponse à la dépêche C11 n'est pas encore mort. Évalué à 6.
C'est justement le problème, en stockant un void* on perd à la fois l'information de type (donc de la sécurité), et on oblige potentiellement à allouer quelque chose sur le tas. Par exemple, si ma valeur est un uint32_t, il me faut l'allouer sur le tas pour qu'il persiste. Avec une map C++ j'aurais pu faire map et c'est plus efficace en stockage.
Les templates laissent le choix, je pense, si tu veux stocker un pointeur tu peux, si tu veux stocker une valeur (primordial quand tu écris un vector générique, par exemple, ou une matrice) c'est possible aussi. En C si tu veux stocker par valeur faut coder une structure de donnée par type (ou utiliser des macros immondes).
Après pour l'opérateur de copie, en C, je vois pas trop d'inconvénient à utiliser memcpy ^^
The cake is a lie.
# moar features
Posté par c^3 . En réponse à la dépêche C11 n'est pas encore mort. Évalué à 8.
Certains ont parlé de surcharge des fonctions, mais une feature du C++ que je trouverais bien plus utile serait d'ajouter au C une forme simple (sans arguments optionnels ni variadiques) de templates. C'est vraiment ce qui me manque le plus, l'absence de types paramétrés interdit d'écrire des structures de données génériques (maps, vecteurs, etc.). Je ne dis pas qu'il faut quelque chose d'aussi compliqué que la STL, mais pouvoir écrire map simplifierait énormément la vie... et diminuerait le copier-coller de code.
Sur ce je me prépare à me faire huer :)
The cake is a lie.