QB64.org Forum

Active Forums => QB64 Discussion => Topic started by: Pete on January 06, 2021, 04:58:12 pm

Title: This UDT thing really bugs me...
Post by: Pete on January 06, 2021, 04:58:12 pm
You can use STATIC with UDTs, but unless I'm missing something, you can't pass a UDT as a single parameter. Instead, you have to do a DIM SHARED of the TYPE, or  pass each variable assigned to the UDT like page.x, page. y, page. z, etc. I don't see why you shouldn't be able to pass the type as a parameter. What are we, a Third World Language?

Pete

Title: Re: This UDT thing really bugs me...
Post by: johnno56 on January 06, 2021, 04:59:37 pm
Please excuse my ignorance... 'UDT'?
Title: Re: This UDT thing really bugs me...
Post by: STxAxTIC on January 06, 2021, 05:09:46 pm
what?

Code: QB64: [Select]
  1.  
  2. TYPE thing
  3.     whatever AS INTEGER
  4.     whateverelse AS DOUBLE
  5.  
  6. DIM dog AS thing
  7.  
  8. dog.whatever = 5
  9. dog.whateverelse = 0.33
  10.  
  11. PRINT dosomething(dog)
  12.  
  13.  
  14. FUNCTION dosomething (i AS thing)
  15.     DIM a AS INTEGER
  16.     DIM b AS DOUBLE
  17.     a = i.whatever
  18.     b = i.whateverelse
  19.     dosomething = a + b
Title: Re: This UDT thing really bugs me...
Post by: bplus on January 06, 2021, 05:16:26 pm
UDT stands for User Defined Type

Here is my what????
Code: QB64: [Select]
  1. TYPE UDT
  2.     x AS LONG
  3.     s AS STRING
  4. REDIM array(1 TO 20) AS UDT
  5. FOR i = 1 TO 20
  6.     array(i).x = i
  7.     array(i).s = CHR$(64 + i)
  8. FOR i = 2 TO 20 STEP 2
  9.     showArray array(), i
  10.  
  11.  
  12. SUB showArray (a() AS UDT, i)
  13.     PRINT a(i).x, a(i).s
  14.  
Title: Re: This UDT thing really bugs me...
Post by: johnno56 on January 06, 2021, 05:20:12 pm
Thanks bplus.
Title: Re: This UDT thing really bugs me...
Post by: Pete on January 06, 2021, 06:16:49 pm
UDT stands for User Defined Type

Here is my what????
Code: QB64: [Select]
  1. TYPE UDT
  2.     x AS LONG
  3.     s AS STRING
  4. REDIM array(1 TO 20) AS UDT
  5. FOR i = 1 TO 20
  6.     array(i).x = i
  7.     array(i).s = CHR$(64 + i)
  8. FOR i = 2 TO 20 STEP 2
  9.     showArray array(), i
  10.  
  11.  
  12. SUB showArray (a() AS UDT, i)
  13.     PRINT a(i).x, a(i).s
  14.  

So passed as "a" it works...

Code: QB64: [Select]
  1. TYPE UDT
  2.     x AS LONG
  3.     s AS STRING
  4. DIM array AS UDT
  5.  
  6. array.x = 10
  7. array.s = CHR$(65)
  8.  
  9. CALL showArray(array, i)
  10.  
  11. SUB showArray (a AS UDT, i)
  12.     PRINT a.x, a.s
  13.  

and this works...

Code: QB64: [Select]
  1. TYPE UDT
  2.     x AS LONG
  3.     s AS STRING
  4. DIM array AS UDT
  5.  
  6. array.x = 10
  7. array.s = CHR$(65i)
  8.  
  9. CALL showArray(array, i)
  10.  
  11. SUB showArray (array, i)
  12.     PRINT array.x, array.s
  13.  

but if you don't use array as UDT in the SUB, it fails...

Code: QB64: [Select]
  1. TYPE UDT
  2.     x AS LONG
  3.     s AS STRING
  4. DIM array AS UDT
  5.  
  6. array.x = 10
  7. array.s = CHR$(65)
  8.  
  9. CALL showArray(array, i)
  10.  
  11. SUB showArray (array, i)
  12.     PRINT array.x, array.s
  13.  

