LupusMic a écrit 1481 commentaires

Des loops ? l'en-tête algorithm est ton ami.

De la gestion mémoire ? Les RAII sont tes amis.

Des effets de bord ? Les variables globales sont interdites sous peine de mort.

de plus en plus de boites interdisent tout simplement PHP

Je suis intéressé si tu as une source.

Penses-tu qu'utiliser HipHop ou HHMV permet de contourner PHP (l'implémentation) efficacement ?

Python à la mode ? Mais c'est déjà has been depuis longtemps : JavaScript, Ruby, Dart ou Rust sont des langages bien plus à la mode !

Ceci est un détail d'implémentation, un double doit être au moins un float, mais ce pas forcément supérieur.

Pas plus qu'il ne suffit d'un moteur pour faire une voiture, mais c'est indispensable.

Un peu comme la bielle au moteur à vapeur ; la roue au transport ; la bêche au jardinage. Des innovations sans lesquelles une technologie n'a pas la même saveur.

« optimiser le passage à l'échelle »
Et en français ça donnerait quoi ? MapReduce permet d'affronter les problèmes de croissance (en volume de données et de requêtes) certes, des problèmes qui irrésolus n'auraient pas permis à Google d'exister. On serait encore à se coltiner des moteurs peu pertinent tels qu'Altavista ou Y!

L'incapacité à scaler aurait empêcher Google de croître, c'est certain. Et c'est ce point que je mettais en avant.

Si, Google c'est MapReduce au départ, ce qui permet une recherche rapide sur un ensemble très large de données. Pas de programmation fonctionnelle, pas de Google.

Ah oui, quand je dis Google, je parles évidement du moteur de recherche, pas le reste autour.

Calmés ? Non, il faut dormir de temps à autre.

Quand je parlais des header C, ce n'était pas pour privilégier std::cout par rapport à std::printf, mais à préciser qu'en C++ correct, on essaye d'employer les mécanismes d'isolation au maximum.

Donc j'aurais préférer lire :

#include <cstdlib>

j'en conviens, c'est du pinaillage. Mais ça indique que le programmeur qui a codé ces quelques lignes que C et C++ sont deux langages différents, dont même les types de base divergent parfois dans leur sémantique et leur implémentation.

Par exemple, le code suivant ne référence pas le même type d'objet en C et C++.

// En scope global:
int const c_counter;

Même comme je l'ai dit, ce n'est pas printf qui m'emmerde, c'est l'emploi bogué de snprintf.

Quand à prétendre employé printf pour éviter les buffer overflow, c'est une blague sympathique. C++ réduit le risque de buffer overflows parce qu'il nous éloigne des pointeurs. Plus on manipule de pointeurs, et en particulier de pointeurs nus, et plus on a de chance de créer du code compromis.

L'exemple canonique est std::vector<>, qui remplace avantageusement les pointeurs de pointeurs, sans aucun risque de buffer overflow.

Le programmation fonctionnelle a changé le monde, le monde n'est pas le même avant et après Google, qui est tout de même l'application du paradigme de la programmation fonctionnelle le plus proéminent (MapReduce et autres applications du paradigme).

Inventer un nouveau paradigme, c'est révolutionnaire, ça change le monde.

C'est gentil et merci, mais je m'en fou des accusations de personne qui réponde par une boucle à une question de logique informatique.

Comment tu réponds alors à des problèmes d'itération de données dans ce cas ?

C'est pas grave, ils trollent…. ils ne savent faire que cela.

Je… mais oui, mais c'est bien sûr, tu es sur DLFP ! Bienvenue \o/

C'est amusant surtout le C/C++… c'est le prof qui leur a dit que c'était pas bien, alors j'accepte la mauvaise note :D

C'est génial le C++, même le C, mais il faut savoir faire la part des choses.

Je répondrai : regarde le code qui est générer en C et en C++ pour ce genre d'opérations et tu auras ta réponse.

Quand je m'intéresse à un outil, et que je dois le compiler, je l'audit pour savoir si le compiler et l'exécuter ne compromet pas mon système. Donc le code source est ce que je vois en premier, et la lecture peut s'arrêter rapidement.

