64bit size_t vs asUINT

Started by
9 comments, last by kulik 17 years, 11 months ago
I tried to compile AngelScript because I am very interested to support such scripting system in my engine. I got 64bit system however (gentoo linux). When I try to compile it I get loads of easily-solveable errors (such as size_t GetLength() isn't equal to asUINT GetLength(), because sizeof( size_t ) != sizeof( unsigned int ) under 64bit). I could correct all these, but first I want to know if somebody has the same problem or if I could correct these and post patches. If I read it correctly AngelScript is supposed to support 64bit (only Win64?) as said in AngelScript 2.6.0 release thread. btw: I declared all defines needed to compile this on 64bit machine as stated in the thread. (AS_MAX_PORTABILITY and AS_64BIT_PTR). If you don't know what I am talking about, take a look in as_array.h, there is:

template <class T> class asCArray
{
public:
	...
	size_t GetCapacity() const;
...
	size_t GetLength() const;
...
	size_t  length;
	size_t  maxLength;
};
This seems right, but later in that file:


template <class T>
asUINT asCArray<T>::GetLength() const
{
	return length;
}
...
template <class T>
asUINT asCArray<T>::GetCapacity() const
{
	return maxLength;
}
It's implemented with asUINT return type but declared with size_t return type. Which doesn't seem right and gcc has the same opinion.
Advertisement
I 'm working on full 64bit support, even with native calling conventions. Currently I have 49 out of 94 tests passing. I don't know how much longer it's going to take me (I have a real life too ;) ) though, so no promises :)

Yiannis.
wow, keep up the good work :)
If you'd like I could help you (don't know a thing about calling conventions though) ... As I said I would be very interested to see this fully working on 64bit linux :)
The problem with this is that Witchlord doesn't have a 64bit machine to develop on himself; so theres not much chance of the most recent versions being fully compatible until he gets his hands on a machine.
Quote:Original post by Deyja
The problem with this is that Witchlord doesn't have a 64bit machine to develop on himself; so theres not much chance of the most recent versions being fully compatible until he gets his hands on a machine.


I don't know what exactly you 're saying here. I 'm working on the latest version, directly from SVN.
Sure, if WitchLord had access to a 64bit machine, it would be probably be converted by now since I 'm studying the code as I go while he knows it already by heart ;). It's just taking me longer...
Quote:Original post by mandrav
Quote:Original post by Deyja
The problem with this is that Witchlord doesn't have a 64bit machine to develop on himself; so theres not much chance of the most recent versions being fully compatible until he gets his hands on a machine.


I don't know what exactly you 're saying here. I 'm working on the latest version, directly from SVN.
Sure, if WitchLord had access to a 64bit machine, it would be probably be converted by now since I 'm studying the code as I go while he knows it already by heart ;). It's just taking me longer...


Are you also commiting changes there? So I can checkout the repo and use it as it is for now (w/o native calling conventions)?
If he branched it, he could work on that seperate copy. I think sourceforge can do that automagically, but needs the admin (ie, witchlord) to initiate it.
Quote:Original post by Deyja
If he branched it, he could work on that seperate copy. I think sourceforge can do that automagically, but needs the admin (ie, witchlord) to initiate it.


Do we really need a separate branch? These changes are so generic that they definitely could go into trunk ... And the native calling conventions could too IMO if they were macroed.
Sure. But it's witchlord's decision to let anyone else modify the source directly. And, nothing against anyone who wants to contribute so directly, I would rather see the library safe in his hands then shared around. I haven't seen a public project that didn't turn into a mess.
kulik:

mandrav has already sent me a patch that should fix the very same problems that you discovered. You can get that from the latest revision in the SVN. The latest revision also fixes some other problems with the 2.6.0 release.

mandrav:

Deyja is right. When I release a new version with new features, it's usually not 100% tested on all platforms supported as I only have 1 myself. The problems that you and kulik found are proof of that. Fortunately the community lets me know about these problems fairly early so that I can get updates out as quick as possible.

I'm happy that half of the tests work already with the native calling conventions. That's very good progress. :D

Would you like for me to check in the code that you already have to the SourceForge project? That way others, like kulik, could help test your code? I could create a new branch for this if you feel like it?

Deyja:

Don't worry I won't let others check in code against the main branch. I prefer to have complete control of when a feature is put into the official library. It's also not always that a contribution made by another developer is completely in line with my ideas for the library, when that happens I usually rewrite parts or even all of the contribution (still crediting the original author of course). It would simply cause too much instability in the library if the main branch was open for others to work on directly.

Now, for everyone:

I'm still new at this whole SourceForge thing. You've mentioned creating branches to allow others to check in code. Now I already know how to create a branch, but how would I go about allowing other developers check in code against that branch and only that branch? Does anyone know that?

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

This topic is closed to new replies.

Advertisement