de la TI au PC moi aussi - Page 3

60

Le 06/01/2004 à 13:47

A oue ? Perso pour les projets que j'ai fait:
20% : design de l'architecture.
30% : ecriture du code et du jeu de tests automatiques.
50% : debuggage et affinage des tests.
Mettons que tu prennes 10% de temps en + en C qu'en C++ pour ecrire (c'est vraiment enorme), ben ca fera que 3% sur le projet. Enfin, je peux me tromper.

sauf que ca a aussi un gros impact dans la partie debuggage, meme plus (bcp) que sur la partie code

(je trouve)

Ben j'y vais pas, car je fais pas de jeux pour PC. Si tu veux je peux y aller.

tu sais que t'as une rubrique general programming qui traite de tout, que ce soit jeux ou pas, que t'as aussi une section multiplayer & networking qui traite certes de l'aspect reseau dans les jeux mais aussi de n'importe quoi qui a rapport avec de la prog reseau, idem pour le forum "maths and physics", pour "Artificial Intelligence", pour "Software Engineering" (qui malheureusement est legerement en deperissement

)
bref, a la base, c'est evidemment plutot en rapport avec les jeux PC, mais il y a des _tas_ de topics generaux qui peuvent s'appliquer a pleins de trucs, par exemple l'autre jour dans general programming y a un gars qui a poste un topic pke il faisait un os (dans un but educatif).. aucun rapport avec les jeux pc

Le caractere maintenable n'a rien a voir avec le langage.

il a a voir, entre autres, avec la lisibilite, surtout quand c'est un code que t'as pas ecrit toi, et la lisibilite, dans le cas de C/C++, je trouve que si, ca a un rapport avec le langage...

et me dis pas que t'as trouve des codes C++ immondes sur le net, ca a aussi a voir avec la norme utilisee pour la presentation... du C++ code avec une norme immonde peut etre bien pire que du C code avec une norme immonde, mais du C++ code avec une norme lisible et claire peut aussi etre mieux que du C code avec une norme lisible et claire... mais bon ca les normes c encore un autre sujet a trolls

moi j'aime pas les accolades a la fin des if sur la mm ligne

En quoi est-elle plus obscure ?
Ton probleme est de vouloir faire du C++ en C. C'est pas la meme chose.

pas du tout, c'est different, mon pbl, c'est que j'ai tout fait en C, mais que pour arriver au niveau d'abstraction dont j'avais besoin, et pour faire certaines choses, j'ai du structurer le proj et mon code d'une certaines facon, employer des ruses diverses (qui ont ete enumerees par toi meme dans ce topic en me repondant

), et au final, je me suis rendu compte que ca n'etait rien d'autre qu'une "emulation" de certaines features du C++.
c'est pas que je veux faire du C++ en C, pas du tout, c'est que je fais du C, mais que pour faire ce que je veux faire, je trouve le C++ est beaucoup plus adapte...

ABI non standardise. Sauf si tu fais des macros inlines

a bon.. heu.. "ABI" ?

Ce qui ne fais pas ton avis. Donc j'attends ton avis a toi.

je viens de te dire que n'ayant pas code en C++, mon avis sur la question je me le fais a partir de l'avis de pleins d'autres personnes

sinon j'aurais pas d'avis... c'est aussi simple que ca

Ca n'a rien d'un hack, et tu n'es pas obblige de le faire.

ah oui ca c'est sur, je suis pas oblige de le faire, c'est pour ca que je le fais pas d'ailleurs ^^

Tous les arguments pour le C++ sont vraiment des broutilles.

bah c'est sans doute des broutilles, mais je trouve que c'est des broutilles utiles

J'ai une vague idee. Mais je sens que votre projet est mal parti.

si tu le sens.. alors c'est surement vrai

ceci dit, si il est mal parti, c'est pas du tout a cause de ca

(mal fini plutot)

Ben c'est tes commentaires sur ton projet qui me l'ont fait penser. c'est tout.

en tt cas je vois pas le rapport...

Si tu passez des vars HWND, c'est que ton programme est trop proche de windows et que tu devrais mettre une couche d'abstraction supplementaire

j'ai bien dit que cette structure etait _privee_, ce genre de trucs n'apparait absolument pas dans l'interface du module, c'est uniquement une gestion interne

et justement, elle est peut etre _volontairement_ tres proche de windows, c'est peut etre la couche d'abstraction la plus basse, qui sert d'interface au reste

Faut simplifier la vie

on est d'accord... et le C me la complique

enfin non, plutot, le C++ me la simplifierait, mais je RE-dis ce que g deja dit une fois au dessus, peut etre (surement) certaines des particularites du C++ que je ne connais pas me la compliquerait, en tout cas tout ce que j'ai pu voir ca me l'aurait simplifiee

(et t'as pas compris mon exemple, pas grave...)

Et alors ? C'est vraiment plus dur de faire appel aux fonctions ? Oui, un peu.

tu dois le faire expres c pas possible

c'est pas une question de DUR........... c'est une question que c'est ILLISIBLE

et que tu dois faire des efforts non pas pour l'ecrire, mais surtout pour comprendre ce que ca fait apres, alors que dans l'autre cas, t'as carrement la formule utilisee devant le nez...
rhalala tu devrais coder quelques shaders en CG tu verrais quel bonheur c'est ^^
en C ca serait l'enfer

bah la c'est pareil...

Moi j'appelle usine a gaz les programmes c++ que je trouve sur le net

je defends pas l'utilisation qui est faite du C++, je trouve aussi pleins de progs que je trouve immondes. je dis juste que le C++ permet (re-re-re-re-repete: juste avec ce que j'en ai vu) de faire des progs plus propres, plus courts, plus simples a debug et faire evoluer...

