I'm making a programming language that has a lot in common with C++. One difference is that I'm going to move the virtual pointer into the pointers and references. This will make it easier to do multiple dispatch and possibly some higher level stuff. Well actually it won't be a virtual pointer but a type id, but it will play the same role. In C++ you only get polymorphic behavior through pointers and references, and I am fine with that limitation in my language. Am I missing anything? Is there going to be something that I can't implement? Anything that will be counter intuitive? I have already though of one situation without a clear answer. Using C++ code to illustrate: struct Base; struct Derived; Base* p = new Derived(); //p has two members, an address and the type id of Derived Base** pp = &p //pp has two members, the address of p and either the type id of a Base pointer or the type id of a Derived pointer. I am thinking that I will go with it being the first, as I think that it will be easier to implement and result in faster code, however it might be unintuitive.

Before writing a language that is almost like C++, take a look at D.

Quote:Original post by Glak
I'm making a programming language that has a lot in common with C++. One difference is that I'm going to move the virtual pointer into the pointers and references.

What? Why!? The type of an object is part of that object, not part of every pointer referencing it. What possible benefit could this have over putting the typeid in the object itself?

Extrarius: because int and int* are two different types. I want to regularize my language as much as possible to allow for higher levels of abstraction. For example I am bringing a lot of lisp like stuff into the language, while still retaining the C++ design philosophy.

HairyTroll: I've looked at it before and it doesn't really go where I am going. Plus working on this project will be fun for me.


Sneftel: I sat here for like three minutes trying to remember why the pointers will have the type ids and eventually I remembered the main reason. I think that there were others though. The original reason was that I don't want primative types to have to contain this sort of information. I am not restricting polymorphism to the "this" pointer. I want to be able to have virtual parameters. I'm sure that at some point everyone has tried to write some collision code and thrown an ugly switch statement in. Virtual parameters are a cool feature, and why make a language for fun if you can't add some features that you like?

However one of the laws of my design is that primative types are full types and get to participate in all of the cool stuff. So I need to be able to write something like this: (again, not the actual syntax of my language)

void f(virtual int* ip)=0;
void f(unsigned int* ip){cout<<"unsigned";}
void f(signed int* ip){cout<<"signed";}

At run time the int needs to identify itself as signed or unsigned. Storing the type id of an int with every int would be insane. If the typeid is the same size of the int then you double the size of an int. You more than double the size of a char. The size of objects would be similarly increased, as at some level they are made up of primative types. Everything would be increased in size.

Java, C#, and similar languages use something called "boxing" to work around this issue. They have int for plain old efficient ints, and Integer for the full blown object versions which do little more than wrap the plain old versions. Then they boast about new features that automatically box and unbox ints. Boasting about a feature that other languages (such as C++) don't need doesn't impress me. I really can't bare the idea of treating primative types so differently.

Pointers to primative types are rare enough that a little extra overhead would be ok, and a lot of those pointers are to arrays so it isn't like we are doubling memory usage.

Pointers to more complex types are common enough that the overhead might be an issue, especially in things like linked lists. Iterators would become larger too, as they are generally small and contain a pointer. However if my language is not as efficient as C++ that is ok with me. I want my language to be decently fast but realistically I am making a high level language and so it will be slower.

Quote:Original post by Glak
I sat here for like three minutes trying to remember why the pointers will have the type ids and eventually I remembered the main reason.

This isn't a good sign.

Quote:Original post by Glak
I want to be able to have virtual parameters.

This sounds suspiciously like templates. Elaborate, please.

CM

Quote:Original post by Glak
I sat here for like three minutes trying to remember why the pointers will have the type ids and eventually I remembered the main reason. I think that there were others though. The original reason was that I don't want primative types to have to contain this sort of information. I am not restricting polymorphism to the "this" pointer. I want to be able to have virtual parameters. I'm sure that at some point everyone has tried to write some collision code and thrown an ugly switch statement in. Virtual parameters are a cool feature, and why make a language for fun if you can't add some features that you like?

What you're taking about is called "multiple dispatch". But multiple dispatch doesn't require you to store the type information somewhere other than the object. I see what you're saying WRT trying to pretend that primitive types aren't primitive types, but examples of where an unsigned int* needs to be treated like a int* through virtual binding are...well, I simply cannot think of a real-world situation where this would be useful. And really, unsigned int has no IS-A relationship with int; its range is not contained in int's range. Finally, keep in mind that the only sane way to treat integers as polymorphic would be to dynamically bind all arithmetic operations. (Yikes.)