D
Danilo Kempf
Folks,
maybe one of you could be of help with this question: I've got a relatively
portable application which I'm extending with a plugin interface. While
portability (from a C perspective) is going to hell just by using
dlopen()/LoadLibrary() respectively, I'm still trying to get it as clean as
possible.
I have a number of different quantums of data and a number of plugins. Since
any plugin can (and possibly will) touch any quantum of data, I have a
many-to-many relationship here.
Now, every plugin can store some "private" data associated to every quantum
it has done some work on.
I thought, I'd realize this with some kind of dictionary. Every plugin gets
a unique key and can (using this key) store an arbitrary value. The
dictionary is implemented as a sorted array - so using the key, the stored
value can be retrieved by a simple binary search.
I thought I could use a "private" pointer for the key. Say, every plugin
uses a pointer to a global variable from the plugin library or a pointer to
some space it has just allocated as the key for the dictionary.
Now my question is, whether this is really portable C. Can pointer values
(coming from different allocation units, pointing to global storage or even
function pointers that were cast' to void *) be compared with each other,
so that I get my sorted array right?
Im sure they can be compared for (in)equality, but for sorting the
dictionary I need a (deterministic) is-less-than comparison at least. Would
casting those pointers to intptr_t help? Does intptr_t guarantee that two
pointers pointing to different things get different intptr_t values?
Sure, I can implement some entity that hands out unique integers or so as
keys, but if I don't have to do this, I'd rather prefer not doing so.
Im furiously searching through the (draft) standard, but I haven't found a
definitive answer yet.
Any thoughts on this are very much appreciated.
Best regards,
Danilo
maybe one of you could be of help with this question: I've got a relatively
portable application which I'm extending with a plugin interface. While
portability (from a C perspective) is going to hell just by using
dlopen()/LoadLibrary() respectively, I'm still trying to get it as clean as
possible.
I have a number of different quantums of data and a number of plugins. Since
any plugin can (and possibly will) touch any quantum of data, I have a
many-to-many relationship here.
Now, every plugin can store some "private" data associated to every quantum
it has done some work on.
I thought, I'd realize this with some kind of dictionary. Every plugin gets
a unique key and can (using this key) store an arbitrary value. The
dictionary is implemented as a sorted array - so using the key, the stored
value can be retrieved by a simple binary search.
I thought I could use a "private" pointer for the key. Say, every plugin
uses a pointer to a global variable from the plugin library or a pointer to
some space it has just allocated as the key for the dictionary.
Now my question is, whether this is really portable C. Can pointer values
(coming from different allocation units, pointing to global storage or even
function pointers that were cast' to void *) be compared with each other,
so that I get my sorted array right?
Im sure they can be compared for (in)equality, but for sorting the
dictionary I need a (deterministic) is-less-than comparison at least. Would
casting those pointers to intptr_t help? Does intptr_t guarantee that two
pointers pointing to different things get different intptr_t values?
Sure, I can implement some entity that hands out unique integers or so as
keys, but if I don't have to do this, I'd rather prefer not doing so.
Im furiously searching through the (draft) standard, but I haven't found a
definitive answer yet.
Any thoughts on this are very much appreciated.
Best regards,
Danilo