[C] Des accolades "just pour le fun" ?

Recherche :

Mot : Pseudo : Filtrer
Page : 1 2 3 Page Suivante Page Précédente Bas de page
Auteur	Sujet : [C] Des accolades "just pour le fun" ?

tbp

Reprise du message précédent :

Emmanuel Delahaye a écrit :

Un léger overhead, c'est possible. Pas de quoi se taper le cul par terre...

Bruit dans la mesure. Parce que si je vire le static des 2 fonctions et que je déplie un vieux gcc 3.4.4 cygming tout moisis,

00401050 <_test_a>:
401050: push %ebp
401051: mov %esp,%ebp
401053: push %edi
401054: xor %edi,%edi
401056: push %esi
401057: push %ebx
401058: sub $0x3c,%esp
40105b: xor %esi,%esi
40105d: mov $0xf423f,%ebx
401062: lea 0xffffffc8(%ebp),%eax
401065: mov %esi,0x8(%esp)
401069: movl $0x402000,0x4(%esp)
401071: add %edi,%esi
401073: mov %eax,(%esp)
401076: call 401900 <_sprintf>
40107b: dec %ebx
40107c: jns 401062 <_test_a+0x12>
40107e: inc %edi
40107f: cmp $0x9,%edi
401082: jle 40105b <_test_a+0xb>
401084: add $0x3c,%esp
401087: pop %ebx
401088: pop %esi
401089: pop %edi
40108a: leave
40108b: ret
40108c: lea 0x0(%esi),%esi

00401090 <_test_b>:
401090: push %ebp
401091: mov %esp,%ebp
401093: push %edi
401094: xor %edi,%edi
401096: push %esi
401097: push %ebx
401098: sub $0x3c,%esp
40109b: xor %esi,%esi
40109d: mov $0xf423f,%ebx
4010a2: lea 0xffffffc8(%ebp),%eax
4010a5: mov %esi,0x8(%esp)
4010a9: movl $0x402000,0x4(%esp)
4010b1: add %edi,%esi
4010b3: mov %eax,(%esp)
4010b6: call 401900 <_sprintf>
4010bb: dec %ebx
4010bc: jns 4010a2 <_test_b+0x12>
4010be: inc %edi
4010bf: cmp $0x9,%edi
4010c2: jle 40109b <_test_b+0xb>
4010c4: add $0x3c,%esp
4010c7: pop %ebx
4010c8: pop %esi
4010c9: pop %edi
4010ca: leave
4010cb: ret
4010cc: lea 0x0(%esi),%esi

Autrement dit, strictement la même chose.

Publicité

Emmanuel Delahaye

C is a sharp tool

MagicBuzz a écrit :

je ne connais pas la syntaxe pour déclarer un array (avec malloc et tout ça).

Oui, ça, il est évident que si il faut appel à malloc(), ce sera nettement plus long, mais ce n'est pas à cause fait que la variable soit définie très localement.

Après tout dépend des besoins. Si il faut créer 10 000 000 instances , y'a pas le choix, il faut 10 000 000 appels à malloc() et se sera toujours plus long que 1 seul appel à malloc(). Faut être un gourou pour savoir ça...

Message édité par Emmanuel Delahaye le 08-01-2007 à 14:45:10

---------------
Des infos sur la programmation et le langage C: http://www.bien-programmer.fr Pas de Wi-Fi à la maison : http://www.cpl-france.org/

Emmanuel Delahaye

C is a sharp tool

MagicBuzz a écrit :

moi je parlais du cas où le gars ne réfléchit pas, et crée sa variable localement dans un for() et du coup qui la réalloue x fois "pour rien", alors qu'il aurait pu simplement la déclarer en global (en dehors du for) et simplement la réécraser à chaque fois.
et là le GC est très intéressant, car il ne refait pas l'affectation à chaque fois.

en C++ c'est plus vrai, car ça s'applique surtout aux objets : le NEW rééinitialise beaucoup de choses dans un objet, qui fait qu'on ne peut pas toujours réutiliser un objet déjà créé en mémoire.

Tu me parles de langages étranges, de GC... Ici, c'est le forum C, on parle du C. Point. Il y a un forum 'langages' non ?

Quand au 'gars qui ne réfléchit', pas, c'est pas en pensant à sa place qu'il va s'améliorer...

