Today, 01:50 AM
steve said what he said in the spirit of "basic does it all for me because otherwise i hate programming in c and doing it all by myself". like what was said about "close" and variable-length strings. many basic programmers don't think about those two. but because the veteran has to think about _mem, he avoids it. i was like this for a long time. in part because there used to be a bug in qb64 (before phoenix edition) that just disallowed me to use _memcopy or otherwise use a simple addition between an integer and an _offset.
but there cannot be a "garbage collector" for everything. such a thing tends to make the programmer lazy and affects program performance. it's a penalty one is willing to pay for using strings in basic all the time. but hopefully the _mem gang would never be used even more than vls's.
watch out: might also require whatever was created with redim to be matched with erase before the program ends.
the qb64 help set a good precedent, in all keywords _mem and related ones. saying the _mem variables should be freed with _memfree.
but there cannot be a "garbage collector" for everything. such a thing tends to make the programmer lazy and affects program performance. it's a penalty one is willing to pay for using strings in basic all the time. but hopefully the _mem gang would never be used even more than vls's.
watch out: might also require whatever was created with redim to be matched with erase before the program ends.
the qb64 help set a good precedent, in all keywords _mem and related ones. saying the _mem variables should be freed with _memfree.