Oui je sais.
mais si l'architecture change trop, il faut mieux tout reprendre. Beaucoup plus sain et au final plus rapide.

bien sur, et je suis le premier a le faire... quand j'ai le temps de le faire

(en prenant en compte le temps que ca ferait gagner par la suite de le refaire, mais meme en prenant ca en compte, c'est pas avantageux dans mon cas actuel...)
pour les petits projets, oui c'est sur c'est bcp mieux, t'as une meilleure vision du truc, tu sais plus ou tu vas, tu refais pas certaines erreurs, c'est plus propre, etc, etc...

Ben Replace all.

pff.. dans certains cas c'est pas aussi simple hein

et pas besoin d'avoir une IDE pour ca, emacs le fait tres bien...

In many respects the Yoshi is like a beautiful woman. A man can come so enamoured that he bestows on her all his time, his energy and his fortune.
- Fred whipple, 1960

*** Ne sous-estimez pas la puissance de la Marmotte ***
© Marmotte Team : LaMarmotte, sBibi, Vark & Sabrina

61

Le 06/01/2004 à 14:11

"Pour resumer, ce que je te reproche c'est de croire que le C++ est un langage magique qui resoud (presque) tout, alors que ce n'est qu'un langage avec une approche differente."

tu me le reproche, mais en meme temps tes arguments me semblent pas tres convaincants (les miens doivent pas te sembler super convaincants non plus

)

"La difficulte de la programmation d'un gros projet ne depend pas vraiment du langage, mais plutot de la maitrise des outils utilises et surtout de celui responsable de l'architecture du projet."

hehe, je dis pas qu'on a du mal, juste que y a moyen que ca soit encore plus simple et plus efficace pt de vue developpement

de toute facons, dans mon cas, si on le faisait en C++, on se planterait tres certainement, vu que je suppose que c'est pas un langage qui se maitrise en 1 mois

c'est pour ca qu'on le fait en C. ce que je vois, c'est qu'on perd du temps a certains endroits, temps qu'on ne perdrait pas si c'etait du C++.
et cette constatation converge vers ma reponse au topic: "C++", apprendre le C++ des le depart (surtout qu'il connait deja le C), lui sera tres utile par la suite quand il attaquera des projs ou le C++ aura une utilite par rapport au C.

tiens d'ailleurs, aucun rapport, mais meme Carmack (crois pas que je sois pas un fan, au contraire, g pleins de trucs a lui reprocher dans ses choix pour Doom3

), qui avait comme reputation d'etre une grosse brute fana de C, s'est rendu compte des vertus du C++

et Doom3 est code en quoi? pas en C

"PS: Et ne me parlez pas de l'industrie. Ils programment comme des porcs dans l'industrie (en general)."

peut etre aussi pke ils ont un temps limite pour faire certaines choses

In many respects the Yoshi is like a beautiful woman. A man can come so enamoured that he bestows on her all his time, his energy and his fortune.
- Fred whipple, 1960

*** Ne sous-estimez pas la puissance de la Marmotte ***
© Marmotte Team : LaMarmotte, sBibi, Vark & Sabrina

62

Le 06/01/2004 à 14:25

1. Je trouve le debugagge c++ plus difficile que le debugage c, mais c'est surement parce que je maitrise pas (ca doit etre equivalent).
2. "C++ code avec une norme lisible et claire peut aussi etre mieux que du C code avec une norme lisible et claire." Ca peut.
3. ne dis pas que cette "emulation du C++" coute.
4. Ben ce module doit inclure windows.h mais je ne pense pas que soit la majorite du projet, non ?
5. C'est parfaitement lisible de detailler chaque appel de fonctions. Et non, je n'ai jamais fait de shaders (Et ne compte pas en faire non plus). Mais perso je les ferais en asm.
6. Meme pour les gros projets. C'est bien plus rapide que ce qu'on pourrait penser de tout reecrire. Je me rappelle d'un pojet de 30000 lignes, que, d'un commun accord, on a reecrit en moins de 7000 lignes et avec toutes les fonctionnalites et ce en moins d'un mois (alors que l'autre version nous avez coute 4 mois).
7. Carmark ne sait pas coder proprement en C. Il suffit de lire les codes qu'il a pondu (Sans etre mechant). D'ailleurs le C++ est tellement rapide que ca ne fait que 3 ans que Doom3 est en projet.
8. Surtout parce qu'ils ne savent pas coder...

63

Le 06/01/2004 à 14:41

3: je vois pas pourquoi se fatiguer a la faire a la base