---------------
Des infos sur la programmation et le langage C: http://www.bien-programmer.fr Pas de Wi-Fi à la maison : http://www.cpl-france.org/

Tamahome

⭐⭐⭐⭐⭐

MagicBuzz a écrit :

Sauf que moi j'utilise les règles de dev établies par IBM : pas plus de 10 lignes par fonction dans la mesure du possible.
De plus, je déclare mes variables le plus tard possible (genre une variable local est déclarée dans un bloc while/for/if plutôt que globalement, étant donné que le GC est justement là pour éviter de recréer éffectivement la variable à chaque passage) -> c'est même conseillé dans la MSDN

Exemple :

Code :

private void Plop(int num)
{
for (int i = 0; i < num; ++i)
{
string prout = string.Empty;
for (int j = 0; j < i; j++)
{
prout += j.ToString() + " ";
}
Console.Write(prout);
}
}

Ici, je n'ai aucune utilitée d'utiliser des blocs {} puisque mes variables ont déjà la portée minimale. Et recréer les variables à chaque occurence des FOR n'est pas gênant grace au GC qui permet la réutilisation des variables libérée depuis la dernière occurence.

bon j'espere que c'est un exemple et pas une vraie méthode en production, parce que les StringBuilder c'est pas fait pour les chiens

0x90

→

10 lignes par fonction, quand t'en bouffe déja 4 pour des accolades ça laisse pas vraiment de champ, tu as limité la largeur des colonnes à 500 caractères ?

---------------
Me: Django Localization, Yogo Puzzle, Chrome Grapher, C++ Signals, Brainf*ck.

tbp

MagicBuzz a écrit :

en C++ c'est plus vrai, car ça s'applique surtout aux objets : le NEW rééinitialise beaucoup de choses dans un objet, qui fait qu'on ne peut pas toujours réutiliser un objet déjà créé en mémoire.

Il y a au moins une chose qu'on ne peut t'enlever c'est que tu es coherent: tu es aussi incompétent en C qu'en C++ et tu dis vraiment portnawak.

Code :

foo_t *bar = new foo_t;
for (...) {
bar->baz();
bar->~foo_t();
new (bar) foo_t;
}

Sve@r

MagicBuzz a écrit :

c'est ce qui est écrit dans la MSDN lorsque Microsoft indique les cas où le GC apporte un réel plus, et dans quelles conditions C# (pourtant censé être plus lent que le C++) peut dans certains cas s'avérer plus rapide que le C++

Oui mais tout ce que dit Microsoft aussi... :heink:

---------------
Vous ne pouvez pas apporter la prospérité au pauvre en la retirant au riche.

Tamahome

⭐⭐⭐⭐⭐

MagicBuzz a écrit :

c'est vrai que je vais écrire 80 lignes de code pour utiliser un StringBuilder dans un petit exemple, alors que StringBuilder n'existe pas en C à ma connaissance...

parce que l'exemple que tu as mis et que je citais c'était du C bien sur, et pas du tout du C# ? :heink:

Edit :

ton code :

Code :

private void Plop(int num)
{
for (int i = 0; i < num; ++i)
{
string prout = string.Empty;
for (int j = 0; j < i; j++)
{
prout += j.ToString() + " ";
}
Console.Write(v_prout.ToString());
}
}

Ce qu'il faut faire :

Code :

private void Plop(int num)
{
StringBuilder v_prout = new StringBuilder();
for (int i = 0; i < num; ++i)
{
for (int j = 0; j < i; j++)
{
v_prout.Append(j.ToString());
v_prout.Append(" " );
}
Console.Write(prout);
}
}

Mon dieu, effectivement ca fait 80 lignes [:totoz]

Message édité par Tamahome le 08-01-2007 à 19:14:21

Tamahome

⭐⭐⭐⭐⭐

tu racontes vraiment n'importe quoi, c'est navrant.

tbp

MagicBuzz a écrit :

t'as aucun programme qui fait ça par hasard ? (et la marmotte...)

Inlining (et on retombe sur le cas précedent). Sinon le C++ et ses accesseurs serait vraiment une brouette.

Publicité

Sve@r

MagicBuzz a écrit :

entre string et char[], y'a pas de différence fondamentale (la preuve, en C++ string est un alias de char[])

