View mode: basic / threaded / horizontal-split · Log in · Help
August 16, 2012
Fragile ABI
http://michelf.ca/blog/2009/some-ideas-for-dynamic-vtables-in-d/

The above blog post, written in 2009, proposes a system for 
solving the Fragile ABI Problem in D. Just wondering whether 
anything like this is a planned feature for druntime.

C++'s fragile ABI makes it very difficult to write class 
libraries without some sort of workaround. For example, RapidXML 
and AGG are distributed as source code; GDI+ is a header-only 
wrapper over an underlying C interface; and Qt makes heavy use of 
the Pimpl idiom, which makes its source code much more complex 
than it needs to be. This is also a major problem for any program 
which wants to expose a plugin API.

It would be nice if D could sidestep this issue. It's frustrating 
that C is currently the only real option for developing native 
libraries without worrying about their ABI.
August 16, 2012
Re: Fragile ABI
You can also use C++ to develop COM components which have 
standardized ABI.
August 16, 2012
Re: Fragile ABI
Kagamin wrote:
> You can also use C++ to develop COM components which have standardized ABI.

...only on Windows.
August 16, 2012
Re: Fragile ABI
I'm aware that just exposing class interfaces (via COM or other 
means) is an option, but that tends to cause many problems of its 
own:

- You can no longer call new or delete on the underlying class; 
you're obliged to use factory methods. This leads to issues with 
templates and stack allocation (although this will be less of an 
issue for D compared to C++).

- You can't directly inherit from any of the library's classes. 
This is an issue for any library which wants to allow "custom 
components" (for example, widgets in a GUI toolkit, dialog boxes 
in a browser plugin, or controls in a desktop panel). Coding 
strictly against interfaces is one workaround, but that often 
makes things more complicated than they need to be.

- The library can't provide template methods for classes exposed 
this way, and class methods can no longer be inlined.

- It forces the developer to maintain both a public interface and 
a private implementation; he can no longer code as though he's 
writing classes for his own use.

All of these are relatively minor issues, but taken together, 
they make library development quite difficult. For example, I 
think it would be almost impossible to develop a COM GUI toolkit.
August 16, 2012
Re: Fragile ABI
On Thursday, 16 August 2012 at 16:25:01 UTC, R Grocott wrote:
>
> All of these are relatively minor issues, but taken together, 
> they make library development quite difficult. For example, I 
> think it would be almost impossible to develop a COM GUI 
> toolkit.

And yet that is what DirectX and WinRT are all about.

When you use programming models like COM, you are programming
against interfaces, this is also know as component model 
programming
in the CS papers.

Your GUI toolkit just needs to expose interfaces for the different
types of events it is required to handle, and you give via API 
calls
objects whose instances implement said interfaces.

To avoid too much code rewrite, some component systems, COM 
included,
support a form of delegation where you can implement just a part 
of the
interface, while delegating the remaining calls to a contained 
object.

--
Paulo
August 16, 2012
Re: Fragile ABI
> And yet that is what DirectX and WinRT are all about.

DirectX, yes: it's a good example of an OO library with a purely 
interface-based API. The only DirectX plugin architecture I can 
bring to mind, though (DirectShow filters), actually uses C++ 
classes (such as CSource) to hide a lot of the underlying 
complexity. I get the impression that wouldn't be necessary if 
interface-based plugins were as simple to create as 
inheritance-based ones.

Likewise, WinRT actually hides a huge amount of complexity inside 
its language bindings. Inheriting from a WinRT object using only 
the underlying COM interfaces involves a lot of hassle, and is a 
prime example of what I'm talking about. See here:

http://www.interact-sw.co.uk/iangblog/2011/09/25/native-winrt-inheritance


> Your GUI toolkit just needs to expose interfaces for the 
> different
> types of events it is required to handle, and you give via API 
> calls
> objects whose instances implement said interfaces.
>
> To avoid too much code rewrite, some component systems, COM 
> included,
> support a form of delegation where you can implement just a 
> part of the
> interface, while delegating the remaining calls to a contained 
> object.

That sounds clean in theory - but so does Pimpl, and I know from 
experience that Pimpl tends to make a horrible mess out of any 
codebase. It doesn't help that, as far as I know, COM is 
Windows-only, and D doesn't natively support the 
method-defaulting system you described.

