probleme avec static inline

Version imprimable

31/05/2008, 14h44
deubelte

probleme avec static inline
Bonjour
Je cherche a compiler sous VC2005 un fichier source .c a la base programmé pour compiler en sous GCC, qui contient ce simple bout de code:
Code:

1 2 3 4 static inline void initialise(gsl_integration_workspace* workspace, double a, double b); }
quand ca compile, voici le message d'erreur qui apparait:
Code:

1 2 3 4 error C2143: erreur de syntaxe : absence de ')' avant '*' error C2143: erreur de syntaxe : absence de '{' avant '*' error C2059: erreur de syntaxe : 'type' error C2059: erreur de syntaxe : ')'
je pense que l'erreur vient du fait que VC2005 ne connait pas: static inline (c'est ce que j'ai compris d'apres mes recherces sur internet)
que puis-je faire pour convertir ce simple bout de code pour que VC2005 puisse le comprendre?
merci
31/05/2008, 15h12
Aurelien.Regat-Barrel

Je crois plutot que le probleme vient que inline n'existe pas en C, si ma memoire est bonne. Peut etre __inline...
31/05/2008, 15h48
deubelte

merci, j'ai essayé, mais ca donne tj la meme erreur.
peut etre faut il essayer un truc dans le style des extern, #IFDEFINe...
31/05/2008, 16h09
droggo

Peo,

Il faudrait un peu plus de code, car là, à voir ce que tu nous montres, tu as une accolade fermante qui n'a rien à faire ici (mais il faut voir le code précédent ce que tu as mis). :)

ben voila le code du fichier entier:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
/* integration/initialise.c
 * 
 * Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2007 Brian Gough
 * 
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation; either version 3 of the License, or (at
 * your option) any later version.
 * 
 * This program is distributed in the hope that it will be useful, but
 * WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
 * General Public License for more details.
 * 
 * You should have received a copy of the GNU General Public License
 * along with this program; if not, write to the Free Software
 * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
 */
static inline
void initialise(gsl_integration_workspace* workspace, double a, double b);
 
static inline
void initialise (gsl_integration_workspace * workspace, double a, double b)
{
  workspace->size = 0;
  workspace->nrmax = 0;
  workspace->i = 0;
  workspace->alist[0] = a;
  workspace->blist[0] = b;
  workspace->rlist[0] = 0.0;
  workspace->elist[0] = 0.0;
  workspace->order[0] = 0;
  workspace->level[0] = 0;
 
  workspace->maximum_level = 0;
}

ensuite ce fichier est utilisé par d'autres fichiers comme suit:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
 
#include <conssfig.h>
#include <stdlib.h>
#include <gsl_math.h>
#include <gsl_errno.h>
#include <gsl_integration.h>
 
 
#include "set_initial.c"
#include "qpsrt.c"
#include "util.c"
#include "initialise.c"....................

mais est-ce un problème de code ou de compilateur?

31/05/2008, 16h33
Davidbrcz

Ah !!!!!!!!!!!!!! Des inclusions de .c ! beurk.
Va revoir le principe de programmation modulaire.

Comment ca peut compiler sans donner des erreurs de multiples definitions ?
31/05/2008, 16h55
Emmanuel Deloget

L'erreur vient du fait que gsl_integration_workspace est inconnu, pas du static inline.

Regarde ta liste d'erreur de nouveau:
* error C2143: erreur de syntaxe : absence de ')' avant '*'
--> clairement, pour que le * lui pose problème, il faut qu'il y ait un problème avant
error C2143: erreur de syntaxe : absence de '{' avant '*'
--> idem
error C2059: erreur de syntaxe : 'type'
--> oh, serait-ce un problème de type ? Mais quel type est donc utilisé sur la même ligne ?

Je pense que tu as soit un problème de header guard, soit une erreur dans le nom du type (quelque part). En tout cas, le problème est là - 99% de chance ;)
01/06/2008, 08h19
deubelte

Oui, c'est cela. Tout ca vient de la GNU scientifique librairy. qui doit tourner sur GCC. Moi j'ai VC2005. J'ai du faire des modifications.
Notamment mettre les header ou est définit le type qui faisait planté la compilation.
01/06/2008, 11h54
zais_ethael

Je ne sais pas pour le reste, mais inline est bien supposé causer une erreur. Il s'agit d'une fonctionnalité du C99, supportée par GCC mais pas par Visual C++. Ce n'est pas la première fois que je vois une biblio ne pouvant compiler à cause de cette spécificité. Change le static inline en static et ça devrait aller un peu mieux.
01/06/2008, 17h14
Mat007
Salut,

