C
Case
I've had some discussions with colleagues about the
API of a module for sending/receiving messages on a
network connection.
On both ends are different applications, each having
their own internal way of storing the data which has
to be communicated (using a common data protocol).
I proposed to use a common interface, having the face
of the network data protocol (XYZ). Many fields in the
protocol message are optional. I proposed to use a
bit-field structure. To prevent one extra copy of
large chucks of data, I proposed to use pointers.
typedef struct
{
unsigned int number1 : 1;
unsigned int number2 : 1;
unsigned int much_data : 8; /* > 0 means length */
} XYZ_ind;
typedef struct
{
int number1;
int number2;
char *much_data;
XYX_ind_t ind;
} XYZ_data_t;
void XYZ_send(XYZ_data_t *data); /* encodes, then sends */
The receiving side uses a callback, with similar prototype.
Both sides will now have to convert their own internal format
to a XYZ_data_t structure. This creates a clea[n|r] interface,
making the XYZ module independent of either side.
The 'opposing' idea is to not specify a common interface for
all users. So, no XYZ_data_t. Instead of one shared XYZ_send(),
there will be two: A_send(A_data_t *) and B_send(B_data *).
Instead of one module, there will be three.
The only advantage above having a real interface, is performance:
no conversion between internal format to XYZ_data_t (which is not
much more than assignments). The A_send() and B_send() will both
encode the message in their own way, and right away.
Yes, we are working on time-critical stuff, but I have the feeling
that this second approach falls in the 97% of the 'premature opti-
mization, being the root of all evil'. I estimated that the clean
interface may add about 1/1000 to the execution time.
Any thoughts on this issue?
Case
API of a module for sending/receiving messages on a
network connection.
On both ends are different applications, each having
their own internal way of storing the data which has
to be communicated (using a common data protocol).
I proposed to use a common interface, having the face
of the network data protocol (XYZ). Many fields in the
protocol message are optional. I proposed to use a
bit-field structure. To prevent one extra copy of
large chucks of data, I proposed to use pointers.
typedef struct
{
unsigned int number1 : 1;
unsigned int number2 : 1;
unsigned int much_data : 8; /* > 0 means length */
} XYZ_ind;
typedef struct
{
int number1;
int number2;
char *much_data;
XYX_ind_t ind;
} XYZ_data_t;
void XYZ_send(XYZ_data_t *data); /* encodes, then sends */
The receiving side uses a callback, with similar prototype.
Both sides will now have to convert their own internal format
to a XYZ_data_t structure. This creates a clea[n|r] interface,
making the XYZ module independent of either side.
The 'opposing' idea is to not specify a common interface for
all users. So, no XYZ_data_t. Instead of one shared XYZ_send(),
there will be two: A_send(A_data_t *) and B_send(B_data *).
Instead of one module, there will be three.
The only advantage above having a real interface, is performance:
no conversion between internal format to XYZ_data_t (which is not
much more than assignments). The A_send() and B_send() will both
encode the message in their own way, and right away.
Yes, we are working on time-critical stuff, but I have the feeling
that this second approach falls in the 97% of the 'premature opti-
mization, being the root of all evil'. I estimated that the clean
interface may add about 1/1000 to the execution time.
Any thoughts on this issue?
Case