Discussion :

[mi6fred]

Bonjour,

Je développe une bibliothèque réseau portable qui doit permettre l'envoi d'objets. J'ai donc décidé d'utiliser les archives boost et d'envoyer le flux généré par les sockets Windows/Unix. J'aimerais un moyen simple d'y arriver, j'ai vu par exemple la classe stringstream, si je pouvais dériver de cette classe et simplement implémenter les opérations de lecture/écriture ce serait assez sympa (je ne vais pas réinventer le buffer).

Toutes les procédures de lecture/écriture sont implémentée, je dois simplement en faire un flux de type iostream sans avoir à réinventer la roue. J'aimerais n'utiliser que la STL, ou Boost (mon appli repose déja dessus).

Merci,

Fred

[Swoög]

Salut !

La STL ou Boost n'intègrent pas (pour le moment) la gestion des Sockets.

Cependant, il y a une annexe de boost : Boost.Asio qui permet de gérer les sockets

[mi6fred]

Merci de ta réponse,

Mais en réalité, j'ai déja rédigé toutes les procédures de communication, il ne me reste pour ainsi "plus qu'à" encapsuler ce code dans un objet iostream. Je suis en train de me renseigner, mais j'ai peur de devoir réécrire toute la gestion du buffer. Les opérations de lecture/écriture sont assez spéciales (envoi d'objets), et étant donné que j'ai déja écrit mes classes de communication, je n'ai pas besoin d'une nouvelle classe qui sera sans doute plus lourde et plus complexe à modifier.

Si vous aviez une solution qui me permette de proposer un objet iostream en n'implémentant que les fonctions qui permettent de remplir le buffer (recevoir) et vider le buffer (envoyer), ca me simplifierait bien la vie

[Laurent Gomila]

Tu peux tenter une recherche sur streambuf, on a déjà donné quelques bons liens à ce sujet.

Sinon il me semble aussi que certaines bibliothèques qui font du socket utilisent cette méthode (ACE ?), tu pourrais t'en inspirer.

[mi6fred]

Je continue mes recherches, merci

Et on commence par la :
http://groups.google.de/group/fr.com...rch+this+group
http://www.cmla.ens-cachan.fr/Utilis..._entree_sortie

[mi6fred]

Finalement, ces liens adressent plutôt le problème du contrôle de données plutôt que celui de l'écriture sur un nouveau média (ils utilisent une strcture FILE pour gérer leur buffer). Je suis en train de regarder socket++ pour m'inspirer de leur implémentation. Je me demande encore si strstream ne peut pas être dérivé simplement ...

[Luc Hermitte]

Si tu veux ton stream à toi, alors tu devras dériver un streambuf. C'est ainsi.
Visiblement, tu as déjà trouvé la FAQ de fclc++.

[mi6fred]

J'avance tranquillement avec mes flux, j'ai donc dérivé std::streambuf, mais j'ai une petite question sur la fonction overflow. En effet, cette fonction prend un type "int_type" en entrée, probablement pour implémenter tous les caractères de contrôle comme EOF. Cependant, la fonction send ne prend en argument que des char* (sous VC8 int_type est un entier 64bits), j'aimerais savoir si le cast que j'opère est correct :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
virtual int_type overflow (int_type c)
{
	int nsent;
 
	if (c != EOF)
	{
		nsent = send(m_Socket, (char *)&c, 1, 0);
		if ( nsent != 1 )
		{
			throw SocketIOException("Unable to send data", send_error,
						"SocketStreamBuffer::overflow", __FILE__, __LINE__);
		}
	}
 
	return c;
}

Une autre question, moins language celle là : sachant que je veux envoyer des petits objets serialisés, est-il judicieux d'utiliser un buffer ou peut-on utiliser un envoi synchrone (objet par objet, via xsputn) ?

[Médinoc]

moi, je dirais plutôt:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

char c2 = (char)c; send(&c);