My guess is the reason is something like you have to not only pass the variable, but when SHARED is not used, you have to pass the type to the sub, along with the variable. If that's the reason, maybe it should be noted that you couldn't write array = 10 in the code, either. That stated, what other reason(s), if any, would prevent QB64 from allowing the last example to compile and work?

Pete
Title: Re: This UDT thing really bugs me...
Post by: STxAxTIC on January 06, 2021, 06:19:29 pm
what the hell is

Code: QB64: [Select]
  1. CHR$(65i)
Title: Re: This UDT thing really bugs me...
Post by: FellippeHeitor on January 06, 2021, 06:20:02 pm
If you don't write AS UDT, the array parameter is a SINGLE type variable.
Title: Re: This UDT thing really bugs me...
Post by: STxAxTIC on January 06, 2021, 06:21:12 pm
Ah, came back to say what Fellippe just said ^.

Funny, cause all he did was copypaste my example but deleted too much :-)
Title: Re: This UDT thing really bugs me...
Post by: Pete on January 06, 2021, 06:21:44 pm
what the hell is

Code: QB64: [Select]
  1. CHR$(65i)

It's a TYPeO.

Pete
Title: Re: This UDT thing really bugs me...
Post by: Pete on January 06, 2021, 06:27:30 pm
If you don't write AS UDT, the array parameter is a SINGLE type variable.

No it isn't, because it was DIMmed as a TYPE. That's why the IDE won't accept it as a variable.
Title: Re: This UDT thing really bugs me...
Post by: FellippeHeitor on January 06, 2021, 06:32:09 pm
Code: QB64: [Select]
  1. TYPE UDT
  2.     x AS LONG
  3.     s AS STRING
  4. DIM array AS UDT
  5.  
  6. array.x = 10
  7. array.s = CHR$(65)
  8.  
  9. CALL showArray(array, i)
  10.  
  11. SUB showArray (array AS UDT, i)
  12.     PRINT array.x, array.s
  13.  
  14.  
Title: Re: This UDT thing really bugs me...
Post by: FellippeHeitor on January 06, 2021, 06:32:49 pm
'array' in the main module is a separate entity from 'array' as a parameter to a sub.
Title: Re: This UDT thing really bugs me...
Post by: Pete on January 06, 2021, 06:47:31 pm
And that was my reasoning, too, but since QB64 won't allow "array" to be used as a variable, once it is assigned as a UDT, maybe it could be made to be passed as...

Code: QB64: [Select]
  1. TYPE UDT
  2.     x AS LONG
  3.     s AS STRING
  4. DIM array AS UDT
  5.  
  6. array.x = 10
  7. array.s = CHR$(65)
  8.  
  9. CALL showArray(array, i)
  10.  
  11. SUB showArray (array, i)
  12.     PRINT array.x, array.s
  13.  

What "bugs" me about having to add the "AS UDT" in the sub is the extra size it adds to the line of code, making it more difficult to read when there are several additional parameters passed.

My guess is as much as I would like my abbreviated example, it would conflict with too many established constructs such as...

Code: QB64: [Select]
  1.  
  2. CALL showArray(a)
  3.  
  4. SUB showArray (a)
  5.     a = 1.5
  6.     PRINT a

vs...

Code: QB64: [Select]
  1.  
  2. CALL showArray(a)
  3.  
  4. SUB showArray (a AS INTEGER)
  5.     a = 1.5
  6.     PRINT a

...for examples.

Well, as much as I have't worked with UDT's in the past, I may just bite the bullet on this one, and consider turning more of my variables into UDT's. That way, I can pass more variables under fewer parameters, and shorten those SUB () lines.

Thanks for batting this around with me.

Pete
Title: Re: This UDT thing really bugs me...
Post by: luke on January 06, 2021, 06:55:38 pm
My guess is as much as I would like my abbreviated example, it would conflict with too many established constructs such as...

Code: QB64: [Select]
  1.  
  2. CALL showArray(a)
  3.  
  4. SUB showArray (a)
  5.     a = 1.5
  6.     PRINT a

