using System;
using System.Collections;
using System.Collections.Generic;

namespace Intrepid.Collections.Generic
{
	public class EnumerableWrapper<T> : IEnumerable<T>
	{
		class EnumeratorWrapper : IEnumerator<T>
		{
			IEnumerator enumerator;

			public EnumeratorWrapper(IEnumerator enumerator)
			{
				this.enumerator = enumerator;
			}

			public void Dispose()
			{
				// maybe we should dispose the underlying IEnumerable?
			}

			public bool MoveNext()
			{
				return enumerator.MoveNext();
			}

			public void Reset()
			{
				enumerator.Reset();
			}

			object System.Collections.IEnumerator.Current
			{
				get { return enumerator.Current; }
			}

			public T Current
			{
				get { return (T)enumerator.Current; }
			}
		}

		IEnumerator enumerator;

		public EnumerableWrapper (IEnumerable enumerable)
		{
			enumerator = enumerable.GetEnumerator();
		}

		public IEnumerator<T> GetEnumerator()
		{
			return new EnumeratorWrapper(enumerator);
		}

		IEnumerator System.Collections.IEnumerable.GetEnumerator()
		{
			return enumerator;
		}
	}
}

Programming in assembly is almost everytime a bad idea.

So first, what exactly is assembly?
Assembly is a text language with which you can write opcodes and arguments of machine code processed by the processor by hand. This gives you a very high amount of control of what the processor does. Whereas higher languages generate the machine code for you as they deem it to fit you can choose which machine code would fit.

Assembly isn’t difficult to learn. Assembly is very straight forward. It just is hard to program for you don’t have functions, you don’t have high level structures, you don’t have all the aid of a high level languages.

The reason programmers claim that assembly is superior is for with assembly you can write faster and smaller code. This is only partially true.

When you know all opcodes and tricks you can pull on all different architectures you can beat a compiler.. The problem here is that there are tens of architectures with totally different opcodes and even more subarchitectures with each a slightly different implementation and different performance characteristics of each opcode or way to do something.

So to truely beat a compiler which compiles one piece of code to assembly, you have to create for each different architecture a seperate piece of assembly source.

You’d also have to learn all the opcodes of one cpu, that aren’t just a few hundred which would suffice to get it working, but thousands which are required to get it working as fast as possible.

Compilers know all these extra opcodes and tricks for each architecture and would therefore a higher level programmer would do a better job on creating an executable than an experienced assembly programmer in the same amount of time. If the assembly programmer would want to beat the higher level programmer he would require not just 2 times more time but at least 10 times.

Also assembly isn’t very portable. If you want to change one little thing you got to change it for all optimalizations for all different processors. I haven’t seen a big application written in assembly. And that has got a reason.

Most programmers that claim to be able to write quick assembly don’t have got an idea how everything works exactly and are just thrilled that they made a little program work in assembly.

Assembly though can be usefull. An example is an arbitrary length integer class like GMP which uses optimized assembly for certain operations. It aren’t a lot of operations done in assembly, but it certainly has got a lot of assembly. And it is worth it.

Sticking with a good compiler and a high low level language like C is always the best option for good applications.

A solution could be to create a new class which inherits the original class although it can only be instanciated using a cast from an instance of the original class or instanciating providing the original instance. Also it won’t be able to override anything otherwise it couldn’t act as its base object.

A possible implementation of this idea could be:

wrapper Int_IsOdd : int {
  public bool IsOdd() {
    return this % 2;
  }
}

And it could be used in several ways:

int myInt = 100;
print ((Int_IsOdd)myInt).IsOdd();
print myInt.IsOdd();
print new Int_IsOdd(myInt).IsOdd();

The first way would be the easiest for both a reader which isn’t familiar with the extension and for the compiler to guess errors. The second would be neat to use but it would be confusing for people that cannot access the rest of the source or do not know what function is meant. The third way would be very compatible.