(enfin si, elle est moins fatiguante que d'apprendre le C++ ca c'est sur, mais justement voila l'interet de maitriser les deux langages et pas qu'un seul...)
4: non c'est pas la majorite du projet, c'est juste un detail qui avait pour seul but de montrer que balancer une fonction par fichier n'etait pas sans inconvenients dans tous les cas...
5: voila, le meme probleme, sauf que la la performance est plus critique, mais les compilateur CG ou HLSL font du tres bon boulot d'optimisation, surtout que les shaders c'est assez special, y a des optis tres differentes en fonction du GPU, et si tu veux les coder en asm, soit tu veux la meilleure perf possible et tu code une version optimisee pour chaque GPU (plus lent a faire), soit tu code une version generale pour tous les GPU (plus rapide a faire que 1 par GPU), soit tu le fais en CG, c'est encore plus rapide a coder que de le faire en asm, et point de vue perfs ca se situe entre les deux autres... c'est tjrs une histoire de compromis ca

et biensur, point de vue lisibilite, y a pas photo entre CG et asm

(comme entre C et asm en fait ^^)
6: je crois que l'incomprehension vient de la... un proj de 30000 lignes, j'appelle pas ca un gros projet... non seulement on est relativement satisfait de la structure actuelle, mais meme si ca prenait un mois pour tout refaire (en fait ca prendrait surement moins, 2 semaines on va dire...), on n'a pas un mois a perdre, ni deux semaines...
4: j'ai pas dit qu'il "savait coder proprement en C", juste que jusqu'a present il faisait tout en C, alors qu'il aurait pu passer au C++ bien avant, en meme temps que les autres de son secteur (le gamedev pc). et il a du finir par se rendre compte que le C++ avait des avantages non negligeables (bien que tout soit faisable en C aussi)
et Doom3 aurait peut etre mis plus de 3 ans si ca avait ete en C... quoi qu'il en soit, je me suis pas assez renseigne sur la dev du jeu pour savoir pourquoi ca fait 3 ans qu'ils sont dessus (en tout cas ils ont repris Q3)
8: #chevilles#

et toi tu sais biensur?

tu trouve pas que c'est assez pretentieux de dire un truc pareil de facon aussi generale?

In many respects the Yoshi is like a beautiful woman. A man can come so enamoured that he bestows on her all his time, his energy and his fortune.
- Fred whipple, 1960

*** Ne sous-estimez pas la puissance de la Marmotte ***
© Marmotte Team : LaMarmotte, sBibi, Vark & Sabrina

64

Le 06/01/2004 à 15:17

moi j'aime pas les accolades a la fin des if sur la mm ligne

65

Le 06/01/2004 à 15:18

3. Sa fatiguer a cause de ca ? Desole mais les bugs que je rencontre sont bien plus vicieux et difficile.
4. Pas forcement, mais c'est un bon debut.
5. De toute le code des shaders n'est pas gros. Alors c'est negligeable a mon avis la difference.
6. Ben alors c'est combien un gros projet ? 2 semaines pour toute remttre au propre, j'appelle pas ca du temps perdu.
7. Doom3 serait sorti plus vite s'il avait ete fait en C.
8. Je parlais pas d'ID mais de l'industrie en general. Et mon experience me fait dire que ca vole tres bas.

66

Le 06/01/2004 à 15:21

8. C'est des gens qui sortent d'où, ceux qui codent en industrie ? IUT ?

« Quand le dernier arbre sera abattu, la dernière rivière empoisonnée, le dernier poisson capturé, alors vous découvrirez que l'argent ne se mange pas. »

67

Le 06/01/2004 à 15:27

Tout sauf informatique.

68

Le 06/01/2004 à 15:29

Non, mais franchement ?
C'est des gars qui sortent d'IUT/BTS ou de plus haut ?
Peut-être que les gars qui sont plus haut ne codent pas, mais managent ?

En tout cas, en IUT, je trouve qu'on a un mauvais niveau, oui.

« Quand le dernier arbre sera abattu, la dernière rivière empoisonnée, le dernier poisson capturé, alors vous découvrirez que l'argent ne se mange pas. »

69

Le 06/01/2004 à 15:33

3: heu j'ai pas parle de bugs la O_o je repondais a ton "emulation du C++", c'est du travail en plus, qui pourrait etre evite et utiliser ailleurs (a debug justement par exemple)
5: bof, pas quand t'en as plusieurs centaines a faire

(et que tu multiplie ce chiffre par 3 ou 4 pour les != versions de GPU que tu veux supporter et pour ATI/NVIDIA)
6: 300000 lignes ca commence a devenir gros

30000 - 100000 perso je classe ca dans les projets de taille moyenne mais bon, la notion de gros ca depend bcp de trucs aussi hein... 30000 lignes c'est gros pour un proj a faire par une personne en 1 mois, c'est minuscule pour 10 personnes en 2 ans

et dans notre cas, si, etant donne qu'on le considere pas comme "sale", et que c'est suffisemment propre, c'est du temps de perdu, (etant donne aussi que la moindre semaine compte...)
7: bof, peut etre, peut etre pas

c'est le genre d'avis qui est valable que en provenance de quelqu'un qui a bosse sur le truc en question, qui sait ce qu'il y a derriere, et qui connait les raisons d'un ralentissement quelconque (si il y en a vraiment eu un), et le retard peut peut etre s'expliquer aussi par le fait que l'equipe de dev ne connaissait pas le C++ a fond quand ils ont commence

8: oui, j'avais bien compris l'industrie en general. mais meme, il y a suffisemment de surmasses dignes de respect dans l'industrie pour eviter de sortir des affirmations pareilles qui englobent tout le monde

