Problème de définition d’appel function avec StormC

[Gofromiel]

Gofromiel

#889

Bonjour à tous. Dans la série : “j’adore mon compilateur mais comme je connais pas les autres je les essai et je me mords les doigts”, voilà mon dilème:

J’ai une fonction dans ma bibliothèque qui s’appelle “F_CreateClassA(struct TagItem *TagList)” et sa version va-arg “F_CreateClass(…)”. Mais apparement, ce cher StormC ne veut rien savoir de “(…)” pour lui, il y a un problème.

J’ai réussi à le tromper en mettant un paramètre bidon en plus : “F_CreateClass(ULONG dummy,…)” et en modifiant également la ligne “#pragma tagcall(FeelinBase,0x144,F_CreateClass(d0,a0))” et là, au miracle ça marche. Alors, de deux choses l’une : soit ça ne se fait pas d’utiliser “(…)” et SASC est bien gentil de me l’accorder, soit StormC ne sait plus ou sont ses pieds à force de faire sa tempète (storm… oui, c’est moyen ).

Y aurait-il quelqu’un dans l’assistance assez aimable pour me venir en aide ? J’ai passé la nuit dessus… là il est 10H05 et faut que je sorte acheter une cravate… c’est drôle la vie

MERCI !

[stan]

stan

#23731

Il est effectivement illégal (d’après le K&R) de créer une fonction à nombre d’arguments variable n’ayant aucun argument nommé.

Si tu regardes les macros servant à accéder aux arguments non nommés d’une telle fonction (va_start, etc., dans stdarg.h), tu verras qu’elles ont besoin d’un argument nommé pour accéder aux arguments non nommés.

[hybrid]

hybrid

#23732

Sinon, juste pour info, Storm est un IDE pas trop mal foutu mais c’est un compilo assez buggé (en mode Storm) et c’est une assez mauvaise adaptation de GCC en mode GCC.

Pour exemple, mon code qui compile sous StormC 4 en mode GCC refuses de compiler sous GCC avec le SDK de MOS …

Bon, je suis pas un dieu du code et doit y’avoir pas mal de chose qui horrifierait n’importe quel “vrai” codeur qui se respecte mais bon, c’est pour montrer que Storm GCC, c’est pas GCC tout court …

En plus, Storm ne permet que de compiler pour Classic et WarpOS ce qui en limite sérieusement son intérêt.

Actuellement, les 2 seuls compilos C/C++ capables de porter sans trop de douleurs d’un système à l’autre sont VBCC et GCC.

[Gofromiel]

Gofromiel

#23733

Flute alors ! Il me reste plus qu’à modifier ma fonction…

Je n’ai pas encore mis mes petits doigts sur GCC, mais après avoir essayé StormC et vbcc, j’ai vraiment l’impression que SAS/C est une merveille (dommage pour le PPC…). Par ailleurs, est-ce possible de créer un équivalent des Global Symbol Table (GST) avec vbcc ?

[stan]

stan

#23734

Je ne connais pas les GST… (ni SAS/C). Mais si c’est pour ta lib partagée, tu auras peut-être des infos dans CLib-SDI ou CLib37x sur Aminet… (hum, je suppose que tu as déjà récupéré CLib-SDI.. mais on sait jamais.)

[Gofromiel]

Gofromiel

#23735

@Stan: la GST de SAS/C c’est un peu les Modules du E, sauf que tu peux mettre TOUS tes includes dans une seule GST, ou varier les plaisir en créant une GST générale, une GST typique à une application, une pour la détente ou encore pour la pétanque. C’est super pour les ptis Migas, comme ça ils ont pas à lire 1000 fichiers d’includes à chaque compilation, tout est en sécurité et bien rangé dans un seul fichier.

/me: toujours prêt à expliquer des trucs

[gindrou]

gindrou

#23736

MorphOs sait exécuter du code PPC PowerUP.

Vu que SASC sait compiler dans ce code, je ne m’emmerde pas avec les autres compilateurs.

Il n’est pas aussi bogué que certains l’affirment.

J’ai seulement décelé qu’un gros bogue dans le nombre d’argument en entrée.

Maintenant si tu parviens a recompiler tes programmes, je suis tout ouïe.

[corto]

corto

#23737

gindrou a écrit :

MorphOs sait exécuter du code PPC PowerUP.

Il n’est pas aussi bogué que certains l’affirment.

J’ai seulement décelé qu’un gros bogue dans le nombre d’argument en entrée.

Il n’a pas dû être très éprouvé … et vu la qualité de l’émulation 68k sur PPC, je ne suis pas certain que ce soit une bonne idée de faire générer du code PowerUP par SAS/C.

Gofromiel : Je ne comprends pas trop ta position. Tu encenses SAS/C mais tu utilises StormC tout en regrettant de ne pas pouvoir générer du code PPC …

Si tu envisages coder sur PPC, essaie de programmer dans un style standard avec les compilateurs correspondants, à savoir GCC ou VBCC (chacun leurs qualités).

[Gofromiel]

Gofromiel

#23738

Ma position ? Ben, j’essaie juste que mon projet soit utilisable par un maximum de gens sans qu’ils se prennent la tête (je me la prend à leur place).

vbcc me donne plein de fil à retordre, il est vraiment TRES pénible ! Ca compile sans le moindre avertissement avec SAS/C, DICE et StormC. Mais vbcc n’arrête pas de se plaindre. Il y a des choses que je ne comprends pas:

mes protos dans clib

...

void F_DisposeObj(FObject Obj);

...

mon application:

FObject app;

app = ApplicationObject

...

F_DisposeObj(app);

...

Compilation:

F_DiposeObj(app);

warning 85 : assignment of different pointers

Si on pouvait m’expliquer le problème exactement. Parce que là je vois pas où il se trouve ? Je vais essayer GCC tanto on verra ce qu’il me reprochera Ô joies de la programmation !

[stan]

stan

#23739

J’imagine que VBCC a une bonne raison de te dire ça, mais là avec ce que tu as pasté je ne peux pas dire . Si tu utilises des inlines, il y a peut-être un problème à ce niveau. Ou alors c’est lié à la définition de FObject… qui sait.