I wondered by myself whether normal inheritance could provide this functionality.. and it does. The only problem is that polyforism only works up and not down as the wrapper requires. (when you got a class a and b inherits of a, you can with inheritance treat an instance of b as a but you cant treat an instance of a as b which is required for the wrapper)

Also a wrapper would be more cached and not really a new instance as suggested by the way it seems to work and can already be slightly implemented in existing languages.

Maybe it’ll be put in paradox.

update – I talked with Kaja, and it will most likely be a feature of paradox

In the posts before (part 1, part 2) I discussed the possibility to inherit behaviour of an ‘object’ in C by adding a type pointer which handles initialization and destruction of the object; achieving the possibility to extend an ‘object’ by adding fields at the end and updating the type pointer to a new type.

Any object contains a pointer at the start to its type. The type of an object is passed to the CreateInstance function when an instance needs to be created of the object. The type itself just contains a few fields:

• Length, the required length of the object, this allows an inheritance to extend the amount of data.
• Constructor Function Pointer, the Constructor Function Pointer is called after the object is allocated to construct its contents.
• Destructor Function Pointer, the Destructor Function Pointer is called before the object is freed to destruct its contents.

These fields, along with using function pointers in the instance itself instead of functions, allow an inherited type to expand the existing type. The problem is that an object can’t inherit from more than one object, for both object’s expect to start just after the pointer to the type. To solve this an additional field needs to be added:

• QueryInterface Function Pointer, the QueryInterface Function Pointer can be used to get an instance of a supported type from the instance called.
• Top Object Pointer, the Top pointer points to the top object. (An object returned from QueryInterface its Top pointer would point to the object where QueryInterface was called)

nb. The latter one will be added after the type pointer in the instance instead of in the type

A good example would be a type called ICloneable which itself only contains one field: Clone, a functionpointer to a function to clone the object. When you would want to clone an object given you would use:

ICloneable* interface = toClone->top->type->QueryInterface(toClone->top->type, toClone->top, ICloneableType);
Object* clone = interface->Clone(interface);

Lets take a look to the first line:
ICloneable* interface = toClone->top->type->QueryInterface(toClone->top->type, toClone->top, ICloneableType);
This line queries the interface that the object that will be cloned wants you to use to clone it. The top object is used for that is the only way to be certain that you are dealing with the top object and the latest code instead of some base. Using this code an object can be cloned by just providing its interface!

(the QueryInterface takes 3 parameters: first one is the type itself where the function pointer relies, second is the object in question, third is the requested type where ICloneableType is an instance of the ICloneable type).

Object* clone = interface->Clone(interface);
The second line just calls the functionpointer in the interface queried.

To ensure that every bit of behaviour can be overriden, the object queried using ->top->type->QueryInterface on the provided object must be used instead of the provided object itself for the provided object can be a whole different object merely supporting that interface secondarily.

The nice thing about this architecture is that a top object merely wraps its implemented objects and returns them (possibly addapted) when queried for it. This allows way more access to the inherited types than in any other object orientated model.

This model is quite easy to implement in C and (I hope) will be easy to intergrate with for instance objects in a Virtual Machine.

I won’t talk about how to use the C ‘GC’, but how to implement new-generation alike Garbage Collectors in C(++).

The best GC`s can be found in Intermediate Language Virtual Machines which keep track of every object`s type in the memory and can therefore freely move objects in the memory. The great advantage of this is that object that have survived about as much Garbage Collects tend to link a lot to eachother and use eachother. That group survivors is called a generation. When you put a generation close to eachother in the memory, it will usualy only take 1 RAM memory load for the CPU, caching the whole generation in the CPU cache, for a while which is a lot quicker considering that l2-cache is about a thousand times faster than normal RAM.

The problem in C(++) is that you can’t just move objects. You don’t know what part of the memory of an object is a pointer, and what is just a mere integer. Therefore it is impossible to make a generation based Garbage Collector for you just can’t move stuff.

