The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Explicit Message Passing in C

Usually, basic object oriented programming is implemented in C by passing the "this/self" pointer explicitly to an object's method. Some don't even consider this object orientation and refer to it by other names e.g. abstract data types.

An example:

void PersonSetName(Person *p, char *name);
void PersonGetName(Person *p, char **name);
etc..

The above approach is very common and used in countless C project. Lately I've been thinking about using explicit message passing instead. Instead of trying to make the OO details hidden from the API user and end up with a half baked OO system, why not sacrifice usability a bit and make message passing explicit.

A possible implementation could involve
- a default message broker (unsure about the correct term) functioning as a "root" class in a class hierarchy
- a message structure containing an int for the message number and the message's arguments
- a message broker for each class. The default parent broker
- a SendMessage function (not unlike Win32)

Advantages:
- Inheritance can be implemented in obvious ways (i.e. by delegation, just like the ADT approach).
- Support for aspect oriented programming - since all calls go through a SendMessage function implementing interceptor stack shouldn't be too difficult.
- Common messages for disparate classes e.g. toString() like in Java, maybe a common AGE message.
- Support for runtime introspection e.g. you can ask an object for the types of messages that it responds to.

Disadvantages:
- SendMessage(obj, message) is not as intuitive as func(obj, message)
- There's probably another way to implement a class but for the time beign I forsee a switch-case construct analogous to Win32 Windows Procedures.

I'm just thinking outloud for a future version of a C library that I'm maintaining. Any thoughts?
MFH Send private email
Monday, December 05, 2005
 
 
I don't think it will work too good if used anywhere, because you will eventually end in an argument mess - just take a look at the Win32 API.

When you want to substitute specialized functions like this:

  MyObjectFunc(obj, foo, bar, baz)

you either must provide some general arguments in SendMessage with ugly and error-prone casting all your way around, or you need something like this to enable multiple-argument functions:

  struct MyStruct mys;
  mys.Foo = foo;
  mys.Bar = bar;
  mys.Baz = baz;
  SendMessage(obj, CALLMYOBJECTFUNC, &mys);
 
For any single call performing a special functionality, of course, if you don't want to give the parameters through global variables...

Just take a look at an average application of yours and try to estimate the additional code bloat. Then you may know if the additional flexibility is worth it.
Secure
Monday, December 05, 2005
 
 
I was thinking of using format strings (something like scanf/printf except that the arguments would be converted to a byte array instead of a string) to implement support for multiple arguments and types.

For example for a message that needs a string and an integer as its arguments you could have something like this:

SendMessage(obj, MSG_NUMBER, serialize_arguments("%s %d", the_string, the_integer));

(I'm ignoring performance and efficiency for the time being of course)
MFH Send private email
Monday, December 05, 2005
 
 
Some macros could help with the message broker functions similar to how wxWidgets event handling system works.

e.g.

BEGIN_EVENT_TABLE(MyFrame, wxFrame)
  EVT_MENU    (wxID_EXIT, MyFrame::OnExit)
  EVT_MENU    (DO_TEST,  MyFrame::DoTest)
  EVT_SIZE    (          MyFrame::OnSize)
  EVT_BUTTON  (BUTTON1,  MyFrame::OnButton1)
END_EVENT_TABLE()

(taken from http://www.wxwindows.org/manuals/2.6.2/wx_eventhandlingoverview.html)
MFH Send private email
Monday, December 05, 2005
 
 
While there surely are some areas where this approach might be really useful, especially when lots of different objects with similar behaviour are involved, e.g. GUI programming or object and creature handling in role playing games, you should seriously ask yourself if you are still using the right tool for the job. It is possible to do in C, for sure, but wouldn't it be better to switch to a language where such designs have better native support, since you seem to want it as a complete programming approach? C++ or some other language?
Secure
Monday, December 05, 2005
 
 
You have an excellent point. And in fact I am moving in that direction. However, my choice isn't C++. To be honest I don't find C++ worth the extra effort. Instead I'm going down the road of embeddable languages.

One of the reasons I'm doing message passing in C is so that I can easily implement interfaces with embeddable languages. Instead of implementing wrapper functions, in the embeddedable language, for each function in my library, all I have to do is create wrapper functions for the object system's functions e.g. SendMessage, CreateObject etc..

At the moment I'm choosing between three embeddable languages - Lua, Scheme via mzscheme, Scheme via CHICKEN. All three options include a language to C compiler.

It might seem a bit like over-engineering though.

And thank you very much for your input.

MFH
MFH Send private email
Monday, December 05, 2005
 
 
I think you would find the performance hit for intra class linkages is too slow, but fine between more independent subsystems.
son of parnas
Monday, December 05, 2005
 
 
Have you considered Objective C? Its an OO extensions that's not NEARLY so "extensive" as C++. Its also available in GCC. Its based on a more explicit notion of messages and borrows more from a Smalltalk style OO background. And it only adds like 2-3 new primitives. Just a thought...
Matt Send private email
Monday, December 05, 2005
 
 
I agree with parnas: I think the performance hit you will suffer (both in terms of execution time and code size) will limit its use in embedded systems. If you need OO features, why not look for a compiler that supports embedded C++ (EC++) or Objective-C (as suggested by another poster)?
A. Nonymous
Tuesday, December 06, 2005
 
 
Yes, Objective C is what you want.
Art Wilkins
Wednesday, December 07, 2005
 
 
Thanks guys
MFH Send private email
Wednesday, December 07, 2005
 
 
Hi!
Ah yes, Objective C! And what about good libraries for database access, GUI development? Do they exist for Objective C on a Windows box?
I'm also thinking about leaving VB for C (I must develop a very, very fast application -1st project) but I will also have to develop a management application (it will be my second project with my soon to be created company); so I'm a little bit lost about what language to use in my second project.
I really don't want to use VB6 (I'm tired of fighting the language); C++ is not an option - just too complicated (I don't want to spend 10 months just learning the language!!!).
Java -- I really don't like the UI looks ( I want the application to have a native look (Windows, linux, whatever)...

Any advice would be great! Thanks!
Jorge C.
Jorge C. Send private email
Wednesday, December 07, 2005
 
 
You could look into writing the fast application in plain or objective C, and the management application in Python.  Python is easy to learn and pleasant to program in.  Python and C and relatively painless to integrate.  The wxWidgets library can be used from Python to give somewhat native look-and-feel on Win32/Linux/Mac.  Other GUI libraries are also available, and I personally use GTK+ and PyGTK on Windows without anyone complaining of it looking bad.

Python: http://www.python.org/

wxWidgets: http://www.wxwidgets.org/ and http://www.wxpython.org/

GTK+: http://www.gtk.org/ and http://www.pygtk.org/

If you find you like Objective-C this project advertises an interface between it and Python: http://pyobjc.sourceforge.net/
Tim Evans Send private email
Wednesday, December 07, 2005
 
 
Jorge, are you aware that Objective C is fully compatible with C?
Art Wilkins
Thursday, December 08, 2005
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz