N
nroberts
I'm having trouble figuring out how to get seemingly mutually
exclusive goals and criteria to work together.
The technical lead/architect for the project I'm on is from an
embedded background and therefore doesn't like heap allocation. I
don't know if this is a real issue in that domain, having never done
it myself, but that's what he's told me when complaining about my use
of allocated buffers and such. Factory like functions also seem to
upset him. I'm not so sure about function pointers, but every time
I've made something that wasn't of the direct call, stack or global
variable kind of design he's kind of freaked out on me.
At the same time he wants me to write reusable code and has previously
wanted me to make unit tests, though now I'm not even sure about that
since he won't even look at them.
I'm getting kind of pissed off to tell the truth, but I still want to
try.
I'm coming into a project where the best solution seems to be a
multithreaded service. It's basically a proxy for a soap server
created by a third party that we're making generic and less soapy in
order for our various products to use it. Some of the calls can take
a long time and writing it multithreaded allows us to use the gsoap
library without having to muck about to use it asynchronously as it
doesn't really support such use.
I created a prototype for this service in C++ using all the
allocation, RAII, polymorphism, etc...so I could get a clear picture
of the problem. Now I need to convert the design into C (I'm fairly
certain he's going to tell me to). Normally this would be fairly
easy, replace exception processing with error codes, rewrite std::list
and such for all the types I want to hold or to use void*...use opaque
types and createXXX() functions... I'm not doing anything
particularly incredible with the C++, it could almost as easily be C.
This kind of stuff doesn't fly here though.
I can create circular buffer stacks to handle things like my thread
pools instead of allocating stack nodes. I can just declare my opaque
types openly and have initXXX() functions. Etc...I think this kind of
thing would make the guy happy but I don't see how to do that while
also meeting another goal he's said I need to meet: make this thing so
that it's a generic architecture for any soap connecting proxy. I
can't think of how to do such circular buffer stacks for specific
types (because I can't allocate) and still write them in a way that
can be used in different ways.
How does one make reusable components without at least some generics
and heap allocations? When everything has to be a direct call, how do
you allow clients to override behavior? What are some idioms,
patterns, whatever that I can use to at least make some attempt at
getting both of these ideals to work together?
exclusive goals and criteria to work together.
The technical lead/architect for the project I'm on is from an
embedded background and therefore doesn't like heap allocation. I
don't know if this is a real issue in that domain, having never done
it myself, but that's what he's told me when complaining about my use
of allocated buffers and such. Factory like functions also seem to
upset him. I'm not so sure about function pointers, but every time
I've made something that wasn't of the direct call, stack or global
variable kind of design he's kind of freaked out on me.
At the same time he wants me to write reusable code and has previously
wanted me to make unit tests, though now I'm not even sure about that
since he won't even look at them.
I'm getting kind of pissed off to tell the truth, but I still want to
try.
I'm coming into a project where the best solution seems to be a
multithreaded service. It's basically a proxy for a soap server
created by a third party that we're making generic and less soapy in
order for our various products to use it. Some of the calls can take
a long time and writing it multithreaded allows us to use the gsoap
library without having to muck about to use it asynchronously as it
doesn't really support such use.
I created a prototype for this service in C++ using all the
allocation, RAII, polymorphism, etc...so I could get a clear picture
of the problem. Now I need to convert the design into C (I'm fairly
certain he's going to tell me to). Normally this would be fairly
easy, replace exception processing with error codes, rewrite std::list
and such for all the types I want to hold or to use void*...use opaque
types and createXXX() functions... I'm not doing anything
particularly incredible with the C++, it could almost as easily be C.
This kind of stuff doesn't fly here though.
I can create circular buffer stacks to handle things like my thread
pools instead of allocating stack nodes. I can just declare my opaque
types openly and have initXXX() functions. Etc...I think this kind of
thing would make the guy happy but I don't see how to do that while
also meeting another goal he's said I need to meet: make this thing so
that it's a generic architecture for any soap connecting proxy. I
can't think of how to do such circular buffer stacks for specific
types (because I can't allocate) and still write them in a way that
can be used in different ways.
How does one make reusable components without at least some generics
and heap allocations? When everything has to be a direct call, how do
you allow clients to override behavior? What are some idioms,
patterns, whatever that I can use to at least make some attempt at
getting both of these ideals to work together?