[mi6fred]

C'est sans doute la solution la plus pratique et la plus propre, je me demande pourquoi je n'y avais pas pensé . Merci !

La seconde question tient toujours : sachant que je veux envoyer des petits objets serialisés, est-il judicieux d'utiliser un buffer ou peut-on utiliser un envoi synchrone (objet par objet, via xsputn) ?

Et pendant que j'y suis, une petite interrogation sur le type int_type : Où est-il réellement défini ? Visual C++ le définit dans std::char_traits<char>::int_type, mais cette déclaration n'est sans doute pas portable. std::int_type n'existe pas, et int_type n'existe pas non plus dans le namespace global. Les fonction overflow et underflow utilisent ce type, en connaissez-vous une définition propre (je n'ai pas envie d'utiliser le namespace global) ?

[loufoque]

moi, je dirais plutôt:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

char c2 = (char)c;

Inutile de caster ici.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

char c2 = c;

fonctionne très bien et est plus sûr.

[mi6fred]

Inutile de caster ici.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

char c2 = c;

fonctionne très bien et est plus sûr.

Ce code ne réalise-t-il pas déja un cast implicite ? Par quelle autre méthode le compilateur pourrait-il convertir ce type de base, et pourquoi est-ce plus sûr ?

[Médinoc]

Inutile de caster ici.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

char c2 = c;

fonctionne très bien et est plus sûr.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

warning C4244: 'initializing' : conversion from 'int' to 'char', possible loss of data

Quand Médinoc met un cast, c'est qu'il sert à quelque chose.
Par contre, je n'aurais pas dû mettre un cast C. un static_cast est plus approprié.

[mi6fred]

Merci Medinoc, je ne connaissais pas les cast statiques, ils me seront bien utiles

Par contre, j'ai toujours un problème avec ces int_type qui sont définis n'importe où ... voici mon code :

SocketClasses.hpp

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
#include <streambuf> // SocketStreamBuffer base class
 
namespace SocketClasses
{
class SocketStreamBuffer : public std::streambuf
{
// ...
protected:
	virtual int_type overflow (int_type c);
	virtual std::streamsize xsputn (const char *buf, std::streamsize len);
}
}

SocketClasses.cpp

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
#include "SocketClasses.hpp"
 
namespace SocketClasses
{
int_type SocketStreamBuffer::overflow (int_type c)
{
// ...
}
 
std::streamsize SocketStreamBuffer::xsputn (const char *buf, std::streamsize len)
{
// ...
}
}

Et les erreurs de type qui s'en suivent :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
------ Build started: Project: Socktest, Configuration: Test Win32 ------
Compiling...
SocketClasses.cpp
d:\alm\socktest\socktest\socketclasses.cpp(26) : error C2143: syntax error : missing ';' before 'SocketClasses::SocketStreamBuffer::overflow'
d:\alm\socktest\socktest\socketclasses.cpp(26) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
d:\alm\socktest\socktest\socketclasses.cpp(27) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
Build log was saved at "file://d:\ALM\Socktest\Socktest\Test\BuildLog.htm"
Socktest - 3 error(s), 0 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

