String Pointers?
BlitzMax Forums/BlitzMax Beginners Area/String Pointers?
| ||
| Although I can see reasons why string pointers would not be implemented, I can also see situations where they could be very useful. ( For example, a self-contained InputBox in a custom GUI, so the box can actually put it's result into a variable automatically. ) The thing is, I did a quick forum search and I found a thread with someone talking about string pointers in BlitzMax, but I can't find any way to declare them. String Ptr is an "illegal pointer type" according to the compiler. Are they declared differently or been removed or whoever was talking about them was confused? |
| ||
| Variable type pointers have been removed with 1.16 or 1.18 (assume for consistency reason. Within BM, everything is managed and a ptr is not manageable ...) |
| ||
| I see, thanks. Well that's a damn shame. Makes it very much harder to write self-contained objects when the objects access to external variables is limited like that. I suppose a workaround is to use a Bank, have the object resize it and put the contents of the string into it, and then get it back out to a variable again later, but it's going to be quite slow and it's a pretty ugly solution since you have to manually update the variable from the bank. |
| ||
| As it needs to update anyway, I would suggest directly using a string and maintain a subscriber list (list of all objects that use the string) which is notified of updates. |
| ||
| That doesn't really work. When the gadget gets destroyed, it's not deleted because the string object still has a reference to it and the gadget doesn't know about the string, so it can't do anything about it. So the string would have to have a TList connected to it, and the Gadget would have to have yet another link ( it already has one for the list of gadgets and one more if the object is a child of a parent gadget ) and it would probably have to be implemented in an abstract gadget type, which means objects that have no connection to a string still have the link and have to check if it's non-null and remove it if it is. Pretty much as ugly as the solution I mentioned above. |
| ||
| If an object subscribes to something, this is a 2 sided action. Once on the object that it subscribes to and once on itself. As your objects needs to update the string it must known to which "string offerer" it is subscribed and this can be used to unsubscribe it before freegadget-ing |
| ||
| Isn't a string just an array of bytes? Use Varptr(MyString)? |
| ||
| A string is a structure that contains its length and a pointer to a buffer of (unsigned) shorts. You could in theory get the pointer to it, but it's probably not worth it since you'll still have to reallocate the memory and such if you need to expand the string. |
| ||
| After further consideration, I've decided ( in case anyone searches for this and wonders the same things I wondered ) that the cleanest way to handle this is with two function pointers, one to a function which sets the string and one to a function which gets the string. It means writing those functions for every string I want to use it with, BUT it doesn't require wrapping the string in another object, which would be very ugly, and it doesn't require a TList or anything like that. |
   |