C'est le même problème qu'ici et ce n'est pas le compilateur qui en est la cause mais le type non défini comme l'explique Emmanuel...
Manifestement tu n'es pas supposé compiler ce fichier directement mais compiler des fichiers qui eux l'inclus, en ayant au préalable inclus les .h qui vont bien (ceux qui commencent par gsl_ donc).
Alors oui, c'est pas très malin de la part de GSL d'avoir organisé leur code comme ça, mais il faut aussi réfléchir un peu 2 mn : si tu ne mets aucun include il n'y a aucune chance que tu puisses utiliser du code d'une bibliothèque externe (enfin sauf en passant par des precompiled headers, ok)...
Donc là rajoute déjà au début du fichier que tu as bidouillé quelque chose comme :
Code:

1 2 3 #include <gsl_math.h> #include <gsl_errno.h> #include <gsl_integration.h>
Après il y aura sans doute aussi un problème d'intégration de code C dans du C++ à régler, c'est sûr.

Cela dit comment as-tu compilé GSL à la base ? Avec Cygwin puisque ça semble être la seule plate-forme supportée sous Windows ?

MAT.
01/06/2008, 20h14
NiamorH
Citation:

Envoyé par Davidbrcz

Ah !!!!!!!!!!!!!! Des inclusions de .c ! beurk.
Va revoir le principe de programmation modulaire.

Comment ca peut compiler sans donner des erreurs de multiples definitions ?

Il m'est déjà arrivé d'inclure des .cpp lorsque je voulais rassembler des instanciations explicites de templates pour compiler une dll par exemple :
Code:

1 2 3 4 5 6 7 8 // IntanciationsExplicites.cpp #include <Moteur.cpp> #include <Renderer.cpp> template Moteur<Win32>; template Renderer<OpenGL>; template Renderer<DirectX>;
01/06/2008, 20h27
Davidbrcz

Bah dans ce cas on nomme pas son fichier en .cpp.
On le nomme en .tpl ou en ce que tu veux mais pas .cpp. Même si au final ca va rien chnager pour le pré-processeur, c'est "par principe".

Enfin bon, là ca m'étonerai qu'il travaille avec des templates, surtou qu'il bosse avec du C :D
01/06/2008, 21h34
NiamorH

Oui on peut tout à fait les nommer .tpl dans ce cas bien que je perde l'avantage de la coloration syntaxique que m'offre l'extension cpp ainsi que la complétion.

Deuxième inconvénient : dans l'exemple j'ai cru bon de regrouper les instanciations car elles se reportaient au même thème.
Si je n'ai qu'un seul template à instancier, je le fait directement dans le cpp qui contient l'implémentation, et là, il faut qu'il ait l'extension .cpp pour être compilé. Donc par cohérence, je garde partout .cpp.
01/06/2008, 21h45
Davidbrcz

Citation:

Oui on peut tout à fait les nommer .tpl dans ce cas bien que je perde l'avantage de la coloration syntaxique que m'offre l'extension cpp ainsi que la complétion.

Euh, ca osef un peu.Suffit de régler ton éditeur hein :aie:

Citation:

Deuxième inconvénient : dans l'exemple j'ai cru bon de regrouper les instanciations car elles se reportaient au même thème.
Si je n'ai qu'un seul template à instancier, je le fait directement dans le cpp qui contient l'implémentation, et là, il faut qu'il ait l'extension .cpp pour être compilé. Donc par cohérence, je garde partout .cpp.

Là je comprend très bien.
01/06/2008, 22h41
NiamorH

Peut-être qu'il existe aussi une option dans le projet qui dirait de compiler les tpl comme des cpp, mais ça devient moins portable comme solution.
01/06/2008, 23h20
NewbiZ

C'est à ca que servent .inl et .hxx :)
02/06/2008, 09h17
deubelte

merci pour les rep

Citation:

Cela dit comment as-tu compilé GSL à la base ? Avec Cygwin puisque ça semble être la seule plate-forme supportée sous Windows ?

Non avec visual 2005. Bien sur, j'ai du bidouiller l'ensemble du code. Mais ca fonctionne. Au depart, c'est fait pour etre compiler sur GCC et comme il y a des trucs qui ne fonctionnennt pas sous Visual 2005, je suis obligé de manipuler le code. Notamment "inline".
Mais je n'ai pas compiler GSL, seulement certains fichiers de GSL.

Puisqu'on parle de .cpp/.c, quel sont les risques si dans un projet C++ sous VC2005, on melange des fichiers cpp et .c?
02/06/2008, 10h05
Médinoc

Je dirais aucun risque si c'est fait correctement (extern "C", pas de code C dans les fichiers .cpp, pas de code C++ dans les fichiers .c...)
03/06/2008, 06h42
Aurelien.Regat-Barrel

Citation:

Envoyé par NiamorH

Il m'est déjà arrivé d'inclure des .cpp lorsque je voulais rassembler des instanciations explicites de templates pour compiler une dll

Je vois pas trop le rapport avec une dll. Les templates et les dlls se marient mal.
Les instanciations explicites de template, en general, c'est mauvais signe. Le code de ton template doit etre dans le .h, c'est pas top, mais c'est ainsi (tant que export n'est pas plus largement supporte).
Tu peux le mettre dans un .tpp que tu inclus a la fin du .h (voir FAQ), mais au final, le code de ton template doit etre inclus en totalite via le .h.
03/06/2008, 08h05
NiamorH

