Hi All, I'm working on ways to make the Boost Interfaces library easier to use. This involves making interface definitions compile faster and making them easier to read. Unfortunately, these are somewhat conflicting goals: really messy-looking interface definitions may compile much faster than simple ones. I'm working on four approaches to interface definitions; I plan to implement them all and then compare them. Right now I'm looking for feedback on number 4: 1. The current IDL, possibly slightly modified, in which an interface definition consists of a sequence of macro invocation 2. A modified IDL in which an interface definition consists of a single invocation; this increases the amount of preprocessor metaprogramming but decreases the amount of template metaprogramming 3. The pseudocode IDL, together with an IDL compiler which translates pseudocode definitions into C++ class definitions requiring virtually no metaprogramming. 4. Hand written interfaces, requiring virtually no metaprogramming. The point of allowing hand-written interfaces is to decrease compile times. There's no question that writing interfaces by handle will be the most difficult of the above four options. Still, writing interfaces by hand has to be reasonably straightforward or no one will ever do it. So here's my question. Consider the interface: interface IBar { void foo(const char*); int foo(int, int); }; Is the following definition of IBar so complex that it would be pointless to offer it as an alternative? template< typename Derived, typename Base, typename Flags > struct ibar_impl { struct type : Base { struct interface_metadata : metadata_base<Derived, Base, Flags> { const char* names = { "foo", "foo" }; typedef mpl::vector< void(const char*), int(int, int) > signatures; }; void foo(const char* name) { return invoker<interface_metadata, 1>::execute(this, name); } int foo(int n, int m) { return invoker<interface_metadata, 2>::execute(this, int, int); } }; }; typedef interface< ibar_impl<_, _, _> > IBar; Best Regards, Jonathan
Jonathan Turkanis wrote:
Is the following definition of IBar so complex that it would be pointless to offer it as an alternative?
template< typename Derived, typename Base, typename Flags > struct ibar_impl { struct type : Base { struct interface_metadata : metadata_base<Derived, Base, Flags> { const char* names = { "foo", "foo" }; typedef mpl::vector< void(const char*), int(int, int) > signatures; }; void foo(const char* name) { return invoker<interface_metadata, 1>::execute(this, name); }
int foo(int n, int m) { return invoker<interface_metadata, 2>::execute(this, int, int); } }; };
I simplified it a bit: template< typename Derived, typename Base, typename Flags > struct ibar_impl { struct type : Base { struct interface_metadata : metadata_base<Derived, Base, Flags> { const char* names = { "foo", "foo" }; typedef mpl::vector< void(const char*), int(int, int) > signatures; }; void foo(const char* name) { return execute<1>(this, name); } int foo(int n, int m) { return execute<2>(this, int, int); } }; }; typedef interface< ibar_impl<_, _, _> > IBar; Jonathan
----- Original Message ----- From: "Jonathan Turkanis" <technews@kangaroologic.com> To: <boost@lists.boost.org> Sent: Friday, March 04, 2005 5:05 PM Subject: [boost] [interfaces] Hand written interfaces
Hi All,
I'm working on ways to make the Boost Interfaces library easier to use.
Yay!
This involves making interface definitions compile faster and making them easier to read. Unfortunately, these are somewhat conflicting goals: really messy-looking interface definitions may compile much faster than simple ones.
I'm working on four approaches to interface definitions; I plan to implement them all and then compare them. Right now I'm looking for feedback on number 4:
1. The current IDL, possibly slightly modified, in which an interface definition consists of a sequence of macro invocation 2. A modified IDL in which an interface definition consists of a single invocation; this increases the amount of preprocessor metaprogramming but decreases the amount of template metaprogramming 3. The pseudocode IDL, together with an IDL compiler which translates pseudocode definitions into C++ class definitions requiring virtually no metaprogramming. 4. Hand written interfaces, requiring virtually no metaprogramming.
The point of allowing hand-written interfaces is to decrease compile times. There's no question that writing interfaces by handle will be the most difficult of the above four options. Still, writing interfaces by hand has to be reasonably straightforward or no one will ever do it.
So here's my question. Consider the interface:
interface IBar { void foo(const char*); int foo(int, int); };
Is the following definition of IBar so complex that it would be pointless to offer it as an alternative? template< typename Derived, typename Base, typename Flags > struct ibar_impl { struct type : Base { struct interface_metadata : metadata_base<Derived, Base, Flags> { const char* names = { "foo", "foo" }; typedef mpl::vector< void(const char*), int(int, int) > signatures; }; void foo(const char* name) { return invoker<interface_metadata, 1>::execute(this, name); }
int foo(int n, int m) { return invoker<interface_metadata, 2>::execute(this, int, int); } }; };
typedef interface< ibar_impl<_, _, _> > IBar;
I think what would happen if you did this is that users would hand roll their own macros because it is just too ugly. That was the first thing I tried to do when I saw it. So I don't like it. The custom IDL pre-processor is my favourite option. One of the biggest advantages (apart from being much much faster), is that it can also include a built in optimizer and we will have more coherent errors output earlier. That is by far the biggest problem with the other three options. Christopher
christopher diggins wrote:
----- Original Message ----- From: "Jonathan Turkanis" <technews@kangaroologic.com> To: <boost@lists.boost.org> Sent: Friday, March 04, 2005 5:05 PM Subject: [boost] [interfaces] Hand written interfaces
Hi All,
I'm working on ways to make the Boost Interfaces library easier to use.
Yay!
This involves making interface definitions compile faster and making them easier to read. Unfortunately, these are somewhat conflicting goals: really messy-looking interface definitions may compile much faster than simple ones.
I'm working on four approaches to interface definitions; I plan to implement them all and then compare them. Right now I'm looking for feedback on number 4:
1. The current IDL, possibly slightly modified, in which an interface definition consists of a sequence of macro invocation 2. A modified IDL in which an interface definition consists of a single invocation; this increases the amount of preprocessor metaprogramming but decreases the amount of template metaprogramming 3. The pseudocode IDL, together with an IDL compiler which translates pseudocode definitions into C++ class definitions requiring virtually no metaprogramming. 4. Hand written interfaces, requiring virtually no metaprogramming.
The point of allowing hand-written interfaces is to decrease compile times. There's no question that writing interfaces by handle will be the most difficult of the above four options. Still, writing interfaces by hand has to be reasonably straightforward or no one will ever do it.
So here's my question. Consider the interface:
interface IBar { void foo(const char*); int foo(int, int); };
Is the following definition of IBar so complex that it would be pointless to offer it as an alternative? template< typename Derived, typename Base, typename Flags > struct ibar_impl { struct type : Base { struct interface_metadata : metadata_base<Derived, Base, Flags> { const char* names = { "foo", "foo" }; typedef mpl::vector< void(const char*), int(int, int) > signatures; }; void foo(const char* name) { return invoker<interface_metadata, 1>::execute(this, name); }
int foo(int n, int m) { return invoker<interface_metadata, 2>::execute(this, int, int); } }; };
typedef interface< ibar_impl<_, _, _> > IBar;
I think what would happen if you did this is that users would hand roll their own macros because it is just too ugly. That was the first thing I tried to do when I saw it. So I don't like it.
I didn't think of that. What's worse, I relized I left out part of the metadata, so the real definition would be even worse.
The custom IDL pre-processor is my favourite option. One of the biggest advantages (apart from being much much faster), is that it can also include a built in optimizer
Could you elaborate?
and we will have more coherent errors output earlier.
I'll formed interface definitions will be caught by the IDL compiler. But most errors will occur when users misuse an interface instance; by that time, the IDL compiler is out of the picture, and we have to rely on diagnostic machinery embedded in the C++ class definition. But this machinery can also be generated by macros.
Christopher
Jonathan
----- Original Message ----- From: "Jonathan Turkanis" <technews@kangaroologic.com> To: <boost@lists.boost.org> Sent: Friday, March 04, 2005 6:02 PM Subject: [boost] Re: [interfaces] Hand written interfaces
christopher diggins wrote:
----- Original Message ----- From: "Jonathan Turkanis" <technews@kangaroologic.com> To: <boost@lists.boost.org> Sent: Friday, March 04, 2005 5:05 PM Subject: [boost] [interfaces] Hand written interfaces
Hi All,
I'm working on ways to make the Boost Interfaces library easier to use.
Yay!
This involves making interface definitions compile faster and making them easier to read. Unfortunately, these are somewhat conflicting goals: really messy-looking interface definitions may compile much faster than simple ones.
I'm working on four approaches to interface definitions; I plan to implement them all and then compare them. Right now I'm looking for feedback on number 4:
1. The current IDL, possibly slightly modified, in which an interface definition consists of a sequence of macro invocation 2. A modified IDL in which an interface definition consists of a single invocation; this increases the amount of preprocessor metaprogramming but decreases the amount of template metaprogramming 3. The pseudocode IDL, together with an IDL compiler which translates pseudocode definitions into C++ class definitions requiring virtually no metaprogramming. 4. Hand written interfaces, requiring virtually no metaprogramming.
The point of allowing hand-written interfaces is to decrease compile times. There's no question that writing interfaces by handle will be the most difficult of the above four options. Still, writing interfaces by hand has to be reasonably straightforward or no one will ever do it.
So here's my question. Consider the interface:
interface IBar { void foo(const char*); int foo(int, int); };
Is the following definition of IBar so complex that it would be pointless to offer it as an alternative? template< typename Derived, typename Base, typename Flags > struct ibar_impl { struct type : Base { struct interface_metadata : metadata_base<Derived, Base, Flags> { const char* names = { "foo", "foo" }; typedef mpl::vector< void(const char*), int(int, int) > signatures; }; void foo(const char* name) { return invoker<interface_metadata, 1>::execute(this, name); }
int foo(int n, int m) { return invoker<interface_metadata, 2>::execute(this, int, int); } }; };
typedef interface< ibar_impl<_, _, _> > IBar;
I think what would happen if you did this is that users would hand roll their own macros because it is just too ugly. That was the first thing I tried to do when I saw it. So I don't like it.
I didn't think of that. What's worse, I relized I left out part of the metadata, so the real definition would be even worse.
The custom IDL pre-processor is my favourite option. One of the biggest advantages (apart from being much much faster), is that it can also include a built in optimizer
Could you elaborate?
If you were to write a separate stage pre-processor for the IDL then I believe you could more easily produce more efficient code simply due to the significant reduction in the complexity of the problem. I don't have any hard examples for you for the time being though, I would have study more the possibilities for optimization.
and we will have more coherent errors output earlier.
I'll formed interface definitions will be caught by the IDL compiler.
What do you mean by the IDL compiler? Do you mean the macros?
But most errors will occur when users misuse an interface instance;
It depends on the user. My own experience is that the large majority of my compilation errors have occured because of little typos in the IDL declarations. Then again I am a sloppy coder, my pascal days made me adopt the bad habit of using the compiler to catch syntactical errors.
by that time, the IDL compiler is out of the picture, and we have to rely on diagnostic machinery embedded in the C++ class definition. But this machinery can also be generated by macros.
Yes. Christopher Diggins Object Oriented Template Library (OOTL) http://www.ootl.org
christopher diggins wrote:
The custom IDL pre-processor is my favourite option. One of the biggest advantages (apart from being much much faster), is that it can also include a built in optimizer and we will have more coherent errors output earlier. That is by far the biggest problem with the other three options.
And the custom IDL pre-processor is my *least* favorite option :-) For the simple fact that it will slow adoption. As it will require another tool people will need to use. And that is especially painful for IDE users, where they may not have an easy way to change the tool functionality. I still prefer the current, CPP multiple macro, IDL because it presents many more option for use and doesn't require additional resources. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
Rene Rivera wrote:
christopher diggins wrote:
The custom IDL pre-processor is my favourite option. One of the biggest advantages (apart from being much much faster), is that it can also include a built in optimizer and we will have more coherent errors output earlier. That is by far the biggest problem with the other three options.
And the custom IDL pre-processor is my *least* favorite option :-) For the simple fact that it will slow adoption. As it will require another tool people will need to use. And that is especially painful for IDE users, where they may not have an easy way to change the tool functionality.
Good point.
I still prefer the current, CPP multiple macro, IDL because it presents many more option for use and doesn't require additional resources.
The reason I am searching for alternatives is that interfaces written with the current IDL take a long time to compile on some compilers (notably GCC). The sixty-four regression tests currently take between 40 minute and a hour to run, almost all of which is compilation, on GCC alone. Most of the tests involve a three-level hierarchy of 8 small interfaces. I guess I should have said in my first post that I am considering 3 and 4 to supplement 1 or 2. I'll chose between 1 or 2 at some future date. The FSM library gave me an idea for another compile-time optimization: allow interface implementations to be placed in .cpp files. It may seem strange that interfaces have implementation, but they do, and some of the metaprogramming is devoted to definig them. Interfaces whose implementations are separated this way would be slightly less efficient, but for some applications of interfaces, such as RPC, this shouldn't matter at all. Jonathan
"Jonathan Turkanis" <technews@kangaroologic.com> wrote in message news:d0am2b$7hu$1@sea.gmane.org...
Hi All,
I'm working on ways to make the Boost Interfaces library easier to use. This involves making interface definitions compile faster and making them easier to read. Unfortunately, these are somewhat conflicting goals: really messy-looking interface definitions may compile much faster than simple ones.
I'm working on four approaches to interface definitions; I plan to implement them all and then compare them. Right now I'm looking for feedback on number 4:
1. The current IDL, possibly slightly modified, in which an interface definition consists of a sequence of macro invocation 2. A modified IDL in which an interface definition consists of a single invocation; this increases the amount of preprocessor metaprogramming but decreases the amount of template metaprogramming 3. The pseudocode IDL, together with an IDL compiler which translates pseudocode definitions into C++ class definitions requiring virtually no metaprogramming.
I know you wanted feedback on #4, but please, please do not force upon us an IDL compiler. It complicates usage too much. // Johan
Johan Nilsson wrote:
"Jonathan Turkanis" <technews@kangaroologic.com> wrote in message
I know you wanted feedback on #4, but please, please do not force upon us an IDL compiler. It complicates usage too much.
The IDL compiler would never be the only way to generate interfaces; it would only be offered as an alterative. The same goes for #4. As for 1 #1 and #2, I'll probably eventually choose one or the other. Thanks for your input. Jonathan
participants (4)
-
christopher diggins -
Johan Nilsson -
Jonathan Turkanis -
Rene Rivera