Autant je suis une tanche en C++, autant je sais quand-même qu'un tableau de char c'est autre chose qu'un objet "string" (même si les deux peuvent dans des cas très restreints être utilisés de façon quasi identique...)

MagicBuzz a écrit :

c'est bien, continuez comme ça, après-tout on n'a pas élevé les cochons ensemble.

Ah ? Tu as élevé les cochons ??? Je comprends mieux certaines choses maintenant...

Message édité par Sve@r le 08-01-2007 à 19:22:33

---------------
Vous ne pouvez pas apporter la prospérité au pauvre en la retirant au riche.

tbp

MagicBuzz a écrit :

Que tu peux très bien écrire sous cette forme, qui bouffe bien plus de temps : (tu ne fais que répéter ce que je viens de dire. tu as raison, je dois vraiment être incompréhensible...)

Non, c'est juste que tu dis n'importe quoi et que tu commentes un code que tu ne comprends pas.

Version originale commentée pour les neuneux.

Code :

foo_t *bar = new foo_t; // allocation
for (...) {
bar->baz();
bar->~foo_t(); // appel du dtor explicite
// appel du ctor explicite, sans allocation
// parce que c'est un placement new, pas un new. bouffon.
new (bar) foo_t;
}

Alors que cette version est un bug ambulant.

Code :

for (...) {
foo_t *bar = new foo_t;
bar->baz();
bar->~foo_t();
new (bar) foo_t; // <-- 2 ctors pour un 1 dtor et un vieux leak des familles.
}

MagicBuzz a écrit :

hors si comme dans mon exemple précédent, tout ce qui est à l'intérieur du for est dans une fonction, c'est pas très commun de passer par des références mémoires sur un objet qui n'est utilisé qu'en interne par ta fonction... perso, je travaille pas souvent avec des variables locales déclarées en global que je passe par pointeur à toutes ma fonction...

Arretes la drogue.

Message édité par tbp le 08-01-2007 à 19:30:12

tbp

MagicBuzz a écrit :

c'est vrai qu'on peut passer en inline n'importe quelle fonction...

Bienvenue en 2007.

http://www.gelato.org/pdf/apr2006/ [...] urcery.pdf

Tamahome

⭐⭐⭐⭐⭐

enfin c'est pas trop grave si tu piges rien au C et au C++, on va pas en faire un fromage hein...

el muchacho

Comfortably Numb

