Page 1 of 2

[Implemented] Multi dimensional array support in structures!

Posted: Wed Apr 28, 2004 5:23 pm
by Shannara
I cannot believe that structures are so severly limited in PB! Bleh, if anything why don't fred make a new structure type, called "type", that will bypass all of the limitations of structures? This is aweful..

Anyways, I found out the hard way that structure arrays are severly limited, they can only be single dimensioned. What the.... thats another horrible limitation.. bah! So.... I wish... bleh.... that structures would support mutlidimensioned arrays.

(Implemented as 'Array YourArray(1,2,3)')

Posted: Wed Apr 28, 2004 6:05 pm
by freak
Wee, what a nice way to *ask* for a feature.. did nobody tell you how to be polite :?:
if anything why don't fred make a new structure type, called "type", that will bypass all of the limitations of structures? This is aweful..
I have no idea what you mean by this :?

Timo

Posted: Wed Apr 28, 2004 6:09 pm
by Shannara
Well, I keep on running into major limitations of structures in PB, its driving me crazy. :) First, the arrays in structures are inconsistant with the normal arrays (you have to minus 1, and the declaration is different [] instead of ()). 2nd, they are only single dimensioned (what the, not mentioned in the manual anywhere..), 3rd, they cannot be resized. 4th, what was this one.. ah.. now I have to look on my list..


Anyways, since Fred gave a reason for the weird array declaration in structures, in the manual, why not just create a new Structure type, called, "Type" or whatever (like in VB), that has all these features in it? That way we dont have to code complex work around for something that could be added (albit differently) ?

Not the same thing

Posted: Thu Apr 29, 2004 5:50 am
by oldefoxx
Type statements can be very useful, and they define exactly how data may be organized in some situations - for instance, a file record may be 8072 bytes in size, and the data in that record can be understood to have some bytes used collectively for numerical values, and other bytes used together to represent strings.

I too, like types because of this, and I also like the ability to overlay types so that the data can be interpreted in different ways -- in some cases, an internal flag in the record may indicate that the same sized record needs to be interpreted in a different manner, or regarded as an extension of a previous record. It's sort of like the pages of a book. If the book is written in the same font throughout, and unbound, then the page number is your first clue as to the correct sequence of pages, and Chapter and other Header markings identify where the book is organized in smaller We understand that every page is a fixed size, and only capable of having a given amount of text reported on it, but we'v mastered the ability to handle both smaller and larger amounts of text without difficulty through the concept of sentences, paragraphs, chapters, and sections. So much so that we take this for granted.

If you had a record size that corresponded to a single page, then each record would represent the information that should appear on that page. And the TYPE concept would lend itself to that very nicely.

But not everyone needs to think about data in this fashion. The author, who wrote the book initially, was not concerned with page layout or page count. The reviewer was not concerned either. The editor also was not concerned, though some estimates of the size book and costs might be called for.

I would like to see the intoduction of TYPEs in PureBasic, but I would also like to see more data types as well. What I don't see is that it is a super critical issue right now - there is a lot to like about PureBasic and a lot to learn and do with it as well.

Posted: Thu Apr 29, 2004 6:01 am
by Dare2
Okay, I'm clueless! :D

I read this and still don't understand the difference between types (VB-ish I assume) and structures (C and PB-ish, I assume).

Can someone explain. Again. It may help me if you use words of one syllable and short "Janet and John - Your Child's First Reader" like sentences. :?

Thanks.

Posted: Thu Apr 29, 2004 9:04 am
by oldefoxx
Both represent organized data, but in PB, a structure that includes non-numeric types, such as strings, relies on an embedded pointer that points to the particular string in string space. This is how a PB structure can accept any string length as part of that structure, and how the structures themselves can be relatively small.

A Type, on the other hand, defines exactly how data lies in a block of memory. If you define a string, you have to size the string to the maximum number of characters any indexed string of that type can have. For all other strings that have fewer characters, you have embedded spaces or null characters added to bring the string up to that maximum length, and the actual valid characters (the ones that are suppose to be there) are either left justified or right justified in that string. Must strings of this nature use nulls, as this nicely pads them out into ASCIIZ (null terminated strings), but PowerBasic has more flexability in this regard. Everything in a type can be located from the initial byte of any array or item defined as being of that type, based on the order of elements, what they are, and their understood or defined lengths.

