All numberic types are 64 bit on Objeck?

[ghost]

If Int is 64 bit then the maximum value for an Int is 9223372036854775807 isn't it?

https://learn.microsoft.com/vi-vn/cpp/cpp/data-type-ranges?view=msvc-160

But this piece of code doesn't agree with it:

N := 9223372036854775807;
(N-1)->PrintLine();

It printed 2147483646. This mean the maximum value for an Int on Objeck is 2147483647 so Objeck's Int is 32 bit.

[objeck]

The best way to state this is that Objeck is 64-bit for the host environment. For Win64, longs are 32-bit; however, they are 64-bit on POSIX per the platform specifications. As such, program code data (such as literals) are capped at 32 bits. Some optimization is done within the compiler (i.e., constant folding and propagation) and assumes long 32-bit literals. The VM and its JIT compilers run in 64-bit mode with a cast to 32-values as needed.

[ghost]

For Win64, longs are 32-bit;

Yep, but Windows also provides long long which is 64 bit. Objeck is kind of like Java, why don't you learn from Java? Java's long is 64 bit regardless of the platforms. What's the point of compiling to bytecode and running on a VM if you don't care about being platform independent at all?

Update: My point is, even though on Win64 long is 32 bit, Windows also provides long long which is 64 bit. Objeck, on the other hand, provides nothing. There is no 64 bit integer on Win64 with Objeck. What if people need to use 64 bit integer on Win64 with Objeck? Do you ever think about it? If it's all int64_t and size_t underlying why don't make it consistent between platforms like Java?

Another update: Unlike Fantom, Objeck doesn't allow the users to specify the data type. On Fantom, type inference is something completely optional and people could write something like Int foo := 1 instead of foo := 1 to force foo to have type Int. On Objeck, we have no such luxury. You will have to rely on type inference entirely. So even if you added a 64 bit integer type independent to platforms, e.g: Int64, we still have no way to force the variable to be of this type. Maybe implemented as a compiler switch. But if using a compiler switch then the type Int64 is not needed at all, simply forcing Int to be 64 bit when compiling with this switch on and done. But, it's longer like a Java style platform independent language anymore. It's like C/C++ with syntactic sugar that still has C/C++ shortcomings like platform dependent types, compiling to bytecode and running on a VM.

[objeck]

@iahung a type can be enforced via the following a : Int := 'h'; the character will be treated as an Int. The issue is not "learning" from Java. It is changing a 64-bit Windows environment to operate like a Posix 64 environment. Lots of minor changes to system APIs that operate on long to ensure they are operating on int64_t on Windows. A lot of APIs to check between the compiler and VM.

I may make a branch and explore further. There is incompatibility with the C++ STL and int64_t on Windows using VC, which I'll explore later.

[ghost]

@iahung a type can be enforced via the following a : Int := 'h'; the character will be treated as an Int.

Add it to document please? Otherwise who could know about that other than you?

[objeck]

@iahung a type can be enforced via the following a : Int := 'h'; the character will be treated as an Int.

Add it to document please? Otherwise who could know about that other than you?

I think it's here

[objeck]

Point taken, I will take action to explore changing the 64-Windows model to be POSIX 64 compliant.

[ghost]

@iahung a type can be enforced via the following a : Int := 'h'; the character will be treated as an Int.

Add it to document please? Otherwise who could know about that other than you?

I think it's here

Just another weird syntax @objeck:

a, b : Float := 13.5;
b += -a * 13;
"{$b}"->PrintLine();

In this case, both a and b were assigned to 13.5 or only a was assigned to 13.5 and b is undefined?

If b is undefined how could you add -a * 13 to it? So b must be auto initialized to 0 somehow?