Deprecated: Array and string offset access syntax with curly braces is deprecated in /homepages/21/d38531796/htdocs/jose/smfforum/Sources/Subs.php on line 3825
global variables

Author Topic: global variables  (Read 19811 times)

0 Members and 1 Guest are viewing this topic.

Offline Charles Pegge

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 685
  • User-Rate: +27/-1
    • Charles Pegge
Re: global variables
« Reply #15 on: September 24, 2007, 02:20:33 PM »
No problem at all in Freebasic

The structure defined below is actually 12 bytes long, so it must contain an FB string descriptor.

It's all down to what dynamic capabilities are included in the runtime.

Freebasic
Code: [Select]
type dynastringstruc
 s as string
end type
                              '
dim dd as dynastringstruc     '

dd.s=string$(16000," ")       '
print sizeof(dd.s)            ' answer: 12
dd.s="hello world!"           '
print dd.s+"<<"               ' answer: hello world! (13 chars)
print sizeof(dynastringstruc) ' answer: 12
end



« Last Edit: September 24, 2007, 02:30:05 PM by Charles Pegge »

Offline Eros Olmi

  • Full Member
  • ***
  • Posts: 243
  • User-Rate: +18/-7
    • thinBasic
Re: global variables
« Reply #16 on: September 24, 2007, 02:22:52 PM »
I am not 100% sure. Thats why I searched the link to my Purebasic shortcut :-).
I thought i remember something like that.

Btw. how is that in Freebasic?

Pure Basic strings are like C strings more or less so no native BSTR support

FreeBasic: it manages dynamic strings in a way quite similar to BSTR but handling structure have not the same layout. Quite pity because they were very similar. In any case BSTR can be managed using the many SysAlloc... OLE functions. So not big problems, just a little overhead. In any case, if I'm not wrong dynamic stgrings are possible inside TYPEs but you know, types in FreeBasic are now going to an OO view. See http://www.freebasic.net/forum/viewtopic.php?t=4504&highlight=dynamic+strings+inside+type
YES, THERE ARE BIG PROBLEMS: FB allows var-len string fields, but they aren't deallocated automatically when they go out of scope.. Post is Jun2006 so maybe this info is out of scope. But if not, we are at the same exact position of PowerBasic where the problem is memory de-allocation. For reference on FreeBasic string 12 bytes structure: http://www.freebasic.net/forum/viewtopic.php?t=3704

Those languages have the problem to keep compatibility between the systems they are present at high level priority.

I think the biggest problem to have dynamic strings inside an UDT is the release of memory. Whatever will be the method, compiler has be store the fact that extramem, other than the one of the UDT, has to be de-allocated. String handling is not the problem.
« Last Edit: September 24, 2007, 02:35:56 PM by Eros Olmi »
thinBasic Script Interpreter - www.thinbasic.com | www.thinbasic.com/community
Win7Pro 64bit - 8GB Ram - Intel i7 M620 2.67GHz - NVIDIA Quadro FX1800M 1GB

Offline José Roca

  • Administrator
  • Hero Member
  • *****
  • Posts: 2487
  • User-Rate: +204/-0
Re: global variables
« Reply #17 on: September 24, 2007, 02:36:44 PM »
 
Time ago, I asked for native support of VARIANTs inside structures. They can be used to manage any data type, even arrays of variants or object variables. With support for variants and object variables (if classes are implemented in a future version of the compiler) you will have everything. No need to "invent" new types of structures each time you want additional features.

Offline Eros Olmi

  • Full Member
  • ***
  • Posts: 243
  • User-Rate: +18/-7
    • thinBasic
Re: global variables
« Reply #18 on: September 24, 2007, 02:47:01 PM »
That would be the perfect solution I think.

With variants you can store whatever you prefer. Of course it would be programmer responsability to free variant content in case of dynamic allocated content. For all numeric it would be automatically dealocated with the UDT.

Can be a great suggestion to solve the problem.

thinBasic Script Interpreter - www.thinbasic.com | www.thinbasic.com/community
Win7Pro 64bit - 8GB Ram - Intel i7 M620 2.67GHz - NVIDIA Quadro FX1800M 1GB

