For this to be complete, we must allow also 'As datatype array()' in UDTs (in this case, the descriptor is allocated for 8 dimensions), in addition to 'As datatype array(Any, ...)' (where the allocated descriptor is sized depending on the number of 'Any' declared) and...

I think that only if you declare the dynamic array as: {Dim|Static} [Shared] As datatype array() (without any indication of sizing) the allocated descriptor is sized for the maximum number of dimensions (8). But if you declare the dynamic array as: {Dim|Static} [Shared] As datatype array...

"fbcadcam.net/forum/" is it down (I get no page or a blank page depending on broswer)?

The size of the array descriptor may depend on the number of dimensions. If you increase the number of dimensions, the descriptor should be reallocated in memory, which should often change its address, but change the referencing of an array is not possible. I think that only if you declare the dynam...

But the bigger problem is to distinguish between a var-len array in the heap and a fix-len array in the .BSS or .DATA section. For example, in your Scope block, between: Redim As Double d(4, 5 to 7) '' var-len array data in the heap and Static As Double d(4, 5 to 7) ''...

Sub Proc(ByRef Result As Integer, Ar() As Integer) Print Result '<- Valid ReDim Preserve Ar(20) '<- The reference is invalidated Print Result '<- Invalid, the element may have been moved @Result = @Ar(1) Print Result '<- Valid, the reference has been reinitialized End Sub Dim Array() As Integer ReD...

In the present structure of array descriptor, one single field could be instanced on a shorter word (than Pointer/Integer). This is the number of dimensions (between 0 and 8). Is it better to use here a Byte instead of an Integer in the descriptor structure?

MrSwiss wrote:Why do you always feel the need, to state the obvious?

I do not feel that other users view most of my posts and articles and documentation pages as obvious information.

In any way, the final decision is up to the developer (Jeff).

Anyway, as this type of structure (descriptors) already contains pointers and most of the other fields are information linked to available addressing, this will be done naturally with 32/64 bits.

maybe it would make sense to have two topics. 1) "Variable Scope and Lifetime" - beginner, most common use cases 2) "Object and Data Lifetime" - advanced, more detailed mechanics of allocation/deallocation, pointers & references Therefore, I propose for the "Programmer'...

'Namespaces' page filled in the Programmer's Guide / Declarations:
- ProPgNamespaces → fxm [new page created]
- CatPgProgrammer → fxm [added link to "Namespaces" page]
- PrintToc → fxm [added link to "Namespaces" page]

coderJeff wrote: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)

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...

Referring to the behavior described for C ++ (see my previous post), the following seems normal to me: namespace one declare sub s1() declare sub s2() end namespace using one sub s1() '' definition of one.s1() end sub declare sub s1() '' .s1() declared in the scope overrides one.s1() sub s1() '' OK,...