In practice, I think that proper interoperability w/r/t classes 
and inheritance will tend be cleaner than coding strictly against 
an interface. This can be demonstrated by choosing any base-class 
derived-class pair, from any OO codebase, and attempting to 
rewrite that parent-child relationship as a server-client one.
August 17, 2012
Re: Fragile ABI
On Thursday, 16 August 2012 at 14:58:23 UTC, R Grocott wrote:
> C++'s fragile ABI makes it very difficult to write class 
> libraries without some sort of workaround. For example, 
> RapidXML and AGG are distributed as source code; GDI+ is a 
> header-only wrapper over an underlying C interface; and Qt 
> makes heavy use of the Pimpl idiom, which makes its source code 
> much more complex than it needs to be. This is also a major 
> problem for any program which wants to expose a plugin API.

Since pimpl is useful but messy, given D's metaprogramming 
capabilities, maybe what we need is a Pimpl template in Phobos:

// The implementation struct.
struct SImpl {
   int a, b, c;

   void fun() {}
}

// Automatically generate code for the Pimpl wrapper.
alias Pimpl!SImpl S;

auto s = new S;

On the other hand, IIUC Pimpl doesn't solve the vtable part of 
the problem, only the data members part.  (Correct me if I'm 
wrong here, since I admit to knowing very little about the 
fragile ABI problem or its workarounds.)
August 17, 2012
Re: Fragile ABI
Hm. Come to think of it, I have another question for somebody 
knowledgeable about this stuff:

The blog post I linked only talks about rewriting vtables at 
dynamic-link-time. Would it be possible to implement something 
similar for the sizes of structs and scope-classes, and the 
relative address of member variables? dsimcha's post has led me 
to realize that without these additional features, the ABI would 
still be quite fragile.

I know very little about dynamic linking, but I guess it might be 
too expensive to justify? If nothing else, it would probably 
block a few compile-time optimisations (since offsets and sizes 
would have to be treated as unknown variables rather than integer 
constants).
August 17, 2012
Re: Fragile ABI
On 2012-08-16 14:58:22 +0000, "R Grocott" <rgrocottbugzilla@gmail.com> said:

> http://michelf.ca/blog/2009/some-ideas-for-dynamic-vtables-in-d/
> 
> The above blog post, written in 2009, proposes a system for solving the 
> Fragile ABI Problem in D. Just wondering whether anything like this is 
> a planned feature for druntime.

I wrote this post. I'd still like to have a non-fragile ABI. But 
there's probably a tradeoff to make: if you want absolute performance, 
a non-fragile ABI will get in your way. If you're writing a GUI 
toolkit, performance probably isn't going to be your biggest concern, 
but if you're writing a game it might.

So I think this problem would be worth solving in a way that allows the 
designer of a class to choose.


> It would be nice if D could sidestep this issue. It's frustrating that 
> C is currently the only real option for developing native libraries 
> without worrying about their ABI.

It's frustrating indeed.

The D/Objective-C proof of concept I developed is interesting in this 
regard: extern(Objective-C) classes have a non-fragile ABI (for 
methods, and for fields too if I add support for Apple's modern 
runtime). So basically you have fragile and non-fragile objects living 
together, using two distinct class hierarchies. The extern(Objective-C) 
hierarchy being the non-fragile one, but slightly slower too.


-- 
Michel Fortin
michel.fortin@michelf.ca
http://michelf.ca/
August 17, 2012
Re: Fragile ABI
On Thursday, 16 August 2012 at 14:58:23 UTC, R Grocott wrote:
> http://michelf.ca/blog/2009/some-ideas-for-dynamic-vtables-in-d/
>
> The above blog post, written in 2009, proposes a system for 
> solving the Fragile ABI Problem in D. Just wondering whether 
> anything like this is a planned feature for druntime.
>
> C++'s fragile ABI makes it very difficult to write class 
> libraries without some sort of workaround. For example, 
> RapidXML and AGG are distributed as source code; GDI+ is a 
> header-only wrapper over an underlying C interface; and Qt 
> makes heavy use of the Pimpl idiom, which makes its source code 
> much more complex than it needs to be. This is also a major 
> problem for any program which wants to expose a plugin API.
>
> It would be nice if D could sidestep this issue. It's 
> frustrating that C is currently the only real option for 
> developing native libraries without worrying about their ABI.

The is only so, because in most mainstream OSs, the C ABI is the 
OS ABI.

If you make use of an OS written in, lets say Modula-2, then the 
OS ABI
would be a Modula-2 ABI, which even C would have to comply to 
somehow.

I think z/OS, if I'm not mistaken on the OS, is one of the few OS 
where
you have a good ABI across multiple languages.

This is similar to what Microsoft somehow tries to achieve with 
COM and .NET.

--
Paulo
« First   ‹ Prev
1 2 3 4 5
Top | Discussion index | About this forum | D home