Implémentation du C++11 ?

[rafoudiablol]

Salut !

Quand je dis C++11, je pense surtout aux constructeurs de mouvement: pour les classes lourdes, nottement sf::Image, il serait utile d'y ajouter cette fonctionalité.

Après il doir y avoir une raison pour laquelle ce n'est pas encore fait... Une volonté de compiler sur un maximum de configurations, sans doute ?
Il serait possible avec __cplusplus d'écrire un code générique, avec une compatibilité qui ne serait que meilleur 

Je trouverais assez superflu de recompiler la SFML pour ça, ce qui au contraire empêcherait une compatibilité des binaires de la lib

Merci !


PS: non ce n'est ni pour le fun ni le lolz, quand des fabriques renvoient des Images ça fait assez mal 

[Lynix]

Je trouverais assez superflu de recompiler la SFML pour ça, ce qui au contraire empêcherait une compatibilité des binaires de la lib

Ce que tu demandes à Laurent c'est de distribuer des binaires C++03 et des binaires C++11 ? Je doute qu'il accepte

[Laurent]

https://github.com/SFML/SFML/issues/129

[rafoudiablol]

Non, justement les binaires C++11 ont une compatibilité ascendante avec pe C++03 il me semble
- La SFML peut être compilée en C++11
- et les headers fournissent ou non le prototype de constructeur de mouvement si le C++11 est activé

Édit: exactement Laurent 
Est-il possible d'aider au développement de la SFML ?

[Laurent]

Est-il possible d'aider au développement de la SFML ?

Bien entendu. Le plus simple c'est de forker sur github, et de soumettre des pull requests quand t'as quelque chose à proposer. Mais attention je suis très pointilleux quant aux contributions

[rafoudiablol]

Ok tant mieux, la SFML doit rester ce qu'elle est.
Je vais voir les features de suite

[rafoudiablol]

Ce que tu demandes à Laurent c'est de distribuer des binaires C++03 et des binaires C++11 ? Je doute qu'il accepte

Non, c'est ça qui est marrant: ce qui est possible, c'est de compiler la SFML en C++11 et de laisser le choix à l'utilisateur d'utiliser les nouvelles fonctionalités ou non (ou tout simplement parce que son compilateur ne le supporte pas).

Un petit exemple rapide. Laurent, tu me dis si un pull qui ressemblerai à ça serait accepté

Imaginons que je compile ma librairie libtest.so pour supporter ET le C++11 ET les anciennes versions. Voilà le contenu des fichiers:

Test.hpp

#ifndef TEST_HPP
#define TEST_HPP

struct Test
{
        Test();
        ~Test();
        Test(const Test&);
        Test& operator=(const Test&);

        #ifdef USE_RREF // aha!
                Test(Test&&);
                Test& operator=(Test&&);
        #endif
};

#endif // TEST_HPP
 

Test.cpp

#include <iostream>
#include "Test.hpp"

using namespace std;

Test::Test()
{
        cout << "default constructor" << endl;
}

Test::Test(const Test&)
{
        cout << "copy constructor" << endl;
}

#ifdef USE_RREF // re- aha!

        Test::Test(Test&&)
        {
                cout << "move constructor" << endl;
        }

#endif

Test::~Test()
{
        cout << "destructor" << endl;
}

Test& Test::operator=(const Test&)
{
        cout << "operator= copy" << endl;
        return *this;
}

#ifdef USE_RREF

        Test& Test::operator=(Test&&)
        {
                cout << "operator= move" << endl;
                return *this;
        }

#endif
 