G++ 3.4.4 me donne :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
# g++ -ansi -Wall -pedantic -c SocketClasses.cpp
SocketClasses.cpp:26: error: `int_type' does not name a type

Le type int_type est défini dans la classe mère std::basic_streambuf, je trouve curieux que je puisse utiliser ce type dans ma définition de classe (header) mais pas dans mon implémentation (cpp). Avez-vous une solution propre à ce problème ? Est-ce un bug du compilateur ? La seule solution que j'aie pour l'instant consiste à implémenter les fonctions dans le hpp, ou de déporter le traitement en inline dans d'autres fonctions qui ont des signatures à arguments courants et d'implémenter ces dernières fonctions dans le cpp. Mais très franchement, cette solution ne me satisfait pas du point de vue de la clarté du code.

Merci !

[mi6fred]

On n'est jamais mieux servi que par soi même : le remplacement de int_type par SocketStreamBuffer::int_type fonctionne, tout compile correctement

Juste une question de fondamentaux : pourquoi les types définis dans la classe ne peuvent ils pas dans notre cas être utilisés directement dans les signatures de fonctions, alors qu'ils peuvent l'être dans la définition de la classe ?

Ne vous inquiétez pas, je mettrais le tag "résolu" lorsque j'aurais publié une première version qui fonctionne de mes classes

[Matthieu Brucher]

Parce que dans la définition de la fonction, on est à l'extérieur de la déclaration de la classe. Il peut y avoir un type externe - oui, ça serait très sale - qui a le même nom, et ça reviendrait alors à une fonction surchargée

[mi6fred]

Merci Miles . Après réflexion ça parait logique, mais j’ai pensé que ces types seraient exportés et reconnus par les fonctions implémentées à l’extérieur de la classe.

Je suis presque au bout de mes peines, vous aurez bientôt mon code qui fonctionne ! Mais auparavant, j’ai toujours un drôle de warning avec VCC 8 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 d:\alm\socktest\socktest\socketclasses.hpp(87) : warning C4996: 'std::basic_streambuf<_Elem,_Traits>::xsgetn' was declared deprecated
        with
        [
            _Elem=char,
            _Traits=std::char_traits<char>
        ]
        c:\programme\microsoft visual studio 8\vc\include\streambuf(324) : see declaration of 'std::basic_streambuf<_Elem,_Traits>::xsgetn'
        with
        [
            _Elem=char,
            _Traits=std::char_traits<char>
        ]
        Message: 'You have used a std:: construct that is not safe. See documentation on how to use the Safe Standard C++ Library'
SocketClasses.cpp

Le ligne 87 est la suivante (dans ma classe SocketStreamBuffer) :
virtual std::streamsize xsgetn (char_type *buf, std::streamsize len);

Pour information, ce code compile parfaitement avec gcc, mais j’aimerais savoir s’il existe une autre façon d’implémenter les écritures de chaines sans buffer. Xsgetn est vraiment considéré comme obsolète ?

[Matthieu Brucher]

Le warning indique qu'il peut y avoir des problèmes de sécurité avec cette manière de faire, mais on peut supprimer ces warnings "non standards".
Pour trouver la fonction qui est plus adaptée avec ce compilo, regarde sur le site de la MSDN.
Pour comprendre le pourquoi de ces warnings : http://msdn2.microsoft.com/en-us/library/ms404581.aspx

[mi6fred]

C'est exactement ce que je cherchais, merci !

Donc sous Windows, on remplace :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
virtual streamsize xsgetn(
   char_type *_Ptr,
   streamsize _Count
);

Par :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
virtual streamsize _Xsgetn_s(
    char_type *_Ptr,
    size_t _Ptr_size,
    streamsize _Count
);

Par contre je ne saisis pas vraiment l'intérêt de cette nouvelle version ... j'ai juste modifié ma fonction xsgetn standard en ajoutant cette ligne, je ne sais pas si c'est vraiment judicieux :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
#ifdef WIN32
	len = min(len, count);
#endif

En effet la doc Microsoft distingue longueur du tableau et nombre de caractères demandés. Dans mon esprit, on demandait assez de données pour remplir le tableau, si on en avait besoin de moins, il suffisait de réduire la taille 'len' du tableau en argument ...

Je vais commencer mes tests, dès que j'ai quelque chose de potable qui fonctionne, je poste.

[Matthieu Brucher]

L'objectif est de sécuriser au maximum les fonctions pour éviter des dépassement de mémoire, et autres. Pour une fois que Microsoft fait ce qu'il dit - ie promouvoir la sécurité - on leur tape dessus en disant qu'ils veulent faire leur propre standard