BMax Still Implicitly casts TAnything to Byte Ptr
BlitzMax Forums/BlitzMax Programming/BMax Still Implicitly casts TAnything to Byte Ptr
| ||
| I complained about this a while ago, and I was sure I read somewhere where Mark or Skid said that it had been or would be changed. Not on my thread, I don't think, but somewhere. But no, it's still possible : SuperStrict Function AFunc(B:Byte Ptr) End Function Type TAnything Field Something:Int Field SomethingElse:Float Field SomethingDifferent:String End Type Global AThing:TAnything=New TAnything AFunc(AThing) or even Type TAnything Field Something:Int Field SomethingElse:Float Field SomethingDifferent:String End Type Global AThing:TAnything=New TAnything Global B:Byte Ptr=AThing This is a debugging nightmare. It's so easy to make a mistake because the compiler won't alert you to it. Now I don't mind if it happens in non-strict, I don't mind if it happens in Strict. I don't even mind if it's possible in SuperStrict as long as it's done with an explicit type cast. But to have TAnything cast to a Byte Ptr automatically is just asking for problems. I fully accept that this problem only arises if you're a bit stupid ( I am! ) and you're prone to making a lot of stupid mistakes ( That's me! ) but that's what Strict and SuperStrict are for, isn't it? To stop stupid people making stupid mistakes? |
| ||
| Why are you creating Byte Ptr variables at all if you want to be strict about things? Shouldn't you use Object or something? |
| ||
| Yes BytePtr are for external usage but using something unmanaged within BM will garantee that there will rise far worse nightmares than a simple "implicit cast" if you only forget to free one single memory block! |
| ||
| Why are you creating Byte Ptr variables at all if you want to be strict about things? Shouldn't you use Object or something? Because I'm not using them as I demonstrated above, it's simplified for demonstration purposes ;) BytePtr are for external usage I'm using them for external usage. It doesn't change the problem because the implicit cast happens with Externs too. As I say, this is to demonstrate the problem, not my reason for using them. |
| ||
| well I cant see what your "problem" is without a real world example, byteptr works *very* well as is, in fact its invaluable! its a pointer to an individual memory location, its up to you to decide what its actually pointing too... |
| ||
| His problem is mainly that it implicitely casts to Byte Ptr, without needing a Byte Ptr(sometypethingy) ... As it is with $z / $w as well. I would suggest that this is changed, at least in superstrict, so you need to explicitely cast everything that is casted somewhere ... (I'm only using strict, so I don't mind much) |
| ||
| PYTE PTR is a "universal" pointer in blitzmax to a address - i think what about using PTR (alias void* IN C++) as a universal pointer? and the compiler should do not alert you. But if you use BYTE PTR - it should alert... Or a special strict mode - without conversations |
| ||
| well I cant see what your "problem" is without a real world example, byteptr works *very* well as is, in fact its invaluable! And it'll be just as invaluable if you have to explicitly cast to it. I'm not asking to remove the ability, only to enforce explicit casting, so you don't do it by mistake. I'm surprised wrapping Ogre hasn't demonstrated the problems with the current situation, but maybe you're wrapping very differently to how I do. His problem is mainly that it implicitely casts to Byte Ptr, without needing a Byte Ptr(sometypethingy) ... Precisely! I would suggest that this is changed, at least in superstrict, so you need to explicitely cast everything that is casted somewhere ... (I'm only using strict, so I don't mind much) Again, precisely! Leave it alone in Strict and non-Strict, no need to penalize users who don't want strict error checking, but SuperStrict implies that I want all my mistakes pointed out and that I have to declare my intentions at every stage. |
| ||
| Can you give me a better explanation with a real world example, the way byte ptr works is very handy and in no way a hinderance to me, just what is causing you the problem I just dont see how you are having any real problem?? |
| ||
| Sorry, I've learned in the past that justifying yourself in feature requests / bug reports just gets the thread way off topic with silly banter back and forth about why you should be programming in an entirely different way, and I'm not going to fall into that trap again. There's no good reason for implicit casting in SuperStrict. If you want it, cast it. Can't be bothered to cast it, don't use SuperStrict. Simple. |
| ||
| BRL? |
| ||
| :( Bump. |
| ||
| And again :( :( |
| ||
| Bumping it won't help. Either it is in BM 1.22 or it isn't. |
| ||
| Well without a simple reply, I can't even be sure if anyone from BRL has read it, can I? This is the second thread on the subject, and to my recollection, no one from BRL ever commented on the first thread either. I'm not asking for a lengthy piece of prose. A simple "Will be done soon", "might be done, but not just yet", "will have a think about it", "not likely, and not any time soon" or "you must be joking. never gonna happen" would suffice. |
| ||
| Write a piece of code that describe the problem and runable, then post it to BUG report, it should help. |
| ||
| I'm certain it's not a bug, or I would have reported it long ago. The piece of code that is runnable and describes the problem is in my first post. |
   |