Re: Question about bgt handles

Are handles supported for strings in BGT? It's kinda weird about handles for things like vectors.
@1: Handles make more sense if you have experience with C / C++ / C#. Except they do some confusing things at times, even then, compared to their low-level counterparts. Handles are kinda like pointers, which are references to the memory address where the variable in question is stored. At the lowest level, you're dealing with how things are handled in the CPU and RAM, except CPUs, afaik, don't have a way to deal with object-oriented programming on a hardware level, and what's being passed around are values in CPU registers. Unless they're wrapped in a high-level construct, arrays are basically a pointer to the first entry, and saying x[y] is equivalent to a pointer to x+(y×sizeof(&x)).
Naturally, that can get messy real quick with complex programs, and Java simplifies it by making everything function as a handle/pointer/reference. This means you need methods for cloning objects (ex: System.arraycopy), which normally isn't that big a deal. For some reason, Angelscript (in which BGT is built) goes with something in between but closer to C#.
So anything done in BGT without an @ is trying to act on the data directly. To make matters more confusing, if you call a function like myfunc(x), it works regardless of whether the function takes a handle or its referent.
Generally speaking, if you want it to work the way it does in Java, you'll be using lots of @s. And that's usually what you want.
BGT doesn't let @ work on ints, floats, etc, which I believe is how it works in Java, too? But if you declare a function or method that takes "int &out" instead of just "int", that's effectively the same as sending a reference rather than a copy. ... But you don't do anything different when modifying the variable, because that would make sense -_-

Generally, you want to use handles in these situations:

  • Comparing class instances. If (@a == @b), if (@x == @this). This is the same as Java if (a == b) and if (x == this).

  • When a function or method needs to permanently modify the objects passed to it. If you wanted to write an implementation of quicksort in BGT, for instance, your parameters would be declared as int[]@, rather than just int[]. Same holds if it's a different type of array.

  • Assigning. "@a = b" makes it so that a and b reference the same instance. "a = b" attempts to clone b to a, which will usually break on an already-initialized object without an opAssign method. You're probably wondering why it's "@a = b", and not "@a = @b", and I have no idea.

  • Dictionaries. BGT is sufficiently weird about this that I try to always have functions to simplify it. If you want to add a sound to a dictionary, you'd do something like "dict.add(key, @handle)", and to get something from a dictionary, you need to have a handle to assign it to: "dict.get(key, @handle)".

  • Factory functions should generally return handles. "sound@ get_sound(string filename)", for instance.

  • Object arrays, especially as members of another class. This shows up a lot in games (ex, a class for a map, level, etc, with an array of items or enemies). "enemy@[] enemies". This gets confusing, because you can say "enemy@[]", "enemy[]@", "enemy@[]@", or "enemy[]", and they all mean slightly different things. If the @ is after the brackets, it's a handle to the array. If it's before the brackets, it's an array of handles. I generally use arrays of handles more than handles to arrays, and handles to arrays of handles is probably useful but hasn't come up much.

  • Remember that null is already treated like a handle, so you should never say "@null", but should always say "@a = null" when nullifying a reference. I think "a=null" would cause a null pointer error.

As a general rule, when in doubt, use handles. Also, order of operations can be a jerk and require you use parentheses to avoid ambiguity regarding to what the @ refers, but I haven't worked out the exact order and just use parentheses for anything with a dot or brackets, just to be safe.

-- 
Audiogames-reflector mailing list
Audiogames-reflector@sabahattin-gucukoglu.com
https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
  • ... AudioGames . net Forum — Developers room : ricardo0922 via Audiogames-reflector
    • ... AudioGames . net Forum — Developers room : Hijacker via Audiogames-reflector
    • ... AudioGames . net Forum — Developers room : CAE_Jones via Audiogames-reflector
    • ... AudioGames . net Forum — Developers room : Hijacker via Audiogames-reflector
    • ... AudioGames . net Forum — Developers room : Kyleman123 via Audiogames-reflector
    • ... AudioGames . net Forum — Developers room : Kyleman123 via Audiogames-reflector
    • ... AudioGames . net Forum — Developers room : ricardo0922 via Audiogames-reflector
    • ... AudioGames . net Forum — Developers room : ricardo0922 via Audiogames-reflector

Reply via email to