(tu devrais aller faire un tour sur gamedev

mais juste y passer en coup de vent ca sert a rien... c'est comme ici si tu passe en coup de vent pour regarder des topics de prog ti...)

In many respects the Yoshi is like a beautiful woman. A man can come so enamoured that he bestows on her all his time, his energy and his fortune.
- Fred whipple, 1960

*** Ne sous-estimez pas la puissance de la Marmotte ***
© Marmotte Team : LaMarmotte, sBibi, Vark & Sabrina

70

Le 06/01/2004 à 16:00

Nil>

PpHd> le temps gagné en codage puis reperdu pour la compilation peut etre utilisé utilement #animes#

納豆パワー！
I becamed a natto!!!1!one!

71

Le 06/01/2004 à 16:15

3. C'est negligeable.
5. Je vois pas pkoi vous devez en faire des centaines....
6. 300000 est un projet surement surcomplique a mon avis. Regarde gcc (430420 lignes de code). Faudrait le decouper pour garder un niveau suffisament simple. M'enfin je preche dans le vide.
8. J'ai dit ca en fonction de ma propre experience de l'industrie et des ssii.

72

Le 06/01/2004 à 16:16

tss.. gagne apres quand les gars qui bossent avec toi doivent capter ce que t'as fait

remarque si tu veux regarder des animes ca peut etre une strategie aussi de coder obscur volontairement pour pouvoir les matter pendant qu'ils essayent de comprendre

In many respects the Yoshi is like a beautiful woman. A man can come so enamoured that he bestows on her all his time, his energy and his fortune.
- Fred whipple, 1960

*** Ne sous-estimez pas la puissance de la Marmotte ***
© Marmotte Team : LaMarmotte, sBibi, Vark & Sabrina

73

Le 06/01/2004 à 16:17

lol

納豆パワー！
I becamed a natto!!!1!one!

74

Le 06/01/2004 à 16:19

3: moue bof, admettons...
5: tres simple: pke tu ne sais pas ce qu'on fait, et pas besoin que tu le sache, ca n'apportera rien au debat (deja qu'il est sans interet

)
6: c'est pas un projet surcomplique... juste gros

et oui, gcc rentre dans ce que j'appelle "gros"
"Faudrait le decouper pour garder un niveau suffisament simple" -> bah oui, c'est pour ca qu'on decoupe notre truc en 5 grosses parties

"M'enfin je preche dans le vide." -> heu, comment ca tu preche? O_o
8: soit, dit comme ca ok, tel que tu l'av dit, ca faisait hyper pretentieux comme affirmation, enfin moi je m'en fous hein je disais ca pour toi

c'est bien au fur et a mesure les posts retrecissent

In many respects the Yoshi is like a beautiful woman. A man can come so enamoured that he bestows on her all his time, his energy and his fortune.
- Fred whipple, 1960

*** Ne sous-estimez pas la puissance de la Marmotte ***
© Marmotte Team : LaMarmotte, sBibi, Vark & Sabrina

75

Le 06/01/2004 à 16:26

[HS]

c'est bien au fur et a mesure les posts retrecissent

Merde, le Troll s'essouffle

[/HS]

76

Le 06/01/2004 à 16:29

un petit coup de Kevin et chuis sur il a un superbe boost

mais tant mieux qu'il s'essoufle, pke la il m'empeche d'aller ecrire mon rapport

In many respects the Yoshi is like a beautiful woman. A man can come so enamoured that he bestows on her all his time, his energy and his fortune.
- Fred whipple, 1960

*** Ne sous-estimez pas la puissance de la Marmotte ***
© Marmotte Team : LaMarmotte, sBibi, Vark & Sabrina

77

Le 06/01/2004 à 16:39

Et moi de corriger mes bugs vicieux.

78

Le 06/01/2004 à 17:13

Bon faut relancer le troll alors...
Moi je ne connais rien ni au C++ ni à l'objective C mais
il est clair que le C++ est un truc bidon pour faire du code bloaté... contrairement à l'Objective C, qui est une extension minimaliste et bien pensée permettant, sans alourdir le langage, d'accéder à toute la puissance du paradigme orienté-objet en C (et c'est dire

)

Voici quelques messages présentant des arguments objectifs pour alimenter la discussion : ici ^^

« Le bonheur, c'est une carte de bibliothèque ! » — The gostak distims the doshes.
Membrane fondatrice de la confrérie des artistes flous.
L'univers est-il un dodécaèdre de Poincaré ?
(``·\ powaaaaaaaaa ! #love#

79

Le 06/01/2004 à 18:28Edité par Boo le 06/01/2004 à 18:29

PpHd> si tu codais si bien que ca t'aurais pas de "bugs vicieux"

In many respects the Yoshi is like a beautiful woman. A man can come so enamoured that he bestows on her all his time, his energy and his fortune.
- Fred whipple, 1960

*** Ne sous-estimez pas la puissance de la Marmotte ***
© Marmotte Team : LaMarmotte, sBibi, Vark & Sabrina

80

Le 06/01/2004 à 18:28

Surtout qu'il ne s'agit que de faire une soustraction

81

Le 06/01/2004 à 18:29

lol... tiens ca me rappelle qd je debuggais ma vm ca

In many respects the Yoshi is like a beautiful woman. A man can come so enamoured that he bestows on her all his time, his energy and his fortune.
- Fred whipple, 1960

*** Ne sous-estimez pas la puissance de la Marmotte ***
© Marmotte Team : LaMarmotte, sBibi, Vark & Sabrina

82

Le 06/01/2004 à 18:54

nitro
:
Kevin Kofler :
1. Ce n'est pas du "vrai C++", c'est du -fno-exceptions.

Il n'y a rien dans le standard du C++ qui interdit les exceptions dans les libs dynamiques. D'ailleurs ça marchait la dernière fois que j'ai testé.

Mais ça pose des tonnes de problèmes:
* MinGW a été obligé de garder le système setjmp/longjmp plutôt que le DWARF2 moderne entre autres pour ça (aussi pour des raisons de taille du code d'ailleurs).
* GCC a été obligé de passer libgcc (qui contient des trucs comme les multiplications/divisions de long long sur les plateformes 32 bits) en dynamique pour que ça marche. Donc maintenant pratiquement tous les programmes Linux ont une dépendance de plus à cause de cette horreur de C++. Heureusement qu'il y a une option -static-libgcc.

De plus il y a des implémentations d'exceptions qui n'induisent pas de pénalités exagerées

Le problème n'est pas ça.

2. Ça marche très mal. Il faut compiler avec la même version de GCC que la DLL, sinon tout foire. Et il y a plein d'autres problèmes (entre autres avec les exceptions, ce qui ne concerne pas Qt parce qu'elle ne les utilise pas).

Chez moi j'ai des apps KDE compilées avec g++ 3.3.3 alors que les libs KDE et Qt sont compilées avec g++ 3.3.2 et je n'ai pas le mondre problème.

Normal, c'est la même version (3.3). Maintenant, essaye avec g++ 3.1 ou 3.4, voire 3.0, 2.96-rh ou 2.95 (3.2 et 3.3 sont en théorie compatibles, mais il y a au moins un bogue de compatibilité qui est visible dans Qt/KDE, donc je pense que tu peux rajouter 3.2 à la liste).

Si il y a des problèmes c'est à cause de bugs dans le compilateur, ça ne vient pas du standard.

Si le standard (autant le standard ISO C++ que la spécification de l'ABI) n'était pas aussi complexe, il n'y aurait pas autant de bogues.

As-tu essayé ton code sous Linux/glibc?
En codant comme tu dis, le programme ne fonctionne de manière acceptable que sous Linux/glibc... c'est pas terrible pour du C qui est sensé être universellement portable.

Ça fonctionne de manière "acceptable" sous toute plateforme qui a une libc acceptable. Je ne peux pas dire si l'implémentation de M$ fonctionne bien parce qu'elle est propriétaire. Tout ce que je peux dire, c'est que celle de NetBSD est mal faite, et le noyau aussi (pas de mremap). Et franchement, ce n'est pas mon problème.

sBibi :
"Et voilà ton erreur. La logique du C veut que 1 module == 1 fichier .c, pas un répertoire."

haha excellent tu te repond toi meme, c'est pas une erreur tres cher, c'est un choix. et cette "logique" du C fait entre autre (d'un point de vue strictement structurel) que le C est pas le langage le plus adapte pour les gros projets modulaires. desole j'aime pas trop avoir a parcourir des fichiers monstrueux avec une quantite enorme de fonctions dedans

module.c:
#include "partie1.c"
#include "partie2.c"
#include "partie3.c"
C'est sale, mais le fait d'avoir des modules en plusieurs fichiers quand le système de visibilités (static) est fait pour faire exactement le contraire l'est aussi.

sBibi :
"Le surchargement de fonctions simplifie le code???"

eh oui

"Le seul effet que ça a est qu'on ne sait plus quelle fonction est appelée."

justement, c'est la tout l'interet, au cas ou tu l'aurais pas compris c'est de ne plus avoir a se preocupper de quelle fonction est appellee...

Sûr que ça t'arrange beaucoup pour déboguer.

Bon sang, tu ne sais même pas dans quel overload est le bogue!
Et tu trouves ça "lisible"??? Pas moi...

"Si tu donne des noms différents, on voit tout de suite quelle est la fonction appelée."

oui, et tu dois te faire chier, quand t'as 20 fonctions de multiplication matricielle par exemple, a choisir la bonne en fonction des arguments, etc, etc...
si t'overloade une fonction par exemple mat_mult, t'as pas besoin de te soucier de quoi que ce soit, tu lui passe des matrices 3*3, 4*3, 3*4, 4*4, 4*5, n'importe quoi, et du moment que la bonne version est overloadee, ca passe tout seul. mais je vois pas pourquoi tu semble ignorer ou ne pas comprendre ca alors que ca a l'air d'etre une des bases

Les overloads ne sont pas la bonne solution pour la multiplication matricielle. Tu en aurais besoin d'une infinité! La bonne solution pour règler ce problème de manière générale et simple est la notation taille/tableau.

"Quant au surchargement d'opérateurs, je suis d'accord avec PpHd que c'est presque toujours abusif et illisible."

c'est peut etre illisible parceque c'est abusif, cf ce que j'ai dit au dessus.. l'utiliser a tout va est aussi mauvais que d'utiliser des listes chainees a tout va...
et desole mais je trouve ca:

c_vector_4 truc;
c_vector_4 machin;
...
truc += machin;

beaucoup plus lisible, simple et rapide a ecrire que ca:

t_vector_4 truc;
t_vector_4 machin;
...
truc.x += machin.x;
truc.y += machin.y;
truc.z += machin.z;
truc.t += machin.t;

et encore, un vecteur a 4 dimensions c'est un exemple simple compare a d'autres trucs...

vadd(truc,machin);
Court, et montre clairement que c'est une opération sur une structure et pas sur un nombre.
Mais si tu veux absolument noter +, pour les vecteurs, GCC te permet de noter:
int truc __attribute__((mode("V4SI"));
int machin __attribute__((mode("V4SI"));
truc += machin;

Et cette dernière notation a l'avantage d'utiliser les opérations sur les vecteurs du matériel quand c'est possible.

Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

83

Le 06/01/2004 à 19:21

Au fait, pour ce problème:

sBibi
: aussi, j'essaye de modulariser mon code au maximum, et tout est decoupe en modules, chaque module ayant son repertoire, et chaque repertoire de modules etant regroupe dans d'autres repertoires correspondant aux differentes couches d'abstractions. chacun de ces modules a une interface bien definie, dans un .h "public", qui a, comme toute interface, pour but d'abstraire le fonctionnement interne du module, et un ou des .h "prives", dans un repertoire include au sein du module, qui lui contient tout ce qui est specifique a l'implementation et au fonctionnement interne du module. or en C, hormis mettre des variables ou des fonctions qui sont censees etre "privees" en static (ce qui implique d'avoir tout le code qui doit s'en servir dans le meme fichier), je connais pas d'autre solution.

, il y a une solution: __attribute__((visibility(hidden))).
Mais il faut compiler tes fichiers en une librairie.

janjan2
: s'il y a bien un toolkit vraiment themable c'est gtk et surement pas Qt

Ah oui? Alors explique-moi comment faire en sorte que les "popups" (l'équivalent des dropdowns) sous GTK se comportent comme des dropdowns Windows ou Qt (oui, Qt a le comportement attendu)? Bluecurve s'y rapproche, mais c'est loin d'être parfait.
Franchement, le seul défaut de Qt est d'être codé en C++ (et aussi que la version Win32 n'est pas libre, mais il y a un projet pour un portage Win32 inofficiel sous GPL en cours).

sBibi :
c'est pas une question d'effort bordel, c'est une question d'abstraction...

tvector_matmul_2x2_3x2_inverse_transpose(&a, b, c)
ou:
tvector_matmul_2x2_3x2_inverse_transpose_pointer_c(&a, b, &c) ?
ou encore: tvector_matmul_2x2_3x2_inverse_transpose_pointer_b_pointer_c(&a, &b, &c) ?

Tu passes tes matrices par valeur, toi? Évidemment que tous les 3 arguments sont toujours des pointeurs.

sBibi
: pour win.h: pas a chaque fichier non, sauf dans un module de gestion de fenetres ou t'as par exemple une structure privee qui est utilisee dans tout le module et qui contient des vars du style HWND ou autres

typedef int HWND;
Pas besoin d'inclure windows.h pour ça.

Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

84

Le 06/01/2004 à 19:55

sBibi
: et pas besoin d'avoir une IDE pour ca, emacs le fait tres bien...

Emacs est une (<TROLL>mauvaise</TROLL>) IDE.

PpHd
: 1. Je trouve le debugagge c++ plus difficile que le debugage c, mais c'est surement parce que je maitrise pas (ca doit etre equivalent).

Aussi parce que gdb ne gère pas aussi bien le C++ que le C.

sBibi :
6: 300000 lignes ca commence a devenir gros

Alors GCC est "gros" parce que la version TIGCC fait 773267 lignes, et la version complète (avec tous les targets) encore plus. Et c'est codé en C!

Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

85

Le 06/01/2004 à 20:52

c'est vrai que debugger du C++ avec gdb est parfois un peu coton mais bon

fabetal_ > Hier, je me suis fait monter par un pote
redangel > et en chevals, ça donne quoi?
Nil> OMG I think I'm gay

86

Le 06/01/2004 à 21:27

bon allez on va repondre a tout ca

Ça fonctionne de manière "acceptable" sous toute plateforme qui a une libc acceptable. Je ne peux pas dire si l'implémentation de M$ fonctionne bien parce qu'elle est propriétaire. Tout ce que je peux dire, c'est que celle de NetBSD est mal faite, et le noyau aussi (pas de mremap). Et franchement, ce n'est pas mon problème.

oui, la je suis d'accord que l'implementation de realloc de NetBSD est mal faite, mais il me semble qu'il n'y a que linux qui supporte MREMAP... et si ca n'est pas ton probleme, c'est peut etre celui d'autres personnes

module.c:
#include "partie1.c"
#include "partie2.c"
#include "partie3.c"
C'est sale, mais le fait d'avoir des modules en plusieurs fichiers quand le système de visibilités (static) est fait pour faire exactement le contraire l'est aussi.

tu pouvais pas trouver plus immonde? et je pense pas que ca soit necessaire de te rappeller l'interet d'avoir plusieurs .c ... (a tout hazard: plus lisible, pas besoin si t'as 20 fichiers dans un module de recompiler les 20 a chaque fois que tu change une ligne dans un seul de ces fichiers)

Sûr que ça t'arrange beaucoup pour déboguer.
Bon sang, tu ne sais même pas dans quel overload est le bogue! Et tu trouves ça "lisible"??? Pas moi...

bien sur que si je le sais (enfin je le saurais)
suffit d'avoir un systeme de logging d'erreurs un minimum bien concu

Les overloads ne sont pas la bonne solution pour la multiplication matricielle. Tu en aurais besoin d'une infinité! La bonne solution pour règler ce problème de manière générale et simple est la notation taille/tableau.

d'une infinite? O_o je vois pas trop la ou tu veux en venir, y en a pas besoin de plus que ce que t'as sans overload... explique mieux pke la je vois pas

vadd(truc,machin);
Court, et montre clairement que c'est une opération sur une structure et pas sur un nombre.
Mais si tu veux absolument noter +, pour les vecteurs, GCC te permet de noter:
int truc __attribute__((mode("V4SI"));
int machin __attribute__((mode("V4SI"));
truc += machin;
Et cette dernière notation a l'avantage d'utiliser les opérations sur les vecteurs du matériel quand c'est possible.

, il y a une solution: __attribute__((visibility(hidden))). Mais il faut compiler tes fichiers en une librairie.

oue, et si je veux que mon code compile avec d'autres compilateurs que GCC, je peux me le fourrer bien profond c'est ca?

Tu passes tes matrices par valeur, toi? Évidemment que tous les 3 arguments sont toujours des pointeurs.

exemple debile pour imager le post d'avant, mais si j'ai envie de les passer par valeurs, ca te derange?...
(de toute facons j'ai l'impression que tu t'imagine que je fais des copier coller de mon code, je te rassure j'ai absolument rien d'aussi horrible que ca, c'est seulement des _exemples_ kevin...)

typedef int HWND; Pas besoin d'inclure windows.h pour ça.

bordel, exemple encore, ca aurait pu etre n'importe quoi d'autre, comme une collections de trucs dans windows.h ...
si t'utilise que printf tu vas faire quoi?
int printf(char *format, ...);
ou bien
#include <stdio.h>
?

bref une autre remarque a cote de la plaque pour pas changer...

Emacs est une (<TROLL>mauvaise</TROLL>) IDE.

t'as bien fait de mettre les balises pke je suis pas du tout d'accord avec toi sur le "mauvaise"

<TROLL>je le trouve infiniment mieux que l'IDE de TIGCC (qui pux (a mort (comme un terrier de marmotte (en chaleur (qui a pas baise (depuis 3 mois))))))

</TROLL>

Alors GCC est "gros" parce que la version TIGCC fait 773267 lignes, et la version complète (avec tous les targets) encore plus. Et c'est codé en C!

et alors? le kernel de linux est aussi sans doute code en C (j'en sais rien), et surement bcp plus gros que ca. mais et alors?

In many respects the Yoshi is like a beautiful woman. A man can come so enamoured that he bestows on her all his time, his energy and his fortune.
- Fred whipple, 1960

*** Ne sous-estimez pas la puissance de la Marmotte ***
© Marmotte Team : LaMarmotte, sBibi, Vark & Sabrina

87

Le 06/01/2004 à 22:35

sBibi
:
Sûr que ça t'arrange beaucoup pour déboguer.
Bon sang, tu ne sais même pas dans quel overload est le bogue! Et tu trouves ça "lisible"??? Pas moi...

bien sur que si je le sais (enfin je le saurais)
suffit d'avoir un systeme de logging d'erreurs un minimum bien concu

Tu as quand-même besoin d'un log d'erreurs. Moi, je te parle de déboguer du code en le lisant. Apparemment, tu ne sais pas ce que veut dire "lire du code".

Les overloads ne sont pas la bonne solution pour la multiplication matricielle. Tu en aurais besoin d'une infinité! La bonne solution pour règler ce problème de manière générale et simple est la notation taille/tableau.

d'une infinite? O_o je vois pas trop la ou tu veux en venir, y en a pas besoin de plus que ce que t'as sans overload... explique mieux pke la je vois pas

Il y a une infinité de dimensions possibles. (|N*² a une infinité d'éléments.) Si tu fais une surcharge pour 3×3 et une pour 3×4, pourquoi pas une pour 32767×65535?

, il y a une solution: __attribute__((visibility(hidden))). Mais il faut compiler tes fichiers en une librairie.

oue, et si je veux que mon code compile avec d'autres compilateurs que GCC, je peux me le fourrer bien profond c'est ca?

Oui.

Je n'y peux rien si les autres compilateurs sont pourris.

De toute façon, GCC tourne partout, donc pas besoin des autres.

Tu passes tes matrices par valeur, toi? Évidemment que tous les 3 arguments sont toujours des pointeurs.

exemple debile pour imager le post d'avant, mais si j'ai envie de les passer par valeurs, ca te derange?...

Passer une matrice par valeur. <SARCASM>Quelle intelligence suprême...</SARCASM>

typedef int HWND; Pas besoin d'inclure windows.h pour ça.

bordel, exemple encore, ca aurait pu etre n'importe quoi d'autre, comme une collections de trucs dans windows.h ...
si t'utilise que printf tu vas faire quoi?
int printf(char *format, ...);
ou bien
#include <stdio.h> ?

Dans le cas d'un gros header comme windows.h duquel tu n'utilises qu'un ou deux identifiants, la première solution est tout à fait raisonnable.

<TROLL>je le trouve infiniment mieux que l'IDE de TIGCC (qui pux (a mort (comme un terrier de marmotte (en chaleur (qui a pas baise (depuis 3 mois))))))</TROLL>

Ça ressemble à du LISP tellement il y a des parenthèses.

Et pour le contenu:

!

Alors GCC est "gros" parce que la version TIGCC fait 773267 lignes, et la version complète (avec tous les targets) encore plus. Et c'est codé en C!

et alors? le kernel de linux est aussi sans doute code en C (j'en sais rien), et surement bcp plus gros que ca. mais et alors?

Ça montre que les gros projets en C sont tout à fait possibles. Et le code de GCC n'"émule" pas "le C++".

Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

88

Le 06/01/2004 à 23:13

Kevin Kofler :
Normal, c'est la même version (3.3). Maintenant, essaye avec g++ 3.1 ou 3.4, voire 3.0, 2.96-rh ou 2.95 (3.2 et 3.3 sont en théorie compatibles, mais il y a au moins un bogue de compatibilité qui est visible dans Qt/KDE, donc je pense que tu peux rajouter 3.2 à la liste).

Bah si c'est incompatible c'est à cause de gcc. Le standard est là, et si toutes ces versions là de gcc ne le respectent pas, c'est normal que ce soit incompatible. Une fois qu'ils auront implémenté correctement l'ABI, il y aura de la compatibilité.

Si le standard (autant le standard ISO C++ que la spécification de l'ABI) n'était pas aussi complexe, il n'y aurait pas autant de bogues.

Le standard est complexe, et alors ? Il n'existe pas de langage équivalent moins complexe. De toute façon ça ne peut être que complexe quand on s'obstine à vouloir garder la compatibilité avec des choses obsolètes.

Ça fonctionne de manière "acceptable" sous toute plateforme qui a une libc acceptable. Je ne peux pas dire si l'implémentation de M$ fonctionne bien parce qu'elle est propriétaire. Tout ce que je peux dire, c'est que celle de NetBSD est mal faite, et le noyau aussi (pas de mremap). Et franchement, ce n'est pas mon problème.

Eh ben quand la plateforme est imposée (comme c'est bien souvent le cas), on ne peut pas faire autrement que coder comme sBibi l'a fait.

So much code to write, so little time.

89

Le 06/01/2004 à 23:31

nitro
:
Kevin Kofler :
Normal, c'est la même version (3.3). Maintenant, essaye avec g++ 3.1 ou 3.4, voire 3.0, 2.96-rh ou 2.95 (3.2 et 3.3 sont en théorie compatibles, mais il y a au moins un bogue de compatibilité qui est visible dans Qt/KDE, donc je pense que tu peux rajouter 3.2 à la liste).

Bah si c'est incompatible c'est à cause de gcc. Le standard est là, et si toutes ces versions là de gcc ne le respectent pas, c'est normal que ce soit incompatible. Une fois qu'ils auront implémenté correctement l'ABI, il y aura de la compatibilité.

Déjà le "standard" d'ABI en question n'est pas un standard officiel ISO, mais une convention entre les développeurs de compilateurs pour le fameux "Itanic" qui a été adapté pour les autres plateformes dans g++. Ensuite, il y a aussi des erreurs dans la spécification de l'ABI (par exemple des trucs incompatibles avec le standard ISO C++, ou des "optimisations" contre-productives qu'aucun des compilateurs implémentant l'ABI n'implémentent) qui sont corrigés avec le temps.

De toute façon ça ne peut être que complexe quand on s'obstine à vouloir garder la compatibilité avec des choses obsolètes.

Quelles choses "obsolètes"? Des choses "obsolètes" comme l'arithmétique des pointeurs, qui fait toute l'efficacité du C/C++?!

Ça fonctionne de manière "acceptable" sous toute plateforme qui a une libc acceptable. Je ne peux pas dire si l'implémentation de M$ fonctionne bien parce qu'elle est propriétaire. Tout ce que je peux dire, c'est que celle de NetBSD est mal faite, et le noyau aussi (pas de mremap). Et franchement, ce n'est pas mon problème.

Eh ben quand la plateforme est imposée (comme c'est bien souvent le cas), on ne peut pas faire autrement que coder comme sBibi l'a fait.

Ben non, le code fonctionne sous la plateforme demandée. Il performe mal, mais c'est la faute de l'OS et/ou de la librairie C et pas de l'application.

Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

90

Le 07/01/2004 à 00:34

Tiens:

Kevin Kofler
:
nitro
:
Kevin Kofler :
1. Ce n'est pas du "vrai C++", c'est du -fno-exceptions.

Il n'y a rien dans le standard du C++ qui interdit les exceptions dans les libs dynamiques. D'ailleurs ça marchait la dernière fois que j'ai testé.

Mais ça pose des tonnes de problèmes:
[...]
* GCC a été obligé de passer libgcc (qui contient des trucs comme les multiplications/divisions de long long sur les plateformes 32 bits) en dynamique pour que ça marche. Donc maintenant pratiquement tous les programmes Linux ont une dépendance de plus à cause de cette horreur de C++.

... et voici le résultat: http://gcc.gnu.org/ml/gcc/2004-01/msg00239.html. Toutes les architectures qui ont changé de modèle d'exceptions (pour passer au DWARF2 pour des raisons de performances) ont ce problème.

Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité