Tableaux à deux dimensions - Page 2

Enfin moi je prefere le C. Puis d'ailleurs un ingenieur C est mieux paye qu'un ingenieur C++

C:\Documents and Settings\Paul>tigcc -S -O2 z.c z.c:1: error: variable-size type declared outside of any function

Mauvaise foi! Et puis en déclarant mon tableau comme global (cf post de départ) il n'y aurait aucun problème. Le but ici est de définir le tableau dans la fonction main.
#undef dimX #define nom_table (tableau) #define dimX 50 printf("%i",mat(0,0)); }

Sinon on peut toujours jongler avec des #define et #undef, je pense que cela fonctionne.#define mat(x,y) ((nom_table)[x+dimX*y])
void ma_fonction(TABLE *tableau)
{
 #undef nom_table

Note: Ce code est très certainement ridicule et je suis quasiment sûr qu'on peut faire mieux mais c'est juste pour "exprimer ma pensée"

Thibaut B :
int y[] n'est pas une déclaration de tableau de taille indéfinie ?

Pas dans un paramètre de fonction. Dans un paramètre de fonction, int y[] == int *y. Et cela depuis le K&R, donc le C99 n'a pas pu changer ça pour des raisons de compatibilité antérieure.

Vous voulez carrément passer le tableau ?
a_fonction(Tableau) ({typeof(Tableau) Copie= Tableau; _ma_fonction_(Copie);})La fonctionnalité du C++ doit pouvoir être simulée avec un code de ce genre :#define m

Pas du tout. Ce qu'on veut passer, c'est le tableau et sa dimension, en un seul paramètre. La dimension peut ensuite être obtenue par un sizeof. Mais ce n'est pas encore implémenté dans GCC.
Ce qu'on peut faire, c'est passer la taille et le tableau en des paramètres séparés (même pour les tableaux à plusieurs dimensions! Par exemple: int n;int (*x)[n], int m, int n), donc inutile de donner une méthode qui fait ça.

Ce qu'on veut passer, c'est le tableau et sa dimension, en un seul paramètre. La dimension peut ensuite être obtenue par un sizeof.

Ha j'avais pas saisi

Kevin Kofler
:

Pollux
: z.c:1: error: variable-size type declared outside of any function

Ben oui, il faut le mettre dans une fonction, évidemment... Tu t'attends que le compilateur lit dans tes pensées pour savoir combien de mémoire allouer dans l'exécutable ou la section BSS si la taille n'est pas constante? Et si la taille est constante, alors utilise #define, pas const.

Voilà, c'est ce que je dis depuis le début
Le C n'est pas fait pour avoir des trucs propres comme les const, et donc on est obligé de faire des hacks (qui ne marchent pas toujours) avec le préprocesseur... Le C++, lui est fait pour ça. C'est tout, je ne fais que le constater. Mais on peut quand même faire des programmes en C, hein

Et idem si tu le déclares dans une structure j'imagine

Pas si la structure est locale.

Je parle d'une structure quelconque (dans le cas qui nous intéresse, la structure va typiquement représenter un niveau, lequel va typiquement être dans un fichier ou dans une variable globale). Donc non, pas possible en C sans #define et ##.

Ca m'est arrivé assez souvent d'en utiliser, mais c'est vraiment pas terrible : si tu mets des fonctions dedans, c'est complètement indébuggable.

Justement, dans ld-tigcc, il y a des fonctions entières codées avec des ## (suivies d'une ligne pour chaque spécialisation (pour reprendre le langage des templates, parce que c'est ce que c'est en réalité)).

Oui, bien entendu. Mais ce n'est pas pratique du tout (ex : localisation des erreurs de syntaxe, et quand tu as un débogueur C : débuggage à l'intérieur de la fonction), donc ça ne convient que pour les fonctions assez simple, ou alors une fois la fonction débuggée, on peut la passer en "template" (mais ce n'est qd même pas idéal). En plus, la spécialisation de templates n'est pas possible... Je pense que ce que tu veux dire par "spécialisation" est en réalité "instantiation", non? (j'entends par spécialisation : vector<typename T> = blablabla; vector<bool> = gnagnagna, donc vector<bool> spécialisation de vector<T>).

Et pour l'exemple qui nous intéresse, ce n'est pas du tout aussi flexible que 'const int xdim' puisqu'on est obligé de le mettre dans une variable donnée et de déclarer à la main, pour tous les noms de variables possibles, la largeur du tableau...

Voilà pourquoi je conseille toujours la syntaxe C99 qui met ça là où ça a sa place: dans la déclaration du type.

Mhu? Au contraire, 'const int xdim' ne peut pas être mis dans le type. #define mavar_XDIM doit être utilisé à chaque fois qu'on utilise un nouveau nom de variable (et attention aux conflits entre fonctions si on oublie les #undef )

D'ailleurs, le C99 prévoit aussi le passage de tableaux à une fonction sans avoir à préciser manuellement la taille, avec la syntaxe int y[*]. Mais GCC n'implémente pas encore ça.

C'est à dire?

Pollux
: En plus, la spécialisation de templates n'est pas possible... Je pense que ce que tu veux dire par "spécialisation" est en réalité "instantiation", non? (j'entends par spécialisation : vector<typename T> = blablabla; vector<bool> = gnagnagna, donc vector<bool> spécialisation de vector<T>).

Oups, en effet, j'ai mal choisi mon terme. Mais la spécialisation est possible en GNU C: http://tigcc.ticalc.org/doc/gnuexts.html#SEC104___builtin_types_compatible_p.

Et pour l'exemple qui nous intéresse, ce n'est pas du tout aussi flexible que 'const int xdim' puisqu'on est obligé de le mettre dans une variable donnée et de déclarer à la main, pour tous les noms de variables possibles, la largeur du tableau...

Voilà pourquoi je conseille toujours la syntaxe C99 qui met ça là où ça a sa place: dans la déclaration du type.

Mhu? Au contraire, 'const int xdim' ne peut pas être mis dans le type. #define mavar_XDIM doit être utilisé à chaque fois qu'on utilise un nouveau nom de variable (et attention aux conflits entre fonctions si on oublie les #undef )

Ben non, on déclare sa variable en int (*p)[123] et on n'a pas besoin de définir quoi que ce soit. Si on veut changer la taille, on la change dans la déclaration de type.

D'ailleurs, le C99 prévoit aussi le passage de tableaux à une fonction sans avoir à préciser manuellement la taille, avec la syntaxe int y[*]. Mais GCC n'implémente pas encore ça.

C'est à dire?

Que ce n'est pas encore implémenté, je ne vois pas comment détailler plus.

Mais la spécialisation est possible en GNU C

Ca a déjà été dit, mais tu es obligé d'avoir les deux définitions au même endroit ou bien de changer de nom. Et la syntaxe devient vite lourde.

Ben non, on déclare sa variable en int (*p)[123] et on n'a pas besoin de définir quoi que ce soit. Si on veut changer la taille, on la change dans la déclaration de type.

OK, en passant par des tableaux à deux dimensions. Mais de manière plus générale, si on a besoin d'un attribut qui soit constant et qui ne dépende que du type de la variable, on ne peut pas le faire en C.

> C'est à dire? Que ce n'est pas encore implémenté, je ne vois pas comment détailler plus.

Je parlais de 'int y[*]'. Ca veut dire que la taille est passée en paramètre?

La réponse a été donnée : topics/30353-tableaux-a-deux-dimensions/2#34

Implémente-le dans GTC, ça t'avantagera un peu

Oups désolé, j'avais complètement loupé la deuxième page

yAro pourrait pas enlever le formulaire de réponse pour les pages autres que la dernière? Ca éviterait de se planter et en plus ça accélèrerait légèrement le chargement des pages (ou alors, ne pas systématiquement mettre à jour sur last.php, et ne le faire que lorsqu'on regarde la dernière page du topic, mais c'est plus compliqué à implémenter je pense).

./31> Mais non, C++ powa Et pkoi un ingénieur C est mieux payé qu'un ingénieur C++ ?

Mauvaise foi! Et puis en déclarant mon tableau comme global (cf post de départ) il n'y aurait aucun problème. Le but ici est de définir le tableau dans la fonction main.

Pourquoi mauvaise foi? Je dis juste que le C oblige à tout mettre dans le namespace du préprocesseur, ce qui est très gore et empêche d'associer à un certain type de données un attribut correspondant à ce type (puisqu'on ne peut que l'associer à une variable).

Sinon on peut toujours jongler avec des #define et #undef, je pense que cela fonctionne

Oui, tant qu'il ne s'agit que de variables "pures". Dès qu'il s'agit d'expressions, ça ne marche plus. Et comme je l'ai déjà dit, un #define par nom de variable différent

Parce que le C++ c'est simple, et le C c'est complique! Voyons. La meme chose (avec une plus grande difference) avec Java.
(Quoique perso je pense que le C++ est impossible a maitriser).

le C++ c'est simple, et le C c'est complique

Tu rigoles? Je dirais que quand tu maîtrises le C++ alors normalement tu devrais aussi maîtriser le C (sinon tu risques de faire des routines lentes )
Qu'est-ce que ça a de plus simple, à part la syntaxe qui est parfois complètement tordue?

rge des opérateurs par exemple !prout= "hello" + world;Les objets et la surcha

Ca ne simplifie que la syntaxe, et c'est ultra-pratique Si utiliser un langage qui a une syntaxe merdique ça veut dire être un Déus, alors je me remets de ce pas au Pascal ou au CAML

Brunni> si tu regardes encore ce topic, soit le type de retour de alloue, tu le mets en bool, soit tu te crées des constantes genre #define MEM_OK 1 ce sera plus propre

Et sinon, le C, c'est mieux que le C++ - je suis assez de l'avis de PpHd, mais c'est sans doute parce que je n'arrive pas encore à tout saisir dans le C++ - et à bas Java, sauf sur les JavaPIC -

>Je dirais que quand tu maîtrises le C++ alors normalement tu devrais aussi maîtriser le C
Astuce: on remarque un imposteur lorsqu'il dit maitriser le C++. Personne au monde ne maitrise le C++. Trop complique.

Donc un programmeur C++ est soit un mauvais programmeur, soit un imposteur ?

Bon à savoir

Pas tous quand même.
Il faut distinguer ceux qui font du C++ et ceux qui font des MFC .

Il ne faut pas dire que le C++ est trop compliqué. C'est juste une question de bon sens.
Je vous enjoinds d'ailleurs à lire cette page avec quelques clarifications sur certains points prétenduments incompréhensibles du C++ : http://www.apostate.com/programming/c-tech.html.

Le dernier, notamment est le plus amusant, et pourtant sa compréhension est d'une froide et implacable logique. C'est juste du français (enfin, de l'anglais je veux dire) :

In this instance, ~y() is a protected abstract virtual base pure virtual private destructor of z

Euh, pour bien comprendre, faut couper après base, et reprendre la suite après

Brunni> si tu regardes encore ce topic, soit le type de retour de alloue, tu le mets en bool, soit tu te crées des constantes genre #define MEM_OK 1 ce sera plus propre

Bah pourquoi pas...

Il faut distinguer ceux qui font du C++ et ceux qui font des MFC

Qu'est-ce qu'elles ont les MFC? J'ai essayé à l'époque mais j'ai tout lancé loin. Maintenant je fais du truc bizarre peut-être encore plus compliqué où tu fais des trucs du style:
SendDlgItemMessage(hDlg,IDC_STRICT,BM_GETCHECK,0,0);
Comment ça s'appelle ça pour Windows? (chouette je découvre maintenant que les balises pre sont dans le panneau de format yaronet à droite! )

Tu rigoles? Je dirais que quand tu maîtrises le C++ alors normalement tu devrais aussi maîtriser le C (sinon tu risques de faire des routines lentes )

Le C++ est plus lent que le C? Bah je suis encore assez étonné de la rapidité du C sur ordi. Mais les contrôles windows... c'est pas trop ça! Et la grosse M pour mettre un texte dans un RichTextBox avec EM_STREAMIN et le callback de la mort... Et pourtant ça a pas l'air si lent que ça y paraît (quand je pense ce que c'était en VB... simple mais LENT)

Tu devrais chercher un toolkit graphique digne de ce nom (suivez mon propos : pas MFC)

Il me semble que TrollTech va bientôt sortir Qt3 pour windows sous GPL. A suivre.
Sinon, tu peux essayer wxWindows.
Ces deux toolkits sont portables windows/Linux en plus.

Ce que je reproche à MFC ? ben en fait exactement la même chose que ce que cette page reproche : http://phil.freehackers.org/kde/fr_qt-vs-mfc.html
En même temps c'est logique, j'ai eu la même expérience que l'auteur de la page (programmation en MFC d'abord puis en Qt après #soulagement#).

Et ceux qui voudraient répondre que Codejock améilore les choses sont priés de lire jusqu'au bout. Ca devrait plus s'appeler Codejoke que Codejock.


Une note finale : juste un truc tout bête hein, vous avez déjà programmé avec les mfc :
1) deux vues séparées par un séparateur ajustable (splitter) ?
2) une vue avec des onglets ?
Moi, oui. C'est le bordel le plus monstrueux que j'aie jamais rencontré. En Qt, vous avez juste à poser les composants, et ils se comportent correctement immédiatement.

Ta page ne me semble pas très crédible. Globalement, tout a un ton de flamewar, et, même si je ne suis pas capable de critiquer leurs "arguments" contre MFC (puisque je ne connais pas), je peux qd même citer ce paragraphe :

La documentation est un aspect primordial à considérer lorsqu'on veut utiliser une bibliothèque graphique riche en fonctionnalités. Celle de Visual, MSDN semble pléthorique, tient sur 10 CDROM. On y trouve des articles pour faire toutes sorte de choses. Cependant, elle laisse l'impression que ce qui est documenté provient d'une mauvaise architecture. La navigation à l'intérieur est de piètre qualité : impossible d'accéder facilement depuis une classe a ses classes mères ou filles, présentations des méthodes sans la signature, accès difficiles aux méthodes héritées, etc. Par ailleurs, en recherchant de l'aide sur un mot-clé, on tombe sur l'aide de tous les langages sur ce mot-clé: Java, Visual Basic, C++, InterDev, ...

Tous les arguments sont faux :
- MSDN prend 3 CD-ROM, autant que je sache
- il y a des liens vers toutes les classes mères, et même un dessin le représentant
- présentation des méthodes sans la signature : complètement faux
- accès difficile aux méthodes héritées : idem
- on peut filtrer pour avoir la doc seulement C++

Donc le type qui a écrit ça n'a visiblement jamais utilisé VS et donc jamais les MFC. Tous les arguments "QT c'est plus simple" me paraissent donc très douteux...

Je passe sur le seul passage sur lequel j'ai daigné jeter un oeil après avoir lu la remarque de Pollux, et j'ai un scoop: On peut mettre directement plusieurs langues dans une String Table, et la langue choisie par défaut est celle de windows lors de l'exécution. D'accord ça prend plus de place, mais pour du texte...
Et inutile de tout mettre dans la DLL, on peut mettre la String Table dans l'exe lui-même. Sans compter qu'on peut avoir une String Table sans utiliser les MFC...

=> Et c'est vrai que charger des entrées de la string table, c'est vachement plus simple et pratique que de juste marquer tr("la chaine qui doit etre localisée")

Pollux :
- jette un oeil à la documentation de Qt, pour comparer.
- sur 10 arguments intéressants, t'as juste sélectionné une partie d'un des arguments. Ca en laisse encore 9,5

=> Tu devrais également jeter un oeil à la documentation de certains objets COM/OLE, par exemple la documentation des objets Excel, ou l'interface WMI.
Aux dernières nouvelles, ben t'avais que la documentation VB, et si tu veux y accéder en C++, c'est freestyle.

Sasume :
Ah ? Curieux, pourtant c'est du C ANSI

Encore faut-il la switch -ansi (qui n'est pas mise par défaut quand
on utilise l'IDE).

(Prêts pour un clash de KK ?)

Le C ANSI sert plus à nous interdire les comments // qu'à autre chose.
Pour moi, le GNU C est une norme suffisante: pas chiante sur
des détails (//), permettant quelques *abus* qu'en fait tout
le monde fait (les long long, utilisés aussi dans Visual C++).

Bon, si on voulait être Posix, là faudrait mettre -ansi.
Mais je crois pas qu'un #define _POSIX_SOURCE 1 ait le moindre
effet dans TIGCC.

> jette un oeil à la documentation de Qt, pour comparer.
Oui, quand j'en aurai besoin, pourquoi pas.

> sur 10 arguments intéressants, t'as juste sélectionné une partie d'un des arguments. Ca en laisse encore 9,5
Hmm, pour les autres arguments, je ne suis pas en mesure de confirmer ou d'infirmer le fond. Mais le style est /tellement/ lourd (et vu ce que je peux dire du seul paragraphe avec lequel je puisse être d'accord ou non) que ça ne m'a pas l'air si "intéressant" que tu le dis (c'est à mon avis très très partial, au point de raconter n'importe quoi).

Cela dit, ça n'empêche que Qt est certainement une alternative intéressante (surtout parce qu'elle est portable) aux MFC, et c'est même possible que Qt soit bien mieux ; en tout cas, c'est pas ta page web qui me convaincra sur ce point-là

WxWindows powered - ça m'a l'air quand même mieux que les MFC, mais l'avantage de ces derniers est la possibilité de dessiner directement avec eux, et je crois que CW arrive à les gérer. A vérifier... -

spectras
: Aux dernières nouvelles, ben t'avais que la documentation VB, et si tu veux y accéder en C++, c'est freestyle.

On peut toujours s'arranger, même en C. Cf. la source du Tokens89 Command-Line Converter (http://members.chello.at/gerhard.kofler/kevin/francais/pcprogs/), qui charge un OCX VB en C (MinGW GCC). Mais c'est absolument illisible. On voit que c'est du M$.

RedSilk
:

Sasume :
Ah ? Curieux, pourtant c'est du C ANSI

Encore faut-il la switch -ansi (qui n'est pas mise par défaut quand on utilise l'IDE).

Qui n'est pas mis parce qu'il ne fonctionne pas. -ansi n'est pas supporté par TIGCC. Essaye et tu verras que tu auras des tonnes d'erreurs dans les headers.

Le C ANSI sert plus à nous interdire les comments // qu'à autre chose.

En d'autres mots, il ne sert à rien.
Et de plus, les commentaires // sont du C standard ISO C99. Il faut se mettre à jour, le standard ISO C90 (ANSI C89) n'est plus depuis 4 ans.

Pour moi, le GNU C est une norme suffisante: pas chiante sur
des détails (//), permettant quelques *abus* qu'en fait tout le monde fait (les long long, utilisés aussi dans Visual C++).

Les long long sont aussi du C standard ISO C99.

Bon, si on voulait être Posix, là faudrait mettre -ansi.

Pas du tout. À part pour des programmes tordus qui utilisent par exemple du //* sans espaces et qui de toute façon arrêteront de marcher quand le C99 deviendra le mode par défaut des compilateurs, tous les programmes en C ISO/ANSI sont compilables sans switches particuliers.

Et d'ailleurs, -ansi tout seul ne suffit pas pour que GCC soit conforme au standard ANSI/ISO, il faut aussi mettre -pedantic ou -pedantic-errors (carrément pas supporté du tout par TIGCC, tu auras au moins une bonne centaine de warnings ou erreurs dans les headers).