Boost logo

Boost :

From: christopher diggins (cdiggins_at_[hidden])
Date: 2005-03-04 19:13:18

----- Original Message -----
From: "Jonathan Turkanis" <technews_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Friday, March 04, 2005 6:02 PM
Subject: [boost] Re: [interfaces] Hand written interfaces

> christopher diggins wrote:
>> ----- Original Message -----
>> From: "Jonathan Turkanis" <technews_at_[hidden]>
>> To: <boost_at_[hidden]>
>> 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.


Christopher Diggins
Object Oriented Template Library (OOTL)

Boost list run by bdawes at, gregod at, cpdaniel at, john at