The main difference is that int is a primitive. It isn't an object at all. Even Java does it this way - int does not inherit from Object, but they do have Integer, Double, String, etc.
That is why doing assignment with int, or any primitive, isn't by reference.
Object o; just creates a null reference. Object o(); isn't supported, because then o wouldn't be a reference, but an object itself. Object o = new Object(); however is because o is then a reference to a newly allocated Object.
This is where Java differs from C++, because C++ supports pointers, so you can do Object *o = new Object(); as well as supporting pure objects, like Object o(); But to remove pointers, I believe you would also need to remove pure objects (Or whatever you'd like to call them).
Opinion: AngelScript 2.0 operators
When looking as AS from a C++ perspective, I would say using new allocated it on the heap (persistent object). Not using the new allocates it on they stack, which means that it gets deleted as it goes out of scope. I'm not sure if that's how it's going to be, though.
AS currently supports creating objects without the new operator, so I don't see a reason why it should be removed.
AS doesn't do garbage collection (AFAIK), only reference counting. I'm not sure if it's even possible to do full garbage collection because of the ineraction between AS and C++. What would happen if you make AS allocate an object and use it in a C++ function? The other way around would also cause problems because the gargabe collector doesn't know about it.
AS currently supports creating objects without the new operator, so I don't see a reason why it should be removed.
AS doesn't do garbage collection (AFAIK), only reference counting. I'm not sure if it's even possible to do full garbage collection because of the ineraction between AS and C++. What would happen if you make AS allocate an object and use it in a C++ function? The other way around would also cause problems because the gargabe collector doesn't know about it.
First of all, thanks for explaining that to me Mortal.
However, you also illustrated what I've (indirectly) been trying to say. Sorry to keep going on about it, but the use of references, IMHO, should be a change in the actual engine, not the scripts. I believe that the scriptwriter shouldn't have to worry about the physical storage of any object, whether primitive or custom.
I therefore think that we don't need operator new; the script should handle the creation of the object for us. If I am the only one who thinks like this, I will gladly shut up, but I'm not sure I've expressed my opinion clearly enough.
However, you also illustrated what I've (indirectly) been trying to say. Sorry to keep going on about it, but the use of references, IMHO, should be a change in the actual engine, not the scripts. I believe that the scriptwriter shouldn't have to worry about the physical storage of any object, whether primitive or custom.
I therefore think that we don't need operator new; the script should handle the creation of the object for us. If I am the only one who thinks like this, I will gladly shut up, but I'm not sure I've expressed my opinion clearly enough.
Quote:Original post by desertcube
First of all, thanks for explaining that to me Mortal.
However, you also illustrated what I've (indirectly) been trying to say. Sorry to keep going on about it, but the use of references, IMHO, should be a change in the actual engine, not the scripts. I believe that the scriptwriter shouldn't have to worry about the physical storage of any object, whether primitive or custom.
I therefore think that we don't need operator new; the script should handle the creation of the object for us. If I am the only one who thinks like this, I will gladly shut up, but I'm not sure I've expressed my opinion clearly enough.
Nah, it's just that (As I have read) the major change in AngelScript 2.0 is that pointers are being removed from the scripting language itself, not the library code, because Witch finds them too difficult/messy/complicated to deal with. With the removing of pointers from the script language, other things have to be changed too.
I would personnaly prefer keep in mind C++ style, so assignement would still make copy of value, and not reference (I think it's clearer when references are specified using '&' to avoid dangerous confusion like the desertcube's example shows).
BTW, as you (Wichlord) said that operators would still be overridable, wouldn't be an idea to find, which would allow us (as developpers, not scriptwriters) to choose between the 2 ways (like StringFactory() exist for strings management) (with c++ way switched on by default :)). It could be provided either as defines, or operators factory, or whatever you think is better...
Lbas
BTW, as you (Wichlord) said that operators would still be overridable, wouldn't be an idea to find, which would allow us (as developpers, not scriptwriters) to choose between the 2 ways (like StringFactory() exist for strings management) (with c++ way switched on by default :)). It could be provided either as defines, or operators factory, or whatever you think is better...
Lbas
Well, it's certainly been an interesting discussion. The lazy part of me say that I should go with the Java way, as it is much much easier to implement. My intellectual part tell me to go with the C++ way, even though it is much more complicated.
Fortunately my intellect is larger than my laziness, so the C++ way it is [wink].
I've scrapped my first attempt at version 2.0.0, and started over. I was trying to change too much at once, and as usual it was just too difficult to get the pieces to fit together.
Now I'm doing the following changes:
- Pointers are removed from the script language. The main reason for this is consistency and simplicity in the library. For example if I decided to keep pointers I would have to make obj *[]*[]* a legal type declaration. It could possibly be made through some trickery, but the code would be awfully ugly.
- All objects will be stored on the heap by AngelScript, with a simple pointer to the object on the context stack. This will not change the way objects are treated from the script writer's point of view, i.e. assignments will be by value.
- The interface between script engine and application will be changed to pass objects by pointers. The interface for calling script functions will be much simpler because of this. The application functions will require a little more work to register. At first it will not be possible to register functions that take objects by value, but I intend to allow that in a future version.
- The application will be able to specify memory management functions per object. It will for example be possible to have the script engine allocate objects from an application specified memory pool, and then return the memory when the object is no longer used. In AS 1.10.1 that is not possible since the object is always placed on the stack, instead a wrapper object is needed.
- The application will be able to specify (in the declaration) if the object it receives in a parameter will be owned by the application or by the engine, i.e. who should be responsible for freeing the object after it is no longer used. If an application function receives the ownership of an object it may store it for later use or free it before returning, otherwise the library will free the object after the application function returns.
These are the changes that I will make in 2.0.0. They will make the library both easier to work with and much more flexible.
They will also build the foundation for future script declared classes, that will require full fledged garbage collection.
I consider the question about the assignment operators closed now (at least for version 2.0.0, maybe I'll open it again for version 3.0.0 [wink]). I hope my decision pleases the majority of you.
Fortunately my intellect is larger than my laziness, so the C++ way it is [wink].
I've scrapped my first attempt at version 2.0.0, and started over. I was trying to change too much at once, and as usual it was just too difficult to get the pieces to fit together.
Now I'm doing the following changes:
- Pointers are removed from the script language. The main reason for this is consistency and simplicity in the library. For example if I decided to keep pointers I would have to make obj *[]*[]* a legal type declaration. It could possibly be made through some trickery, but the code would be awfully ugly.
- All objects will be stored on the heap by AngelScript, with a simple pointer to the object on the context stack. This will not change the way objects are treated from the script writer's point of view, i.e. assignments will be by value.
- The interface between script engine and application will be changed to pass objects by pointers. The interface for calling script functions will be much simpler because of this. The application functions will require a little more work to register. At first it will not be possible to register functions that take objects by value, but I intend to allow that in a future version.
- The application will be able to specify memory management functions per object. It will for example be possible to have the script engine allocate objects from an application specified memory pool, and then return the memory when the object is no longer used. In AS 1.10.1 that is not possible since the object is always placed on the stack, instead a wrapper object is needed.
- The application will be able to specify (in the declaration) if the object it receives in a parameter will be owned by the application or by the engine, i.e. who should be responsible for freeing the object after it is no longer used. If an application function receives the ownership of an object it may store it for later use or free it before returning, otherwise the library will free the object after the application function returns.
These are the changes that I will make in 2.0.0. They will make the library both easier to work with and much more flexible.
They will also build the foundation for future script declared classes, that will require full fledged garbage collection.
I consider the question about the assignment operators closed now (at least for version 2.0.0, maybe I'll open it again for version 3.0.0 [wink]). I hope my decision pleases the majority of you.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