I find it amusing you refer to this as established usage, since this is QB64-only code. QB45 will complain about a type mismatch, because you're trying to pass an integer by-reference to a function expecting a single. QB64 is being "helpful" and implicitly adding a CINT() around your argument.

This may cause surprises if you expect the parameter to be an output parameter:
Code: QB64: [Select]
  1. p = 2
  2. q = 3
  3. PRINT p, q
  4. xchg p, q
  5. PRINT p, q
  6.  
  7. SUB xchg (a, b)
  8.     temp = a
  9.     a = b
  10.     b = temp
Doesn't swap the values because they're being passed by-value (and yes, I know we already have a SWAP command).
Title: Re: This UDT thing really bugs me...
Post by: SMcNeill on January 06, 2021, 07:08:19 pm
And if you want to do something really strange, DECLARE LIBRARY your own sub and pass an offset value of something to it, so it can process it as a UDT...

Code: QB64: [Select]
  1. DECLARE CUSTOMTYPE LIBRARY 'Use Customtype for self-referencing a sub written inside your program
  2.     SUB SUB_EXAMPLE (BYVAL passed AS _OFFSET) 'this points to SUB EXAMPLE below, but uses an OFFSET to point to its parameter.
  3.     'NOTE:  The sub/function name *MUST* be the same as QB64 translates it as, for us.
  4.     'General rule of thumb is to make the subname ALL CAPS, preceeded by SUB_ or FUNCTION_ as dictated.
  5.     SUB SUB_EXAMPLE2 (BYVAL passed AS _OFFSET)
  6.  
  7. TYPE DataType 'A datatype to use as an example
  8.     x AS STRING * 12
  9.     y AS LONG
  10.     z AS LONG
  11.  
  12. TYPE DataType2 'a second datatype
  13.     byte1 AS _UNSIGNED _BYTE
  14.     byte2 AS _UNSIGNED _BYTE
  15.     byte3 AS _UNSIGNED _BYTE
  16.     byte4 AS _UNSIGNED _BYTE
  17.     byte5 AS _UNSIGNED _BYTE
  18.     byte6 AS _UNSIGNED _BYTE
  19.     byte7 AS _UNSIGNED _BYTE
  20.     byte8 AS _UNSIGNED _BYTE
  21.     byte9 AS _UNSIGNED _BYTE
  22.     byte10 AS _UNSIGNED _BYTE
  23.     byte11 AS _UNSIGNED _BYTE
  24.     byte12 AS _UNSIGNED _BYTE
  25.     byte13 AS _UNSIGNED _BYTE
  26.     byte14 AS _UNSIGNED _BYTE
  27.     byte15 AS _UNSIGNED _BYTE
  28.     byte16 AS _UNSIGNED _BYTE
  29.     byte17 AS _UNSIGNED _BYTE
  30.     byte18 AS _UNSIGNED _BYTE
  31.     byte19 AS _UNSIGNED _BYTE
  32.     byte20 AS _UNSIGNED _BYTE
  33.  
  34. a$ = "Hello World " + MKL$(-1) + MKL$(3)
  35.  
  36.  
  37. SUB_EXAMPLE _OFFSET(a$) 'Call the sub with the offset to a string
  38. SUB_EXAMPLE2 _OFFSET(a$) 'Notice, we passed the same string, but are handling it differently here,
  39. '                             according to the paramters set in the second sub
  40.  
  41.  
  42.  
  43.  
  44.  
  45.  
  46. SUB Example (t AS DataType) 'And here, we want to set up the actual sub to work with our example datatype.
  47.     PRINT t.x 'print the values of that memblock
  48.     PRINT t.y
  49.     PRINT t.z
  50.  
  51. SUB Example2 (x AS DataType2)
  52.     COLOR 12
  53.     PRINT x.byte1
  54.     PRINT x.byte2
  55.     PRINT x.byte3
  56.     PRINT x.byte4
  57.     PRINT x.byte5
  58.     PRINT x.byte6
  59.     PRINT x.byte7
  60.     PRINT x.byte8
  61.     PRINT x.byte9
  62.     PRINT x.byte10
  63.     PRINT x.byte11
  64.     PRINT x.byte12
  65.     PRINT x.byte13
  66.     PRINT x.byte14
  67.     PRINT x.byte15
  68.     PRINT x.byte16
  69.     PRINT x.byte17
  70.     PRINT x.byte18
  71.     PRINT x.byte19
  72.     PRINT x.byte20
  73.  

