Reprise du message précédent :
lis la bible, tu vas voir, en 5 min c'est réglé tes insomnies.

 
Ah, tu veux des exemples? En voilà trois:
 
 
vi /usr/include/c++/3.3.1/bits/stl_alloc.h
 
Copyright (C) 2001, 2002, 2003 Free Software Foundation, Inc.
Copyright (c) 1996-1997 Silicon Graphics Computer Systems, Inc.
 
/free
/malloc
/realloc
/abort
/memcpy
 
Pourquoi tant de C?
 
 
vi /usr/include/c++/3.3.1/bits/stl_algobase.h
 
Copyright (C) 2001, 2002, 2003 Free Software Foundation Inc
Copyright (c) 1994 Hewlett-Packard Company
Copyright (c) 1996-1998 Silicon Graphics Computer Systems, Inc.
 
/memmove
/memset
/memcmp
 
Pourquoi tant de C?
 
 
Et le meilleur pour la fin...
 
vi /usr/include/c++/3.3.1/bits/locale_facets.tcc
 
Copyright (C) 2001, 2002, 2003 Free Software Foundation Inc
 
/atoi
 
Pourquoi cette fonction C toute dépriciée dans ce beau code C++? Hein? Pourquoi? Mais pourquoi tant de C dans ce monde?
 
 
Moralité: en suivant tes âneries, c'est vraiment des gros newbies incapables de pondre du C++ correct à la Free Software Foundation, chez SGI et HP
 
 
ps: pour le realloc, tu sais très bien ce que je veux dire. Merci de ne pas te faire encore plus con que tu ne l'es déjà
 
edit: copyright, locale_facets.tcc et non pas .h, détails à la con
 
 

 
Bon, pour le realloc. J'écarte d'emblée tout appel à une tierce librairie écrite en "C", comme la stl par exemple , wrappant un quelconque et "dégueulasse" realloc de C pour gérer le tableau à votre place On est donc soit au niveau de sa "propre" implémentation de la stl en pur C++ ou ailleurs dans votre code, dans le fond, c'est pareil.
 
Bref, un jour ou l'autre, tout programmeur digne de ce nom doit faire des allocations dynamiques de tableaux. En C++ de fanatique intégriste lobotomisé, d'une manière naïve, cela se fait avec new CPPBullshit[nBullshits].
 
Maintenant, supposons que vous ayez besoin d'agrandir ce tableau de n éléments, la lib ou vous-même, n'ayant pas un pendant en C++ du realloc C tel que "renew" auront besoin de faire:
  - new CPPBullshit[nBullshits+n]
  - boucle sur les nBullshits pour les copier dans le nouveau tableau
  - delete [] old_bullshits
 
