[Prev][Next][Index][Thread]
Re: com and gcc question
> BTW, is COM used in oskit in it's binary form, or is it just a model
> to base code on? I ask because binary COM will come crashing down if
> oskit is ported to 64-bit architectures.
This is too subtle a distinction for me so let me show you what we do.
Here's the essential part of oskit/fs/filesystem.h.
/*
* Basic file system object interface,
* IID 4aa7df93-7c74-11cf-b500-08000953adc2.
*/
struct oskit_filesystem {
struct oskit_filesystem_ops *ops;
};
typedef struct oskit_filesystem oskit_filesystem_t;
struct oskit_filesystem_ops {
OSKIT_COMDECL (*query)(oskit_filesystem_t *f,
const struct oskit_guid *iid,
void **out_ihandle);
OSKIT_COMDECL_U (*addref)(oskit_filesystem_t *f);
OSKIT_COMDECL_U (*release)(oskit_filesystem_t *f);
OSKIT_COMDECL (*statfs)(oskit_filesystem_t *f,
oskit_statfs_t *out_stats);
OSKIT_COMDECL (*sync)(oskit_filesystem_t *f, oskit_bool_t wait);
OSKIT_COMDECL (*getroot)(oskit_filesystem_t *f,
struct oskit_dir **out_dir);
OSKIT_COMDECL (*remount)(oskit_filesystem_t *f,
oskit_u32_t flags);
OSKIT_COMDECL (*unmount)(oskit_filesystem_t *f);
OSKIT_COMDECL (*lookupi)(oskit_filesystem_t *f, oskit_ino_t ino,
struct oskit_file **out_file);
};
Given the standard assumption that structs of pointers are layed out
the same as arrays of pointers, you can read it as saying that for a
oskit_filesystem_t* object fs,
(*fs)[0] = query
(*fs)[1] = addref
(*fs)[2] = release
...
which is what the COM standard requires and will work on both 32 and
64 bit architectures assuming, as I say, that structs of ptrs are
layed out the same way as arrays of ptrs.
In fact, since all our code uses struct decls like the above, I think
all our code will be consistent even without this assumption - it just
won't be "COM" anymore and people calling our objects from other
languages like ML would have to figure out how our structs were being
layed out.
HTH
--
Alastair Reid reid@cs.utah.edu http://www2.cs.utah.edu/~reid/
References: