1
Suggestions de nouvelles fonctionnalités / Re : Implémentation du C++11 ?
« le: Mai 02, 2013, 12:07:25 am »
Donc ça reviendrait à compiler la SFML en C++11, sauf si tu veux distribuer des binaires spécifiques à son support 
Voir les contributions
Cette section vous permet de consulter les contributions (messages, sujets et fichiers joints) d'un utilisateur. Vous ne pourrez voir que les contributions des zones auxquelles vous avez accès.
Pages: [1] 2 3 Suivante »
2
Suggestions de nouvelles fonctionnalités / Re : Implémentation du C++11 ?
« le: Mai 01, 2013, 01:30:21 pm »
Ajouter conditionnellement le support du C++11 ? Mais donc la sfml restera compilée en C++04.
Donc les ajouts se situeront au niveau des headers
Ou alors rajouter des sources qui seront compilées dans le code client, mais ça ne serait pas très élégant.
Donc les ajouts se situeront au niveau des headers
Ou alors rajouter des sources qui seront compilées dans le code client, mais ça ne serait pas très élégant.
3
Discussions générales / Re : SFML 2 est là avec son nouveau site web
« le: Mai 01, 2013, 03:18:48 am »
Bravo
*applaudit
La version 2.0 utilise toujours GLEW 1.7 ?
*applaudit
La version 2.0 utilise toujours GLEW 1.7 ?
4
Suggestions de nouvelles fonctionnalités / Re : Implémentation du C++11 ?
« le: Avril 29, 2013, 07:44:02 pm »
Les moves constructors seraient d'une grande utilité (une fois qu'on commence à les utiliser on s'en passe plus 
), et assez facile à implémenter.
Je n'ai pas vu de pull request concernant le C++11, il pourrait être sympa d'essayer de commencer sans l'y intégrer tout de suite dans la SFML
Aucun rapport, mais bravo pour le nouveau site de la SFML
), et assez facile à implémenter.Je n'ai pas vu de pull request concernant le C++11, il pourrait être sympa d'essayer de commencer sans l'y intégrer tout de suite dans la SFML
Aucun rapport, mais bravo pour le nouveau site de la SFML
5
Suggestions de nouvelles fonctionnalités / Re : Implémentation du C++11 ?
« le: Avril 29, 2013, 01:55:14 pm »
Ok si j'ai bien compris les nouvelles fonctionnalités devront être ajoutées dans les headers, du moims le code "externe" de la SFML
Merci
Merci
6
Suggestions de nouvelles fonctionnalités / Re : Implémentation du C++11 ?
« le: Avril 29, 2013, 01:23:37 pm »
Oui c'est pour ça que les libs statiques sont distribuée pour les différents compilos.
Donc serait il possible de passer la compilation SFML au C++11 ?
On pourrait appliquer l'idée en faisant attention à tout ça
PS: faute de frappe dans le précédent post, *dans et non "sans".
Donc serait il possible de passer la compilation SFML au C++11 ?
On pourrait appliquer l'idée en faisant attention à tout ça
PS: faute de frappe dans le précédent post, *dans et non "sans".
7
Suggestions de nouvelles fonctionnalités / Re : Implémentation du C++11 ?
« le: Avril 29, 2013, 12:49:09 pm »
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++ ?
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++ ?
8
Suggestions de nouvelles fonctionnalités / Re : Implémentation du C++11 ?
« le: Avril 28, 2013, 11:26:45 pm »
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 ?
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 ?
9
Suggestions de nouvelles fonctionnalités / Re : Implémentation du C++11 ?
« le: Avril 28, 2013, 10:27:07 pm »
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
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
10
Suggestions de nouvelles fonctionnalités / Re : Implémentation du C++11 ?
« le: Avril 28, 2013, 07:50:37 pm »Citer
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
#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
#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;
}
#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
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
11
Suggestions de nouvelles fonctionnalités / Re : Implémentation du C++11 ?
« le: Avril 28, 2013, 02:32:42 pm »
Ok tant mieux, la SFML doit rester ce qu'elle est.
Je vais voir les features de suite
Je vais voir les features de suite
12
Suggestions de nouvelles fonctionnalités / Re : Implémentation du C++11 ?
« le: Avril 28, 2013, 02:16:25 pm »
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 ?
- 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 ?
13
Suggestions de nouvelles fonctionnalités / Implémentation du C++11 ?
« le: Avril 28, 2013, 12:43:29 pm »
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
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
14
Général / Re : SFML sans glew 1.7?
« le: Avril 23, 2013, 07:33:34 pm »
Ok merci !
Enfin pour la licence y a t il une restriction si je distribue un programme avec la version de la sfml recompilée?
Bon ben super je vais réviser mon anglais, et j'irais faire un petit tour sur l'autre forum !
Enfin pour la licence y a t il une restriction si je distribue un programme avec la version de la sfml recompilée?
Bon ben super je vais réviser mon anglais, et j'irais faire un petit tour sur l'autre forum !
15
Général / Re : SFML sans glew 1.7?
« le: Avril 17, 2013, 10:35:27 am »
La recompilation utilisera automatiquement ma version de glew?
J'espère qu'il n'y pas de prob de compatibilité entre la 1.7 et la 1.8/1.9
Merci de ta réponse rapide
Je me demandaisaussi, (complètement hs) pourquoi la SFML officielle reste à la 1.6 ? J'ai l'impression que le site n'est plus maintenu (ce que j'espère n'est qu'une impression ^^)
J'espère qu'il n'y pas de prob de compatibilité entre la 1.7 et la 1.8/1.9
Merci de ta réponse rapide
Je me demandaisaussi, (complètement hs) pourquoi la SFML officielle reste à la 1.6 ? J'ai l'impression que le site n'est plus maintenu (ce que j'espère n'est qu'une impression ^^)
Pages: [1] 2 3 Suivante »