D'ailleurs je n'ai eu aucune réponse en retour concernant mes questions pour l'analyse en objet d'une Hotline, des 45000 filtres en 0.7 seconde (normalement c'est 30 minutes avec les objet TableDB du marché),

Pas la peine, mon ordi quantique en IPoT le fait déjà en 6,59 ns (tu vois, ça c'est troller, apprends la différence).

et autres questions qui rendent réel et concrète des discussions stériles et stupides puisque basée sur un dogme appri, et ne serait-elle basée que sur le résultat de compilation on ferrait avancer le schmilblique ;)

Des dogmes découverts, sous des stèles sur lesquelles je sacrifie des petits chats à la gloire de Meyers, Sutter et Stroustrup.

Et puisque tu me semble correct, franchement, ça m'amuse, je sais ce que je vais sortir dans quelques semaines et j'attend avec impatience leurs remarques, vraiment j'en rigole déjà, tu pourras leur demandé leur opinion de "spécialiste" :D à ce moment là.

J'espère avoir du temps à tuer !

Perso je suis pas un spécialiste ou un excellent programmeur, mais j'ai toujours fait des programmes mi en production chez des gros clients et qui ont toujours fonctionner SANS PLANTAGE ni téléphone d'URGENCE pendant DES ANNEES de fonctionnement en PRODUCTION REEL. Avec des fois des algos assez sympa, je crois.

Je te crois sans problème, j'ai vu tellement d'horreurs qui fonctionnent dans ma petite vie de programmeur que ça ne m'étonne pas.

Mais si je l'ai fait ainsi c'est que à un moment la class ne se créait pas et j'avais un zéro en retour.

Oh, de la programmation par hasard :o)

Franchement, c'est un bogue de ton compilo… à moins que tu ne compiles en désactivant les exceptions ?

Ça dépend quel est le but de la publication. Un gars qui vient nous raconter qu'il est plus malin que tout le monde, alors que son code montre un manque de maîtrise des parties du langage dans lequel il implémente sa panacée, n'a pas ma clémence. Et plutôt que de rejeter les remarques constructives que les pinailleurs dans mon genre fait, il devrait les considérer.

Ensuite, du code caca, j'en écris aussi. C'est publié, mais je n'en fait pas une publicité monstre en disant que je révolutionne le monde.

Oh si, ça a une utilité : montrer ce qu'est une fausse bonne idée :-D

POSIX ⇒ Portable Operating Système Interface
La portabilité à de toute façon toujours des limites.

La décision de flusher est de la responsabilité de std::cout ou std::cerr, voire std::clog. À noter que std::cerr (et donc std::cerr) n'est pas bufferisé dans un environnement POSIX. Tout ça est en fait défini dans POSIX, pour les flux standard de sortie. L'idée est que STDERR n'est pas souvent écrit, et donc il n'y a pas de problème à flusher, et ça répond surtout à ton interrogation ; alors que STDOUT est destiné à envoyé du bois, et doit donc être configuré au mieux pour une sortie optimale.

Ensuite, si tu utilises un autre système de log, ça configuration devrait se faire en fonction des compromis que tu dois faire. Il n'y a là pas de solution universelle, mais une question de besoin de l'application et de ses clients.

Concernant le "satck Overflow", j'ai beaucoup de chance.

En effet.

./evenja `python -c "print 'x' * 4100"`

Une version non internationalisée :

std::cout << "The captain is " << age << " old.\n";
std::cout << std::format("The captain is %d old.\n") % age;

Traditionnellement, pour traduire une phrase on utilise la fonction (ou la macro) _ :