Une manière moins naïve est d'allouer avec new non pas un tableau d'objets mais un tableau de pointeurs afin de ne recopier que les pointeurs sur sa connerie (avec une boucle toute pourrie hein! Ici, on fait du C++ de fanatique intégriste lobotomisé et memcpy, c'est du C!)
   
Dans les deux cas:
  - gâchis sur les cycles à utiliser un code non-optimisé en asm pour se passer du runtime C
  - gâchis sur les cycles à allouer une zone mémoire probablement inutile
  - gâchis fort probable sur la mémoire utilisée (deux tableaux alloués en même temps de manière certaine)
 
Dans le deuxième cas seulement:
  - gâchis à faire une copie du tableau de pointeurs qui n'aurait probablement pas, ou tout du moins peut-être pas, été nécessaire avec un realloc
 
Conclusion: vouloir un code C++ sans le moindre appel au runtime C est une connerie pure de fanatique intégriste lobotomisé.

std::vector si tu ve redimensionner, ou est le probleme ? c'est optimisé quand meme vector, c'est le but, pas besoin de redefinir ses tableaux ou autre
 
enfin ce que je comprend pas c'est ou tu veux en venir, parce que si tu dit pour ces raisons que malloc/realloc c'est mieux que new[], alors a ce moment la on peut par exemple dire que sous windows c'est aussi pour les memes raisons completement stupide d'utiliser alloc et realloc vu que au final c'est HeapAlloc et HeapReAlloc (et la on peut ppas descendre plus bas) qui sont invoquées?

j'en ai rien à battre, je te lis plus, t'es un abruti fini.
 
- je te dis de ne pas me parler de petite optimisation en cas de spécialisation pour char tu le fais
- tu me sors malloc/realloc/free, peut être que tu ne comprends pas que des fois pour maintenir un buffer, on souhaite séparé allocation et construction. bref, c'est la réécriture de new comme il est fait en interne
 
ça fait 2 fichiers ...
 
 
 
mot de la fin : qu'est-ce que t'y connais en optimisation vu que t'es pas capable d'évaluer la complexité d'un algorithme ?

 
Tu délires complètement mon pauvre naz parce que je n'ai jamais parlé de spécialisation de char où que ce soit sur ce fil
Mais si tu es capable d'expliquer en quoi tous les appels au runtime C mentionnés ci-dessus (malloc, realloc, free, memcmp, memcpy, atoi et, le meilleur, abort) ont la moindre rapport avec une spécialisation de char, chapeau !
 
Ensuite question abruti, quand je te vois:
- incapable de coder un move de fichier correct
- inventer un comportement complètement délirant et fantasmé du new placement créant des structures sorties d'on ne sait où pour gérer soit-disant des allocations en shared memory (tu disais déjà à ce propos que tu ne me lirais plus alors ça a donné quoi le vi du new.h?)
- faire un strlen merdeux avec des variables qui ne servent à rien
 
he bien, je me dis que tu es effectivement très bien placé pour me donner des leçons de complexité
 
En clair, tu reproches à des newbies de faire des choses que n'importe quel bon programmeur fait. Et pourquoi? Parce que tu es un grooos frustré de la vie et qu'il s'agit avant tout de les écraser pour faire valoir ton égo et le soulager un peu. "Je te marche sur la gueule donc je suis". Ca va, c'est pas trop dur? Tu devrais les prendre au berceau tant qu'à faire...
 
Tiens, une belle illustration de ta psychologie, pour ton move de fichier tout bugué, tu souhaitais qu'on te dise "ô taz, tu manipules les streambufs comme un Dieu". Bref, tu veux qu'on te récite le "notre taz".
 
Je ne sais pas si tu es au courant mais il y a les maisons de tolérance pour les frustrés dans ton genre. A la rigueur, tu peux aussi engager une psychothérapie mais ça te coutera plus cher.
 
Enfin, ce qui est marrant, c'est que quand on te fait remarquer que tu dis des conneries plus grosses que toi, c'est toujours la même chanson: "et gnagnagna! et je te répondrai plus d'abord! Et même que oui! et même que t'es qu'un sale con! et même que non, je ne prends pas mes jambes à mon cou!"

franchement les gars, se battre pour C ou C++ ! C'est la même merde buggogène. Sauf qu'il y en a un des 2 qui a une grammaire plus imbitable que l'autre.

 
c'est une question de mesquinerie. S'attaquer à des newbies, je trouve ça minable. Je me charge donc de lui rendre la pareille

bof, sa soulage.

vous me faites flippé sur ce forum
 
c'est quoi ces histoires de

 
et de  

 
vous psychotez pour des bouts de code, a chaque fois qu'un newbi pose une question c'est l'occasion de declancher une nouvelle guerre ?
 
vous avez vu la tournure de ce topic ?

mes excuses pour le topic mais ça fait un bout de temps qu'il me gonfle avec ses "c'est du C" à moitié niaiseux.
 
sur ce, bonne journée.

moi je déclenche rien. quand je vois un topic C avec que du C si ce n'est des cout, je le dis. si je vois des topics C++ avec du C++ quasi partout mais des FILE* je le dis.
après j'y peux quoi si pour certains c'est pas clair que c'est 2 langages, 2 styles de programmation, 2 bibliothèques. je vois pas le mal à vouloir utiliser prioritairement STL quand on fait du C++.

t'as entendu parler de std::vector ou std::deque ? c'est un truc d' ultra-fanatique terroriste du c++, ces gens-là sont des fous!
mais t'as raison, malloc sai bon mangez-en même si c'est plus lent qu'un new, et realloc c'est super, ça redimensionne sans recopier les données, ça perd pas de temps à appeler les constructeurs, et puis c'est vraiment que du bonheur de passer son temps à reinventer une roue voilée.

Bon, je vois que tout le monde a fait son overdose de moquette par ici
 
taz> t'es mignon à m'inventer à chaque fois des implémentations de new sorties du chapeau et c'est bien: tu as de l'imagination. Après, lire le code de son runtime, ça peut être utile pour ne pas passer pour un bouffon vis-à-vis de personnes qui ont un peu plus d'expérience que les newbies auxquels tu te mesures habituellement.
Captain> Lire le source de gcc sera bon pour vous aussi. malloc plus lent que new??? Et mon cul, c'est du poulet?
 
 
Pour commencer par le plus simple, le new placement. Ca ne fait que ça:

 
un new de base, ça ne fait que ça:

 
Un new[], ça fait exactement la même chose qu'un new simple.
 
Un delete - oh que c'est compliqué - ça fait :
 

 
...
 
 
 
Ensuite, les vector c'est bien mignon mais leur comportement suit exactement le gâchis que j'ai décrit plus haut et ce dont je parle n'est pas une question de séparation entre la construction et l'initialisation comme l'affirme l'autre...
C'est juste que pour suivre le standard C++, on utilise new. Comme il n'y a pas de renew en C++, on est obligé d'allouer deux tableaux dès lors qu'on doit réallouer en interne. C'est l'éternelle tare congénitale du C++. Vous aurez beau beugler, ratiociner, pleurer et m'inventer tout ce que vous voudrez les enfants, ça n'y changera jamais rien.
 
Pour finir sur le runtime C en C++, à partir du moment où il y a le moindre élément de langage C++ dans un code, ce n'est plus du C et en aucun cas, la réciproque n'est vraie. Il suffit d'un class, d'un opérateur de résolution de portée ( :: ), d'un opérateur de référence (& ), ...
Si vous croyez que c'est du C, donnez le donc à un compilateur C et préparez-vous à ce qu'il vous pisse dessus de rire en disant qu'il ne comprend rien à vos conneries.
 
Moralité: putain de bordel de merde de sa race maudite lisez les sources de vos runtime, vous direz moins de conneries.

 
fait gaffe, tu oublie d'appeler tes constructeurs et destructeurs

 
QUand on doit réallouer dynamiquement, on évite les tableaux. Il y a suffisament de conteneurs divers et variés dans la STL pour y trouver son bonheur

 
gcc utilise ces implémentations par défaut
 
lire aussi varasm.c pour ceux qui en ont le courage

 
Dites, je parle chinois?

mais justement, quand tu a besoin de reallouer tu utilise vector, si tu fais ca avec realloc tu devra gerer toi meme les appels de constructeur/destructeur
vector fait ca tres bien et est tres optimisé, et avec vector il n'y a jamais de gachi de place

Hmmmm, petite precision : si tu as besoin de reallouer souvent, tu evites d'utiliser vector, qui a de fortes de recopier le vecteur entier en cas de fragmentation de la memoire. Et si tu n'as plus de bloc de memoire libre de taille suffisante pour contenir la nouvelle taille du vecteur, c'est la cata. Il faut utiliser std :: deque (double-ended queue, qui est une sorte de melange entre vector et liste doublement chainee) dans ce cas precis.

Les runtime en fait, c'est juste la traduction des fonctions de l'OS dans le langage de la librairie standard, c'est bien ca?

 
On appelle runtime toutes les fonctions fournies par un langage et qui ne sont pas "implémentées" (ou plutôt traduites) directement par le compilateur (comme par exemple un opérateur ++ sur entier qui sera traduit directement en assembleur au moment de la compilation). En clair, le runtime est ce qui permet à un programme de s'exécuter. C'est pour cette raison qu'on appelle ça aussi parfois environnement d'exécution et on peut y trouver des choses assez diverses (comme une machine virtuelle). Maintenant, un runtime n'est pas nécessairement lié à un langage particulier (je pense bien sûr au CLR de .NET) Enfin, c'est quelque chose que tout programmeur se doit de lire au moins une fois pour savoir ce qui va se passer lors des appels aux fonctions qu'il utilise. Pour dire, même microsoft fournit le source de son runtime (enfin dans le VC6, pour .NET, je ne sais pas).

 
Le gros problème de la fragmentation mémoire dans un conteneur, ce n'est pas tant la réallocation (même si je suis d'accord que c'est un petit problème) mais surtout le page fault qui surviendra tot ou tard lorsque vous aurez beaucoup d'éléments à parcourir. Un page fault, c'est à peu près 1 000 000 de cycles foutus à la poubelle.

mince alors

Si je comprends bien, alors la source d'un runtime est completement dépendante du systeme, j'ai bon?

 
Ca dépend des fonctions. C'est le cas de malloc par exemple où forcément, on a à faire des appels à l'api win32.
 
edit: sous windows bien sûr