Is this a bug or dirty memory handling on my part?

[Dreglor]

Simple code to interpret.

Code: Select all

Structure SimplePixel ;32 bit color, no unicode!
  Red.c
  Green.c
  Blue.c
  Padding.b
EndStructure

Structure SimplePixelByReference ;it shouldn't have any memory allocated towards it.
  Pixel.SimplePixel[0]
  Value.l[0]
EndStructure

MyPixel.SimplePixelByReference ;should have memory?
MyPixel\Value = $FFFFFF ;I can write to it but, is it safe?

Debug SizeOf(MyPixel) ;well it REPORTS 0 but is it?
Debug MyPixel\Value

It intentions is to allow simple walking through pixels in a image stored in memory and access for copy (value) or R,G,B operations. However it's use as a single pixel on a local variable has me confused if it a legal way of code, does pure basic allocate memory for the variable and size of is reporting a bad size or is it not allocating memory and pure basic is just pointing to random location and I'm shoving data into it (stack leak?).
It seams to work but not sure if it works in more repetitive use.

[ts-soft]

A Array[0] has a 0 size! You can't use it without memoryallocation!

[pdwyer]

I use structures like this with [0]

BUT

I only use them a pointers to these structures so that I can use pointer arithmatic through a memory block. since they have no size if you dim an actual variable on them all you can do is walk off the end of it and get into trouble.

I overlay a pointer to a strucutre like this on a mem block I allocate myself so I know how big it is.

If you look at the quicksearch algo in the tips section I use this method

[netmaestro]

I think because you're initializing a variable of the specified type, it is allocating space for a pointer to each of the elements, which is why you're getting away with writing to it. But it's by no means safe. With a size of 0 you must use a pointer variable and set it to an allocated memory block as ts-soft said or you will eventually get (possibly random) crashes.

[Kaeru Gaman]

besides the pointers and all the stuff...

Code: Select all

Structure SimplePixel ;32 bit color, no unicode!
  Red.c
  Green.c
  Blue.c
  Padding.b
EndStructure

Structure SimplePixelByReference ;it shouldn't have any memory allocated towards it.
  Pixel.SimplePixel[0]
  Value.l[0]
EndStructure 

... and access for copy (value) or R,G,B operations.

so I guess you want to Access the SAME Pixel by Long-Value or RGBA...
you'll need a Union for this:

Code: Select all

Structure SimplePixel ;32 bit color
  Red.b
  Green.b
  Blue.b
  Padding.b
EndStructure

Structure SimplePixelByReference ; UNION to adress same pixel arbitrarily as LONG or as RGBA
  StructureUnion
    Pixel.SimplePixel
    Value.l
  EndStructureUnion
EndStructure

after that you can Allocate Mem and Adress it via a Pointer structured with SimplePixelByReference,
even set this pointer to the bitmap of an existing Image.

always use Byte, not Char, just handle the sign.

[Dreglor]

Right, Anyways reason i was asking was it figure out if i can get away with using a variable for optimization reasons rather then use copymemory() for every iteration of the loops for the image processing.

I ended up creating another structure that actually holds information rather then pointing towards it

on another note: the reason I use char is the very fact that I don't have to handle the sign it be comes a mess when I do and I prevent it to being compiled to Unicode with a compiler if which makes it safe to use.

[pdwyer]

agree! lack of unsigned vars in PB is a notable feature gap IMO

Personally, I would think that a language that has bit shifting operands would have unsigned vars of some sort too. chars don't count because their bit width changes with the unicode compile type making them unstable (in the sense that they are not portable without risk).

Under the hood, FASM I believe has unsigned types (could be wrong) so it seems odd these are not exposed to PB.

I'm sure there's a good reason for it but its still a little frustrating at times.

[Dreglor]

unfortunately it doesn't and under hood so to speak it's signless. The sign and unsigned aspect really doesn't matter until mul and div (hence the opcodes imul and idiv) in terms of integer math, floating point I can't be sure of.
But, considering that we have char, where halfway there to a unsigned byte and the rest of the unsigned partners but our simple one character native type would be uprooted which make things interesting for the back end of the compiler. Figuring that it took a while for quad and doubles to show up. I can only wonder how long (and how much work) it would be for all the unsigned equivalents of our types to show up

[Kaeru Gaman]

[ot] the image urls in your signature are invalid... [/ot]

floating point always has a sign, it's part of the definition.

concerning integers, your definitely right, under the hood all are unsigned.
besides that it is not that much problem to handle the fact that PB interpretes every integer to be signed.

[pdwyer]

until wading into the implementation of an encryption algo and remembering to add "& $7fffffff" to the right shifts etc

[Kaeru Gaman]

well, something like that would preferably be done with inline-asm, don't you think?

hey, ok, it would be nice to have unsigned variables, no question...

I would like predictable or rather controllable typecasting aswell...

[pdwyer]

it'd be nice to be able to code in ASM too