shbrol a écrit 498 commentaires

Relis attentivement l'exemple de Thomas. Si tu ne comprends pas pourquoi il faut un comptage de référence atomique, tu devrais t'abstenir de faire de la programmation multi-thread, tu vas au devant de sérieux problèmes.

il faut remplacer les .begin et .end par .cbegin et .cend, j'imagine pour que l'inférence de type produise un const_iterator au lieu d'un iterator, c'est logique mais comme cela nécessite de changer les habitudes des programmeurs, ça fera probablement une "erreur" (mineure) commune de plus.

Et on a maintenant deux fonctions .begin et .cbegin qui retournent un const_iterator (pareil pour end), pour ne pas casser le code qui utilisait .begin sur un vector const ... c'est moche.

20 lignes ? J'aimerais bcp voir un pool en 20 lignes qui marche et qui est efficace (temps d'allocation, support multithread,...)

Oui, 20 lignes, c'est nettement suffisant pour un pool simple, sans multi-thread (tu rajoutes des contraintes quand ça t'arrange). Pour un exemple, demande à Herb, il te montrera.

Et il a quelle taille ton pool ?

Un pool à multiples blocs, typé et réutilisable, c'est grosso-modo 20 lignes de code, sans aucun impact sur le reste si on surcharge new/delete dans la structure bob. Ou est le problème ?

J'ai un peu de mal à cerner le genre de programme auquel tu fais référence : on a besoin d'un maximum de performances (on descend jusqu'au lignes de cache), mais d'un autre coté on alloue de nombreux objets de petite taille, avec cycle de vie court (la performance des ctor/dtor a été évoquée), et on ne peut pas faire de pré-allocation massive parce qu'il faut aussi réduire l'empreinte mémoire globale...

Un exemple concret serait le bienvenu.

Ca depend du cas comme pour tout, si par defaut ton vecteur a une taille allouee de 10 objets (parce que dans le cas usuel ou le vecteur contient quelque chose il en a 10), ton constructeur va faire une allocation a chaque fois par exemple.

Gni ? L'implémentation de std::vector n'est pas obligée de faire une préallocation si on ne donne pas de capacité initiale. Si le constructeur par défaut le fait quand même, c'est un problème de qualité d'implémentation de std::vector.
Si dans ton cas particulier le vector contient généralement 10 elements, rien ne t'empeche de faire un reserve(10) avant la premiere insertion, que le vecteur soit alloué dynamiquement ou non.

L'allocateur standard dans Windows a tout un tas de features pour eviter qu'un buffer overflow dans la heap ne se transforme en vulnerabilite (...), je ne connais a peu pres aucun allocateur 'custom' qui a ces features.

Un simple pool de char[sizeof bob] obtenues via l'allocateur est suffisant.

a) J'evites le cout du constructeur / destructeur si le vecteur n'est pas utilise

Quel est le cout d'un constructeur / destructeur pour un vecteur vide ? Si le cycle de vie de la structure est un probleme de performance, ca ne viendrait pas plutot de l'allocateur ?