Ici, on peut choisir de supporter au non les constructeurs de mouvement.
Compilons la lib avec ce nouveau support (sans oublier d'utiliser C++11  ):

g++ -shared Test.cpp Test.hpp -DUSE_RREF -std=c++11 -o libtest.so
 

Après, le code utilisateur pourra choisir d'utiliser les nouvelles fonctionalitées ou non:

main.cpp

#include <Test.hpp>
#include <iostream>

using namespace std;

int main()
{
    Test t1;
    t1 = Test();

        return 0;
}
 

me:~/projects/tests$ mv libtest.so ~/home/me/bin
me:~/projects/tests$ g++ main.cpp -I. -L/home/me/bin -ltest -o sans_rvalue
me:~/projects/tests$ g++ main.cpp -I. -L/home/me/bin -ltest -o avec_rvalue -std=c++11 -DUSE_RREF
me:~/projects/tests$ ./sans_rvalue
default constructor
default constructor
operator= copy
destructor
destructor
me:~/projects/tests$ ./avec_rvalue
default constructor
default constructor
operator= move // Le constructeur de copie n'est ici plus utilisé
destructor
destructor
 

Et avec la seule librairie compilée en C++11 
Après il peut être encore meilleur de détecter automatiquement si le compilateur supporte les nouvelles fonctionalités désirées, sans que l'utilisateur n'ai rien à définir

[Laurent]

Non, c'est ça qui est marrant: ce qui est possible, c'est de compiler la SFML en C++11 et de laisser le choix à l'utilisateur d'utiliser les nouvelles fonctionalités ou non (ou tout simplement parce que son compilateur ne le supporte pas).

Oui alors attention, tout n'est peut-être pas compatible binairement parlant. Imagine que tu changes la taille d'une classe en activant ou non une fonctionnalité C++11, là tu ne pourras plus utiliser le même binaire pour les deux standards. Et il y a beaucoup de façons vicelardes de casser la compatibilité binaire.

Mais c'est pas vraiment un souci, je vais utiliser le standard que le compilo supporte par défaut. Seuls les gens qui changent explicitement de standard (via -std= pour gcc) auront potentiellement des soucis de compatibilité, et devront recompiler SFML.

Laurent, tu me dis si un pull qui ressemblerai à ça serait accepté

A vrai dire, j'aimerais assez m'occuper de ça moi-même. Il est important que je maîtrise les nouveautés C++11 qui sont ajoutées à SFML -- ce qui n'est pour l'instant pas le cas à 100%.

[rafoudiablol]

Ha tu me pose une colle là 

Dans le cas d'une lib, toutes les données ne sont pas déja codées, notamment la taille de la classe ?
Dans l'exemple que j'ai donné, on ne fait que masquer une fonction (elle existe toujours) pour éviter une insulte du compilo...
Je ne pense pas que ça change qqc pour les binaires je n'ai eu à ce jour aucun problème avec la SFML en C++11. C'aurait été pour le moins ennuyeux si chaque lib aurait dû être recompilée pour la nouveau standard
Après tout on ne retire ou n'ajoute jamais du contenu à la classe, on ne fait que masquer ou démasquer une fonctionnalité.

Après c'est ces rvalues références là principale nouvelle fonctionnalité, il ne s'agit pas de récrire la SFML
Un bon lien: http://www.cprogramming.com/c++11/rvalue-references-and-move-semantics-in-c++11.html, et développez.com possède de bons topics la dessus.
Il ne s'agit que de "voler" le contenu d'une variable temporaire sans plus avoir besoin de copier quoi que ce soit

Après pour les améliorations interne à la SFML (.cpp), il peut être utile d'utiliser les nouveaux headers qu'offre le C++11: random, chrono par exemple.
Mais c'est une autre histoire

[Laurent]

ans le cas d'une lib, toutes les données ne sont pas déja codées, notamment la taille de la classe ?

Justement, c'est ça qui pose problème. Car toi quand tu vas compiler ton programme, tu vas avoir potentiellement une taille différente pour la même classe, si tu as des optons de compilation différentes. C'est notamment pour ça que les binaires debug et release ne peuvent pas être mélangés avec Visual C++.

Là on ne fait qu'ajouter une fonction, mais on peut imaginer d'autres genres de modifications qui cassent la compatibilité binaire. Imagine, par exemple, que j'utilise std::thread au lieu de sf::Thread quand ce premier est dispo : ça va changer la définition de la classe de laquelle le thread est membre, et boum. Bon évidemment je ne vais pas faire ce genre de choses, mais c'est juste pour dire que ce n'est pas trivial d'assurer une compatibilité binaire.

[rafoudiablol]

Oui si on change un attribut entre le header et la source ça peut poser des soucis... Je ne pense pas que ce passerait à l'édition des liens.
Car une fois cette étape passée, je ne suit pas sûr qu'un bug soit possible.

Et dans ce cas, du moins pour les constructeurs de mouvement, il n'y aucune modification: la fonction est juste masquée quand l'option n'est pas supportée.
L'implémentation de ceci serait une première étape au support du C++11, sans risque

Pour le problème que tu pose (qui ne concerne heureusement pas l'implémentation exemple du post d'avant ),  il faudrait tout simplement éviter de jongler avec les types. Toute utilisation de la bibliothèque du c++11 devrait se passer dans l'interne de la sfml, uniquement. Ça me changerais rien pour l'utilisateur, qui passera dans tous les cas par le code c++11 compilé de la SFML. Heu oui ça n'ajoute pas grand chose...

Mais le plus important pour moi serait de fournir une interface c++11 pour ceux qui le souhaitent, ce qui peut être fait avec les rvalue références.
Les anciennes fonctions n'en seraient alors aucunement modifiées

Pour savoir si c'est possible, la SFML est elle compilée avec le nouveau standard ?

[Lynix]

Mon message était écrit avec les binaires incompatibles en tête.

Alors oui, il est possible de compiler en C++11 et d'utiliser en C++03, en restreignant de beaucoup.
Comme Laurent l'a indiqué, la taille de la classe ne doit pas changer, mais il n'y a pas que ça.

Un jour j'ai compilé une classe avec une méthode que j'enlevais du header lors de l'utilisation, j'ai eu les pires bugs de ma vie et n'ait plus jamais recommencé.

Bon après, comme je n'ai tenté le coup qu'une fois, je ne peux pas trop l'affirmer, c'était sans doute lié aux vtable (la méthode en question était virtuelle).

Mais bon, une telle compatibilité binaire ne fait pas partie du standard à ma connaissance, autrement dit c'est jouer avec le feu pour pas grand chose.

D'ailleurs aucune compatibilité binaire ne fait partie du standard

[Laurent]

Oui si on change un attribut entre le header et la source ça peut poser des soucis... Je ne pense pas que ce passerait à l'édition des liens.
Car une fois cette étape passée, je ne suit pas sûr qu'un bug soit possible.

Je pense que tu as mal compris ce que j'ai expliqué

Comme on n'a pas d'exemple concret avec du C++11, je vais utiliser un exemple qui montre le problème entre binaires debug et release avec Visual C++, et qui est exactement le même problème.

Imagine une telle classe :

class Blop
{
    std::vector<int> v;
};

Assez anodine en apparence.

Mais si tu regardes la définition de la classe std::vector, tu vois un truc dans ce genre (ne prends pas ça à la lettre, c'est pour illustrer):

template <typename T, typename Allocator = std::allocator<T> >
class vector
{
#ifdef _MACRO_DE_DEBUGGING_ALACON
    Pouet debug_data;
#endif

    T* data;
    size_t size;
};

Ensuite tu compiles ta bibliothèque en release: la classe Blop est donc composée d'un vecteur lui-même composé d'un pointeur et d'une taille. sizeof(Blop) == 8 (sur architecture 32 bits). En outre, pour accéder au membre "data" du vecteur, le compilateur applique un offset de 0 sur "this".

Puis, tu utilises cette bibliothèque mais en mode debug. Du coup le compilateur prend la définition du vecteur contenant les debug_data, et du coup sizeof(Blop) > 8. En outre, pour accéder au membre "data" du vecteur, le compilateur applique un offset de sizeof(Pouet) sur "this".

Puis vient l'étape finale : tu crées un Blop via ton code, puis refourgue son adresse à ta bibliothèque. Comme c'est ton code qui l'a créé, il a un membre debug_data et son pointeur vers les données se trouve à l'offset sizeof(Pouet). Mais comme ta lib a été compilée avec une version de std::vector dont le pointeur se trouve à l'offset 0... lorsque ta lib utilise cette instance de Blop... ça pète, elle accède en réalité à des bits appartenant à "debug_data".

Voilà

[rafoudiablol]

Ce problème se pose si la classe compilée avec des options différentes peut avoir plusieurs tailles différentes, c'est bien ça

Or les méthodes ne sont pas elles pas stockées de façon linéaire dans le code: leur résolution est faite selon la table contenant le nom de la fonction, qui n'influt pas sur le bytecode en mémoire de l'objet
Donc retirer le prototype de la fonction ne fait que empêcher que la résolution de celle ci.
Ou je me trompe.... Je viens de remarquer que j'utilise la sfml release dans du code compilé en debug ! C'est donc une erreur, mais je n'avais remarqué aucun bug

Lynix, ton problème était un bug de quel ordre: Corruption de la mémoire ou tout simplement les appels de mauvaises fonctions ? ça mérite des tests tout ça
Mais il n'y a pas une compatibilité ascendante garantie par la norme entre les différentes versions du C++ ?

[Laurent]

Là on ne fait qu'ajouter une fonction, mais on peut imaginer d'autres genres de modifications qui cassent la compatibilité binaire.

Oui oui, comme je l'ai déjà dit pour cet exemple en particulier ça ne pose aucun problème. Mais on ne peut pas généraliser.

Je viens de remarquer que j'utilise la sfml release dans du code compilé en debug ! C'est donc une erreur, mais je n'avais remarqué aucun bug

A priori ça ne pose problème qu'avec Visual C++ (et si tu as des classes de la lib standard dans tes classes publiques). Les autres compilateurs sont suffisamment intelligents pour garder la même définition des classes standards quelque soient les options de compilation.

Mais il n'y a pas une compatibilité ascendante garantie par la norme entre les différentes versions du C++ ?

Compatibilité de l'API, bien entendu. Mais tout ce qui est binaire, c'est l'histoire du compilo, la spécification du langage n'a rien à voir avec ça. Chaque compilo fait sa propre sauce quand il s'agit de compiler et lier du C++.