global variables

[Charles Pegge]

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 Expand


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




[Eros Olmi]

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.

[José Roca]

 
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.

[Eros Olmi]

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.

[Eros Olmi]

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 ?

[José Roca]

 
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.

[Eros Olmi]

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.

[José Roca]

 
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.

[Eros Olmi]

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

[José Roca]

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.

[Eros Olmi]

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.

[Charles Pegge]

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?

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.

[José Roca]

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.

Hope Mr. Zale can get this suggestion.

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

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

[Eros Olmi]

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

Ciao
Eros

[Paul Squires]

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.