Yingle Jia's Weblog

Design refactoring: delegates

yljia@msn.com — Tue, 01 Mar 2005 19:12:00 GMT

What is delegate?
A delegate represents a callable entity. In the .NET world, a callable entity is either a static method or an instance method plus an object reference. In C++, function objects are also callable entities, e.g.:

struct Foo {
void operator()() { ... }
};

Foo f;
f(); // calls operator()

Since function objects can contain state, they are much more useful than static functions. Thus a delegate class written for C++ must provide first class support for function objects.

.NET also supports chaining delegates via Delegate.Combine and Delegate.Remove methods. Multicast delegates are commonly used for events.

The old design
In previous versions of ACF, the delegate design is just a simple porting from the .NET framework. Here is an example:

static void F() { ... }

RefPtr > d = new Delegate0(&F);
d->Invoke();

The old design has the following drawbacks:
- Performance. In the old design, delegates are reference types and are allocated on heap. This leads to significant performance overhead compared to C++ function pointers and function objects.
- Syntax. The old syntax is a little hard to use. First, one has to remember and use Delegate0, Delegate1, Delegate2, ... instead of Delegate, and the function prototype is not quite clear (e.g. Delegate2). Second, since delegates are reference types, one has to call the Invoke method to call the delegates, while the function call operator () is more nature for C++ developers.
- Does not support function objects.

The new design
The new design addresses all the problems listed above. The delegate class is now a concrete type like int, std::string, etc; it uses a new syntax based on template partial specialization (which is borrowed from boost.function); and it also supports function objects. Here are some examples:

static void F() { ... }

struct MyObj {
void G() { ... }
};

struct Functor {
void operator()(int n) { ... }
};

Delegate a(&F);
a();

MyObj o;
Delegate b(&o, &MyObj::G);
b();

Delegate c(Functor());
c(10);

The delegate template uses the following declaration: Delegate, where R is the return type, and T1, T2, ... TN are argument types. This syntax requires your compiler to support template partial specialization and function type parsing (I tried VC++ 7.1 and GCC 3.2).

Here is the Delegate template class definition:

template
class Delegate; // no body

template
template <>
class Delegate {
// Constructors/Destructor
public:
    Delegate();
    Delegate(R (*fp)(T1, T2, ..., TN));
    template Delegate(T* obj, R (T::*mfp)(T1, T2, ..., TN));
    template Delegate(TPtr obj, R (T::*mfp)(T1, T2, ..., TN));
    template Delegate(const TFunctor& f);
    Delegate(const Delegate& right);
    ~Delegate();

// Properties
public:
bool IsEmpty() const;

// Operators
public:
    Delegate& operator=(const Delegate& right);
    operator bool() const;
    bool operator!() const;
    bool operator==(const Delegate& right) const;
    bool operator!=(const Delegate& right) const;
    R operator()(T1, T2, ..., TN) const;
};

Comparing delegates
Delegate comparison is required when chaining delegates (more explicitly, removing delegates). The Delegate class supports comparison via the == and != operators. However, only static function and member function comparisons are supported, function object comparison is not supported. The reason why providing function object comparison is infeasible can be found in boost.function documents.

Chaining delegates
The new design supports chaining delegates through the DelegateList template class, which is a specialized singly linked list. It is also a function object, so you can use it to construct multicast delegates.

Here is an examle:

static void F() { ... }
static void G() { ... }

Delegate a(&F), b(&G);

DelegateList<Delegate > list;
list += a;
list += b;

list(); // calls a() and b(), which calls F() and G()

Delegate c(list); // c is a multicast delegate
c(); // calls the delegate list

Here is the DelegateList template class definition:

template
class DelegateList; // no body

template
template <>
class DelegateList > {
// Constructors/Destructor
public:
    DelegateList();
    DelegateList(const DelegateList& right);
    ~DelegateList();

// Properties
public:
bool IsEmpty() const;

// Methods
public:
    void Add(const Delegate& d);
    void Remove(const Delegate& d);
    void Clear();

// Operators
public:
    DelegateList& operator=(const DelegateList& right);
    operator bool() const;
    bool operator!() const;
    void operator+=(const Delegate& d);
    void operator-=(const Delegate& d);
    R operator()(T1, T2, ..., TN) const;
};

