Fixed-dimension, variable-length, is handy for compile time type checking. Also, saves some space in the descriptor. '' a() must be 2 dimensional sub proc( a(any,any) as integer ) end sub dim a(1 to 10) as integer proc( a() ) '' type mismatch Yeah, I was just trying to work out if a "fixed-dim&...

Static - dynamic: to my understanding a static (fixed size) array´s descriptor must not be changed at runtime. That is number of dimensions and number of elements must be static. You must not be allowed to redim or erase such an array. Just a little brightening; Using the future 'static' flag, ERAS...

Static - dynamic: to my understanding a static (fixed size) array´s descriptor must not be changed at runtime. That is number of dimensions and number of elements must be static. You must not be allowed to redim or erase such an array. This allows for compile time optimization. A dynamic array curr...

Sorry, but this is only good for FBC 32 bit ... not so, for FBC 64 bit! Except the "bitfield" (aka: flags) is of a fixed size: ULong (not UInteger). new flags field will be UINTEGER which will be same size as cpu's native word size. True this size could be 32 or 64 bits, but we only ever ...

What is the actual contents of variable "resp"? You must be getting something if program makes it past the INPUT statement. Add a print "*" & resp & "*" after the input statement. That might help determine if it's a coding problem or a hardware problem; like a f...

The field will have 32 bits available for array descriptor options. I hope this will be an Integer (32/64 bits) like all other fields, so 32 bits useful? Where exactly do you intend to add this field in the array descriptor structure? (perhaps just before the number of dimensions) yes, new field wi...

Does this mean that all arrays will have descriptors, exposed and available, in this future version? david Yes, that is the intent. Plus, also trying to create a bit of a structure for other additions, like string descriptor, or file i/o, or whatever. To note, I am trying to keep a little separatio...

As already said above when you expand the FBARRAY type, add one or more "reserved" members. This gives room for future ideas, without breaking compatibility with every new step. Yes, I read through the code for your proposed additions. From your code and other comments in this topic, the ...

FBintern -- whould clear the issue ... just a idea, up for discussion. Thanks, MrSwiss. Yes, the changes I added immediately create 2 issues that I will lazily defer to later to resolve. 1) namespace FBC , I really would like to reserve the FBC namespace for compiler internals, so, should the need ...

fxm, yes, go for it. Thank you. It's good to have your expertise added to the programmer's guide. You should feel free to cut and rearrange topics as needed. Also, if it makes sense to rename or delete pages, just go ahead as needed because if we really had to get an old version, the pages are also ...

This will be no problem anymore as soon as Jeff changes the descriptor´s definition, because then this workaround will be obsolete. By next weekend should be merge in. I ran out of time this weekend to get the array descriptor changes added. The first part needed, which is to document existing arra...

OK, so we have a number of array related bugs reported on sf.net, plus some new ones reported in this topic, and maybe some others hidden in other topics on the forum. First step, I think, is to expose the existing array descriptor for developers and advanced users. This will give us a record of our...

Just another thought: No. :) I'm not giving the compatibility another thought. fxm's idea of placing data just before the descriptor (I think), would be fairly compatible, though also not 100% in all cases, so my opinion, is to not bother, and go for the simplest solution. I'm adding a field for fl...

Simplest solution is to add information (i.e. a "flags" field) to existing array descriptor and break compatibility. Because this is not the only bug reported that is going to break compatibility to fix, we are going break binary compatibility anyway on next release. Apart from the static...

Juergen Kuehlwein wrote:This will be no problem anymore as soon as Jeff changes the descriptor´s definition, because then this workaround will be obsolete.

By next weekend should be merge in. I ran out of time this weekend to get the array descriptor changes added.