Page 2 of 3
Re: Named Enumerations
Posted: Thu Apr 12, 2018 10:35 am
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
Re: Named Enumerations
Posted: Thu Apr 12, 2018 11:01 am
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.
Re: Named Enumerations
Posted: Thu Apr 12, 2018 11:13 am
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.
Re: Named Enumerations
Posted: Thu Apr 12, 2018 11:25 am
by uweb
I understand. Thank you!
Re: Named Enumerations
Posted: Thu Apr 12, 2018 11:32 am
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.
Re: Named Enumerations
Posted: Thu Apr 12, 2018 11:53 am
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.
Re: Named Enumerations
Posted: Thu Apr 12, 2018 12:20 pm
by Josh
Okay, I see. I've never used 'sound' and never thought about it
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.
Re: Named Enumerations
Posted: Thu Apr 12, 2018 12:24 pm
by Trond
There are still gaps for #Gadget = 1000, but not when you use #PB_Any.
Re: Named Enumerations
Posted: Thu Apr 12, 2018 12:43 pm
by IdeasVacuum
The Help on this subject needs a complete overhaul!
Re: Named Enumerations
Posted: Thu Apr 12, 2018 1:03 pm
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
Re: Named Enumerations
Posted: Thu Apr 12, 2018 1:26 pm
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.
Re: Named Enumerations
Posted: Thu Apr 12, 2018 1:49 pm
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
Re: Named Enumerations
Posted: Thu Apr 12, 2018 4:05 pm
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.
The same three-line code consumes more than double the memory when the higher indexes
(100000) are used.
Re: Named Enumerations
Posted: Thu Apr 12, 2018 4:14 pm
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.
Re: Named Enumerations
Posted: Thu Apr 12, 2018 4:19 pm
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