Rene Rivera wrote:
Jonathan Turkanis wrote:
Matthew Vogt wrote:
Or the one I use for my project...
INHERITED(INTERFACE(DataTransferEvent),Event) ENUM(DataTransferEventType) NAME(Type VALUE(0x003)) ENUM_CLOSE ENUM(Request) NAME(DataExtent) NAME(Data) NAME(Complete) ENUM_CLOSE METHOD(DataTransferEvent::Request,getRequest,ARGS0,throw()) VOID_METHOD(getRequestData,ARGS2(UInt64&,UInt64&),throw()) VOID_METHOD(readDataExtent,ARGS1(UInt64&),throw()) VOID_METHOD(readData,ARGS3(UInt64&,UInt64&,Pointer&),throw()) METHOD(bool,isComplete,ARGS0,throw()) VOID_METHOD(setDataExtent,ARGS1(UInt64),throw()) VOID_METHOD(setData,ARGS3(UInt64,UInt64,Pointer),throw()) VOID_METHOD(setComplete,ARGS0,throw()) INTERFACE_CLOSE INTERFACE(Exception) METHOD(UString,getMessage,ARGS0,throw()) METHOD(UString,getDescription,ARGS0,throw()) DECLARE_NESTED(INTERFACE(PreconditionViolation)) DECLARE_NESTED(INTERFACE(InvalidArgument)) DECLARE_NESTED(INTERFACE(InvalidResult)) INTERFACE_CLOSE
Unfortunately, once you switch to the boost macro-naming conventions, having a macros to declare the argument list becomes a bit verbose: BOOST_IDL_VOID_METHOD(readData,BOOST_IDL_ARGS3(UInt64&,UInt64&,Pointer&)) I guess you could have the outer macro stick the prefix on the inner macro, so there wouldn't really be any ARGn macros. Is that what you do? The project you mention looks interesting. What sort of interfaces are you generating? Jonathan