Offline Eros Olmi

  • Full Member
  • ***
  • Posts: 243
  • User-Rate: +18/-7
    • thinBasic
Re: global variables
« Reply #19 on: September 24, 2007, 02:53:05 PM »
What about writing to support at powerbasic . com asking about this addition?

I see Mr. Zale is here and can read about that but official road is to ask at support. I remember that developed features have higher priority depending on how many customers asked about it.

Does it make sense to you to have variants inside UDT ?
thinBasic Script Interpreter - www.thinbasic.com | www.thinbasic.com/community
Win7Pro 64bit - 8GB Ram - Intel i7 M620 2.67GHz - NVIDIA Quadro FX1800M 1GB

Offline José Roca

  • Administrator
  • Hero Member
  • *****
  • Posts: 2487
  • User-Rate: +204/-0
Re: global variables
« Reply #20 on: September 24, 2007, 03:00:40 PM »
 
VARIANTs are the best solution because it covers all. If added native support for them inside structures, the only memory that you will need to release will be if you use a VT_BYREF variant to reference a pointer to memory that you have allocated, but no need to free strings nor arrays if you use safe arrays.

Offline Eros Olmi

  • Full Member
  • ***
  • Posts: 243
  • User-Rate: +18/-7
    • thinBasic
Re: global variables
« Reply #21 on: September 24, 2007, 03:07:12 PM »
Are you sure?
I suppose it depends on how PB implements it. I mean if they just add 16 bytes and make VARIANT$, VARIANT# and VARIANTVT working on that 16 bytes, do you think memory will be released automatically? Who will release it if a dynamic string will be inside a VARIANT in a UDT structure? And what about OS before Win2K?

If it is all magically handled by some engine it would be fantastic and be the solution for all.
thinBasic Script Interpreter - www.thinbasic.com | www.thinbasic.com/community
Win7Pro 64bit - 8GB Ram - Intel i7 M620 2.67GHz - NVIDIA Quadro FX1800M 1GB

Offline José Roca

  • Administrator
  • Hero Member
  • *****
  • Posts: 2487
  • User-Rate: +204/-0
Re: global variables
« Reply #22 on: September 24, 2007, 03:09:25 PM »
 
With native support for variants inside structures, PB will have to call the VariantClear function for each variant when an UDT containing variants is going to be freed. This is what VariantClear does:

The function clears a VARIANTARG by setting the vt field to VT_EMPTY. The current contents of the VARIANTARG are released first. If the vt field is VT_BSTR, the string is freed. If the vt field is VT_DISPATCH, the object is released. If the vt field has the VT_ARRAY bit set, the array is freed.

If the variant to be cleared is a COM object that is passed by reference, the vt field of the pvarg parameter is VT_DISPATCH | VT_BYREF or VT_UNKNOWN | VT_BYREF. In this case, VariantClear does not release the object. Because the variant being cleared is a pointer to a reference to an object, VariantClear has no way to determine if it is necessary to release the object. It is therefore the responsibility of the caller to release the object or not, as appropriate.

In certain cases, it may be preferable to clear a variant in code without calling VariantClear. For example, you can change the type of a VT_I4 variant to another type without calling this function. Safearrays of BSTR will have SysFreeString called on each element not VariantClear. However, you must call VariantClear if a VT_type is received but cannot be handled. Safearrays of variant will also have VariantClear called on each member. Using VariantClear in these cases ensures that code will continue to work if Automation adds new variant types in the future.

Offline Eros Olmi

  • Full Member
  • ***
  • Posts: 243
  • User-Rate: +18/-7
    • thinBasic
Re: global variables
« Reply #23 on: September 24, 2007, 03:16:27 PM »
Well, the idea is very clever but the way is not so simple.
Again, the compiler has to keep track of possible VARIANTs declared inside the UDT, and here again the same problem as dynamic strings mentioned above.

I personally would accept to have VARIANTs inside UDT even if the programmer will keep responsability to free them.
Of course if compiler will handle all those stuff I will be more happy :D

