Named Enumerations

Just starting out? Need help? Post your questions and find answers here.
uweb
User
User
Posts: 98
Joined: Wed Mar 15, 2006 9:40 am
Location: Germany

Re: Named Enumerations

Post by uweb »

Please excuse me if I did not understand everything correctly. My English isn't the best.
I know you know PB a lot better than I do and I'm sure you saw the opportunity, too.
So this is a question - not another method or work-around.
What is the disadvantage of that would be to use the existing part of PB without Named Enumerations?

Code: Select all

;IncludeFile 1
Enumeration #PB_Compiler_EnumerationValue 
  #Gad11
  #Gad12
  #Gad13
EndEnumeration

;InlcludeFile 2
Enumeration #PB_Compiler_EnumerationValue 
  #Gad21
  #Gad22
  #Gad23
EndEnumeration
Please pardon my English, my native tongue is German.
User avatar
TI-994A
Addict
Addict
Posts: 2490
Joined: Sat Feb 19, 2011 3:47 am
Location: Singapore

Re: Named Enumerations

Post by TI-994A »

uweb wrote:What is the disadvantage of that would be to use the existing part of PB without Named Enumerations?

Code: Select all

;IncludeFile 1
Enumeration #PB_Compiler_EnumerationValue 
  #Gad11
  #Gad12
  #Gad13
EndEnumeration

;InlcludeFile 2
Enumeration #PB_Compiler_EnumerationValue 
  #Gad21
  #Gad22
  #Gad23
EndEnumeration
That's a perfectly valid and safe implementation.

But, when mixing objects in such continuous enumerations, the objects with bigger constant values would have gaps in their index tables.

Code: Select all

Enumeration #PB_Compiler_EnumerationValue 
  #gadget1  ;0
  #gadget2  ;1 
  #gadget3  ;2
EndEnumeration

Enumeration #PB_Compiler_EnumerationValue 
  #font1   ;3
  #image1  ;4
  #sound1  ;5
EndEnumeration
The above code enumerates four different objects (gadgets, fonts, images, sounds) sequentially, and the four object tables would look like this:

Code: Select all

GADGET Index Table:
0 = #gadget1
1 = #gadget2
2 = #gadget3

FONT Index Table:
0 = (unused)
1 = (unused)
2 = (unused)
3 = #font1

IMAGE Index Table:
0 = (unused)
1 = (unused)
2 = (unused)
3 = (unused)
4 = #image1

SOUND Index Table:
0 = (unused)
1 = (unused)
2 = (unused)
3 = (unused)
4 = (unused)
5 = #sound1
Those unused entries in the respective tables are wasted resources. Again, it's not an issue for smaller applications, but it could be quite substantial in bigger projects which utilise a lot of gadgets and resources.
Texas Instruments TI-99/4A Home Computer: the first home computer with a 16bit processor, crammed into an 8bit architecture. Great hardware - Poor design - Wonderful BASIC engine. And it could talk too!
Fred
Administrator
Administrator
Posts: 14413
Joined: Fri May 17, 2002 4:39 pm
Location: France
Contact:

Re: Named Enumerations

Post by Fred »

uweb wrote:Please excuse me if I did not understand everything correctly. My English isn't the best.
I know you know PB a lot better than I do and I'm sure you saw the opportunity, too.
So this is a question - not another method or work-around.
What is the disadvantage of that would be to use the existing part of PB without Named Enumerations?

Code: Select all

;IncludeFile 1
Enumeration #PB_Compiler_EnumerationValue
  #Gad11
  #Gad12
  #Gad13
EndEnumeration

;InlcludeFile 2
Enumeration #PB_Compiler_EnumerationValue 
  #Gad21
  #Gad22
  #Gad23
EndEnumeration
The problem here is #PB_Compiler_EnumerationValue takes the last value of the last created enumeration. So it's not safe to use it accross file, because if you put another enumeration in between it will fail:

Code: Select all

