Jump to page: 1 25  
Page
Thread overview
Fragile ABI
Aug 16, 2012
R Grocott
Aug 16, 2012
Kagamin
Aug 16, 2012
Piotr Szturmaj
Aug 18, 2012
Ivan Trombley
Aug 21, 2012
Kagamin
Aug 20, 2012
Jacob Carlborg
Aug 16, 2012
R Grocott
Aug 16, 2012
Paulo Pinto
Aug 16, 2012
R Grocott
Aug 17, 2012
Jacob Carlborg
Aug 22, 2012
xenon325
Aug 22, 2012
Jacob Carlborg
Aug 20, 2012
Kagamin
Aug 20, 2012
R Grocott
Aug 21, 2012
Paulo Pinto
Aug 21, 2012
Kagamin
Aug 21, 2012
David Piepgrass
Aug 21, 2012
Paulo Pinto
Aug 22, 2012
David Piepgrass
Aug 22, 2012
Paulo Pinto
Aug 22, 2012
Michel Fortin
Aug 22, 2012
Paulo Pinto
Aug 23, 2012
Kagamin
Aug 17, 2012
dsimcha
Aug 17, 2012
R Grocott
Aug 17, 2012
Michel Fortin
Aug 17, 2012
Paulo Pinto
Aug 17, 2012
R Grocott
Aug 17, 2012
Michel Fortin
Aug 17, 2012
Paulo Pinto
Aug 17, 2012
Michel Fortin
Aug 17, 2012
Paulo Pinto
Aug 18, 2012
Michel Fortin
Aug 18, 2012
Andrej Mitrovic
Aug 18, 2012
Paulo Pinto
Aug 18, 2012
Michel Fortin
Aug 18, 2012
Paulo Pinto
Aug 18, 2012
Jacob Carlborg
Aug 18, 2012
Michel Fortin
Aug 18, 2012
R Grocott
Aug 18, 2012
Michel Fortin
Aug 18, 2012
R Grocott
Aug 18, 2012
Jacob Carlborg
Aug 17, 2012
R Grocott
Aug 17, 2012
Michel Fortin
Aug 18, 2012
Jacob Carlborg
Aug 17, 2012
Jacob Carlborg
August 16, 2012
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
You can also use C++ to develop COM components which have standardized ABI.
August 16, 2012
Kagamin wrote:
> You can also use C++ to develop COM components which have standardized ABI.

...only on Windows.
August 16, 2012
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
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
> 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
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
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
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
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