thinBasic Script Interpreter - www.thinbasic.com | www.thinbasic.com/community
Win7Pro 64bit - 8GB Ram - Intel i7 M620 2.67GHz - NVIDIA Quadro FX1800M 1GB

Offline José Roca

  • Administrator
  • Hero Member
  • *****
  • Posts: 2487
  • User-Rate: +204/-0
Re: global variables
« Reply #24 on: September 24, 2007, 03:21:21 PM »
Quote
Again, the compiler has to keep track of possible VARIANTs declared inside the UDT, and here again the same problem as dynamic strings mentioned above.

But with the same work, you add support for everything, not just for strings.

Offline Eros Olmi

  • Full Member
  • ***
  • Posts: 243
  • User-Rate: +18/-7
    • thinBasic
Re: global variables
« Reply #25 on: September 24, 2007, 03:24:11 PM »
Hope Mr. Zale can get this suggestion.
For what it concernes to me, I will write down a request and I will send to support.
thinBasic Script Interpreter - www.thinbasic.com | www.thinbasic.com/community
Win7Pro 64bit - 8GB Ram - Intel i7 M620 2.67GHz - NVIDIA Quadro FX1800M 1GB

Offline Charles Pegge

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 685
  • User-Rate: +27/-1
    • Charles Pegge
Re: global variables
« Reply #26 on: September 24, 2007, 03:31:48 PM »
Thanks Eros, for your comments about Freebasic and deallocating strings in a UDT. Below is V1ctor's advice,
on how to release the string space before the structure goes out of scope.

Now I presume that if structures containing variants, were implemented in Powerbasic, we would still need some mechanism for releasing VARIANT strings and other referenced structures. Or are there OLE calls to do that for us?

Quote
FB allows var-len string fields, but they aren't deallocated automatically when they go out of scope, so if declaring/allocating them inside functions, remember to always set the fields to "" (including each item if it's an arrays of UDT's that contain var-len string fields) before exiting the functions or memory will leak.
 

Offline José Roca

  • Administrator
  • Hero Member
  • *****
  • Posts: 2487
  • User-Rate: +204/-0
Re: global variables
« Reply #27 on: September 24, 2007, 03:36:39 PM »
Quote
I personally would accept to have VARIANTs inside UDT even if the programmer will keep responsability to free them.

The purpose of having native support is to no have to handle memory management manually. Otherwise, you can have variants inside UDTs right now. Just declare a member of the structure as VARIANTAPI and use the various API functions to manage variants and safe arrays. A variant is just an structure, and PB allows to have structures inside structures.

Quote
Hope Mr. Zale can get this suggestion.

You bet. I have made already send this suggestion, and many others, to him.

Quote
Now I presume that if structures containing variants, were implemented in Powerbasic, we would still need some mechanism for releasing VARIANT strings and other referenced structures. Or are there OLE calls to do that for us?

See what I have posted about VariantClear above. It's time to learn some COM programming :)

Offline Eros Olmi

  • Full Member
  • ***
  • Posts: 243
  • User-Rate: +18/-7
    • thinBasic
Re: global variables
« Reply #28 on: September 24, 2007, 03:38:33 PM »
Yes Charles, the problem is axactly how to determine the presence of a dynamic data (string or VARIANT) inside UDT and where and how release them.
Josè seems to have the exact idea on how to release, see above post from Josè.

In the meantime I'm writing my request to PB support to have VARIANTs in UDT. Will be a little voice, but you know, sea is made by little drops :D

Ciao
Eros
thinBasic Script Interpreter - www.thinbasic.com | www.thinbasic.com/community
Win7Pro 64bit - 8GB Ram - Intel i7 M620 2.67GHz - NVIDIA Quadro FX1800M 1GB

Offline Paul Squires

  • Jr. Member
  • **
  • Posts: 90
  • User-Rate: +11/-5
    • PlanetSquires
Re: global variables
« Reply #29 on: September 24, 2007, 03:50:10 PM »
The idea of using a VARIANT in a TYPE to handle variable strings is a great idea. It never occured to me. Using a VARIANT would certainly allow for a greater degree of flexibility.
Paul Squires
FireFly Visual Designer SQLitening Database System JellyFish Pro Editor
http://www.planetsquires.com