;IncludeFile 1
Enumeration #PB_Compiler_EnumerationValue  ; This one makes no sens, which last enumeration value will it use ?
  #Gad11
  #Gad12
  #Gad13
EndEnumeration

Enumeration
  #Font1
  #Font2
EndEnumeration

;InlcludeFile 2
Enumeration #PB_Compiler_EnumerationValue  ; Will continue with the last value of the font enumeration
  #Gad21
  #Gad22
  #Gad23
EndEnumeration
#PB_Compiler_EnumerationValue is an advanced feature and should be only in last resort (useful in macro for example), it's very error prone

BTW, the Enumeration : EndEnumeration is a generic feature, used to avoid to set hard number to a group of consecutive constant, so you can easily reorder them in the group (insert, remove etc.). It's not tied to PB object in particular, it's just useful to use them to have consecutive contants values.
uweb
User
User
Posts: 98
Joined: Wed Mar 15, 2006 9:40 am
Location: Germany

Re: Named Enumerations

Post by uweb »

I understand. Thank you!
Please pardon my English, my native tongue is German.
User avatar
Josh
Addict
Addict
Posts: 1184
Joined: Sat Feb 13, 2010 3:45 pm

Re: Named Enumerations

Post by Josh »

TI-994A wrote:Those unused entries in the respective tables are wasted resources. Again, it's not an issue for smaller applications, but it could be quite substantial in bigger projects which utilise a lot of gadgets and resources.
As I wrote in a previous post, I don't think it matters whether you use a gadget number of 0, a gadget number of 100000 or #PB_Any in the finished compiled exe. In my opinion, the waste of resources only plays a role in the compiler during the compilation process. So I wouldn't be too close to the gaps in the gadget numbers.

Maybe Fred can tell us something about the background.
sorry for my bad english
Fred
Administrator
Administrator
Posts: 14413
Joined: Fri May 17, 2002 4:39 pm
Location: France
Contact:

Re: Named Enumerations

Post by Fred »

There is a waste of resource for indexed number as it uses an array internally. So if you use a #Sound number of 5000 for your first sound, 5000 slots (0-4999) will be unused. That's why there is a error message in the debugger to warn about too big numbers. We also sometimes need to iterate all objects internally and it will spend time on empty slots. So, it's not at compile time, it's at runtime.
User avatar
Josh
Addict
Addict
Posts: 1184
Joined: Sat Feb 13, 2010 3:45 pm

Re: Named Enumerations

Post by Josh »

Okay, I see. I've never used 'sound' and never thought about it :lol:

I was thinking more of Windows and Gadgets. Am I correct in assuming that in this case are no gaps due to high gadget numbers? Just out of interest, because I rarely use fixed numbers.
sorry for my bad english
Trond
Always Here
Always Here
Posts: 7446
Joined: Mon Sep 22, 2003 6:45 pm
Location: Norway

Re: Named Enumerations

Post by Trond »

There are still gaps for #Gadget = 1000, but not when you use #PB_Any.
IdeasVacuum
Always Here
Always Here
Posts: 6385
Joined: Fri Oct 23, 2009 2:33 am
Location: Wales, UK
Contact:

Re: Named Enumerations

Post by IdeasVacuum »

The Help on this subject needs a complete overhaul! :)
IdeasVacuum
If it sounds simple, you have not grasped the complexity.
User avatar
TI-994A
Addict
Addict
Posts: 2490
Joined: Sat Feb 19, 2011 3:47 am
Location: Singapore

Re: Named Enumerations

Post by TI-994A »

Josh wrote:I was thinking more of Windows and Gadgets. Am I correct in assuming that in this case are no gaps due to high gadget numbers?
According to the manual, each object type maintains independent object indexes. So, technically, they're all affected by such enumerated gaps.
The PureBasic Manual wrote:Overview of the different PureBasic objects

Different PureBasic objects (windows, gadgets, sprites, etc.) can use the same range of object numbers again. So the following objects can be enumerated each one starting at 0 (or other value) and PureBasic differs them by their type:

