-
Salut, j'ai fait un test avec du code, mais j'ai toujours un caractère en trop au début du paquet que j'envoie, voici ce que je fait dans la fonction onSend :
const char* datas = static_cast<const char*> (getData());
buffer.assign(datas, datas + getDataSize());
vector<char>::iterator it;
string message;
for (it = buffer.begin(); it != buffer.end(); it++)
message += *it;
cout<<"Message : "<<message<<endl;
for (unsigned int i = 0; i < message.size(); i++)
buffer.push_back(message.at(i));
dataSize = buffer.size();
return &buffer[0];
Lorsque j'affiche le message en console il me rajoute à chaque fois un caractère en trop dans le début du message.
-
Ce serait bien de voir un code complet minimal.
Il va falloir que je le dise à chaque fois, ou bien... ?
-
Le voici, code côté serveur :
#include <SFML/Network.hpp>
#include <iostream>
#include <vector>
using namespace sf;
using namespace std;
#include "symEncPacket.h"
int main () {
vector<TcpSocket*> clients;
TcpListener listener;
SocketSelector selector;
if (listener.listen(4567) == Socket::Done)
cout<<"Ok"<<endl;
selector.add(listener);
string message;
while (true) {
if (selector.wait()) {
if (selector.isReady(listener)) {
TcpSocket *client = new TcpSocket();
if (listener.accept(*client) == Socket::Done) {
cout<<"Client connected"<<endl;
selector.add(*client);
clients.push_back(client);
}
}
for (unsigned int i = 0; i < clients.size(); i++) {
if (selector.isReady(*clients[i])) {
SymEncPacket packet;
if (clients[i]->receive(packet) == Socket::Done) {
string message;
packet>>message;
//cout<<"Received from client (TCP) : "<<message<<endl;
packet.clear();
message = "Ceci est un message TCP!";
packet<<message;
clients[i]->send(packet);
} else {
selector.remove(*clients[i]);
vector<TcpSocket*>::iterator it;
for (it = clients.begin(); it != clients.end();)
if (*it ==clients[i])
it = clients.erase(it);
else
it++;
}
}
}
}
}
return 0;
}
Code côté client :
#include <SFML/Network.hpp>
#include "symEncPacket.h"
#include <iostream>
#include <sstream>
#include <vector>
using namespace std;
using namespace sf;
int main () {
TcpSocket socketTCP;
if (socketTCP.connect(IpAddress::LocalHost, 4567))
cout<<"Ok"<<endl;
SocketSelector selector;
selector.add(socketTCP);
string message;
while (true) {
SymEncPacket packet;
packet.clear();
message = "Ceci est un message TCP!";
packet<<message;
socketTCP.send(packet);
if (selector.wait()) {
if (selector.isReady(socketTCP)) {
packet.clear();
if (socketTCP.receive(packet) == Socket::Done) {
packet>>message;
//cout<<"Received from server (TCP) : "<<message<<endl;
}
}
}
//sleep(seconds(0.5f));
}
return 0;
}
Et une bête classe gérant l'envoi de paquet personnalisés côté serveur et côté client, ici j'envoie le message tel quel, pas de cryptage neccessaire pour reproduire le bug.
Voici le .cpp
#include "symEncPacket.h"
using namespace std;
using namespace sf;
const void* SymEncPacket::onSend (size_t& dataSize) {
const char* datas = static_cast<const char*> (getData());
buffer.assign(datas, datas + getDataSize());
vector<char>::iterator it;
string message;
for (it = buffer.begin(); it != buffer.end(); it++)
message += *it;
cout<<"Message : "<<message<<endl;
for (unsigned int i = 0; i < message.size(); i++)
buffer.push_back(message.at(i));
dataSize = buffer.size();
return &buffer[0];
}
void SymEncPacket::onReceive (const void* data, size_t dataSize) {
const char* datas = static_cast<const char*> (data);
buffer.assign (datas, datas + dataSize);
string message;
vector<char>::iterator it;
for (it = buffer.begin(); it != buffer.end(); it++)
message += *it;
for (unsigned int i = 0; i < message.size(); i++)
buffer.push_back(message.at(i));
append(&buffer[0], buffer.size());
}
#endif
Et voici le .h
#ifndef SYM_ENC_PACKET
#define SYM_ENC_PACKET
#include <SFML/Network.hpp>
#include "symEnc.h"
class SymEncPacket : public sf::Packet {
private :
virtual const void* onSend(std::size_t& dataSize);
virtual void onReceive (const void* data, std::size_t dataSize);
std::vector<char> buffer;
std::vector<char> encBuffer;
};
#endif
-
C'est avant envoi, ou après reception que tu as le bug ?
Et quand tu dis "un caractère en trop", c'est en trop par rapport à quoi ? Comment sais-tu combien d'octets le paquet est censé contenir ?
-
Avant l'envoi, dans la fonction onSend, quand je fais le getData(), il y a un caractère en trop au début.
-
Et quand tu dis "un caractère en trop", c'est en trop par rapport à quoi ? Comment sais-tu combien d'octets le paquet est censé contenir ?
Bah la fonction getDataSize() ne renvoie t'elle pas le nombre d'octets que contient le paquet ?
Et j'ai à chaque fois un octet en trop au début du paquet, je ne sais pas d'ou il vient peut être est-ce la taille du paquet qui est rajouté au début du paquet ?
-
Avant l'envoi
Du coup on s'en fout un peu de tout le setup TCP, en terme de code minimal on a juste besoin de ta classe de paquet et du code qui met quelque chose dedans... Même tout ce que tu as dans la fonction onSend est inutile pour constater le bug, il suffit d'afficher getData() / getDataSize().
Bah la fonction getDataSize() ne renvoie t'elle pas le nombre d'octets que contient le paquet ?
Si. Mais c'est quoi ta référence pour dire "en trop" ? Tu compares ce que te donne getDataSize() à quoi ?
peut être est-ce la taille du paquet qui est rajouté au début du paquet ?
Non. Par contre il y a la taille de la chaîne, mais elle fait 4 octets, pas 1.
-
Si. Mais c'est quoi ta référence pour dire "en trop" ? Tu compares ce que te donne getDataSize() à quoi ?
Bah là j'essaye de comparer ce que donne getData() comparé à getDataSize().
Non. Par contre il y a la taille de la chaîne, mais elle fait 4 octets, pas 1.
Ha merci, c'était ça, il y avait en effet les 4 octets qui mentionnaient la taille de la chaine en trop, c'étais ça qu'il rajoutait à chaque fois avant que je renvoie mon message.
Je les ai ignorés avant de renvoiyer le message et là ça marche.
const void* SymEncPacket::onSend (size_t& dataSize) {
const char* datas = static_cast<const char*> (getData());
buffer.assign(datas, datas + getDataSize());
vector<char>::iterator it = buffer.begin();
string message="";
it+=4;
for (; it != buffer.end(); it++)
message += *it;
cout<<"Message : "<<message<<endl;
for (unsigned int i = 0; i < message.size(); i++)
buffer.push_back(message.at(i));
dataSize = buffer.size();
return &buffer[0];
}
PS : ça m'étonne je pensais que tu l'avais déja fait dans ton code source, le fait qu'il ne renvoie pas la taille de la chaine avec le getData(), vu que tu encapsules le code.
-
Je les ai ignorés avant de renvoiyer le message et là ça marche.
Oui sauf que de l'autre côté ton paquet ne saura pas décoder la chaîne. C'est pas pour faire joli que j'ai mis la taille dans les données du paquet ;)
ça m'étonne je pensais que tu l'avais déja fait dans ton code source, le fait qu'il ne renvoie pas la taille de la chaine avec le getData(), vu que tu encapsules le code.
Il faut envoyer la taille de la chaîne ! Sinon comment je sais où elle s'arrête, pour la relire ?
Ce que tu fais dans onSend/onReceive ne doit pas altérer les données, sf::Packet a son propre protocole de communication, si tu touches aux données ton paquet ne va plus rien comprendre après réception.
En clair, ce qui sort de onReceive doit être strictement ce qui était entré dans le onSend correspondant.
PS : je comprends vraiment pas ce que tu fais dans onSend. Au final tu te retrouves avec la même chose en double dans 'buffer', non ?
-
Il faut envoyer la taille de la chaîne ! Sinon comment je sais où elle s'arrête, pour la relire ?
Ce que tu fais dans onSend/onReceive ne doit pas altérer les données, sf::Packet a son propre protocole de communication, si tu touches aux données ton paquet ne va plus rien comprendre après réception.
Ok, en effet c'est vrai quand je touche aux données dans onSend, le onReceive correspondant ne comprend plus rien.
Le problème c'est que je veut récupérer les données et les crypter avant de les envoyer, et ainsi les décrypter à la réception, malheureusement, il me crypte aussi la taille du paquet, du coup, dans ma plus grosse appli parfois ça bug, je reçois un paquet avec rien dedans.
-
Et ça gêne en quoi qu'il y ait la taille de la chaîne dedans ? A ce niveau ce que tu traites c'est un paquet d'octets quelconques, donc peu importe ce qu'il y a dedans (et dans la fonction onSend, c'est pas vraiment tes affaires) ce que tu fais devrait toujours marcher pareil. Tu ne peux rien supposer sur le contenu que tu reçois, et encore moins essayer de l'interpréter en chaîne de caractères.
-
Au fait le terme correct est "chiffrer", pas "crypter" ;)
-
Ha ok donc je devrai selon toi, directement chiffrer sur les octets et pas réinterprêter ça en chaine de caractère, avant d'envoyer, c'est bien ça ?
-
C'est tout à fait ça.
onSend est juste censée transformer une soupe d'octets en une autre soupe d'octets ; ensuite onReceive doit retransformer cette dernière soupe d'octets en la soupe d'octets originale.
-
Ha ok j'ai compris alors pourquoi ça plante mon système.
-
Bon, je suis obligé de réinterpréter le pointeurs sur void* en char* car les opérations mathématiques ne marchent pas sur les pointeurs de void* et puis des données, pas des adresses que je veux chiffrer.
Pour me simplifier la vie je mets tout dans un string car je rajoute des octets au début du paquet avant de l'envoyer, c'est plus facile de faire ça avec un string qu'avec un tableau.
const char* datas = static_cast<const char*> (getData());
buffer.assign(datas, datas + getDataSize());
string message="";
vector<char>::iterator it;
for (it = buffer.begin(); it != buffer.end(); it++)
message += *it;
string cryptedMessage = SymEnc::encrypt(message);
buffer.clear();
for (unsigned int i = 0; i < cryptedMessage.size(); i++)
buffer.push_back(cryptedMessage.at(i));
dataSize = buffer.size();
return &buffer[0];
Malheureusement , ne marche pas toujours, parfois mon paquet reçois des données invalides. :/
-
Bon le problème doit venir de mon code alors, car, ça marche très bien quand j'envoie des messages serveur/client pour déplacer le personnage, mais quand je commence à lui envoyer des messages avec l'IA pour attaquer, c'est à ce moment là que par moment ça freeze car mon client ne reçoit pas un message..., ça ne me le fait pas tout le temps mais, assez souvent. :/
-
Déjà je pense que ton code peut être grandement simplifié :
string cryptedMessage = SymEnc::encrypt(std::string(getData(), getData() + getDataSize()));
buffer.assign(cryptedMessage.begin(), cryptedMessage.end());
dataSize = buffer.size();
return &buffer[0];
Et je comprends pas ces conversions inutiles vector <-> string. Le vector<char> est le plus idiomatique pour traiter un tableau d'octets. std::string c'est pour des chaînes de caractères.
-
Oui je vais simplifier le code déjà, les vector de char j'y ai pensé mais je préfère les string, de toute façon les string ce sont des vector de char et c'est plus simple pour insérer des caractères en début de chaine pour le chiffrage, car il y a des méthode comme la méthode insert dans la classe string qui existent déja hors qu'avec un vector t'es obligé de le faire toi même, car y'a que le push_back.
-
Bon j'ai déjà simplifier le code, mais ça ne résoud pas le problème que j'ai.
const void* SymEncPacket::onSend (size_t& dataSize) {
string cryptedMessage = SymEnc::encrypt(std::string(static_cast<const char*> (getData()), getDataSize()));
buffer.assign(cryptedMessage.begin(), cryptedMessage.end());
dataSize = buffer.size();
return &buffer[0];
}
void SymEncPacket::onReceive (const void* data, size_t dataSize) {
string message = SymEnc::decrypt(std::string(static_cast<const char*> (data), dataSize));
buffer.assign(message.begin(), message.end());
append(&buffer[0], buffer.size());
}
Je me retrouve toujours avec un paquet vide et une erreur de temps en temps quand le serveur envoie un paquet en TCP au client.
-
Oui je vais simplifier le code déjà, les vector de char j'y ai pensé mais je préfère les string, de toute façon les string ce sont des vector de char et c'est plus simple pour insérer des caractères en début de chaine pour le chiffrage, car il y a des méthode comme la méthode insert dans la classe string qui existent déja hors qu'avec un vector t'es obligé de le faire toi même, car y'a que le push_back.
std::vector possède aussi une fonction insert, comme tous les conteneurs standards.
std::string(static_cast<const char*> (getData()), getDataSize())
Comme je te l'ai dit, il ne faut pas interpréter les données comme une chaîne de caractère. Là tu utilises le constructeur qui prend une chaîne C (terminée par zéro). Or il peut très bien y avoir un zéro à n'importe quel endroit du paquet.
Il faut utiliser le constructeur qui prend deux itérateurs :
const char* data = static_cast<const char*>(getData());
std::string s(data, data + getDataSize());
-
Ok, je vais tester avec un vector pour voir ce que ça donne.
-
Mais je serai toujours obligé de travailler à un moment avec des string que je devrai ajouter dans le nouveau vecteur d'octet, car, gmp travaille avec des string pour la gestion des grand nombres.
-
A moins que gmp permette aussi de travailler directement avec des octets. (c'est à dire des vector de char au lieu des fameux set_str et get_str.)
Je ne connais pas encore très bien gmp..., j'ai juste pris un code que j'ai trouvé sur un forum à l'époque pour généré mes grands nombres et chiffrer.
-
Ca n'a rien à voir, GMP prend des chaînes représentant des nombres (par exemple "126567983121"), pas des tableaux d'octets quelconques.
D'ailleurs tu fais quoi avec GMP dans ce contexte ? Et tu utilises quel algorithme de chiffrement ?
Tu n'utilises pas une bibliothèque de crypto qui te fait tout le boulot ?
-
Non je n'utilises pas une bibliothèque de crypto qui fait tout le boulot, j'utilise un chiffrement hétérogène, (1 er chiffrement : chiffrement rsa, second chiffrement : chiffrement symétrique à l'aide d'une bête fonction.)
Mais bon j'ai réfléchi un peu et j'ai trouvé pourquoi ça crashais parfois, en fait, j'ai oublié de faire une chose dans mon moteur réseau.
J'utilise plusieurs thread pour envoyer et recevoir des paquets.
La programmation multi-thread à de nombreux avantages mais en contre partie c'est plus dur pour débuguer.
Etant donné que j'ai fait un thread qui lis les données et un autre thread qui les envoyaient, il arrivait parfois que mon programme recevait et envoyait des données en même temps, j'ai donc rajouté un mutex autour des fonction send et receive de mes sockets et là ça va ça ne plante plus. :)
-
Ca n'a rien à voir, GMP prend des chaînes représentant des nombres (par exemple "126567983121"), pas des tableaux d'octets quelconques.
C'est bien pour ça que je suis obligé de convertir mon tableau d'octets en string pour je puisse ensuite représenter mes grands nombres avec gmp.
Maintenant que tu me l'as dis j'aurai pu aussi utiliser les socket SSL de Qt pour le cryptage rsa, mais pour le cryptage symétrique je préfère utiliser mon propre algorithme de chiffrement, cela est plus sécurisé que les bibliothèque dont on connait les failles.
Je ne me sert du cryptage rsa uniquement pour transférer la clé publique pour le cryptage symétrique.
-
C'est bien pour ça que je suis obligé de convertir mon tableau d'octets en string pour je puisse ensuite représenter mes grands nombres avec gmp.
Mais il n'y a pas de nombre dans les données du paquet. Les grands nombres dont tu parles sont ceux dont tu as besoin pour le chiffrement non ? Alors quel rapport avec le fait de coller toutes les données du paquet dans un std::string ?
Maintenant que tu me l'as dis j'aurai pu aussi utiliser les socket SSL de Qt pour le cryptage rsa, mais pour le cryptage symétrique je préfère utiliser mon propre algorithme de chiffrement, cela est plus sécurisé que les bibliothèque dont on connait les failles.
Bien sûr. Et tous les logiciels qui font du chiffrement codent leur propre algorithme pour cette même raison, et du coup les bibliothèques de crypto existent juste pour faire beau. Et évidemment ton code sera plus sécurisé que ces bibliothèques ; n'hésite pas à le vendre une fois que tu auras terminé.
... :P
-
Lol Laurent, pour le cryptage chacun à sa manière de faire et ça ne se vend pas il y a juste quelques méthodes de cryptage assymétrique qui existent et utilisés par certaines librairies et qui sont devenu un standart comme par exemple le cryptage RSA pour les fameuses licenses d'activation des logiciels par exemple.
Ca, c'est tout ce que j'ai trouvé au niveau du cryptage sur internet, le reste, ce sont plutôt des méthodes de hachage et pas de cryptage comme par exemple la méthode de hachage md5.
Mais pour le cryptage symétrique tout se résume à une simple fonction qui chiffre les données et qui ne doit justement pas être connue, il est donc peut probable que tu trouves une librairie qui fasse cela et puis mon algorithme RSA fait exactement la même chose que ce que fait le cryptage SSL utilisé par d'autres librairies qui utilisent les socket SSL et que tu pourrais aussi implémenter à la SFML si tu le veux, ces librairies utilisent utilisent juste un algorithme de hachage en plus surement pour envoyer les clés.
Sinon t'inquiéte pas pour moi je pourrai bientôt si je veux faire un site ou je pourrai vendre d'autres choses, comme par exemple un tutoriel pour créer un mmo en c++ par exemple avec la SFML. :P
Je pense que t'en serai content tiens!
-
Ce que je veux dire, c'est pourquoi ne pas utiliser OpenSSL, qui fournit vraiment tout ce qu'il faut pour faire du chiffrement de qualité :
SYMMETRIC CIPHERS
blowfish(3), cast(3), des(3), idea(3), rc2(3), rc4(3), rc5(3)
PUBLIC KEY CRYPTOGRAPHY AND KEY AGREEMENT
dsa(3), dh(3), rsa(3)
CERTIFICATES
x509(3), x509v3(3)
AUTHENTICATION CODES, HASH FUNCTIONS
hmac(3), md2(3), md4(3), md5(3), mdc2(3), ripemd(3), sha(3)
Je ne pense pas que la sécurité d'une transmission soit assurée par le secret de l'algorithme. Je pense qu'il faut plutôt utiliser un algorithme connu pour être incassable (avec les technologies et connaissances actuelles). Je suis loin d'être un expert en chiffrement, mais je pense que si des standards et des algorithmes existent, c'est pour être utilisés. Ceux-ci sont testés, utilisés et retournés dans tous les sens tous les jours. Alors que ton algorithme, une fois que quelqu'un aura fait du reverse-engineering sur ton code, il le cassera en quelques minutes.
-
Ouais t'as peux être raison, je note ça dans les améliorations futur à faire.
-
Bon, j'ai essayer de compiler openSSL mais mon CPU ne le supporte pas, voilà pourquoi je dois faire mes propres algo.
Quand j'essayer de compiler SSL il m'affiche ça :
cryptlib.c:1:0: error: CPU you selected does not support x86-64 instruction set
make[1]: *** [cryptlib.o] Error 1
make[1]: Leaving directory `/c/openssl-src/openssl-1.0.1e/crypto'
make: *** [build_crypto] Error 1
PS : je suis sur windows 7 64bits.
Mais je n'utilise pas de version 64 bits de mingw car je veux que mon code soit compatible aussi sur les systèmes 32 bits.
-
Je pense que OpenSSL est compilable en mode 32 bits. Il faut sûrement juste passer le bon flag de compilation ou de configuration.
-
Houla au niveau des flags je ne m'y connais pas... :/
Comment puis je savoir quel flag il faut mettre ?
-
Apparemment ils ont un script de configuration en Perl, qui détecte le compilo et l'architecture. Du coup je ne sais pas trop, il faut sûrement lire la doc et/ou chercher un peu sur internet.
-
OpenSSL, pour Windows : http://slproweb.com/products/Win32OpenSSL.html
-
Ou là :
http://gnuwin32.sourceforge.net/packages/openssl.htm
(GNU Win32 est l'endroit standard pour trouver des versions Windows de bibliothèques C Linux).
(désolé de ne pas y avoir pensé avant)
-
Je précise qu'utiliser MingW en version x64 pose pas de soucis, suffit dans les options de compilation de lui passer le paramètre -m32, cela crée un binaire x86 et non x64.
-
Ha merci pour toutes ces infos, bah, il y aura du boulot quand je récupérerai mon portable. (La semaine prochaine normalement car le type doit seulement changer l'écran, j'ai hésité entre ça ou en racheter un nouveau comme il as déjà 3 ans mon portable et que c'est vite foutu ces bazard et que en plus, ça coûte cher.)
Bref je m'arrangerai pour en avoir un bon plus tard pas trop cher, je connais des gens. :P
-Je vais pouvoir repasser au c++11 alors, à condition de trouver comment mettre le paramètre -m32 quand je compile avec dans code::block.
-Je vais pouvoir enfin changer mon chiffrement symétrique et faire un hachage pour les mots de passe dans la base de donnée. (Il faut dire pour le moment il n'y a que le chiffrement RSA.)
Je me demandais si il n'y avais pas moyen d'utiliser openSSL via QT mais bon comme je n'utilise pas QT pour la programmation réseau mais les sockets SFML avec les sélectors, je ne sais pas si on peut utiliser openssl avec QT sans passer par les socketSSL.
Bref je préfère largement SFML pour le réseau, j'avais essayer QT dans le passé mais ça ne marchait pas et puis je pense que SFML est plus adapté pour les jeux. :/
Et je vais pouvoir enfin finir a version custom de SFML. (je modifierai sans doute encore SFML après, quand j'aurai plus de connaissance dans la programmation native. (liés aux os.)
Pour tout ce qui est opengl j'ai pas trop de difficulté mais pour tout ce qui est code natif à l'os ça, je suis totalement novice là dedans.
Faut dire il y a tellement de librairies qui font ça pour nous que..., on a plus vraiment besoin de programmer à ce niveau là.
-
Bref je préfère largement SFML pour le réseau, j'avais essayer QT dans le passé mais ça ne marchait pas et puis je pense que SFML est plus adapté pour les jeux. :/
Oui et non, les deux sont de "simple" wrapper, il n'y pas de réelle implémentation orienté jeux. De plus, ces deux libraries utilisent select en backend ce qui adapté pour un jeu multijoueur mais surement pas pour un jeu 'massivement' multijoueur. ;-)
-
Bon l'option -m32 ne marche pas il me renvoie cette erreur :
c:\mingw\mingw64\lib\gcc\x86_64-w64-mingw32\4.8.1\include\c++\cstdlib|178|error: expected unqualified-id before '__int128'|
PS : c'est __int28 et pas __int128.
-
Bon avec l'option -m32 ça ne marche carrément pas :
obj\Debug\main.o||In function `__gthread_equal':|
c:\mingw\mingw64\lib\gcc\x86_64-w64-mingw32\4.8.1\include\c++\x86_64-w64-mingw32\bits\gthr-default.h|680|undefined reference to `_pthread_equal'|
obj\Debug\main.o||In function `f1(int)':|
D:\Projets-c++\Testc++11\main.cpp|9|undefined reference to `___gxx_personality_sj0'|
D:\Projets-c++\Testc++11\main.cpp|9|undefined reference to `__Unwind_SjLj_Register'|
D:\Projets-c++\Testc++11\main.cpp|11|undefined reference to `__ZSt4cout'|
D:\Projets-c++\Testc++11\main.cpp|11|undefined reference to `__ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc'|
D:\Projets-c++\Testc++11\main.cpp|11|undefined reference to `__ZNSolsEi'|
D:\Projets-c++\Testc++11\main.cpp|11|undefined reference to `__ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc'|
D:\Projets-c++\Testc++11\main.cpp|10|undefined reference to `__Unwind_SjLj_Resume'|
D:\Projets-c++\Testc++11\main.cpp|10|undefined reference to `__Unwind_SjLj_Unregister'|
obj\Debug\main.o||In function `f2(int&)':|
D:\Projets-c++\Testc++11\main.cpp|17|undefined reference to `___gxx_personality_sj0'|
D:\Projets-c++\Testc++11\main.cpp|17|undefined reference to `__Unwind_SjLj_Register'|
D:\Projets-c++\Testc++11\main.cpp|19|undefined reference to `__ZSt4cout'|
D:\Projets-c++\Testc++11\main.cpp|19|undefined reference to `__ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc'|
D:\Projets-c++\Testc++11\main.cpp|18|undefined reference to `__Unwind_SjLj_Resume'|
D:\Projets-c++\Testc++11\main.cpp|18|undefined reference to `__Unwind_SjLj_Unregister'|
obj\Debug\main.o||In function `main':|
D:\Projets-c++\Testc++11\main.cpp|26|undefined reference to `___gxx_personality_sj0'|
D:\Projets-c++\Testc++11\main.cpp|26|undefined reference to `__Unwind_SjLj_Register'|
D:\Projets-c++\Testc++11\main.cpp|26|undefined reference to `___main'|
D:\Projets-c++\Testc++11\main.cpp|33|undefined reference to `__ZNSt6thread4joinEv'|
D:\Projets-c++\Testc++11\main.cpp|34|undefined reference to `__ZNSt6thread4joinEv'|
D:\Projets-c++\Testc++11\main.cpp|35|undefined reference to `__ZSt4cout'|
D:\Projets-c++\Testc++11\main.cpp|35|undefined reference to `__ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc'|
D:\Projets-c++\Testc++11\main.cpp|35|undefined reference to `__ZNSolsEi'|
D:\Projets-c++\Testc++11\main.cpp|35|undefined reference to `__ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_c'|
D:\Projets-c++\Testc++11\main.cpp|36|undefined reference to `__Unwind_SjLj_Resume'|
D:\Projets-c++\Testc++11\main.cpp|36|undefined reference to `__Unwind_SjLj_Unregister'|
obj\Debug\main.o||In function `__tcf_0':|
c:\mingw\mingw64\lib\gcc\x86_64-w64-mingw32\4.8.1\include\c++\iostream|74|undefined reference to `__ZNSt8ios_base4InitD1Ev'|
obj\Debug\main.o||In function `__static_initialization_and_destruction_0':|
c:\mingw\mingw64\lib\gcc\x86_64-w64-mingw32\4.8.1\include\c++\iostream|74|undefined reference to `__ZNSt8ios_base4InitC1Ev'|
c:\mingw\mingw64\lib\gcc\x86_64-w64-mingw32\4.8.1\include\c++\iostream|74|undefined reference to `_atexit'|
obj\Debug\main.o||In function `std::operator==(std::thread::id, std::thread::id)':|
c:\mingw\mingw64\lib\gcc\x86_64-w64-mingw32\4.8.1\include\c++\thread|83|undefined reference to `___gxx_personality_sj0'|
c:\mingw\mingw64\lib\gcc\x86_64-w64-mingw32\4.8.1\include\c++\thread|83|undefined reference to `__Unwind_SjLj_Register'|
c:\mingw\mingw64\lib\gcc\x86_64-w64-mingw32\4.8.1\include\c++\thread|84|undefined reference to `__Unwind_SjLj_Unregister'|
obj\Debug\main.o||In function `std::thread::~thread()':|
c:\mingw\mingw64\lib\gcc\x86_64-w64-mingw32\4.8.1\include\c++\thread|143|undefined reference to `__ZSt9terminatev'|
obj\Debug\main.o||In function `std::thread::_Impl_base::~_Impl_base()':|
c:\mingw\mingw64\lib\gcc\x86_64-w64-mingw32\4.8.1\include\c++\thread|97|undefined reference to `__ZdlPv'|
obj\Debug\main.o||In function `std::thread::_Impl_base::~_Impl_base()':|
c:\mingw\mingw64\lib\gcc\x86_64-w64-mingw32\4.8.1\include\c++\thread|97|undefined reference to `__ZdlPv'|
obj\Debug\main.o||In function `std::thread::_Impl_base::~_Impl_base()':|
c:\mingw\mingw64\lib\gcc\x86_64-w64-mingw32\4.8.1\include\c++\thread|97|undefined reference to `__ZdlPv'|
obj\Debug\main.o||In function `std::chrono::duration<long long, std::ratio<1ll, 1ll> > std::chrono::__duration_cast_impl<std::chrono::duration<long long, std::ratio<1ll, 1ll> >, std::ratio<1ll, 1000ll>, long long, true, false>::__cast<long long, std::ratio<1ll, 1000ll> >(std::chrono::duration<long long, std::ratio<1ll, 1000ll> > const&)':|
c:\mingw\mingw64\lib\gcc\x86_64-w64-mingw32\4.8.1\include\c++\chrono|162|undefined reference to `___divdi3'|
obj\Debug\main.o||In function `void std::this_thread::sleep_for<long long, std::ratio<1ll, 1000ll> >(std::chrono::duration<long long, std::ratio<1ll, 1000ll> > const&)':|
c:\mingw\mingw64\lib\gcc\x86_64-w64-mingw32\4.8.1\include\c++\thread|269|undefined reference to `___gxx_personality_sj0'|
c:\mingw\mingw64\lib\gcc\x86_64-w64-mingw32\4.8.1\include\c++\thread|269|undefined reference to `__Unwind_SjLj_Register'|
c:\mingw\mingw64\lib\gcc\x86_64-w64-mingw32\4.8.1\include\c++\thread|279|undefined reference to `_nanosleep'|
c:\mingw\mingw64\lib\gcc\x86_64-w64-mingw32\4.8.1\include\c++\thread|283|undefined reference to `__Unwind_SjLj_Resume'|
c:\mingw\mingw64\lib\gcc\x86_64-w64-mingw32\4.8.1\include\c++\thread|283|undefined reference to `__Unwind_SjLj_Unregister'|
obj\Debug\main.o||In function `std::thread::thread<void (&)(int), int>(void (&)(int), int&&)':|
c:\mingw\mingw64\lib\gcc\x86_64-w64-mingw32\4.8.1\include\c++\thread|133|undefined reference to `___gxx_personality_sj0'|
c:\mingw\mingw64\lib\gcc\x86_64-w64-mingw32\4.8.1\include\c++\thread|133|undefined reference to `__Unwind_SjLj_Register'|
c:\mingw\mingw64\lib\gcc\x86_64-w64-mingw32\4.8.1\include\c++\thread|135|undefined reference to `__ZNSt6thread15_M_start_threadESt10shared_ptrINS_10_Impl_baseEE'|
c:\mingw\mingw64\lib\gcc\x86_64-w64-mingw32\4.8.1\include\c++\thread|135|undefined reference to `__Unwind_SjLj_Resume'|
c:\mingw\mingw64\lib\gcc\x86_64-w64-mingw32\4.8.1\include\c++\thread|135|undefined reference to `__Unwind_SjLj_Unregister'|
obj\Debug\main.o||In function `std::thread::thread<void (&)(int&), std::reference_wrapper<int> >(void (&)(int&), std::reference_wrapper<int>&&)':|
c:\mingw\mingw64\lib\gcc\x86_64-w64-mingw32\4.8.1\include\c++\thread|133|undefined reference to `___gxx_personality_sj0'|
c:\mingw\mingw64\lib\gcc\x86_64-w64-mingw32\4.8.1\include\c++\thread|133|undefined reference to `__Unwind_SjLj_Register'|
c:\mingw\mingw64\lib\gcc\x86_64-w64-mingw32\4.8.1\include\c++\thread|135|undefined reference to `__ZNSt6thread15_M_start_threadESt10shared_ptrINS_10_Impl_baseEE'|
||More errors follow but not being shown.|
||Edit the max errors limit in compiler options...|
||=== Build finished: 50 errors, 0 warnings (0 minutes, 3 seconds) ===|
Hors que sans l'option m32 ce bout de code fonctionne :
#include <iostream>
#include <utility>
#include <thread>
#include <chrono>
#include <functional>
#include <atomic>
void f1(int n)
{
for (int i = 0; i < 5; ++i) {
std::cout << "Thread " << n << " executing\n";
std::this_thread::sleep_for(std::chrono::milliseconds(10));
}
}
void f2(int& n)
{
for (int i = 0; i < 5; ++i) {
std::cout << "Thread 2 executing\n";
++n;
std::this_thread::sleep_for(std::chrono::milliseconds(10));
}
}
int main(int argc, char* argv[])
{
int n = 0;
std::thread t1; // t1 is not a thread
std::thread t2(f1, n + 1); // pass by value
std::thread t3(f2, std::ref(n)); // pass by reference
std::thread t4(std::move(t3)); // t4 is now running f2(). t3 is no longer a thread
t2.join();
t4.join();
std::cout << "Final value of n is " << n << '\n';
return EXIT_SUCCESS;
}
-
Pourquoi est-ce que tu te fais chier avec un compilo 64 bits ?
-
Pour faire des tests et essayer d'implémenter le c++11 mais je n'arrive pas à l'avoir avec un compilateur 32 bits.
Bref je pense que je vais laisser tombé ça.
-
A peu près tous les gcc 32 bits sous Windows sont suffisamment récents pour avoir le support de C++11.
-
Ok, bref je n'ai pas spécialement besoin du support pour le c++11 pour l'instant, mais, pour plus tard peut être, en tout cas la version récente que j'ai téléchargé de mingw apparemment c'est que un compilateur 64 bits, quand je repasse en 32 bits ça ne marche plus avec du c++11, j'ai des undefined référence partout.
Et je dois changer Dwar2 en SJLJ pour les eceptions du compilateur 32 bits aussi mais ça, je ne sais pas trop comment qu'on fait.
-
Bon je tiens à préciser que j'ai une version 4.6.2 de mingw et je n'ai pas le support du c++11.
(J'ai des undefined références partout quand je veux utiliser les threads, et je ne sais pas non comment changer gcc avec l'option pour activer le SJLJ, je pense que je vais chercher carrément une autre version de mingw 32 bits.)
-
4.6 c'est déjà très vieux. Il faut au minimum un gcc 4.7.
-
Ok merci pour l'info, je vais voir si je trouve pas une version plus récente 32bits avec support c++11 qui fonctionne.
-
je vais voir si je trouve pas une version plus récente
Toutes les versions que tu trouves aujourd'hui, que ce soit MinGW ou TDM, sont en 4.7 ou 4.8. Donc ça ne devrait pas être trop difficile ;)
-
Apparemment dans celle que j'ai téléchargée (la 4.7), il n'y avait que une version 64bits de mingw, vu que quand je repasse en 32 bits j'ai des erreur d'incompatibilité, bref, mais je devrai trouvé oui..
-
Bon quand je vais sur le site de mingw il me télécharge la dernière version de mingw qui est soi disant la 4.6, je trouve pas de version 4.7, la 4.8.1 est en bêta mais erreur quand je veux la télécharger, sinon, je dois télécharger Qt ou bien code::block avec mingw mais pas moyen de trouver mingw tout seul pour une version supérieure à la 4.6.
Ou alors si mais ce sont les sources et je sais pas comment qu'on compile mingw, faudrait que je recherche.
-
Je compile SFML avec un MinGW/gcc 4.7, et je n'ai rien fait de bizarre pour l'obtenir, je l'ai pris sur le site officiel.
-
Ce site là ? http://mingw.org
-
Oui.
C'est pas un 4.7.2 là par exemple ?
http://sourceforge.net/projects/mingw/files/MinGW/Base/gcc/Version4/gcc-4.7.2-1/
-
Oui mais je dois cliquer sur quel lien, celui tout au dessus ne marche pas, il ne me donne que un mingw 4.6.2 et pas la dernière version, il faudrait que je leur dise.
En tout cas il y a 18 liens, et les fichiers .tar.lzma je ne sais pas les ouvrir, faut quoi comme programme pour les lire ?
-
Bon ok j'ai trouvé il faut 7-zip pour les lire.
Mal foutu j'ai même pas de sous menu extraire ici avec 7-zip, bref...
-
Bon j'ai cliqué sur le 1er lien (gcc-core.), j'ai mis ça dans un dossier MinGW, codeblock me le détecter bien par contre il ne veut pas l'exécuter, j'ai cet erreur là dans la console :
Cleaned "Testc++11 - Debug"
-------------- Build: Debug in Testc++11 (compiler: GNU GCC Compiler)---------------
mingw32-g++.exe -Wall -g -c D:\Projets-c++\Testc++11\main.cpp -o obj\Debug\main.o
Execution of 'mingw32-g++.exe -Wall -g -c D:\Projets-c++\Testc++11\main.cpp -o obj\Debug\main.o' in 'D:\Projets-c++\Testc++11' failed.
Nothing to be done (all items are up-to-date).
-
Bon, y'a le compilateur c mais pas le compilateur g++, plutôt que de cliquer sur tout les liens je crois que je vais attendre...
-
Bon maintenant j'ai téléchargé le compilateur g++ mais me manque libgmp10.dll, bon, j'arrête un peu avant que je pète un cable avec cet installation. :/
-
Oui, MinGW est un peu chiant à installer, il est fourni par composants à assembler. Il y a un programme qui simplifie tout ça (mingw-get), qui est aussi fourni sur ce même site web.
Sinon cherche une distribution complète pré-packagée. Là ça a l'air pas mal :
http://nuwen.net/mingw.html
-
Bon j'ai installé ce package, ça marche bien à part que me manque des fichier.h j'ai l'impression :
D:\Projets-c++\Testc++11\main.cpp||In function 'void f1(int)':|
D:\Projets-c++\Testc++11\main.cpp|12|error: 'std::this_thread' has not been declared|
D:\Projets-c++\Testc++11\main.cpp||In function 'void f2(int&)':|
D:\Projets-c++\Testc++11\main.cpp|21|error: 'std::this_thread' has not been declared|
D:\Projets-c++\Testc++11\main.cpp||In function 'int main(int, char**)':|
D:\Projets-c++\Testc++11\main.cpp|29|error: 'thread' is not a member of 'std'|
D:\Projets-c++\Testc++11\main.cpp|29|error: expected ';' before 't1'|
D:\Projets-c++\Testc++11\main.cpp|30|error: 'thread' is not a member of 'std'|
D:\Projets-c++\Testc++11\main.cpp|30|error: expected ';' before 't2'|
D:\Projets-c++\Testc++11\main.cpp|31|error: 'thread' is not a member of 'std'|
D:\Projets-c++\Testc++11\main.cpp|31|error: expected ';' before 't3'|
D:\Projets-c++\Testc++11\main.cpp|32|error: 'thread' is not a member of 'std'|
D:\Projets-c++\Testc++11\main.cpp|32|error: expected ';' before 't4'|
D:\Projets-c++\Testc++11\main.cpp|33|error: 't2' was not declared in this scope|
D:\Projets-c++\Testc++11\main.cpp|34|error: 't4' was not declared in this scope|
D:\Projets-c++\Testc++11\main.cpp|36|error: 'EXIT_SUCCESS' was not declared in this scope|
||=== Build finished: 13 errors, 0 warnings (0 minutes, 5 seconds) ===|
-
Là je ne peux pas t'en dire plus, il est possible que certaines parties de la SL ne soient pas implémentées dans cette version.
Sinon au pire essaye de trouver une 4.8 pré-packagée, là tu seras sûr.
-
Oui, j'en ai trouvé une qui fonctionne en 64 bits, et qui implémente bien les threads de la STL, mais, en 32 bits je n'ai encore rien trouvé. :/
-
Et les TDM ?
http://tdm-gcc.tdragon.net/download
-
Bon, j'ai télécharger les 2 version, mingw 4.7 et 4.8, mais, pas de support des threads, j'ai vu que la version 4.8 n'est que expérimental de toute façon, à mon avis, je devrais encore passer par les thread de la SFML un bon moment avant de pouvoir utiliser ceux du c++11.
Dommage que la version 4.8.2 ne marchait que en 64 bits pour les threads (en 32 bits ce n'était pas encore implémenté.), bref...., il y a boost aussi mais j'aime pas trop car c'est un peu plus compliqué.
-
Et là ?
http://sourceforge.net/projects/mingwbuilds/
Ce sont des MinGW-w64 donc il devrait y avoir un bon support des threads. Il y a des versions 32-bits a priori.
-
L'installeur m'insulte, il me dit : "cannot download repository.txt."
-
Là je suis à court d'idées ;D
-
Oui moi aussi mais à l'avenir je vais surement développer uniquement sur linux, trop de virus sur windows, et peut être que avec firefox ça marchera pour le téléchargement, parce ici je suis obligé d'utiliser IE, plus moyen de lancer firefox et ça m'énerve grâve.
-
Bon j'ai réussi à enfin trouver un lien qui fonctionne. (Yeah.)
Sur le site de QT.
Ca supporte bien le support des std::thread en 32 et 64 bits.
Maintenant le truc moins cool c'est que certaines librairies que j'utilise fonctionnent encore en dwarf2 hors que ma version de mingw, la 4.8.1, fonctionne en sjlj pour les objets gérant les exceptions.
Du coup bah je pense que là je suis reparti pour recompliler boost, gmp et installer la nouvelle version de QT, la 5.1.
Peut être que il y a déja des versions pré-compilée, je ne sais pas, faut que je regarde. O_O
-
Sinon il y a aussi Visual C++.
-
J'aime pas, je préfère code::block. :)