En ce qui concerne la taille de la structure et les performances d'un allocateur "standard" par bloc, cela n'est pertinent que si tu alloue tes structures unitairement avec cet allocateur (un gros tableau de structures n'est pas concerné).Si tu as vraiment des problèmes de performance liées a ton allocateur, pourquoi ne pas en prendre un autre, puisque le langage le permet facilement ?

Ah, oui, je comprends mieux. Donc pour gagner en performance, tu rajoute une indirection supplémentaire, et tu parsème ton code de tests if (MonVecteur != 0), c'est bien ça ?

La question portait sur l'allocation dynamique d'un std::vector<T> et la manipulation de pointeurs sur std::vector<T> ensuite, et dans ton exemple tu parles d'un tableau T[], ce n'est pas le meme besoin.

Maintenant, pour l'occupation memoire, le tableau de base, c'est au moins un pointeur, mais tu as aussi besoin de sa capacité (taille allouée), et du nombre d'éléménts présents (taille utilisée). Au final, c'est la même empreinte mémoire, sauf si la capacité et la longueur sont fixes. Mais dans ce cas, pourquoi ne pas utiliser std::array<T> ?

Bref, ca ne sert a rien d'allouer dynamiquement un std::vector<T>.

Tu viens de montrer qu'il est techniquement possible de dériver de std::vector, c'est a dire que le compilateur ne génère pas de diagnostic. Le problème, c'est que le compilateur ne va pas t'avertir des dangers potentiels a l'utilisation.

En modifiant légèrement le main() :

int run( std::vector<int> const& v ) {
    try {
        std::cout << v[1] << std::endl;
    } catch (const std::exception & e) {
        std::cout << "received exception" << std::endl;
        return 1;
    }
    return 0;
}   

int main() {
    MyVector<int> v;
    v.push_back(5);
    return run( v ) ;
}

On obtient a l'exécution :

$ g++ -o vector_inherits -Wall vector_inherits.cpp
$ ./vector_inherits
0
$

Et pourtant, dans la fonction run(), c'est bien l'instance de MyVector qui est utillisée, n'est-ce pas ? Pourquoi le comportement du programme a-t'il changé ?

Tu auras aussi des résultats comiques si tu ajoute un destructeur spécifique a MyVector et que tu manipules tes instances par l'intermédiaire de pointeur sur sdt::vector...

Les containers de la STL ne sont pas conçus pour êtres dérivés en public, mais il n'y a pas de garde fou, comme d'habitude.

Si je perds mon portefeuille qui a des euros dedans, c'est la preuve que les euros sont mal conçus ?

Oui, sauf si c'est moi qui trouve ton portefeuille...

Et depuis quand une clôture empêche une chèvre de brouter de l'autre coté ?

Les champs circulaire, j'admets que ça peut exister, même si c'est rare. Par contre, une chèvre qui broute dans le champ alors qu'il lui est possible de brouter en dehors, ca n'existe pas.
Comme le piquet est fixé a la périphérie, quel que soit la longueur de corde, la surface mangée dans le champ sera toujours nulle, donc il n'y a pas de solution.

Je suis déjà sorti...

Je ne sais plus comment le dire.

Je crois que c'est une question de point de vue, toi phxonx tu est au niveau paquet, et Zenitram est au niveau données émises et recues par les clients.

Si j'ai bien compris le propos, Alice envoie deux données D1 et D2, en les plaçant respectivement dans des paquets P1 et P2. Comme le réseau fait ce qu'il peut, a l'arrivée on reçoit dans l'ordre P2 puis P1, mais comme la vie est bien faite, c'est P1 qui sera traité avant P2 et donc Bob a bien les données dans l'ordre D1 puis D2.

Alice, Bob et Zenitram sont contents, parce que les données reçues sont identiques a celles qui ont été envoyées, mais phxonx n'est pas satisfait parce que c'est l'ordre des paquets qui l'interesse.

En resume le compilo Microsoft est bugge car ne respecte pas la norme ACPI!

Je crois que c'est la le point d'incomprehension avec PbPG. Pour lui, le compilo et la plateforme sont conformes à la norme parce que une source correcte donnera un résultat qui fonctionne. Pour d'autres, la conformité à la norme se mesure plutôt vis à vis de source incorrecte, qui devrait être rejetée par le compilo, ou vautrer a l'execution.

Mais il y a peut-etre dans la norme ACPI (que je ne connais pas) un jeu subtil de "comportement indéfinis" comme dans les normes C ou C++, et dans ce cas son raisonnement est valable, le compilo serait conforme.

Tu nous a dit plus haut :

Windows est conforme, tu lui passe une table ACPI correcte, il l'avale sans problème

et maintenant:

le compilo MS laisse passer plus d'erreurs que le compilo Intel car certaines de ces erreurs sont sans consequences pour Windows

Ahem... si le compilateur MS était moins laxiste, les constructeurs pourraient corriger leurs erreurs, obtenir des tables correctes, et ca marcherait sous Windows mais aussi ailleurs.
Bref, c'est une situation qui vous arrange bien, et on va présumer que ca n'a pas été fait exprès...

Je ne sais pas si c'est systematique ou pas, mais j'ai pas envie d'essayer...

Ben non, c'est tout a fait légal, d'ailleurs la page que tu cite nous dit :

Le retrait de permis (et non de points) peut également être prononcé comme peine complémentaire pour certaines fautes graves relevant du droit pénal. Cette sanction ne concerne pas les infractions mais uniquement les délits, comme la conduite sous l’emprise de stupéfiants ou d’alcool, ou des délits très difficiles à commettre au guidon d’un vélo : grand excès de vitesse, ou délit de fuite après avoir provoqué un accident.

Mais si tu roule bourré en vélo, et que tu as un papier rose, alors on te le confisquera...

Merci pour l'info.

Copain ! Je développe sur mon temps perso un programme qui correspond très fortement à ta description...

C'est .gov, sans le u ...

Modèle de 100GO, commandé à 120 euros.

Wow, où l'as tu trouvé à ce prix ? C'était une promo ?

Voui, mais il semble qu'a l'origine des temps, il n'y avait pas la dedans que des fichiers de configuration, mais aussi tout ce qu'on n'avait pas pu caser ailleurs, avec des scripts (rc), des donnees administratives (passwd), et cetera.

Pour rester lisible, logique et court, "/mess" aurait été pas mal, mais bon...

Le nommage n'est pas du tout sexy (surtout "etc"!),

D'un autre coté, je préfère largement un nom court comme "etc" plutôt qu'un truc à rallonge avec des espaces dedans comme on voit souvent chez les voisins d'en face, qui auraient appelé ca "Editable Text Configuration"...

mais si elles peuvent aussi taxer chaque échange, elles prendront.

Elle le font déja sur les paiement CB, mais c'est transparent pour toi vu que c'est le commercant qui paie (sauf dans certains pays ou l'on te fait payer la commission). Et elles aimeraient bien te faire payer ton chéquier aussi.
Mais à part ca, elle vont être contre la taxe Tobin ...