[quotemsg à chaque itération le programme va se faire chier allouer un espace mémoire pour la string, puis la désaouler.
[/quotemsg]
Il y en a un autre qui devrait désaoûler. [:el g]
En ce qui concerne l'allocation de millions de petits segments mémoire, il est vrai que les GC modernes sont plus rapides que des mallocs, mais on peut aussi utiliser dans ce cas (qui n'est pas vraiment courant dans la pratique) un allocateur spécial en C qui alloue un bloc large et recycle la mémoire. Ca devrait te tomber sous le sens, vu que tous les GC sont écrits en C...
Sinon, les GC, ça a AUSSI des inconvénients, en particulier le déclenchement imprédictible (sauf si on le force) et surtout le temps de recollection qui est imprédictible, et bien souvent bloquant (impossibilité de continuer tant que le ramassage n'est pas terminé, sauf pour les GC générationnels).
Enfin, la machine virtuelle a un coût, le typage dynamique a un coût, et malgré des optimisations puissantes, tout n'est pas gratuit dans les langages à machine virtuelle, sinon ça se saurait.

Message édité par el muchacho le 08-01-2007 à 21:47:04

Tamahome

⭐⭐⭐⭐⭐

le gros problème avec les GC (enfin surtout celui de .net, pour java je ne connais pas assez pour dire) c'est la fragmentation mémoire...

Message cité 1 fois

straffo

MagicBuzz a écrit :

c'était un exemple pour comparer.
entre string et char[], y'a pas de différence fondamentale (la preuve, en C++ string est un alias de char[]).

Euhhh ????
C'est faux ,archi faux !

Et ça :

Citation :

bar->~foo_t();

c'est illégal !

delete ça te dit quelque chose ?

Message cité 1 fois

++fab

victime du syndrome IH

straffo a écrit :

Euhhh ????
C'est faux ,archi faux !

(dans mon rôle d'avovat du diable)
Il a peut-etre voulu dire qu'une string pouvait aliasé un char[] ?

straffo a écrit :

Et ça :

Citation :

bar->~foo_t();

c'est illégal !

Non.

tbp

Voir la section 3.8.7 du standard C++ à ce sujet.

++fab

victime du syndrome IH

Voir aussi l'avis d'Herb Sutter sur cette construction.

Message cité 1 fois

straffo

Heu ... c'est peut être légal mais on est quand même dans le moche

Je vois bien des gorets désallouer un objet pour remettre aussitôt un objet du même type au même endroit
(d'un autre coté ce genre de truc j'ai pratiqué il y a quelques années )

Quand à l'alias j'avoue avoir automatiquement pensé à un typedef

Message cité 1 fois

IrmatDen

++fab a écrit :

Voir aussi l'avis d'Herb Sutter sur cette construction.

C'est dans quel papier que je peut trouver ça stp? Vu la quantité qu'il y a, j'ai peur de mettre des semaines à tout lire (ok, ce serait pas un mal , mais c'est bookmarké pour quand j'aurais un peu plus de temps)

Message édité par IrmatDen le 10-01-2007 à 01:13:09

tbp

straffo a écrit :

Ne pas savoir ou, quand et pourquoi on a le droit de faire un truc pareil c'est l'essence même de la goretitude.

Sinon standard C++ > Herb Sutter

straffo

Tu sera puriste un jour.

C'est juste que tu n'as pas eut le plaisir de passer après des "Ingénieur d'étude" (qui feraient bien de reprendre leurs études au passage ...)capables de pondre sans tiquer ça :

m_pRectangle = z_pZone->dernierRectangle()->suivant();
Perso j'ai du mal à trouver un suivant au dernier dans une liste chainée.

Ou ça :
z_pPremier = z_pPremier->precedent();
même remarque qu'avant.

Message cité 1 fois
Message édité par straffo le 10-01-2007 à 09:49:00

rufo

Pas me confondre avec Lycos!

straffo a écrit :

c'est peut-être une liste chaînée circulaire?

Message cité 1 fois

Chaos Intestinal

MagicBuzz a écrit :

Anyway.

Je ne suis peut-être pas un puriste, je ne maîtrise pas le dixième du langage C, mais cela ne m'empêche pas de travailler avec depuis quelques jours.
Comme quoi vos réflexions à deux balles sur la syntaxe et autres, "pipo et branlo vont au ski". Quand t'as le concept, rien à battre de la RFC 3.8.7
Voici mon troisième patch pour un jeu open source :spamafote:
http://www.tt-forums.net/viewtopic.php?t=29578

Euh, on a quand même le droit de noter qu'il y a grosso modo pratiquement rien dans ton patch ?
Donc c'est bien gentil, mais venir faire la morale à des gens qui maîtrisent un langage quand "travailler avec" ça se résume pour toi à comprendre quelques bouts de code triviaux et écrire des bouts de code encore plus triviaux, c'est hautement comique.

http://www.tt-forums.net//files/su [...] _535.patch = teh lol

straffo

rufo a écrit :

c'est peut-être une liste chaînée circulaire?

Ben ... non ...
(sinon ce serait bcp moins drole )

Chaos Intestinal

MagicBuzz a écrit :

oui, y'a quasiment rien.
et alors ?
déjà à la base, pour faire la modif, j'ai bien dû lire et comprendre le code non ?
ensuite, j'aurais pu faire n'importe quoi dans le code.

alors ouais. ta réponse prouve ta grande bêtise.

je vais pas réécrire le moteur du jeu, juste pour le plaisir de pisser du code... y'a qu'une constante à remplacer parun nouveau paramètre, j'y peux rien si c'est développé proprement.
ça doit pas arriver souvent à ton code vu tes réflexions...

Je critique pas le fait qu'il y ait rien en soit, parce que j'ai bien vu qu'il y avait pas besoin de plus.
Maintenant qu'un mec dont le boulot en C se résume à ça vienne apprendre la vie à certains intervenants de la cat C, je suis un petit peu, hum, mort de rire ? [:opus dei]

Chaos Intestinal

MagicBuzz a écrit :

venir dire quelquechose que je sais déjà

C'était ça qui était pas bien bien évident au premier abord, en fait [:jean-guitou]

Chaos Intestinal

MagicBuzz a écrit :

entre string et char[], y'a pas de différence fondamentale (la preuve, en C++ string est un alias de char[]).

Ca aussi c'est un "exemple de code" ? [:petrus dei]

lorill

MagicBuzz a écrit :

Ca fait bientôt 8 ans que je viens sur ce forum et que je dis "je chie sur le C c'est un langage de merde réservé aux autistes".
Faudrait vraiment que je sois maso pour être expert dans ce langage vu ce que j'en dis...

ben je sais pas, moi je trouve que pour être aussi catégorique et négatif sur une chose, il faut au moins la connaitre un peu

tbp

Elmoricq

Modérateur

MagicBuzz a écrit :

dans la mesure où synaxiquement, le type string s'apparente à char[], oui, c'est bien plus proche pour donner un exemple comparatif que d'utilser un objet StringBuilder(). Franchement, si vous arrivez pas à piger ça, moi je sais pas en quelle langue vous parler.

Syntaxiquement ? Je ne comprend pas ce que tu veux dire, peux-tu expliquer ?

Sve@r

MagicBuzz a écrit :

Tu postes un exemple stupire genre :

Code :

int c, i;
c = 0;
for (i = c; i < 10; i++)
{
c += i;
}

Y'en a toujours un pour te dire que t'es un gros batard d'abruti parceque t'auras pu écrire :

Code :

int c;
c = 45;

Ben en fait, imaginons que "10" soit remplacé par une variable "max" et que tu écrives la même chose, n'importe quel gros batard d'abruti te diras que tu peux écrire "c=max * (max + 1) / 2" [:ddr555]

---------------
Vous ne pouvez pas apporter la prospérité au pauvre en la retirant au riche.

Sve@r

MagicBuzz a écrit :

string ou char, ce sont deux variables.

En fait, string est un objet (donc un truc contenant plein de trucs) et char est un type de base. Mais on va dire que c'est un lapsus et que tout le monde aura compris ton idée même si elle est mal retranscrite...

MagicBuzz a écrit :

même si dans certains langages string est un objet, il n'en reste pas moins un type de valueur.
leur utilisation est donc rigoureusement la même.

Pas tout à fait. Leur but est le même, à savoir pouvoir stocker des chaînes de caractères. Mais leur conception étant différente, on s'en sert forcément différemment

MagicBuzz a écrit :

Les possibilités, oui. Mais comme tu dis, on ne travaille pas de la même façon et la façon de travailler avec l'un ou l'autre influera sur le résultat du code, voire même donnera de gros bug. On ne peut pas laisser ce fait de coté !!! Le C est un langage qui ne vérifie rien (style si je travaille hors limite d'un tableau) et qui, par conséquent, demande un peu de rigeur (et c'est pas de ma faute). Donc si tu veux faire du C, ben tu en fais avec rigeur sinon ce n'est pas la peine d'en faire...

---------------
Vous ne pouvez pas apporter la prospérité au pauvre en la retirant au riche.

tbp

MagicBuzz a écrit :

enfin bref, puisqu'on peut écrire n'importe quoi en inline maintenant, le problème ne se pose plus en C. (j'imagine Windows écrit tout en inline, l'exe passe à 50 Go c'est ça ?

Quand le compilateur le fait de son propre chef, par exemple dans cadre d'une optimisation globale, il y a bien sur une heuristique pour une analyse coût/bénéfice.

Mais je suppose que les qques pages de cette présentation étaient déjà trop pour ta capacité limitée d'attention.

el muchacho

Comfortably Numb

MagicBuzz a écrit :

très franchement, entre string et char[] y'a guère plus de différence qu'entre uint32 et byte[4]. certes, on ne travaille pas tout à faire de la même façon avec l'un ou l'autre, mais les possibilités offertes sont rigoureusement les mêmes. en C, avec quelques précautions, on peut même caster l'un en l'autre sans trop de problèmes (à part faire gaffe à la représentation intel des entiers)

Euh, essaye donc de caster un std::string en char[], tu vas voir comment le compilo va t'accueillir ...

Message cité 1 fois
Message édité par el muchacho le 10-01-2007 à 15:02:21

Sve@r

el muchacho a écrit :

Euh, essaye donc de caster un std::string en char[], tu vas voir comment le compilo va t'accueillir ...

Oui mais c'est bon. Moi aussi j'ai relevé mais j'ai plus essayé de voir le fond que la forme. Il a simplement voulu dire (enfin je pense) que les deux concepts ayant un but similaires, ils possédaient des méthodes appropriées pour passer de l'un vers l'autre...

---------------
Vous ne pouvez pas apporter la prospérité au pauvre en la retirant au riche.

0x90

→

MagicBuzz a écrit :

Réponse totalement biaisée étant donné que le code a été généré en appelant une option d'optimisation spécifique du compilo (donc le résultat n'est pas garanti avec tous les compilos ni dans tous les cas).

Le comportement du GC d'une implé de C# est garanti pour optimiser ce cas et réutiliser systématiquement le même espace mémoire ?

---------------
Me: Django Localization, Yogo Puzzle, Chrome Grapher, C++ Signals, Brainf*ck.

straffo

Je ne crois pas ,par contre (de mémoire) un stringbuilder réutilise le même buffer.

Sve@r

MagicBuzz a écrit :

Je dis donc

Code :

int i, c;
for (int i = 0; i < 10; i++)
{
prout(i, &c);
}
void prout(int i, int *c)
{
*c = i;
// on fait un truc avec *c
}

Est donc plus sale, mais plus optimisé que :

Code :

int i;
for (int i = 0; i < 10; i++)
{
prout(i);
}
void prout(int i)
{
int c;
c = i;
// on fait un truc avec c
}

Certainement franchement plus sale. Rien que pour ça, j'écris la seconde solution qui me parait plus sensée, à savoir "ma fonction déclare les variables qui lui sont utiles pour bosser - si ma fonction est appelée 10000 fois ben tant pis..."

MagicBuzz a écrit :

évidement qu'avec un int, ça n'a aucun intérêt.
quand prout() utilise un uint32[1600][1200] parcequ'il s'agit d'un buffer graphique, ça commence à devenir intéressant de ne pas avoirà gérer un malloc et un free à chaque utilisation de prout().

Dans l'absolu, si ma fonction a besoin de beaucoup de mémoire pour bosser, le raisonnement reste valable; à savoir "ben tant pis, il lui faut de la mémoire elle prend de la mémoire et tant pis si elle est appelée 100000 fois"

Ton idée a du bon... mais on peut pas l'appliquer car on va se prendre la tête. Telle fonction utilise 10M de mémoire est est appelée 100 fois donc on sort la variable qu'on passe en paramètre - Telle autre n'en utilise que 5M mais est appelée 200 fois donc on sort aussi la variable et on la passe aussi en paramètre. Une 3° aussi, et une 4° aussi etc etc. Finallement on se met à tout mettre en global et on n'a plus d'ennui de ce coté... mais on se met à en avoir par ailleurs !!!
Et puis il y a aussi le "static" qui existe qui te permet de ne pas faire du malloc/free à chaque appel (juste un malloc au premier et un free au dernier mais évidemment faut arriver à savoir qu'on est dans le dernier appel)

MagicBuzz a écrit :

Code :

int c;
prout(i, &c); // ou * chais jamais.
...
void prout(int i, int *c)
{
...
}

Pour savoir s'il faut mettre "*" ou "&" lors de l'appel, un truc mnémotechnique tout simple:

"c" est de type "int" or la fonction veut un "int *" donc ça ne va pas. Mais on peut s'imaginer "c" comme de type "& int *" (attention, ce n'est pas la réalité, c'est juste une construction imaginaire pour aider à comprendre tout comme au XVIII° siècle les nombres imaginaires ont aidé à trouver les solutions réelles à des équations du 3° degré) donc si je veux un type "int *" il faut que je mettre le "&" ailleurs car je ne peux pas le perdre donc je le mets devant "c" donc j'appelle ma fonction avec "&c" qui est bien de type "int *"...

Message édité par Sve@r le 10-01-2007 à 17:09:25

---------------
Vous ne pouvez pas apporter la prospérité au pauvre en la retirant au riche.

Publicité

Page : 1 2 3

Page Suivante

Page Précédente

Haut de page

FORUM HardWare.fr

Programmation

[C] Des accolades "just pour le fun" ?

Sujets relatifs
just les bases....
Plus de sujets relatifs à : [C] Des accolades "just pour le fun" ?

Page générée en 0.107 secondes