Allocating a big chunks and putting the objects of the C(++) application however using a custom allocation function will generate some additional performance above the traditional malloc although it still isn’t perfect.

One way to get it to work is to let the GC know what a pointer is and what now. This can be done by letting the first 4 (or 8 bytes in case of a 64bit CPU) be a pointer to a function which returns an array of offsets which resemble the pointers in the type.

Now the GC knows what the pointers are in a structure .

The GC can now move the object by updating the pointers from the other objects to the new location of the object!

The only problem with this is that there can’t be pointers to the object, or inside the object from a not referenced pointer exposing object or a object that doesn’t exposes it pointers at all.

To overcome this I guess it could be feasable to add a flag byte in each object that exposes it pointers which allows it to specify a function that can be called when moving the object or when an object referenced is moved.

I’ve tried out some ways to get this all wrapped up in a nice framework (which is very feasable using my ‘objects in c-framework’ or something similar (easier) in C++ using inheritance).

I`m afraid however that such a GC comes too late for by the time it is reliable the Intermediate Languages would have gained way more ground for these can implement way more optimalizations, including in the GC, during runtime for they tend to use an Ahead of Time and Just in Time compiler.

Feedback on this would be welcome .

Softwire is a library to generate assembly runtime for different kind of processors. It has a great API. Very usefull for JIT alikes.

Kaja is converting it for use in C for the Paradox JIT. Hopefully it’ll be a lot faster replacing virtual class function calls with macro’s.

Great stuff to play with

I did some test on how much the difference would be between having a C# or C++ game engine.

The results were quite supprising:

• C# is slower, but when letting as much as possible be done by the graphics card and direct X instead of C# code the difference between C# and C++ is neglected also due to superior threading control and runtime memory managment of C#
• C# develops a lot faster than C++, far faster than I expected initialy
• Threading and timing the renders and other operations is a lot faster in C# than it is in C++. Also multithreading doesn’t generate as much problems in C# as it does in C++. And maybe even important; debugging threads in C# is a lot easier than in C++
• The second critical area (after the rendering) is the gameplay engine. Most games need to use scripts for it is unfeasable to hardcode everything. C# doesn’t has to use scripts for using seperate .net dll’s works quite well and is hundreds times faster too

I wonder what will be the first major game that will be written in .net. It certainly should atract some attention by game developers.

http://w-nz.com/update/IntrepidCountDown-1.0.0.1.exe

It basicly runs in the background and notifies you of an event or a few minutes before one which you can add yourself.

I’ve written 2 articles (artc. 1, artc. 2) so far about getting OO like behaviour in C, and will write a few more about the more advanced stuff which I’m still experimenting with.

You can download the source of the API I have developed so far here, which by the way is far from finished. Stuff will change, and I am aware of some issues.

I’ll explain how it works in the next parts in the ‘Objects in C’ serie, but to give you a kickstart in the code I’ll explain it briefly:

Every object has got a pointer to its type and its toplevel object, which usualy is itself. The type instance pointed to from the instance provides the size, constructor, destructor and the interfacegetter.
The GetInterface function in the type (the interfacegetter) returns a pointer to an instance of an object of the given type if supported by the object.
Using interfaces can serve different purposes:

Exposing certain objectwide functionality

((ICloneable*)object->top->type->GetInterface(object->top->type, object->top, GetICloneableType()))->Clone(object->top);

This code will return a Clone of the object, even if only the object is passed by a not top level pointer. Using the top pointer ensures proper polyforism, and enables the ability for the top most class to hide, or show some internal functionality of wrapped objects.

Exposing interface specific functionality

((String*)object->type->GetInterface(object->type, object, GetIToStringAble()))->ToString(object);

It now depends on which interface of a certain object is passed which behaviour results.

And more.. and more.. which I will explain in the coming articles.

Download the source so far

It seems that so far 3 people have linked to an article on this blog (all of them to the Objects in C article) already. (Thanks! without readers a webblog is quite useless!)