|
|
Re: custom size for engine structs
[Re: MasterQ32]
#408674
10/05/12 13:54
10/05/12 13:54
|
Joined: Jan 2002
Posts: 4,225 Germany / Essen
Uhrwerk
Expert
|
Expert
Joined: Jan 2002
Posts: 4,225
Germany / Essen
|
If sizeof stopped working you had to calculate all struct sizes by hand and had to change the allocation code every time you changed a data type. This is not only tons of superfluous work but would also render almost any Lite-C code out there wrong. Thousands of Gamestudio user would like to give you "a big warm thank you" if JCL messed with sizeof because of your suggestion. ;-)
You shouldn't access the allocated memory because you cannot. If the compiler would allocate too much memory you still wouldn't know where this is extra space is and how to address it.
Always learn from history, to be sure you make the same mistakes again...
|
|
|
Re: custom size for engine structs
[Re: Uhrwerk]
#408676
10/05/12 14:02
10/05/12 14:02
|
Joined: Nov 2007
Posts: 2,568 Germany, BW, Stuttgart
MasterQ32
OP
Expert
|
OP
Expert
Joined: Nov 2007
Posts: 2,568
Germany, BW, Stuttgart
|
i think you don't get my point... in the engine there is some code like this:
PANEL *newpan = (PANEL*)malloc(sizeof(PANEL));
if you change this to something like this:
size_t sizeOfPanel;
[...]
// Init code:
sizeOfPanel = sizeof(PANEL);
[...]
// User function:
void pan_setsize(int size)
{
sizeOfPanel = maxv(sizeof(PANEL), size);
}
[...]
// Allocation
function pan_create(STRING *def, var layer)
{
PANEL *pan = (PANEL*)malloc(sizeOfPanel);
return pan;
}
now there gets more space per panel allocated, which i can also use from Lite-C:
typedef struct CUSTOMPANEL
{
PANEL panel; //No pointer!
var mydata;
var mydata2;
[...]
} CUSTOMPANEL;
[...]
pan_setsize(sizeof(CUSTOMPANEL));
CUSTOMPANEL *custompan = pan_create("", mylayer);
custompan->panel.pos_x = 256; // Set the position of the panel
custompan->mydata = 3;
custompan->mydata2 = 7;
This will work without any problems....
Last edited by MasterQ32; 10/05/12 14:03.
|
|
|
Re: custom size for engine structs
[Re: MasterQ32]
#408679
10/05/12 14:42
10/05/12 14:42
|
Joined: Jan 2002
Posts: 4,225 Germany / Essen
Uhrwerk
Expert
|
Expert
Joined: Jan 2002
Posts: 4,225
Germany / Essen
|
No, it's not that I didn't get your idea, its just that I think this idea is so badly dangerous and destructive in so many ways. I'm not even sure if if would work the way you suggested. But even if it worked I'll just give you a few examples of the flaws inherent in this:
1. You're using the sizeof operator but with the new semantics its not clear what sizeof should do. As sizeof is static it could only return the actual size of structs. So there would be a discrepancy between the value sizeof returned and the memory actually allocated. Otherwise the return value of sizeof could change at runtime which is awkward and does not make any sense.
2. Example: You're using this feature and you're using a framework which is using the feature as well. The framework uses one additional byte and you want to use two additionaly bytes. Depending on the timing of the pan_setsize call you can be lucky and get the two bytes or the one byte version.
3. You could allocate structs at runtime with different sizes. Because you could call pan_setsize multiple times you could first allocate a panel with 128 bytes, then one with 140 bytes and finally one with 100 bytes. Good luck on keeping track of this.
4. Static arrays cannot be used any more because the size of panels is no longer known at compile time.
I could prolong this list but I think the points made above are already so fatal...
Always learn from history, to be sure you make the same mistakes again...
|
|
|
Re: custom size for engine structs
[Re: Uhrwerk]
#408681
10/05/12 14:57
10/05/12 14:57
|
Joined: Nov 2007
Posts: 2,568 Germany, BW, Stuttgart
MasterQ32
OP
Expert
|
OP
Expert
Joined: Nov 2007
Posts: 2,568
Germany, BW, Stuttgart
|
You're using the sizeof operator but with the new semantics its not clear what sizeof should do Where? So there would be a discrepancy between the value sizeof returned and the memory actually allocated Yes sure because i don't use sizeof() to get the size of the memory i want to allocate. I'm using a variable (which is not forbidden...) You're using this feature and you're using a framework which is using the feature as well You could implement a behaviour which resets the size to the original one after the first allocating. This prevents unwanted allocations and forces a developer to use pan_setsize in context. Static arrays cannot be used any more because the size of panels is no longer known at compile time You shouldn't store any of the engine structs in static arrays like PANEL panArray[10];
|
|
|
Re: custom size for engine structs
[Re: MasterQ32]
#408683
10/05/12 15:18
10/05/12 15:18
|
Joined: Jan 2002
Posts: 4,225 Germany / Essen
Uhrwerk
Expert
|
Expert
Joined: Jan 2002
Posts: 4,225
Germany / Essen
|
1. pan_setsize(sizeof(CUSTOMPANEL));
2. Of cause you're using it. See above. Using variables is perfectly valid, but it's just a detour. You have to initialize the variable.
3. You could do this at the cost of the risk of forgetting it. And this is an error that will be extremely hard to find.
4. You shouldn't but the engine developers will.
The most important issue is still there. You would allow variables of equal type with different sizes, invalidating all pointer artihmetics. Besides you prolong the catalog of things that were necessary to achieve this, while this whole thing is already a beast. ;-)
Always learn from history, to be sure you make the same mistakes again...
|
|
|
Re: custom size for engine structs
[Re: MasterQ32]
#408691
10/05/12 18:53
10/05/12 18:53
|
Joined: Jan 2002
Posts: 4,225 Germany / Essen
Uhrwerk
Expert
|
Expert
Joined: Jan 2002
Posts: 4,225
Germany / Essen
|
i'm using an equal technology to achieve fake derivated classes in lite-c, generic link lists and so on. and it works without any flaws. If it works that way for you, fine. But we're talking about a publicly available API. You have to think way different. Things working out for you personally may go horribly wront when collaborating with others. Don't forget you exactly know how your stuff works. Adding extra complicated stuff to lite-c will raise the bar for beginners. also all structs in the engine are stored in some kind of linked list (just look at the C_LINK structure. so the engine does use pointer arithmetics to get all engine objects in one management loop) Yes, they are in a linked list. But a linked list does not require any pointer arithmethics at all. Actually if pointer arithmetics were used that would be a killer argument against your idea, because your idea would then break the engine internals. why do you think ptr_remove works? Because equal types guarantee equal memory footprints. ;-) Seriously, I have a feeling you got on the wrong track. The original problem you had is so easy to handle, e.g. as Superku suggested. There is absolutely no reason to solve it with this overly complicated, technically questionable monster idea.
Always learn from history, to be sure you make the same mistakes again...
|
|
|
Re: custom size for engine structs
[Re: Uhrwerk]
#408697
10/05/12 20:27
10/05/12 20:27
|
Joined: Dec 2008
Posts: 1,218 Germany
Rackscha
Serious User
|
Serious User
Joined: Dec 2008
Posts: 1,218
Germany
|
Because equal types guarantee equal memory footprints. ;-)
You mean based on the size the allocated memory at a given pointer has, the actual engine object is identified?
MY Website with news of my projects: (for example my current Muliplayer Bomberman, GenesisPrecompiler for LiteC and TileMaster, an easy to use Tile editor) Sparetime-Development
|
|
|
Re: custom size for engine structs
[Re: Rackscha]
#408698
10/05/12 20:39
10/05/12 20:39
|
Joined: Jan 2002
Posts: 4,225 Germany / Essen
Uhrwerk
Expert
|
Expert
Joined: Jan 2002
Posts: 4,225
Germany / Essen
|
lol, no. The engine object type is identified by the hi byte of the C_LINK index variable. Have a look at atypes.h if you're interested in that.
My point was that if the memory footprint of engine objects would be random ptr_remove wouldn't be able to free them because it had no idea how large the area to be released was.
Always learn from history, to be sure you make the same mistakes again...
|
|
|
|