Qt 4 Preview 2 Highlights Accessibility; D-BUS Bindings for Qt 4

I cant agree with this. It not the existing features that make C bad (outdated) its the missing ones! You can use better programming strategies that dont exist in C.

And I wouldn't really call the linux kernel trustworthy...

> I wonder if any of you people have even looked at the dbus code ?? - I have and it looks well written, so why not just accept that some cool programs is written in C and others in C++ (and Haskell, and Java, and C#, and ....).

last time I checked there was glib code pasted into it, but that was like a year ago or so. Overall I wasn't impressed.

> Ohh do you really mean that reading C++ is easier than C ?

Sure it is. Every C++ program follows roughly the same rules. On the other hand for every C library that I use you have to learn a new "object emulation model" or some more or less crazy API.

> C++ is much more complex than C
Yeah, try reading the boost libraries. Even the STL files, in/usr/include/c++/, can be hard to follow. But don't get me wrong, the result is _very_ powerfull both in features as in speed. But indeed KDE's includes are easy to read.
Actually I was quite happy to only have to recompile libfam and Qt/KDE, when upgrading gcc from 3.3 to 3.4. Not to mention the compile time difference. Long live C, and may every library, that I don't have to use, be implemented in C. And which I do use, well mostly it doesn't really matter.

What's really a swamp is building on top of win32, because you don't know what beneath you (and you get sucked away as soon as it becomes too popular).

Interacting with a messaging bus and deeply integrating poorly abstracted code into the kernel are about as similar as installing phone lines are to building on top of another house. Getting a message or not getting a message where a client is in trouble is not the same as the client code blocking the kernel when it crashes because they are directly linked.

The key here is that a messaging system can provide the benefits with a huge buffering effect reducing the issues to a fraction of the problems possible with deep integration. This should affect your need to reboot about as much as a web site going down unless it's done very poorly.

Not too long ago the C++ ABI was standardised. I am not 100% sure but I think its based on an aggreement between gcc and intel.

Not if you are using something like Smoke.

The problem with bindings is the ABI not C++ itself. Name mangling, virtual (method) table structure, memory alignment and calling conventions are the main issues that must be solved for a working binding. And who known better about these ABI things than the compiler for the API itself. So instead of finding out how to map the C++ ABI to Delphi' ABI and invest additional time when a new gcc is released (gcc had a really inconsitent ABI in the past), you "simply" write a C wrapper shared object in C++ and recompile this when gcc has changed.

It is possible to map the C++ ABI of gcc 2.95 to Delphi and it is possible to map the ABI of gcc 3.1 to Delphi ABI.
Name mangling can be resolved by Delphi's shared object import concept "function name(parameter): RetType; cdecl; external soName name 'symbol';" plus the c++filt utility.
VMT mapping works as long as the base class has a virtual method declared before a field, so the C++'s VT pointer is at offset 0. (QObject works perfectly). Otherwise you must use the obsolute "object" keyword (from TurboPascal days). It is the corresponding type for C++'s "class" keyword, but it is obsolute and said to have many bugs (I never found one).
For gcc 2.95 you must declare two dummy virtual methods to move the VMT offset of the first real virtual method 8 Bytes down.
For gcc 3.x the dummy method is not necessary (and would lead to wrong calls)
Memory alignment is no problem at all. With Delphi you can adjust it {$ALIGN 4}
And the calling convention is furtunatelly the "cdecl" one.

But even if you implement all this (it works, I have tested it last year with QObject and QWidget) two issues remain:
1. What is with inlined methods/functions, they are not exported by the shared object. You must find them and reimplement them in Delphi by hand. And C++ programmers tend to use many inline function (at least Qt has lots of them)
2. What is with templates? Templates are always inlined. They are not possible in Delphi except you write all template specializations by hand. Qt does not have that many (what about Qt4 ?) but eight or more are even too many to keep in sync with newer Qt versions.

So you see it is possible with limitations. The perfect solution would be a very small C wrapper (templates?, inline functions) and a native ABI map. But when you already have a C wrapper why not add all things to the wrapper and simply use a C interface from the binding language to the C++ code.

If there would be a common ABI all these issues would not exist. .NET for example has such a common ABI. The intermmediat language is designed to support more than one programming language. That's the reason why beside C# there are also VB#, Delphi.NET, ...

I wish gcc would export an additional "common ABI" for classes and templates like joliet is for iso9660. It is additional but if you cannot read it you can use the "old" one (ok the comparision is not good). Another example is COM under Windows. You can use it in C++, VB, Delphi and even in all .NET languages. And if that "common ABI" would be controllable by a class modifier that would be really great. For example: Q_EXPORT __commonabi class MyClass {} In this case gcc would create a function pointer table for all non-private methods.

struct CommonAbiClass
{
char* name;
CommonAbiClass* bases; // array
CommonAbiItem* methods; // array
void* reserved; // for future extensions
};

struct CommonAbiFuncItem
{
void* myfunc;
char* name;
paramItem** params;
type retType;
void* reserved; // for future extensions
};

And as fields should not be accessed directly all could be handled through these function pointer tables. And you would have an included RTTI for each public and protected method. Even bindings could be generated without the source code.

I'm dreaming, I know.

Regards,

Andreas Hausladen

NO! It's NOT! These are lies perpetuated by people with language agendas (e.g. GNOME trolls) Look at libfam and look at all manner of languages and environments using it even though it's implemented in C++.

http://oss.sgi.com/projects/fam/

While it is still better to write the library in C++ and provide some simple C wrapper if a binding is really needed. Just look at QtC, its not so hard and you only need to wrap up the public API.
Many languages don't need bindings for C++ as there is already some compiler technology to mix them. C++, objC, Java can be mixed to some extent with gcc for instance.

You could also use Fake Objects using C Structs or Pascal Records.
Looks a bit messier than true OO code but it works. The balance between OO and procedural code, while still having the power to export from a library. Messier than OO but cooler than OO :-)

I've attached a file which shows an example of a Pascal code with a few Fake Objects using plain records. Private data in the fake object is accessible if you want to shoot your foot, but is labelled very clearly using _private. Similar things have been done in the C language using _private or private_.

Call me messy but this was just a little experiment of mine. Note how I fake "self". Objects have a self available and in order to make "self" available using records/structs, you must pass a dummy Self parameter throughout some of the functions.

The example file attached shows how to use a Pointer to a record or a regular record without being a pointer. See FakeObject versus TRecord in the attached file. EXE demo is included on win32 - I'll make a linux elf some time later.

This example was done in delphi but should be easily compiled in FPC too. CompactUtils uses true objects, ignore that - the fakeobject examples are in the FakeObject directory.