Quick question on Enum's data type

[dodicat]

Surely an enum is only a shortcut to integer<32> constants, giving then names.
Saving to file and retrieving from file requires only to remember a 32 bit variable is used for a particular udt field.

Save to file.

Code: Select all

 Enum Shapes
   circle = 1
   square
   triangle
End Enum

Type Block
   As Shapes Shape
End Type


dim as block b(1 to 10)

for n as long=1 to 10
    b(n).shape=cint(rnd*3)
    select case b(n).shape
    case 1:print n, "circle"
    case 2:print n, "square"
    case 3:print n, "triangle"
    end select
next

Sub savefile(filename As String,p() As block)
    var n=freefile
    If Open (filename For Binary Access Write As #n)=0 Then
        Put #n,,p()
        Close
    Else
        Print "Unable to save " + filename
    End If
End Sub

savefile("blocks.dat",b())
print

print "OK, saved as blocks.dat"
sleep


 

Load from file:

Code: Select all

#include "file.bi"
Enum Shapes
   circle = 1
   square
   triangle
End Enum

Type Block
   As integer<32> Shape
End Type

sub loadfile(file as string,b() as block)
   If FileExists(file)=0 Then Print file;" not found":Sleep:end
   var  f=freefile
    Open file For Binary Access Read As #f
    If Lof(f) > 0 Then
      Get #f, , b()
    End If
    Close #f
end sub

var lngth=filelen("blocks.dat")\(sizeof(block)) 'get incoming array dimension

'print lngth,filelen("blocks.dat"),sizeof(block)
'print
dim as block s(1 to lngth)
loadfile("blocks.dat",s())

for n as long=lbound(s) to ubound(s)
    select case s(n).shape
    case 1:print n, "circle"
    case 2:print n, "square"
    case 3:print n, "triangle"
    end select
    next 

[MrSwiss]

Surely an enum is only a shortcut to integer<32> constants, giving then names.

No, it is a shortcut to Integer = 64 bit in FBC 64 (your assumption is only valid for FBC 32).
As also confirmed by D.J.Peters (Joshy) and fxm.

Saving to file and retrieving from file requires only to remember a 32 bit variable is used for a particular udt field.

Nobody has ever debated that point (Long = Integer<32>).

[dodicat]

So long as you remember that on retrieving any file udt data (using enum) you must use integer<32> ~ long.
The file can be written using either the 32 or 64 bit compiler (i.e. 32 or 64 bit enums), and retrieved by either the 32 or 64 bit compiler.
I meant to say that enum is a convenient way of creating non float numerical constants, and that is about their extent.
There is no real problem with enums and files.
There is a problem with pointers fields though, but that is another story.

[MrSwiss]

There is a problem with pointers fields though, but that is another story.

Since, SizeOf(Integer) = SizeOf(Any Ptr), we're dealing with the same problem here.
That is: without conversion (implicit or explicit) to Long/Integer<32>.

[dodicat]

I suppose with pointers the logic goes:
If you have UDT pointer fields then obviously you want to use these pointers for some task.
If then you then save an array of these udts, with the pointer fields loaded with addresses (4 bits or 8 bits), then, upon opening the file at some time, these pointers (addresses) will only be meaningless numbers.
So it is hardly worth fiddling about.

[MrSwiss]

I agree with the pointer logic and the conclusions -- so far, but --

it seems, that you've generously forgotten the Data, the pointers point to:

let's assume (for examples sake) a UDT Ptr, to where the really intresting stuff, the Data
itself, is held and that is, what needs to be written to file/retrieved from file ???

We do have to, at times do, all the fiddling about, as you call it.

[mrToad]

A pretty interesting discussion has been struck up here. First, thanks for the solutions earlier all of you. I can make use of the code for sure.

So long as you remember that on retrieving any file udt data (using enum) you must use integer<32> ~ long.

Well, the problem is trying to avoid separate code for retrieving it. Actually it is a rather large UDT record, an array of them, so I'm not sure how I would get each whole record at once with the 32bit enum in the middle somewhere, from a 64-bit compiled version. Wouldn't it be a mess to code around that? It's a different record size.

[MrSwiss]

You talk about a largish UDT (how big really?).

I've come to the conclusion that many people are likely to 'overdo' the UDT's content.
What I'll try to point out is:
everything (in UDT) that can be derived, from other existing entries, shouldn't be
inside the UDT (to keep it as compact as possible).

The Art of writing UDT's is to make it contain only the really needed components.
(and, to avoid, what I'd term: fillers (just for convenience) additions)

[fxm]

Such a UDT has the same size when compiled in 32-bit and 64-bit:

Code: Select all

Type Block
    Enum
        circle = 1
        square
        triangle
    End Enum
    As Long Shape
    
    Union
        As ULongint __
        As Integer Ptr Pt
    End Union
    
    '.....
End Type

[mrToad]

Since the thread question has already been satisfied and beyond, I just want to say first that it's totally fine with me to open it up to anything else you guys want, so keep posting whatever comes to your mind :) I've been learning from the discussion.

You talk about a largish UDT (how big really?).
[...]
The Art of writing UDT's is to make it contain only the really needed components.
(and, to avoid, what I'd term: fillers (just for convenience) additions)

Well, I don't know if I make use of the UDT in some strict form, but it certainly works well. I'm always open to new ways of doing things, though, and this is one area where I've wondered about other possibilities. It's definitely better than the disorganized mess of coding I did years ago.

In this case, my UDT is the heart of an important object. 47 properties (I will call properties because I don't remember if there's a formal word for UDT items), several of those being Types of ~8-15 other properties, as well as one Union that makes the object unique. I've used this form of code for various different projects. I'll give you a simple example (this UDT is not as large as I just mentioned), a modest GUI for a game/small project:

It is Type _gui_obj_. Every GUI object has a number of properties, no matter what kind of object it is. x,y,z (z for layering), width, height, color, border info, parent object, etc etc, also a pointer to a private function, and of course Functions such as Init_Self, Draw_Self, etc etc. Within the UDT there is a Union that extends the object to be unique, such as a button, a list box, a check box, an input box, etc. Example:

Code: Select all

	Union
		As guiButton_		btn
		As guiTextBox_		txt
		As guiListBox_		lst
		As guiCheckBox_	chk
		As guiInputBox_	inb
	End Union

So, this whole record is relatively largish, and saved to file with an Enum (As EnumName) in the middle is what I was referring to as a problem for reading/writing 32/64 (until you guys gave some great suggestions.)

But on the subject of a proper UDT (or the art of a good UDT):
In the end, I have a whole GUI interface with animated buttons, objects all parented to a form which is drag-able onscreen, functions that return user interaction. I invented it from scratch using imagination and the coding skills I had at the time. It was fun, and, most importantly, it works! Is it the most formal or mature way of coding? Nah, I've learned otherwise since then. Shouldn't it be written as true OOP, probably by Extending the object rather than using Union? I would guess so, but I haven't bothered taking it to that level. I'm sure it would make more mature programmers scoff and roll their eyes :)

As I said, I'm open to suggestions and feedback, because I'm always willing to learn. However, I am the type of person who must eventually draw a line on improving what already works, and fixing what isn't broken, because I've spent a lot of years doing that, and I can't spend many more if I want to actually accomplish a finished product.

Sorry for so much explanation, I just had a big coffee. :)

I will say this (again), from 2005 (and technically earlier) up to today, I have benefited greatly from all of you, and many others, in good posts and conversations. I guess that's the whole point of the forum, but I definitely appreciate it.

[mrToad]

Such a UDT has the same size when compiled in 32-bit and 64-bit:

I was just referring to the way I was originally doing it.

Code: Select all

Type Block
Enum Shapes
	circle = 1
	square
	triangle
End Enum
	As Shapes Shape
End Type

[fxm]

I was just referring to the way I was originally doing it.

Code: Select all

Type Block
Enum Shapes
	circle = 1
	square
	triangle
End Enum
	As Shapes Shape
End Type

This above UDT has not the same size when compiled in 32-bit/64-bit (4-byte/8-byte).

[mrToad]

I was just referring to the way I was originally doing it.

Code: Select all

Type Block
Enum Shapes
	circle = 1
	square
	triangle
End Enum
	As Shapes Shape
End Type

This above UDT has not the same size when compiled in 32-bit/64-bit (4-byte/8-byte).

Yes, exactly, that's what I mean. Sorry, the way I wrote the last message probably confused you. The above UDT was the problem that started this thread. It has a different size, so I reached out for help. Thanks for your replies. :)

[fxm]

..... 47 properties (I will call properties because I don't remember if there's a formal word for UDT items), .....

Properties are special member procedures (setters or getters) that allow the user interfacing with generally private data members (inaccessible directly from user).

[MrSwiss]

I don't remember if there's a formal word for UDT items ...

The word you are looking for, is: type member ...