Pointers in AngelScript: Really necessary?

Started by
32 comments, last by WitchLord 19 years, 5 months ago
I've come to think of the pointers in AngelScript as a great burden that I would rather remove. I realize that in some situations they can be useful, and that some of you are already using pointers in the script. Therefore I want to ask your opinion before removing the pointers. If it was possible I would make it a compile time option, with the default turned of (just like I've done with AS_DEPRECATED). Instead of native pointers the application would register a special type, e.g. float_ptr. The library will also allow registration of the -> operator so that the pointer can be emulated. Another advantage of this is that the application would be able to register an indexing operator so that it could work exactly like normal C arrays. instead of:

void function()
{
   Object *obj = GetObject();
   if( obj->property )
      obj->Method();
}
it will be:

void function()
{
   Object_ptr obj = GetObject();
   if( obj->property )
      obj->Method();
}
What do you think? Can I do this without disrupting your projects too much? It would really help me improve the library even further. Let me know what you think. Please. Regards, Andreas

AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game

Advertisement
Well I can only speak for myself but I've got pointers all over my script files. However, I do not do any pointer arithmetic and I do not anticipate anything quite so dangerous. Why would this change help? Is it a parsing problem?
Dan Royer, OwnerMarginally Clever Games
Actually, I wonder if this might be related to a problem I'm having. I

SoundRecording *[] records(5);// initialization of pointers, etc...int vi=3;// void PlaySoundNow(SoundRecording *sr,float volume,bool loop);PlaySoundNow(records[vi],1.0f,false);


and I get an error on PlaySoundNow because

No matching operator that takes the type 'int&' found

and the column offset is the first '[' on the PlaySoundNow line.

update: It appears to be an array indexing problem, not a pointer problem. I can replace vi with a constant and it works fine.
Dan Royer, OwnerMarginally Clever Games
Pointers complicate the code in several places, the parser, the compiler, engine functions etc. To support pointers I need to do a lot of special cases. Removing the pointers would clean up the library code, and make further enhancements easier.

But that's ok, I'll try to clean up the code in another way.

I'll probably only be able to remove the pointers by making a different scripting library.

In the meantime I will implement everything that is necessary to remove the pointers, e.g. the overloaded ->. So that it will be possible to at least optionally remove the pointers from the syntax.

---

The indexing operator is declared to take an uint, so declaring the vi as uint, or casting it to uint, should let you work around the problem.

I've discovered and fixed a few bugs with the implicit cast of types. I'll soon release WIP 6 with these fixes.

A future version of AngelScript will also have much improved rules for implicit type conversions.

AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game

i suppose i could run a "replace in all files" because as far as i'm concerned it's just the declaration that's changed. Tho if you create this pointer system then how would you implement

int **ptr2;

?

thank you for fixing the implicit type conversions! Those were really starting to annoy me. Will you be supporting the alternate syntax (type)var as well as type(var) ?
Dan Royer, OwnerMarginally Clever Games
As far as I'm concerned it only looks like a different notation.

I only use pointers to pass values by reference from my app to the script I don't think it will be a big change for me.
So far in my scripts I have been able to simply use references, but I haven't tried passing objects to/from the script that inherit from a base class, so not really sure if pointers are needed for polymorphism (but surly references will get round this?)

So, I won't miss pointers if you do decide to remove them, but I'm not using AS to it's full capacity yet!
I think some clarification is in order.

By 'no pointers' you mean that the * type modifier will no longer exist. That does not mean we can't use pointers! I generally prefer thin handle classes over raw pointers. I probably won't miss them much. If it makes the library better, go for it. Understand that by better I mean more robust and faster.
Aggrav8d:

A pointer to a pointer would need yet another type. But I can't think of any place where you actually need to store a pointer to a pointer. It is mostly used in parameters, where a reference to a pointer type would work just as well.

I don't think I will support the alternate casting style, (type)expression. But then again, nothing is set in stone. It would be necessary for casting between pointer types, if I decide to keep the pointers.

desertcube:

Once AngelScript supports polymorphism, the references will be work just as well for this purpose.

Deyja:

Exactly, by no pointers in AngelScript I mean that the scripting language won't have the * type modifier. The C++ application will still be able to pass a pointer to the script, which would then have to store it in another type. This replacement type can be a registered type where the application freely chooses the name.

---

In my opinion, since the scripting language don't allow for taking the address of a variable, dereferencing a pointer, or any pointer arithmetic, the pointers don't really bring any advantage to the language.

I thank you all for your support, and your help in deciding the future of AngelScript.

I've not yet made a final decision, so keep writing your comments.

AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game

Pointers should go! From what you've said I think getting rid of pointerss would make your life and the lib better, as well as not taking away much functionality (if any). Registering an Obj_ptr type would take a good 5 seconds, and with references I can't see a situation where you'd need the * explicity. Sure for people who've already got a heap of scripts that use pointers heavily it would be a pain to convert but and afternoon with Find and Replace should be enough for them to convert over. Backwards compatability is nice, but sometimes its worth breaking, and when the break is this easy (changing Obj * to Obj_ptr) then it doesn't seem like there is any real reason not to!

Quote:Pointers complicate the code in several places, the parser, the compiler, engine functions etc. To support pointers I need to do a lot of special cases. Removing the pointers would clean up the library code, and make further enhancements easier.


Sounds like its definatly worth it!

This topic is closed to new replies.

Advertisement