From: msevior_at_physics.unimelb.edu.au
Date: Fri Mar 05 2004 - 13:18:44 EST
>
>
> We also have UT_NumberVector which fjf implemented while back; it
> might be simplest to make use of it where appropriate.
>
Yes I agree. I'm also not sure that this is the cause of the 64 bit issues.
Although <void *> is a 64-bit number on 64-bit OS's, it should cast down to
UT_uint32 without problems.
On the other hand if we ever assign a genuine pointer to a UT_uint32 then
we're *are* in real toruble.
Martin
> Tomas
>
>> Hi,
>>
>> Now, some people attempt to build AbiWord on 64-bits arch like amd64 or
>> ia64. One of the main issues is that we use UT_Vector to store plain
>> UT_uint32 while UT_Vector is designed to store void * (ie pointers). The
>> problem is that on amd64 and ia64, a void * is 64-bits long while an
>> UT_uint32 is still 32-bits.
>> There are patch that does casting madness (see bug
>> http://bugzilla.abisource.com/show_bug.cgi?id=6460 that points to
>> Gentoo's http://bugs.gentoo.org/show_bug.cgi?id=43260)
>>
>> I have a cleaner solution in mind, but this would involve breaking a
>> coding rule: using template.
>>
>> The idea is just to template UT_Vector to either store a void * or an
>> UT_uint32. This would not only benefits for the 64-bits arch issue, but
>> it would also remove wild castings performed in UT_Vector. Off course
>> this fix would involve changes in large parts of the code.
>> And to not overuse the templates, I'll limit it to sublcassing the
>> template instances and only allow these.
>>
>> template <class T> class UT_GenericVector
>> {
>> //....
>> };
>>
>> class UT_Vector
>> : public UT_GenericVector<void*>
>> {
>> //....
>> };
>>
>> class UT_IntVector
>> : public UT_GenericVector<UT_uint32>
>> {
>> //....
>> };
>>
>> Any pros and cons ? Now that almost almost any compiler we use supports
>> template, I don't think this is a big issue.
>>
>> If you are against template, there is a harder solution (plan B), but
>> I'd prefer not use it.
>>
>> (yes, that can wait after 2.1.1 is release)
>>
>>
>> Hub
>
>
>
This archive was generated by hypermail 2.1.4 : Fri Mar 05 2004 - 13:19:48 EST