Serialize long as 32 or 64 bit integer depending on platform

[jakubpawlewicz]

No description provided.

[mirek-fidler]

This would break exchanging data between platforms...

I guess any code that expects long to be 64 bit is sort of broken by default anyway. That said I agree that it would be better to always store long as 64 bits (with slightly different code), but a bit late for that now...

[jakubpawlewicz]

Thank you for a comment. The problem is that some external libraries work on int64_t from <cstdint> which is in fact defined as long. In U++ int64 is long long. Those types are incompatible if you work on templates. Sometimes I am enforced to use int64_t. It took me substantial amount of time why transferring data through U++ serialization resulted in serious problems. But it is ok. I will use my fork of ultimatepp in my applications. If you want you can close that PR.

[mirek-fidler]

That is a pretty valid argument. I will keep thinking about it...

…

On Fri, Sep 6, 2024 at 6:50 PM Jakub Pawlewicz ***@***.***> wrote: Thank you for a comment. The problem is that some external libraries work on int64_t from <cstdint> which is in fact defined as long. In U++ int64 is long long. Those types are incompatible if you work on templates. Sometimes I am enforced to use int64_t. It took me substantial amount of time why transferring data through U++ serialization resulted in serious problems. But it is ok. I will use my fork of ultimatepp in my applications. If you want you can close that PR. — Reply to this email directly, view it on GitHub <#204 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AARH234IZXA42HJ5JTB47FDZVHMO7AVCNFSM6AAAAABNYYLCR6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMZUGQ2TGMBTGM> . You are receiving this because you commented.Message ID: ***@***.***>

[mirek-fidler]

Well, I think I have sort of solid solution evolving for this after all...

The plan is

• actually remove operator%(long &) - this will make sure that no legacy code breaks - developer will just be forced to use the new method. At the same time, it is also very unlikely that any 'normal' longs were ever serialised

• replace with method SerializeLong64(long&). I guess should not be a problem for you to call that instead.

Also add Serialize8/16/32/64 for all intXX_t types, esp. int32_t and int64_t

Yep, a bit trivial solution compared to the time that has taken me to consider it, but I guess the only sound one.

What do you think?

Mirek

[jakubpawlewicz]

Huh, removing operator% breaks some implementation from Core for instance StreamContainer which is used in Vector::Serialize().

Vector<int64_t> should be serializable.

[mirek-fidler]

Ah, thanks, good point. Back to drawing board...

…

On Mon, Oct 21, 2024 at 4:37 PM Jakub Pawlewicz ***@***.***> wrote: Huh, removing operator% breaks some implementation from Core for instance StreamContainer which is used in Vector::Serialize(). Vector<int64_t> should be serializable. — Reply to this email directly, view it on GitHub <#204 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AARH2364FPLQUGE37QETQP3Z4UGTVAVCNFSM6AAAAABNYYLCR6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMRWHA3TMOBYGM> . You are receiving this because you commented.Message ID: ***@***.***>

[mirek-fidler]

Well, all things considered, I think this is the only safe way:

9cc3711

[jakubpawlewicz]

So Vector<int64_t> will not serialize correctly since this relies on operator%. I will stay with my fork for my purposes.

[mirek-fidler]

Well, I really see no way around - dword really is used to store persistent data that has to be correctly saved on windows and loaded in linux. And it basically has to be defined as unsigned long in win32....

[jakubpawlewicz]

For me no problem. I have some other changes and I will keep use my fork of U++ anyway.

I understand that serialization is broken for long in Linux. I encountered some other projects that suffer with portability because of this incompatibility of size of 'long' between Linux and Windows.