How to big structures across libraries

Hi,

I have written library in c++ for c++ application. Here, data exchange between library and client through structure. This structure has 20 members ( strings, integers, reals, pointers).

In some flows, library needs few members should get filled in the structure. for ex, application filled 3 integers information and passed to structure. But, in memory, whole structure is occupied.

I think, If library provides functions for every combination, then it would end up with lot of functions. I want to avoid that.

How to optimize data exchange between client and library? ( number of members may be filled sometimes 1, 2, 3, .. 20)

Thanks.

You can add an additional member to your struct; this should be a bit-mask where each bit corresponds one member of the struct: if 1 - the correspondent member must be taken into account, if 0 - it must be ignored.
A lot of Windows API functions works that way.

Quote:

---

Originally Posted by coolstuff123

I have written library in c++ for c++ application

---

dll ? or static ? ( it does matter, see below )

VictorN's suggestion is great ( moreover, following winapi, the struct could have a first member containing the (known) size of the struct itself or the like; in this way, you can have varying size "input" structures, or manage versions, or layout flat/non-flat containers in memory (like non mutable linked lists) transparently etc ... )

... if it were a c-library.

But you mentioned a c++ library, so the wild proliferation of public members is probably an indication of bad design. Are you sure you can't refactor that combinatorially growing data exchanges in terms of simpler, orthogonal abstractions ? ( this could lead not only to a smaller code base and better mantainability, but possibly also better performance if properly exploited )

... unless this is a dll, in this case ABI ( and client compatibility ) should be taken into account and a simpler, maybe even c-based design might be better ... ( eventually with a thin c++ wrapper used by c++ clients ).

I am not familiar with Windows APIs. Can you point any one API. I will go through their documentation.

@superbonzo, not a dll.

>>he wild proliferation of public members is probably an indication of bad design
Agreed.

>>Are you sure you can't refactor
I am planning to refactor this now. Any design document or open source avail for this requirement. Please share if any.

Quote:

---

Originally Posted by coolstuff123

I am not familiar with Windows APIs. Can you point any one API. I will go through their documentation.

---

LVITEM structure
LVFINDINFO

Quote:

---

Originally Posted by coolstuff123

I am planning to refactor this now. Any design document or open source avail for this requirement. Please share if any.

---

it's hard to give any refactoring advice withouth knowing the purpose/domain of your library; could you post an example of a typical usage of your library functions/classes ( possibly showing a use case where method proliferation manifests itself ) ?

the problem with special structures that handle internal memory management like string, vector, list, map... (and even basic new, delete for that matter since that's C++ runtime managed)is that they depend on a specific version and instance of the C++ runtime library that contains the code for those structures.

if your own code is in a dll, that dll may not have been built with that same specific version of the runtime and as such have different assumptions about the internal structures. This is a surefire way to cause bugs. They could be extremely Obvious but they could also be extremely subtle but therefor no less problematic.

even if your code is in a library there could be issues with trying to pass such things.

that's why for libraries and dll's where you do not provide actual code, it's typically best to make your API's take basic types and not make assumptions about memory management. One way out of that is to provide your API's as COM.

There is a reason why there is a trend in C++ to deliver libraries with code, because it's hard for some libs to make basic API's via a dll (and not everyone likes dll's), and it's equally hard to provide .lib files for every possible brand and version of compiler.