TList doesn't support Integer?
BlitzMax Forums/BlitzMax Beginners Area/TList doesn't support Integer?
| ||
so thenStrict Local test:TList = New TList test.AddLast(1) gives "Compile Error: Unable to convert from 'Int' to 'Object'" I know I could use an array but I want to use a list for ease of use. Am I missing something here or does a list simply not support Integers because they are not "objects" like string? I know I could make a Type called MyInteger with one Integer field but hey, that's lame :-) |
| ||
| You've pretty much answered your own question here. You're not missing anything and yeah wrapping it into an object is a solution, or if speed doesn't matter you may simply store strings and use int <-> string collections. Ideally, BRL should implement standard TInt, TFloat (etc) wrapper types, and even better implement specialized types for integer lists. That's easily doable by yourself, but a standard implemenmentation would be nicer. |
| ||
| TUnsignedLong etc wouldnt come a miss either... |
| ||
| A TList has various TLink objects and the TLink contains an "Object" as a field. That means the only things you can store in it are things that inherit from the `Object` type. That would be any custom types, like arrays, but the basic variable formats - Bytes, Ints, Longs, Floats etc are not objects because you operate directly on them as if CPU registers. So you can't store them as `Objects`. You have to make your own `IntWrapper` type containing an Int field, then store the IntWrapper in the list. |
| ||
| Didnt we have this disscustion a few months ago? The basic types dont inheret from Object. And Im sure you joined in Grey. (Mind you I did a search for something the other day, and found the answer, which had been posted by me) |
| ||
| yeah we did have the discussion I think but I couldn't remember the details. Wonder if anyone has made a TIntList type, wouldn't be too hard? I suspect a may be post a bit more now as I've started my new game this week, and it's scheduled to take 3 months. |
| ||
| Your a self employed full time programmer arnt you Grey? How do you find the dedication/self control to actualy work. or have you always been of the work ethic inclination? I find that without a boss/suppervisor on my back all the time my work rate is abismal. And without someone to say enough is enough I "Optimise" continualy. (Ive rewritten My "IntPair" type eight times. And its only an IntPair) |
| ||
| H&K, and I normally end up rewriting a product 3 times at least before i consider it efficient enough. |
| ||
| Take a look: http://www.blitzbasic.com/codearcs/codearcs.php?code=1585 http://www.blitzbasic.com/codearcs/codearcs.php?code=1584 An Intlist and a Stringlist type for BMAx. |
| ||
| Ideally, BRL should implement standard TInt, TFloat (etc) wrapper types, and even better implement specialized types for integer lists. Actually ideally everything including simple data types would be objects instead of having to put up with wrappers.Once Mark gets a little more into Python, I'm sure he'll see the error of his ways. |
| ||
| I'm sure he won't. He's certainly not going to pay the price for primitive types such as integer being full blown types. In particular given that BlitzMax types are not espacially lightweight. If he'd do that, legions of users would complain about the speed issue, and frankly I'd be in the ranks. Remember BlitzMax may *also* be used for very heavy computations. The only sensible way to not be forced to pay a (too) big price with that feature would be to use just in time compilation, with advanced optimization. Or to drop runtime polymorphism all along, and do that "optimization" at compile time. In short that's asking for a completly different product. |
| ||
| I don't think we want ints and stuff to be wrapped in an object, it would slow things down. |
| ||
| He's certainly not going to pay the price for primitive types such as integer being full blown types. What "price" is that then? I don't think we want ints and stuff to be wrapped in an object, it would slow things down. That's not what I was asking for. I was asking that ints be objects - not wrapped in one. |
| ||
| Type UInt extends Int.... Ummmmm, wouldnt we then need to be able to write + and * functions (Sorry cannot remember what its called Operator overriding I think) Mind you Ive nothing against operator overriding. |
| ||
| H&K: It's pretty simple, I need to earn money to keep my house and feed my family so I need to do proper work. Also, whereas I find the optimisation discussions interesting (I've coded 8-bit and 16-bit assembly) I don't bother with tons of optimisation in my own code. I write something that works and is reasonably efficient and is also easy to understand, reuse and modify. I'm a big fan of ready fire aim, as in get going and tweak as you go along if you need to otherwise you never finish anything, you just have a well optimised tech demo - sound familiar? I also teach Aikido so am reasonably self-disciplined but I need to be as I have a lazy streak a mile wide that needs to be kept under control. klepto2: thanks! for now I'm using a string list of integers but it's fine as it's not holding many values and is not time critical thus doesn't need optimising. So I'm optimising my optimisation! cool. |
| ||
| What "price" is that then? The sad thing here is you're not even kidding.What price? dunno, let's say dynamic dispatch for a start. If you want an integer to act like an object, you have to pay for the additional memory and runtime support for it. Putting an integer in a list that expects an object means at the very least the "integer" to carry the virtual table pointer with it. And it's the same in every single place where you receive an object you don't know the type at all (and may be an integer). That's a price. You may be prepared to swallow it, but the point is that few people will enclined to do so here. Granted, most programs wouldn't see the least noticeable difference in speed. But Mark does know its audience and he probably understands what BlitzMax users won't accept at all. C# more or less resolved the problem by NOT having integers be internall a real object, but wrapping (boxing/unboxing) them only when needed. I guess that would be a good alternative solution. And In fact I'd put my vote on it. But certainly not having integers *always* be implemented as full blown objects. Some precision though about boxing/unboxing : at the semantic level, it is "just as if" integers are *always* full objects. But with an important efficiency difference. It *can* be slower if you constanlty do operations that rely on boxing, but on the other hand if you don't it will necessarily be as fast as with standard raw integers (because that's what they are internally). |
| ||
| We came across this issue last night and damn did it cause problems.... Now we are in need of actually creating a blitz-type C side, which I assume isn't possible (in any sort of easy, non-hacky way....) |
| ||
| Koriolis: Yes that's what I was thinking. Don't make Integers into objects by default but treat them that way if the programmers tries to use them as an object e.g. in an Integer List. Best of both worlds. |
| ||
| @cygnus it might actually be possible to something similar to what you sugest, remind me next time you're on yim or msn will ya @Koriolis don't be taken in by frameducks ignorance act (at least I think its an act) he just trying to to bate people again... |
| ||
| I think the Lisp way is nicer - it treats ints, floats, whatever, as objects, but you can make specific declarations to the compiler to treat them as ints. This way, you only do this when and only when you need to optimize (and are 100% sure that you'll be dealing with an int and not some other type of object - since Lisp has & allows dynamic typing) |
   |