Everything related to a TYPE exists completely inside each incident of something defined as being of that type. You can also define and embed pointers inside a type, which of course can point outside to something else, but it is understood when you set up the type structure that it would be a pointer. This is an overt act on the part of the programmer, whereas with PB, a string reference within a structure is also a pointer, but handled as a string, since the compiler understands the context.

Posted: Fri Apr 30, 2004 8:12 am
by Jose
@oldefoxx

I read with interest your posts.
you have a lot of time on your hands, or type realy fast :lol:

some code here of examples in difference between PB structure and what you see as VB type and why these are good, more code... :wink:

Just a thought, no offence intended.

True Enough

Posted: Fri Apr 30, 2004 9:24 am
by oldefoxx
I've 35 years experience in the computer field, and when my last company cut my whole group in 2001, I found that I could not get back on anywhere in the DC area without a current security clearance (mine had lapsed many years before). So I took early retirement, which I was elgible for, and the wife and I moved back to Pensacola, which is her home.

A few jobs surface around here from time to time, but at my age (63), it seems nobody is hiring. So I monitor the forums sometimes, work on different programming projects as my interest waxes and wanes, and try to answer the easy questions. Other times I go online and gamble for fun (I'm up over 850K in fun money), and swear I will never gamble for real at any of the online gambling sites - it is too easy to rig the games, and even if they try to play honestly, I don't trust their methods of randomizing game play. I'd tell them how to do it, but who listens?

Occasionally, I help some people with their programming projects or set up/clean up computers, but I won't just write code for anyone - I'll help them to a point, mostly with examples and tips, but programming is something you pretty much have to learn to do yourself, and getting me to write it for you is not going to get you over the hump.

That's pretty much it. Thanks for asking.

Posted: Fri Apr 30, 2004 11:34 pm
by Dare2
Hi oldefoxx,

Thanks for the clarifications.

It may be that PB structures can be organised to act as types. Along the lines of:

Code: Select all

Structure twoBytes
  byteA.b
  byteB.b
EndStructure

Structure TypeIsh
  fixedString.b[32]
  StructureUnion
    wordA.w
    twoB.twoBytes
  EndStructureUnion
EndStructure

myRec.TypeIsh

a$=RSet("XYZ",32)
PokeS(@myRec\fixedString,a$,32)
w$=Trim(PeekS(@myRec\fixedString,32))

myRec\wordA=257

Debug w$
Debug myRec\twoB\byteA
Debug myRec\twoB\byteB
Debug myRec\wordA
Unless I missed some point (always possible :) )

Think of it this way...

Posted: Sat May 01, 2004 1:20 am
by oldefoxx
If a block of memory were laid out to represent a sheet of paper, and the paper were sized to hold 80 characters per line and 55 lines per page, then you would have a memory block that was 4,400 bytes long.

If the sheet of paper were organized into columns or a grid, then you have imposed an additional structure onto that paper, and on the memory block as well. In doing so, you have effectively created a type. All this means is that some areas in that memory block are understood to hold certain types of information, and you can describe this as part of a TYPE
structure - how many bytes are used together, what they represent (a byte, a long, a string, whatever), as well as a name for that entry.

You can also organize the columns into arrays within the type. The number of elements and the size of the elements help determine not only where the elements are within the type, but also provide critical information on the organization of those elements.

But you have to keep in mind that all this information is mapped to the same memory block. It just defines in some detail how that memory block is to be treated, and simplifies some operations involving elements of that memory block. By treating the type as a UDT (User Defined Type), and defining other arrays to be of this type, you can map additional blocks of memory to have the same internal layout. The whole idea though, is just to organize the contents of the memory space.

PB Strutures has somewhat the same intent, but they do not define a single coherent block that contains all elements. Rather, they provide you with a means of creating a collection of things that can be dealt with as a unit. Some of that collection lies outside the structure itself, because the PB structure may rely on pointers to let you know where they are, and the structure defines what they are.

A pointer in this regard acts like a link to something else. If you try to access a web page offline, you may find that some of the internal links got broken in the process. PB structures act like web pages that still provide those links, whereas type structures are more like web pages that don't map to other pages or structures via links (pointers). Instead, a type structure has all elements embedded directly in it, rather than linking out to them. Web pages that have dynamic links can be much smaller and more interactive. Somewhat the same thing can be said of PB Structures.

Type pages have the advantage of being directly controlled and interpreted by the program designer, and are generally complete in and of themselves. They more closely resemble the physical media layout on which such records are recorded. That gives them some advantages over PB Structures. And TYPE structures are more generally found

It's not easy to explain these distintions. What is does mean is that a type has everything together just as you arrange it. A PB structure puts everything together just as the compiler arranges it. For many purposes the results are similar enough, but they are not identical. Adding pointers to types can emulate PB Structures, but it is far more difficult to find a way to duplicate Types with PB Structures.

Posted: Sat May 01, 2004 6:25 am
by Dare2
Hi oldefoxx.

Ah. Okay, from the above I am going to go out on a limb here and actually state an opinion. You can ( will :) ) correct me if I am wrong or have missed the point.

The discussion appears to be based on PB's lack of fixed length strings, which we need to emulate. I concur that fixed length strings are a need.

I think the lack is based on PB variable handling, which appears to trade stored (in exe) variable information for size/speed. With strings, this translates to a pointer and reliance on trailing null to terminate the string and determine size, that is, it appears not have a VLI. I am guessing here.

In all other respects a pb Structure = a Type.

We can emulate fixed length strings by using a string of bytes:

Code: Select all

; In PB
Structure myThing
  myFixedString.b[32]
  myWord.w
EndStructure

; In another lang
;TYPE myThing
;  myFixedString AS STRING * 32
;  myWord AS SHORT
;END TYPE

; in pb, to store and retrieve

myRec.myThing

PokeS(@myRec\myFixedString,RSet("XYZ",32),32) 
w$=Trim(PeekS(@myRec\myFixedString,32))

; in another language:

;DECLAREsyntax myRec AS myThing

;myRec.myFixedString="XYZ"
;w$=myRec.myFixedString
As StructureUnion allows redefining or "overlaying" parts of a structure, the thing we were discussing is really the syntax or approach to storing strings in structures?

You are getting close

Posted: Sat May 01, 2004 6:29 pm
by oldefoxx
Think of a TYPE as being complementary to the PB Structure concept. Where it would apply is in organizing memory blocks, or in the case of PB, memory banks. In fact that is where they would be ideal for PB.

PB's approach to handling strings is not based on some idea of speed, because you have to scroll the length of the string just to find out the length of it, and even a move, mid(), copy, or the joining of two strings are functions that are first based on knowing the length of a string.

No, strings under PB are based on the concept introduced in C that strings are incidental, and not primary to the purpose of game play. If you recall, C was developed for the purpose of game play, and only later strengthened with the addition of libraries to take on other tasks. Programmers liked C because of its brevity and neat tricks, which also tended to make it difficult to follow and understand. In fact, it became necessary to write programs, such as Lint, to spot obscure problems and syntatical errors in C and C++, because programmers kept losing the thread of what was going on in the code.

As I understand it PB is built on top of C, which is in part what makes it very fast and small - characteristics of C. That makes it reasonably easy to convert similar functions directly into C code, but maintain the easy readability that is characteristics of BASIC. Between the two, you approach an ideal concept.

But for non-game purposes, strings take on great importance. And the rudamentary string support in C now becomes a limiting factor. Also the types of data become critical as well. Floating Point types need greater precision. Numeric types have to be longer as well. You need a data type ideal for handling currency and financial calculations, since extremely high precision are needed for amorization processes involving huge sums of money.

Anyway, back to the topic. Memory banks are primitive concepts, and with the introduction of types, you would suddently have a way to build out memory blocks in familiar and easy-to-use manner. That is because a type is essentially an overlay of a physical area of memory in a meaningful arrangement. It like looking at an areal photograph of a large area of land, and not really recognizing anything. Then take a clear plastic overlay with lines and notations written on it and lay it on top, and when properly aligned to the picture below, you can suddenly identify towns, roads, railroad tracks, and the like. A TYPE is like that clear plastic overlay, but nore than that, you can now use the familiar terms provided by the overlay to tell the compiler what you want done with portions of the memory underneath.

Fixed length strings are certainly required within a type, because in this approach, all elements within a type must conform to the area of memory that it maps to. But fixed length strings are of themselves a stronger concept than the primitive null-terminated ones that were first introduced in C. Their starting address and length are both givens, and any command that involves manipulating a string already has the advantage of not having to search the string from the beginning to find the end each time it tries to use it. Fixed length strings can also contain bytes of zero value, which is often an advantage in its own right.

But there is another class of strings that would be needed as well, and this is the variable length string that also has a known length associated with it. Unfortunately, this type of string cannot be supported directly with a TYPE (remember that a TYPE corresponds to a fixed area of memory), but you can of course set up a pointer and a length variable and embed them in a TYPE to represent a reference to an external string. This is useful if you need to be able to quickly find any given line within a large flat file, such as a document, possibly as a result of writing your own editor or merge/compare program.

Consider this: If you had a memory block, and a string, and wanted to copy the contents from one to the other, you have to do this with a serise of byte commands, because you do not know where the end of the string is. Each byte copy operation also has to invove a check for the Null byte so that you would know when the end of string has been reached. Everybody who has tried this has decried the fact that there isn't a cleaner and faster way to do this, but that is the nature of primitive strings.

But now suppose you have a TYPE, which involves fixed length strings, or a variable string type that has a known length. It is very simple then to copy one from the other using a MOVE() or COPY() routine, because you have the two beginning addresses and the length of one of the two (usually the shorter one) to determine how many bytes to copy. And now instead of relying on a byte copy operation, you can optimize it with a word copy operation (with an odd byte copy at the end if needed). These determinations are fast, and the result is at maximum speed, because the deliberations can be resolved without having to scroll the length of the strings to find the Null byte first.

The result would be a more flexable and more suited environment for handling non-numeric or extensively numeric calculations and operations.

Posted: Sun May 02, 2004 1:26 pm
by Dare2
Hi oldefoxx,

Firstly, thank you for the time you've spent trying to educate me about the difference between types and structures.

Unfortunately, I still cannot see the conceptual difference between the two. :?

I am going to bow out of this now, but again, thanks for the effort. :)

Posted: Sun May 02, 2004 2:53 pm
by oldefoxx
I understand. Your problem is that they are both targeted towards the same end - a way of grouping related information together and treating it as a unit. Where they do not agree is in exactly how they reflect the area of physical memory that they supposedly occupy. If you look at a type and it says that a string's contents occupy a certain area and is a certain number of bytes (or characters) in size, then that is where it is at and how long it actually is. If you look at a PB Structure and see an embedded string, the string isn't actually there - it is somewhere over in the string space and all you actually have is a pointer (a link) to it. That may seem an insignificant difference, but if you attempt to map a type to an area of memory, or to reflect an area of memory using a PB Structure, you find that is is a profound difference.

But until you actually attempt either of these things, you are not going to understand the difference. You keep getting tangled up in the similarity of purpose and reuse of similar terms. All I can tell you is that the difference centers around whether pointers are being employed to represent objects, or whether the objects themselves appear in that location.

Posted: Sun May 02, 2004 3:19 pm
by Dare2
Heya oldefoxx,

I still think this is a matter of approach.

Code: Select all

structure: myFixedString.b[32]
; versus
type: myFixedString AS STRING * 32
and that the issue lies with the string support in PB, not with structures per se. Fixed length strings, strings capable of containing binary zero (VL strings controlled by a VLI) would be great.

The Setting and Getting of structured fixed-length-strings requires peeking and poking as outlined earlier, versus simple assignment. Otherwise the two (structure v type) appear the same to me.

But I truely am bowing out now. :)