Question

I have a project that contains several submodules, that communicate using some objects that are serialized by one process and then deserialized by another process and used at this other point. So these objects need to contain logic for usage in the first process, in the second process as well as serialization and deserialization logic.

To simplify building the project each process first builds a library and then links with that library (using a specialized main) to build the actually process. All the parts that handle communication (i.e. all the cross cutting objects) are also contained in other more general libraries.

Now the problem is that the code for usage of the generic library contains methods that reference other objects from the second process. So the structure is something like this:

• ProcessA:
  • Depends on libA libGeneric
• ProcessB:
  • Depends on libB libGeneric
• libGeneric contains code that references parts of libA and libB

This way I get a dependency of processA for libB that I do not want. The dependency is just to satisfy the linker, because the code that uses libB is never actually called (but the linker will not know this). So for now I am linking in libB into processA although the code from that lib wont ever be executed.

Is there a better way to handle such a situation? Another Idea would be to just define the interface and only include the methods that are actually used everywhere in libGeneric and put the other methods into libB. However then I would split up object from libGeneric which would make maintenance harder.

I am using G++ 4.4 for compilation.

---

edit:
since I cannot post code from the actual project here some structured pseudocode that might show the problem more clearly:

class Record {
public:
  void produce(...) // called from Process A
  std::string serialize() const;
  void deserialize(const std::string &);

  void do_something(queue) { // called from process B
    // this logic is actually more complicated (depends on subclasses of Record)
    // i.e. cannot be moved out of this class without getting ugly
    queue.add_for_further_processing( this ); // The queue is part of ProcessB
  }
};

From this the best method seems to remove all threading stuff (of which the queue is part) to a common submodule and then have all processes use that.

Answer 1

One way to solve this is to dynamically link with libB (if the size of the executable is your concern).

The other option is to take the common code out of libA and libB into a library (libC). Then, your programs will need to link with libA and libC, and libB and libC.

I do not see other way around this.