C'est pas mauvais signe, c'est juste très rare. Qui dit template ne dit pas "doitforcémentmarcherpourni'mportequeltypeutilisateur". On pense parfois un template pour deux ou trois types bien identifiés. Rien n'empêche alors de ne proposer que ces types au moment du link. L'instanciation explicite est l'outil qui permet de faire cela en laissant toute l'implémentation du template hors du .h et les DLL s'en portent à merveille.

Tu vois il est peu probable qu'un développeur ait un jour l'idée d'écrire Renderer<int>. Une classe template, une fois instanciée pour un type, n'est rien d'autre qu'une classe normale. A partir de là, tout est possible, DLL inclues.
03/06/2008, 13h19
Aurelien.Regat-Barrel

Je suis d'accord que tu peux utiliser les templates comme maniere de factoriser du code dans tes implementations. Mais cela releve du detail d'implementation a mon avis, et ne devrait pas etre expose publiquement.

Le cas typique du renderer qui est implemente de differentes manieres (OpenGL/DirectX) est de passer par une classe abstraite Renderer et une factory qui instancie l'une ou l'autre implementation. Ces implementations peuvent alors reposer sur un template interne, prive.

Concernant les dlls, si j'ai bien compris, tu exportes une instanciation explicite de template (dis moi si je me trompe). C'est super pas portable / limité / risqué. Les template ne sont pas faits pour traverser les frontieres d'un module compilé, telle une dll. Ils ne devraient pas faire partie de leur interface.
03/06/2008, 16h14
NiamorH

Qu'est ce qui pourrait poser problème, dis-moi ? Il y a déjà eu un sujet la dessus : http://www.developpez.net/forums/sho...d.php?t=507420
07/06/2008, 14h27
Aurelien.Regat-Barrel

En ce qui me concerne, il y a plusieurs points "conceptuels" qui me genent sur cette utilisation des templates. J'ai tendance a me demander si on ne devie pas de leur sens premier et si on ne pourrait pas faire au moins aussi bien avec une approche non template.

Je veux bien admettre qu'il existe des cas astucieux, mais je n'arrive pas a les trouver par moi meme. Je ne vois pas l'interret de cette approche par rapport a une approche classique a base de classe abstraite de base.

Ce que je vois c'est que si l'utilisateur est un novice du C++, et qu'il instancie ton template avec un mauvais type, il va se payer une erreur de link au lieu d'une erreur de compilation. C'est le premier point qui me gene.

Ensuite, de mon experience personnelle, au travail, ce genre de pratique remplace les erreurs de compilation par des erreurs de link totalement incomprehensibles par beaucoup de monde.
Parce que dans l'etat actuel des choses, en C++, il n'est pas possible de facilement restreindre de type donne au template, il est facile d'ecrire Renderer<float> et n'avoir aucune erreur, de compilation j'entends. Aussi je ne comprends pas l'interret de:
- exporter un template Renderer<> avec un type DirectX et OpenGL
- face a exporter 2 classes RendererOpenGL et RendererDirectX, qui en interne eventuellement sont implementees via un heritage de template.

Dans mon dernier job, il y avait ainsi une quarantaine de classes declarees comme des typedefs de templates, et dans un gros fichier .cpp, on avait le body des templates et la liste des instanciations explicites, et la liste des specialisations de fonctions membres pour quelques unes de ces classes, parce que bien sur les templates de base ne pouvaient pas etre assez generalistes pour toutes les classes en question. Quand on ajoutait une nouvelle classe, il fallait l'instancier explicitement dans ce gros cpp, puis eventuellement specialiser pour son type certaines fonctions membres. :?

En bref, je trouve que c'est de la magouille, de la magouille qui n'apporte - d'apres ma courte experience - rien par rapport a une approche "conventionnelle" avec classe de base et redefinition de fonction virtuelles dans les classes derivees.

Ensuite, toujours d'apres mon experience, et pour en revenir sur le point initial de mon message comme quoi les templates se marrient mal avec les interfaces exportees d'une, c'est que le risque de violer la "One Definition Rule" est eleve, surtout si tu utilises la STL ou autre.

Dans mon cas, j'exportais une classe non template qui, au sein de ses membres private, contenait un std::vector. Entre la dll contenant l'implementation et le code client compile (chacun instanciant son propre std::vector => violation de l'ODR), il y avait une difference dans les flags du proprocesseur afin de desactiver les warning de depreciation de VC++ dans un cas, a savoir _SECURE_SCL je crois. Ce que je ne savais pas, c'est que ce flag en interne de std::vector modifie la structure du template et de ses iterator. Et j'avais droit a une jolie corruption memoire en release, un truc tordu que j'avais mis 2 jours a trouver :aie:

Plus d'infos:
http://www.unknownroad.com/rtfm/Visu...ningC4251.html