Une version internationalisée (où je considère qu'il existe un overload pour la fonction _(std::stringstream ss) ) :

std::cout << _("The captain is ") << age << _(" old.\n");
std::cout << _(std::stringstream("The captain is ") << age << " old.\n"); 

std::cout << std::format(_("The captain is %d old.\n")) % age;
std::cout << std::format(_("The captain is %1$d old.\n")) % age;

Dans le premier cas, il faudra traduire deux chaînes, qui ne sont pas des phrases complètes. Ici le problème n'est pas très grave, car l'ordre des séquences sera le même en français ou en allemand qu'il l'est en anglais. Mais la traduction risque tout de même de ne pas être correcte ("Le capitaine est ", " vieux.")

Dans le second cas, il y aura autant de chaîne à traduire qu'il y a d'âges possibles. Sans compter que je ne suis pas convaincu gettext supporte l'évaluation d'expressions lors de la création du catalogue de traduction.

Enfin, dans le troisième cas, avec la chaîne de format, il n'y a qu'une chaîne à traduire. Le quatrième permet ici est inutile, mais s'il y a plus d'un arguments à la chaîne (genre le nom du capitaine), il est possible de préciser la position de l'argument, et on pourra donc déplacer l'ordre relatif des placeholders dans la chaîne.

Note qu'en Python, on peut nommer ces arguments et utiliser un dictionnaire pour l'alimenter, ce que certains considéreront plus lisibles, là où d'autres se plaindront de la verbosité.

args = { 'age': age }
print _("The captain is %age old.\n") % args

En effet, j'ai tord sur ce point. Merci d'avoir relevé ce point, j'étais certains que le C++ guarantissait la destruction des objets alloués dynamiquement.

Bon, une variable automatique est donc plus adaptée comme celà a été proposé précédement.

En PHP j'utilises sprintf, jamais la concaténation.
En C++, j'utilises boost::format.
En C, snprintf.
En Python, le mécanisme natif avec l'opérateur %.
En JavaScript, je pleure ma mère et je supplie pour qu'on utilise un système de template à la mustache.

En fait, je trouve la concaténation ou l'injection de chaîne totalement illisible. Le soucis de l'i18n me pousse aussi à employer des formats de chaîne.

Au fait, std::endl, ce n'est pas un synonyme de "\n". std::endl flush en plus, ce qui peut avoir des conséquences sur les performances http://en.cppreference.com/w/cpp/io/manip/endl

Non, il a raison. Je suis le premier à ne pas être tendre, et à taper fortement. Cependant, j'essaye de le faire en argumentant, en évitant les attaques /ad hominem/ et autres pourrissement de débat. Je n'y arrives pas toujours, mais quand même.

En fait, ce qui me choque le plus dans ce passage, c'est l'emploi inutile de sprintf. Utiliser printf directement aurait été plus pertinent, et sans risque de buffer overflow.

Notez que j'aime tendrement snprintf, mais que je ne l'emploi que de manière encadrée.

La mémoire est une ressource comme les autres. Et non, les deux pointeurs automatiques ne font pas de la gestion mémoire : ils peuvent acquérir une resource à la contruction et peuvent la relâcher à la destruction.

Tu noteras d'ailleurs qu'il est possible d'hériter intimement d'un std::shared_ptr pour impléter un gestionaire de mutex, ou tout autre ressource dans ce goût là : http://www.boost.org/doc/libs/1_55_0/libs/smart_ptr/sp_techniques.html#handle

Et tu n'as pas honte de publier (et d'en faire la publicité) sale ?

Je n'ai pas parlé de garbage collector, mais de RAII, qui est un concept qui est apparu avec la maturation de C++ et le besoin de sécuriser l'acquisition et la libération des ressources.

Il sera détruit, donc le destructeur sera appelé. Cependant, si le destructeur fait quelque chose de non-trivial, c'est qu'il y a un problème.

En règle générale, on essaye de toute façon de libérer les ressources gérées de manière explicite, pour éviter au destructeur de devoir gérer des problèmes complexes, sans pouvoir lever d'exceptions (puisque lever une exception depuis le destructeur, c'est verbotten).

struct base
{
    virtual void hop() { }
    void plop() { }
};

#include <iostream>

struct derivate : base
{
    virtual void hop() {  std::cout << "Hop!\n";}
    void plop() { std::cout << "Plop\n"; }
};

int main()
{
    base * p = new derivate;

    p->hop(); // Ok
    p->plop(); // Ko
}

En règle général, on essaye d'éviter ce genre de blagues, pour éviter à l'utilisateur de se tromper dans l'utilisation des objets.