[Résolu] Clang ne trouve pas std::shared_ptr (pb avec C++11)

Misc (Admin Only) Développement technique
1

Salut 4ian,

J’ai un gros problème : je compile mon extension avec MinGW et ça marche. Elle a besoin de std::shared_ptr.
Mais dès que GD compile le jeu avec mon extension qui a besoin de std::shared_ptr, ça bug en disant :

In file included from C:\Users\Victor\AppData\Local\Temp/GDTemporaries/0x6f3ff18events.cpp:3: Extensions/include/Widgets/ScaleObject.h:199:14: error: no type named 'shared_ptr' in namespace 'std' std::shared_ptr<sfg::Scale> obj; ///< shared ptr to SFGUI widget ~~~~~^ Extensions/include/Widgets/ScaleObject.h:199:24: error: expected member name or ';' after declaration specifiers std::shared_ptr<sfg::Scale> obj; ///< shared ptr to SFGUI widget ~~~~~~~~~~~~~~~^

Je parie que vu que Clang n’est pas configuré pour le C++11, il ne trouve pas cela…
C’est assez embêtant car j’ai aucun moyen de contourner cela… :frowning:

Une solution serait de lancer Clang avec l’option --std=c++0x, après je ne sais pas si cela va poser des problèmes de compatibilité.
Est-ce possible ?

Si ce n’est pas possible, je serais obligé de revenir à une ancienne version de SFGUI avec Boost. Mais, le gros avantage de ne plus utiliser Boost au profit de la nouvelle norme est le temps de compilation et le poids de l’exécutable (la dll de sfgui est 2 fois moins lourde par exemple 3 Mo → 1.5Mo)

Merci d’avance.

2

Les fichiers headers auxquels GD a accès quand il compile les évènements ( c’est à dire en gros ceux des objets et ceux déclarant les fonctions utilisées par les actions/conditions ) doivent être le plus léger possible afin de garantir un temps de compilation pas trop énorme.
C’est à dire que hormis :
-Quelques headers de SFML assez courant
-Les headers de Boost
-Les headers standards
-Et ceux de GD

Il vaut mieux éviter d’introduire trop de fichiers headers, en privilégiant les déclarations anticipées de classe ( class MaClasse; plutôt que #include “MaClasse.h” ( Ce qui implique que MaClasse est utilisé uniquement sous forme de référence ou de pointeur dans le fichier header ) ), et éviter au maximum les fichiers headers de d’autres bibliothèques.

Une solution peut être de passer par une sorte de classe “Wrapper” : Ta classe Wrapper contient tout plein de chose compliquées utilisant tout ce que tu veux, et dans la classe de ton objet, tu utilise uniquement un pointeur intelligent vers Wrapper, ce qui permet d’avoir juste une declaration anticipée de Wrapper et non pas tous les includes nécessaires à Wrapper. ( Une sorte de Pimpl idiom : paccalin.info/serge/pimpl.html ).

Bon, le truc c’est que tout ça complique un peu les choses, donc tu est sûr de pas pouvoir utiliser Boost ?
Au moins uniquement du “coté” des choses déclarées à GD. Tu peux utiliser tout le C++11 que tu souhaite dans sfGui ou dans ton extension tant que tu n’en montre pas la moindre goutte à GD ( et donc à Clang ).

3

je peux pas du tout utiliser Boost étant donné que SFGUi utilise elle-même les std::shared_ptr. :wink:
Précision, les widgets doivent être stockés sous forme de std::shared_ptrsfg::Scale dans la cas d’un widget “glissière”.
Est-ce possible de stocker n’importe quel widget (hérité de sfg::Widget) dans un std::shared_ptrsfg::Widget parce que ce n’est pas un vrai pointeur en soit ?

Mais, je vais tester ton idée tout de suite, mais c’est dommage que je ne puisse pas utiliser les templates (pour faire un wrapper qui stocke une classe particulière). A la place, je vais devoir utiliser le dynamic_cast pour ravoir le bon widget.

EDIT :

J’avais pensé à ça comme Wrapper :

[code]#ifndef WIDGETWRAPPER_H
#define WIDGETWRAPPER_H

#include “SFGUI/Scale.hpp”
#include “SFGUI/Entry.hpp”
#include “SFGUI/Button.hpp”

class WidgetWrapper
{
public:
WidgetWrapper(std::shared_ptrsfg::Widget&); // le constructeur fait obj = le 1er paramètre du contructeur;

    std::shared_ptr<sfg::Widget>& get() {return obj;};

private:
    std::shared_ptr<sfg::Widget> obj;

};

#endif[/code]

Est-ce que ça marchera ?
J’ai un doute, je peux utiliser les template pour ma fonction get() ?

EDIT : Ca marche avec un classe template ! Merci de ton aide 4ian ! :smiley:

4

C’est pas idiot ça. :slight_smile:
Mais le principal en tout cas est bien de “cacher” les détails à GD, pour qu’il ne voit que le plus simple. :slight_smile: