|
Post by Walt Decker on May 14, 2022 10:40:13 GMT -5
Walt: I have sequential files that have non-variable length records. Why can't I read them one at a time into a structure? (like I do when reading random files sequentialy) Rod: You said an RAF file is a sequential file? RAF does not stand for random access file? The trouble with using a STRUCT to read and write a file is that some of the elements of the STRUCT might be pointers. We could resolve those to what they point to when we GET and PUT them, but you will need to be careful about the length of strings and other data and manage all that in your code. I would probably be better just to extend/enhance the current random access file mechanisms. I am guessing that the * 125 part of Walt's example is meant to manage the limits of a datum that is referred to by a pointer. Seems like a reasonable way to approach it, but things might get confusing if we decide that our STRUCT should have pointers to other STRUCTs, etc. and how does this map into a random access file? #DEFINE STRUCT MyStruct A AS LONG B AS LONG C AS STRING * 128 #END STRUCT Some sort of well thought out fielded RECORD feature might be easier for most people wrap their minds around. #DEFINE STRUCT MyStruct A AS LONG B AS LONG C AS STRING * 128 #END STRUCT
The above is just a template the compiler uses to define a block of memory when one declares a variable of type MyStruct. The "C AS STRING * 128" defines a field of 128 ansi type bytes, i. e. C$[128], not a pointer. To declare a wide string(unicode) field one could define field "D AS WSTRING * 128" and to declare a null terminated unicode string one could define field "E AS WSTRINGZ * 256".
Since a pointer is a number there is no need to equate it to a string. Simply declare it as:
F AS POINTER G AS Fo STRUCT POINTER
For a random access file there is no need for field strings as in LB4x/PRO. The fields are inherent in the structure so you just write out the memory elements of the structure from top to bottom and read it back the same way directly into the structure. You can jump around in the file to read any record by multiplying the size of the structure by the record you want and setting the file pointer to that position. It is up to the programmer to build a structure appropriate for the data.
As for a pointer in a structure pointing to another structure it seems to me you would have to invent a pointer mechanism in order to address the elements of the external structure.
|
|
|
Post by Carl Gundel on May 14, 2022 10:49:19 GMT -5
The fields are inherent in the structure so you just write out the memory elements of the structure from top to bottom and read it back the same way directly into the structure. You can jump around in the file to read any record by multiplying the size of the structure by the record you want and setting the file pointer to that position. Yes, we could do that but I’m not persuaded that it makes sense to overload that feature of LB.
|
|
|
Post by Walt Decker on May 14, 2022 11:08:08 GMT -5
I do not see where there is any overloading involved. The block of memory is simply written to the file as it is. After all, a file is just a collection of bytes. It can be read or written to any way you want.
|
|
|
Post by Carl Gundel on May 14, 2022 15:17:49 GMT -5
I do not see where there is any overloading involved. The block of memory is simply written to the file as it is. After all, a file is just a collection of bytes. It can be read or written to any way you want. Overloading means that a keyword, feature or function has more than one meaning or function. Let a STRUCT be a STRUCT and a RECORD be a RECORD. I’m not saying that the other approach is without merit but that’s not the way I usually approach things.
|
|
|
Post by Rod on May 14, 2022 15:24:01 GMT -5
I can understand a Struct as a data structure, I can understand hosting an array of those similarly sized structs. The limitation is that strings are finite as defined by the Struct. So not strings at all really. A Struct within a Struct gets a bit hairy, but not if it is a fixed length. So no pointers to variable length strings. With that limitation I can see that holding a variety of data types as a single entity could be useful,. like a bmp header.
So the stone wall seems to be the pointer to a variable length entity.
|
|
|
Post by Walt Decker on May 14, 2022 15:54:32 GMT -5
Yes they are. They take ansi values, not numeric values
Not hairy at all. All elements in a structure are STRICTLY defined.
No problem. The pointer is to an address in memory. Just use WINSTRING(Address) to stuff a string variable. If the address is a pointer to an array of variable length strings then you have a problem. If the address is a pointer to an array of values, you have to know what type of values then sequentially increment the address based on the value type size.
As for files, a record can be anything I want. If I define A = 1000000 and write A to a file, that is 1 record of 4 bytes. If I define A AS CHAR[1024], A = "The quick brown fox" and write A to a file that is 1 record of 1024 bytes. A record is only a construct of the programmer, it is not some law written in stone.
|
|
|
Post by Carl Gundel on May 14, 2022 16:20:20 GMT -5
As for files, a record can be anything I want. If I define A = 1000000 and write A to a file, that is 1 record of 4 bytes. If I define A AS CHAR[1024], A = "The quick brown fox" and write A to a file that is 1 record of 1024 bytes. A record is only a construct of the programmer, it is not some law written in stone. There are many ways to abstract ideas, or to reuse language features in clever ways. However I am referring to what will become concretely implemented language features.
|
|
|
Post by Walt Decker on May 15, 2022 8:43:19 GMT -5
There is nothing abstract or clever about the way I define a record in a file. That is the way the file system is designed and has been used by top programming languages for the past 30+ years. That is why a record in a file can be a structure, and that is why one can define one's own concept of file record and constrain other programmers to h/er concept.
|
|
|
Post by Carl Gundel on May 15, 2022 12:23:24 GMT -5
There is nothing abstract or clever about the way I define a record in a file. That is the way the file system is designed and has been used by top programming languages for the past 30+ years. That is why a record in a file can be a structure, and that is why one can define one's own concept of file record and constrain other programmers to h/er concept. Okay Walter. I think we are talking cross purposes. We don’t seem to think the same way about this.
|
|
|
Post by Marco Kurvers on May 15, 2022 13:49:27 GMT -5
Is it possible that in LB v5.1 the struct can be used as that you saw it in my first example? It's very difficult to make a person table with diffent datatypes and to save it in an array.
If the struct does not get the functionality for that technique later in LB v5.1, Liberty BASIC will lag behind Visual Basic with the functionality. I know that the struct in LB 4 is most commonly used for API functions, but I assume that the use of it becomes less.
I hope that there comes a beautiful solution for structures in Liberty BASIC 5.
|
|
|
Post by Carl Gundel on May 15, 2022 13:59:33 GMT -5
Is it possible that in LB v5.1 the struct can be used as that you saw it in my first example? It's very difficult to make a person table with diffent datatypes and to save it in an array. If the struct does not get the functionality for that technique later in LB v5.1, Liberty BASIC will lag behind Visual Basic with the functionality. I know that the struct in LB 4 is most commonly used for API functions, but I assume that the use of it becomes less. I hope that there comes a beautiful solution for structures in Liberty BASIC 5. Yes, there is a need for a feature like this. Not sure that STRUCT will be it.
|
|
|
Post by Marco Kurvers on May 15, 2022 14:19:51 GMT -5
Ok Carl, thanks for the answer.
|
|
|
Post by Marco Kurvers on Jul 27, 2022 12:27:39 GMT -5
Structs are on the docket to be implemented in LB5 very soon. I am aiming for LB4 compatibility only for v5.0. Perhaps for v5.1 we will see something more. I am leaning more towards some more formal field based record feature, but these ideas are still not completely formed in my mind. Open to suggestions of course. Carl, I think that you mean I can use LB4 structs for compatibility in v5.0. I tried this, but it will not working. Even though the struct command is recognized (it gets the right color), version 5 does not want to execute it.
|
|
|
Post by Rod on Jul 27, 2022 13:44:56 GMT -5
LB5 Structs are simply not implemented yet. Carl hopes to have basic LB4 struct compatibility implemented soon. After that, and some time away, he hopes to offer more functionality on 5 than 4
|
|
|
Post by Carl Gundel on Jul 27, 2022 18:51:17 GMT -5
LB5 Structs are simply not implemented yet. Carl hopes to have basic LB4 struct compatibility implemented soon. After that, and some time away, he hopes to offer more functionality on 5 than 4 That's right. Even when they are implemented, much of the GUI related code that uses them will not work because native widgets are not part of LB5. In the future I will aim to remedy that.
|
|