ACF Project Update

yljia@msn.com — Sun, 30 Jan 2005 18:37:00 GMT

Hello readers,

Recently I was a little busy and stopped blogging. Some readers mailed me asking whether I'll continue working on ACF or not. The answer is absolutely yes. However, I have to be very careful on future directions and certain technique issues before this framework is wide spread (I hope^_^). That's why I'm not going to emit many releases/documents before I spend enough time thinking and trying. Here are some thoughts on relation to the .NET framework and portability. Your feedback are always welcome.

Relation to the .NET framework
At the begining of this project, my initial thought was to bring the .NET framework to standard C++, so I tried hard to mimic nearly everything in the .NET framework, e.g. single inheritance, heap allocation, boxing/unboxing. However, practice proved this is not the right direction. People using C++/C# are developing very different kind of applications, a C++ framework has to be a thin wrapper around OS interfaces to give C++ developers performance and control, otherwise developers will resisit it (if they have choices). If you look at MFC (Microsoft Foundation Classes) or something similiar, you'll understand this situation. Of course, the .NET framework is well organized and designed, and is very easy to learn and use, we should take things that are suitable instead of reinventing ourselves. This leads to our decision on relation to the .NET framework: be close if suitable, otherwise make our own.
Let's look at two examples.
- Streams.
We need to deal with various mediums (file, memory, network, etc), polymorphism is a good solution (we'll have a Stream abstract class and subclasses like FileStream, NetworkStream). Polymorphic objects are commonly allocated on heap (compared to concrete types, such as int, float), so an object management schema (such as reference counting) is necessary. To draw a conclusion, we could adopt the .NET framework stream design with minimum modifications.
- Threading.
The .NET framework threading model is fully based on Win32 threading model (which is not strange). The problem is that Win32 threading model is very complex and rich, whereas other platforms may only have minimum threading support. For example, pthread (POSIX Thread) does not have a general wait handle concept (Win32 supports waiting for single wait handle, as well as waiting for multiple wait handles). As a open source C++ framework, we're not going to provide a complex model that are not supported by many operating systems. Polymorphism and heap allocation are also not necessary here. So we will design our own threading model (may be close to boost.threads). For example, we may have the following mutex/lock model:

class Mutex {
public:
    Mutex();
    void Lock();
    void Unlock();
    ...
}

class ScopedLock {
public:
ScopedLock(Mutex& m);
};

class Foo {
Mutex _m;
double _d;

    void Do() {
        ScopedLock l(this->_m);
        this->_d = sqrt(this->_d);
    }
};

Portability
When I started this project, I worked only on Win32 and VC++. Portability was not considered at that time. After I published ACF, people asked for portability - as a open source project, portability of course should be a basic characteristic. And now I'm daily working on various platforms, so eventually this framework will be portable. I will talk about more about this later.

Got a new job at IBM CSDL

yljia@msn.com — Sun, 28 Nov 2004 00:39:00 GMT

Hello guys,

Recently I got a new job (software engineer) at IBM China Software Development Lab (CSDL) located in Beijing, China. My job responsibility is development of IBM Workplace rich client (which I think is cool). I'll work on various platforms including Windows, Unix, Linux and MacOX, and use C++/Java. So I'll try to port ACF to other platforms in the future - isn't writing a portable C++ framework challenging and interesting? :-)

Design Refactoring: type system

yljia@msn.com — Sun, 28 Nov 2004 00:09:00 GMT

Since I published ACF, I got a lot of feedback from C++ guys. There are positive ones, such as:

Nice job!...

...your framework looks pretty cool...

And also negative ones:

...single root inheritance, huge class tree, virtual functions everywhere... it looks like another OWL/MFC/VCL/AWT...

Great idea, but it is too simple and too hard to use...

Well, I like feedback (including criticisms), since they tell you where you can improve. So recently I spent no time working on new features, but on correcting ACF (to make it more C++ smell and easy to use).

In the past versions, I have been focusing on porting the .NET framework libraries to standard C++ (you see I tried to keep the classes, methods, etc. as close to the .NET ones as possible). However, this partly failed, because C++ and CLR are really very different models, simple porting will not work well (practice proved this).

o CLR has an unified type system, all types inherit from the single root - System.Object. Reference types are allocated on heap and reclaimed by GC, which programmers cannot control. Value types are designed to improve performance, and there are built-in boxing/unboxing support.

o C++ has the most flexible model, where classes are not required to inherit from some root class, and programmers can control where objects are allocated (static, stack, heap). When designing a C++ framework, we should always follow the C++ traditions (give the programmers performance and control), otherwise we will never succeed.

This leads to the following considerations:

o Separate concrete types and polymophic types. In C++, classes are usually categorized to concrete types, abstract types, nodes, etc (for detailed discussions please check The C++ Programming Language, Bjarne Stroustrup).

- Concrete types are like C++ primitive types; they represent simple concepts (e.g. int, date, string, array) and have minimal dependency on other types; they are usually allocated on stack and pass by value or reference; they are not intended to be used as base classes.
Concrete types are much easier to use than other types in C++ (C++ creator Bjarne Stroustrup introduced operator overloading and reference (&) to make them as close to C++ primitive types as possible). This is why some common classes, such as string or array, are implemented as concreate types in most C++ libraries (performance is another good reason). In previous versions of ACF, string and array are implemented as polymorphic types (they inherit from Acf::Object and thus have the VTBL) other than concrete types, this caused usability and performance problems for most cases. For example, people would like to see

    class MyClass {
        string get_Name();
        void set_Name(const string& value); // automatically handles const char* and const wchar_t*

array Split(const array& chars);
};

other than

    class MyClass {
        RefPtr get_Name();
        void set_Name(String* value); // cannot use const char* or const wchar_t*

RefPtr > Split(Array* chars);
};

In the next version of ACF, string and array will be implemented as concrete types, which is a big breaking change (hope it paies). The good news is that you can use them as you would with std::string or std::vector (and a little easier), the bad news is that since they no longer inherit from Object, you have to call box(...) on them if you need to treat them as "objects" (in CLR, string and array do not need boxing/unboxing). Another little problem is naming convention: should I use String/Array, or string/array? (I guess most people will agree with the latter)

There are also some other classes that will be implemented as concrete types other than reference types (e.g. StringBuilder, RegistryKey).

- Polymophic types (include abstract types, nodes, etc) implement OO polymophism and form class hierarchy. For example, consider the encoding classes:

    class Encoding : public Object {
        virtual int GetByteCount(const wchar_t* chars, int count) = 0;
    };

    class Utf8Encoding : public Encoding {
        int GetByteCount(const wchar_t* chars, int count) {
            ....
        }
    };

In ACF, polymophic types should inherit from Acf::Object, since it provides the following services:
- Object life time management (reference counting)
- Locking/unlocking
- Detecting wether an object is allocated on heap or not (which is discussed in my previous posts)

o The programmers can control how to allocate objects, include reference types. For example:

// Allocate a FileStream object on stack
FileStream fs(...);

    // Use pointer since we don't know the real type of the input stream at compile time
    class MyClass {
        StreamPtr _stream;
        MyClass(Stream* stream) : _stream(stream) { }
    };

ACF Portability

yljia@msn.com — Tue, 09 Nov 2004 01:01:00 GMT

Recently I spent some time playing with GCC 3.2 on Win32 (I used Dev-C++ with Mingw port). Now ACF compiles and runs OK, which is much easier than I thought (actually only a little code was modified) :-). The upcoming release of ACF will include Dev-C++ project files (well, I don't like make files though they are not hard to make) so you can build and use it with GCC on Win32.

API consistency

yljia@msn.com — Sat, 06 Nov 2004 16:43:00 GMT

The .NET team tried hard to make the .NET framework API consistent. They did a great job, however, there are still some design and naming inconsistency. The following items will be addressed in the next version of ACF.

- Factory vs. Constructor for parsing
Most classes in the BCL use the Parse pattern for parsing.

int i = int.Parse(“35”);
DateTime d = DateTime.Parse(“10/10/1999”);

However, the Guid structure does not follow this pattern:

Guid g("1234567890123456789012");

Which shall be:

Guid g = Guid.Parse("1234567890123456789012");

- Naming convention

Just list a few:
ASCIIEncoding => AcsiiEncoding
UTF8Encoding => Utf8Encoding
System.IO => System.Io
...

Design Refactoring: I/O

yljia@msn.com — Thu, 04 Nov 2004 00:41:00 GMT

Recently I did some design refactoring to make ACF more C++ friendly (which means syntax, performance and control). This time let's take the Stream class as an example. In the .NET framework, the Stream class's main reading/writing methods are as follows:

class Stream
{
abstract int Read(byte[] buffer, int offset, int count);

    virtual int ReadByte() {
        byte[] buffer = new byte[1];
        int n = Read(buffer, 0, 1);
        return (n == 0 ? -1 : buffer[0]);
    }

abstract void Write(byte[] buffer, int offset, int count);

    virtual void WriteByte(byte value) {
        byte[] buffer = new byte[1] { value };
        Write(buffer, 0, 1);
    }
};

As you can see, the Stream class does not use unsafe code in order to be type-safe. However, the ReadByte/WriteByte methods have to be virtual and be overrided by subclasses, otherwise a temporary array will be created each time ReadByte or WriteByte is called. Another limitation is that you cannot directly read/write structures from/to streams (which is a frequently asked question for C++ developers who just start writing managed applications), which means you have to create temporary arrays in order to load/save structures.

ACF is based on native C++ and thus does not have those limitations. Following is the current (new) design:

class Stream : public Object
{
virtual int Read(byte* buffer, int count) = 0;

    int Read(Array* buffer, int offset, int count) {
        return Read(buffer->GetItemAddress(offset), count);
    }

    int ReadByte() {
        byte b;
        int n = Read(&b, 1);
        return (n == 0 ? -1 : b);
    }

virtual void Write(byte* buffer, int count) = 0;

    void Write(Array* buffer, int offset, int count) {
        Write(buffer->GetItemAddress(offset), count);
    }

    void WriteByte(byte value) {
        Write(&value, 1);
    }
};

The ReadByte/WriteByte methods do not need to be virtual and be overrided, thanks to C++ memory model. Also now you can write structures directly to streams, as shown in the following code:

struct MyStruct {
int X;
double Y;
};

MyStruct st = { 10, 3.14 };

FileStreamPtr stream = File::Create(L"test.bin");
stream->Write((const byte*)&st, sizeof(st));

On ACF 0.4 (Updated 8/13/2004)

yljia@msn.com — Fri, 13 Aug 2004 13:30:00 GMT

Here are the items that I'm planning to add in ACF 0.4:

DateTime parsing & formatting
Simple XML reading & writing
Threading update

The only problem is that I don't have enough time to work on them. These are quite a lot of work, and I, like you, have jobs to do. Some friends of mine told me that they would like to contribute if they have time - hope they could find some spare time. :-)

Your feedback and suggestions are always welcome.

An article worth reading: How Microsoft Lost the API War (Joel on Software)

yljia@msn.com — Wed, 23 Jun 2004 17:16:00 GMT

How Microsoft Lost the API War. Though a little long. :-)

What's new in ACF 0.3: base types parsing and formatting

yljia@msn.com — Sat, 19 Jun 2004 01:15:00 GMT

Base types parsing and formatting are updated in ACF 0.3. For example, the following code shows how to format integer using various formats:

Int32 n = 123456789;
Console::WriteLine(n.ToString(L"C")); // $123,456,789.00
Console::WriteLine(n.ToString(L"E")); // 1.234568E+008
Console::WriteLine(n.ToString(L"P")); // 12,345,678,900.00%
Console::WriteLine(n.ToString(L"N")); // 123,456,789.00
Console::WriteLine(n.ToString(L"F")); // 123456789.00

The following function formats file sizes as shown in Windows Explorer (e.g. "3,012 KB"):

StringPtr FormatFileSize(int64 size) {
    Int64 kb = size / 1024;
    if (size % 1024 != 0)
        kb++;
    return kb.ToString(L"N0") + str(L" KB");
}