Many structs in one header file for this client/server situation (C++)

I'm trying to decide if this is not very nice, or not. Basically, I am writing a client server system. To make it easier and less error prone, I decided all requests/responses/etc. between client and server should be defined as structs in a shared library that is used by both the client and server, and then have a serialization layer that knows how to serialize the structs (again used by both).

For example:

Shared Library:

requestparamstructs.h

#ifndef REQUEST_PARAMS_H
#define REQUEST_PARAMS_H

struct CreateUserRequestParams
{
    std::string name;
    std::string address;
    std::string username;
    int age;
    ..
    ..
};

struct CreateItemRequestParams
{
    std::string name;
    std::string description;   
};

..
..

#endif

And then somewhere in my client:

client.h

CreateUserRequestParams p;
p.name = "Foo";
p.address = "Somewhere";
p.username = "mrfoo";

Request<CreateUserRequestParams> myRequest(p);

client.queueRequest(myRequest);

And then the server receives the request, creates the appropriate struct with a factory and unserializes and performs whatever it needs to do.

Now initially I was putting each struct in a seperate file, but this seems like overkill.

Does putting these structs in a single header like this give you convulsions? The only thing missing I guess is a default constructor to initialise the variables which then makes it more of a class, which then feels like it should be separate files.

Bear in mind I'm going to need to create a lot of these..

Thanks!

EDIT:

1) Just to clarify, this is a client server system that communicates via TCP/IP. There's no shared memory involve. The "shared library" is just code shared in a .lib file and linked in. All the common code that both the client and server can use is put here.

2) Parameterized templates would be great, I think, unfortunately VS2010 does not support variadic templates. At one point I was thinking of something like this:

template <Protocol::ClientRequest RequestCode, typename P1>
class RequestP1 : public Request
{
public:
    RequestP1() : Request(RequestCode) {}
    RequestP1(P1 p1) : Request(RequestCode), m_p1(p1) {}
    virtual void serialize(IArchive &ar)
    {
        serialize(ar, m_p1);
    }
    P1 m_p1;
};

template <Protocol::ClientRequest RequestCode, typename P1, typename P2>
class Reques开发者_开发知识库tP2 : public Request
{
public:
    RequestP2() : Request(RequestCode) {}
    RequestP2(P1 p1, P2 p2) : Request(RequestCode), m_p1(p1), m_p2(p2) {}
    virtual void serialize(IArchive &ar)
    {
        serialize(ar, m_p1);
        serialize(ar, m_p2);
    }
    P1 m_p1;
    P2 m_p2;
};

..
..

Which would allow me to do this:

typedef RequestP1<Protocol::CreateUser, CreateUserRequestParams> RequestCreateUser;

OR specifying the actual params (just showing the first two params here, name and address):

typedef RequestP1<Protocol::CreateUser, std::string, std::string> RequestCreateUser;

Hope that makes sense..

---

Does putting these structs in a single header like this give you convulsions?

No.

Assuming that your server and your client both use most (if not all) of the requests (and hence the *Params objects are used on both sides), the only thing that would make me consider putting them into separate files is the type of their fields.

As long as your parameter objects just have primitives or common types like std::string, I'm fine. However, if you happen to introduce a message which uses types which are not defined in the standard library (e.g. a QPixmap of Qt or the like), I would consider moving that message (and other messages with the same dependencies) into a separate file so that only those clients which need to use those parameters have to pull in the dependencies. I suspect that this is unlikely in your case, so putting all of the Param structs into one file is fine IMHO.

However, if it turns out that there are huge differences in the set of *Param objects used by different clients, I'd consider putting related groups into separate files to reduce compile-time dependencies. Otherwise, adding a new Param type to a group means recompiling all clients - even those, which don't use the corresponding message.