ok. so i shall convert them all to 0-based. and then carefully look over the code and get rid of 1-based assumption. On 3 September 2012 11:58, Luc Fabresse <luc.fabresse@gmail.com> wrote:
Hi Igor,
I am also used to the 0-based when dealing with C-stuff.
Cheers,
#Luc
2012/9/3 Marten Feldtmann <marten@schrievkrom.de>
Hello Igor,
0-based - because it's oriented towards C structures (and therefore memory oriented).
Another way to see this is: it's not an index, its an byte-offset from the beginning of the memory. Therefore I would not name the parameter as something like index, but more like zeroBasedOffset. By the way: VASmalltalk does it the same way.
The same problem might occur, when dealing with pointers to array of primitive data types in ByteArray or instances of NBExternalAddress.
Even here I would suggest using zero based index structures - though it is contrary to Smalltalk typical 0ne-based array index. In VASmalltalk this situation is zero-based access and the parameter is not a byte index, but a data element index. And an index of "0" returns the start of the array (and the first element).
Marten
Am 03.09.2012 02:28, schrieb Igor Stasenko:
Hi, there
i added a bunch of accessors to ByteArray and NBExternalAddress which having uniform look:
nb<type>At: nb<type>At: put:
where types are:
{U}Int<8/16/32/64> or Float<32/64>
the problem is that indexes in ByteArray are 1-based, but in NBExternalAddress is 0-based.
And there's already different places in code which following these rules. But i feel like this should be uniform (so same piece of code can be used for either bytearrays or external addresses), to avoid confusion and mistakes.
i just not sure which one to leave: 1-based or 0-based ?
From one side, all collections in smalltalk is 1-based.. but from other side accessing memory at 1-based offset looks also unnatural.
What you think?
-- Best regards, Igor Stasenko.