Now of this bit of trickery doesn't have you scratching your head and wondering just what the heck is happening here, then you win the Obfuscated Coder Award for 2021!
Title: Re: This UDT thing really bugs me...
Post by: FellippeHeitor on January 06, 2021, 07:30:54 pm
The man doesn't wanna write an extra AS UDT, Steve.
Title: Re: This UDT thing really bugs me...
Post by: Pete on January 06, 2021, 08:28:34 pm
:D :D :D
Title: Re: This UDT thing really bugs me...
Post by: SMcNeill on January 06, 2021, 10:01:54 pm
The man doesn't wanna write an extra AS UDT, Steve.

And he’s not.  He’s writing one string and using it with the UDT above. 

What Pete needs is UDTS (user defined type symbols).  Then he can

TYPE foo(%@)
    X AS INTEGER
    Y AS INTEGER
END TYPE

a%@.x = 12
b%@.y = 11

And PRESTO!!  a and b are automatically recognized as type foos.  Can you imagine the colorful type symbols we'd see someone, like Pete, inserting into his code?
   
Title: Re: This UDT thing really bugs me...
Post by: FellippeHeitor on January 06, 2021, 10:03:53 pm
Still missing the point, big guy.
Title: Re: This UDT thing really bugs me...
Post by: SMcNeill on January 06, 2021, 10:06:36 pm
Still missing the point, big guy.

I gets it.  Pete gets it.  You're just missing out on the satirically snarky humor me and Pete exchange.  ;D
Title: Re: This UDT thing really bugs me...
Post by: FellippeHeitor on January 06, 2021, 10:06:55 pm
Sure. My bad, sir. Won't happen again.
Title: Re: This UDT thing really bugs me...
Post by: Pete on January 06, 2021, 10:54:34 pm
Sure. My bad, sir. Won't happen again.

Having both Steve and I on the same forum might be a bit much for you and luke, at times, but you have to appreciate our co-existence is a great asset to Bill in his quest to prove the existence of a multiverse. Based on the premise both Steve's ego and my ego cannot exist together on the size of this forum, let alone a single universe, Bill is one step closer to understanding unified field theory. Oops, now I've taken us from UDTs to UFTs. Oh well, if you will excuse me, my foo got quantum entangled in my shawl again, and it's time for my hot cocoa.

Pete
Title: Re: This UDT thing really bugs me...
Post by: SMcNeill on January 06, 2021, 11:25:58 pm
...one step closer to understanding unified field theory.

Nothing complicated to understand there.  UFT is just the theory that if you keep all your cows in the same field, you don't have to walk as far to milk them.  Any farmer can explain that one for you!

To break down the humor for Fell, it goes like this:

Pete: "Change QB64 so I don't have to type 6 characters.  I'm lazy!"
Me: "You don't have to!  You can work around that limit by typing half a page of obfuscated code."
Fell: "No, Pete just doesn't want to type 'AS UDT'..."
Me:"OH!  Then we should add extra symbols to type every time you reference a variable!"
Fell:"You're missing the point!"
Me: "No...  You're missing the humor of how I was joking with Pete."
Fell:  *Sulks in the corner and edits a post a half dozen times to say, "Fine.  Whatever."*

See, Pete likes to joke around and ask for unreasonable things, that no one else wants or cares about.  The answer is to give him an equally unreasonable workaround to his problem, or an obnoxiously over-engineered implementation to correct his issue.  Pete's not really looking for any change -- he's just having fun griping about an issue that popped up in his code that he failed to catch and recognize.

It's all just playful banter back and forth, but you have to be the right TYPE to appreciate it. ;D
Title: Re: This UDT thing really bugs me...
Post by: FellippeHeitor on January 06, 2021, 11:26:55 pm
Of course, sir. I apologize once again.