- Database
- Dialog
- Entity
- File
- FTP
- Gadget (including the ScintillaGadget())
- Gadget3D
- Image
- Library
- Light
- Mail
- Material
- Menu (not MenuItem(), as this is no object)
- Mesh
- Movie
- Music
- Network
- Node
- Particle
- RegularExpression
- SerialPort
- Sound
- Sound3D
- Sprite
- StatusBar
- Texture
- ToolBar
- Window
- Window3D
- XML
Texas Instruments TI-99/4A Home Computer: the first home computer with a 16bit processor, crammed into an 8bit architecture. Great hardware - Poor design - Wonderful BASIC engine. And it could talk too!
User avatar
Josh
Addict
Addict
Posts: 1184
Joined: Sat Feb 13, 2010 3:45 pm

Re: Named Enumerations

Post by Josh »

I can only talk about Windows now. Of course, things can be different with Linux and MacOS.
I know the size of an exe file doesn't have to say anything, but maybe a little bit. Try this simple code:

Code: Select all

OpenWindow (100000, 100, 100, 1000, 1000, "TEST")
ButtonGadget (100000, 10,10,100,100,"xxx")
MessageRequester ("100000", "")
And now try the code with Windows/Gadget number with 0 and with #PB_Any. The three created exes are all exactly the same size.
sorry for my bad english
Fred
Administrator
Administrator
Posts: 14413
Joined: Fri May 17, 2002 4:39 pm
Location: France
Contact:

Re: Named Enumerations

Post by Fred »

#PB_Any doesn't use the index way, there is no gap with #PB_Any as it uses a list for storage. Every object has its own index array, that's why you can have a #Window with a number 0, and a #Gadget with a number 0 and so on. I don't follow about the exe size :?:
User avatar
TI-994A
Addict
Addict
Posts: 2490
Joined: Sat Feb 19, 2011 3:47 am
Location: Singapore

Re: Named Enumerations

Post by TI-994A »

Josh wrote:...the size of an exe file doesn't have to say anything, but maybe a little bit. Try this simple code:

Code: Select all

OpenWindow (100000, 100, 100, 1000, 1000, "TEST")
ButtonGadget (100000, 10,10,100,100,"xxx")
MessageRequester ("100000", "")
And now try the code with Windows/Gadget number with 0 and with #PB_Any. The three created exes are all exactly the same size.
The resultant size of compiled binaries are not indicative of the resources they would consume. Compile and run your suggested examples and see their memory footprints in Windows Task Manager.

Image

The same three-line code consumes more than double the memory when the higher indexes (100000) are used.
Texas Instruments TI-99/4A Home Computer: the first home computer with a 16bit processor, crammed into an 8bit architecture. Great hardware - Poor design - Wonderful BASIC engine. And it could talk too!
User avatar
skywalk
Addict
Addict
Posts: 3555
Joined: Wed Dec 23, 2009 10:14 pm
Location: Boston, MA

Re: Named Enumerations

Post by skywalk »

Hi Fred,
Why not manage Objects behind the scene using the #PB_Any List()?
Then there is no need for the user to care about gaps in Enumerations. :idea:
The nice thing about standards is there are so many to choose from. ~ Andrew Tanenbaum
User avatar
kenmo
Addict
Addict
Posts: 1922
Joined: Tue Dec 23, 2003 3:54 am

Re: Named Enumerations

Post by kenmo »

I assume #PB_Any = linked list, dynamic, more flexible, no conflicts
and Indexed = faster access, O(1), no walking through lists every time a gadget is accessed
Right now we have the option to use either.


Exe size is not affected, runtime memory would be. But it doesn't seem that bad.

Code: Select all

N = Val(ProgramParameter(0))
OpenWindow (N, 100, 100, 1000, 1000, "TEST")
ButtonGadget (N, 10,10,100,100,"xxx")
CreateImage(N, 32, 32)
MessageRequester (Str(N), "Look at memory usage")
N = 1 uses 1.4 MB memory for me
N = 1 Million uses 13 MB memory for me
Post Reply