Wishlist: Variable strings in TYPE's

[Paul Squires]

Just to reiterate a past wish by myself and several other board
members. I recently had to use two other flavors of BASIC and
they both allowed variable length strings in TYPE structures. I
had forgotten just how great that feature is. It certainly makes
coding a lot cleaner (at least in most of the applications that I
write).

I currently use variable length strings in TYPE's via some wrapper
routines that manually allocate and deallocate memory. It works,
but it is not a 'BASIC' way of doing things. It would be a lot
cleaner if the compiler took care of allocating the memory space
and destroying it whenever the TYPE variable went out of scope (much
like all other variables).

... oh, and I know the argument about TYPE's needing to be fixed
length in order to be better suited for files opened in random
mode, but that it just one specific case of a use for TYPE variables.
I use them much, much, more often to hold in-memory program data.

Also, while we're at it, why not build into the language two keywords
that allow for the manual allocation and deallocation of memory.
For example, MEMALLOCATE and MEMDEALLOCATE. I currently use wrappers
around the Win API functions to do this but it seems that it should
be part of the PB language itself (hell, we have pointers and in-line
asm, so allowing the programmer to allocate and deallocate memory
is not that big of a step).

... just thought that I would get a couple of shots in before the
end of 2005.

------------------
Paul Squires
FireFly Visual Designer, Cheetah Database System, JellyFish Pro Editor
www.planetsquires.com

[This message has been edited by Paul Squires (edited December 29, 2005).]

[Dale Yarker]

Did they actually use dynamic strings in structures, or hide the
use of STRPTRs from you?

I can almost see how to do it for files -

type BeginEnd
  sBegin as quad
  sEnd as quad
end type
type MyType
  A_Num as long
  A_FixLenStr as string * 10
  A_DynStr as BeginEnd
end type

All the fixed length "MyType" vars at the beginning of the file,
with the dynamic strings after the last MyType. The BeginEnd member
defining file position. To add a var would mean moving the first
dynamic string to make room for the new fixed part.

Basically, you end up building a file system within a file. (Hum, a
database that can have variable length fields? Is that an idea for
a sellable DLL?? (If somebody does this, I'd like one free copy in
in trade for the idea.))

It makes my head hurt try'in to figure how PB could get the compiler
do it in memory AND keep it generic enough for the majority
of customers.

I think I like your MEMALLOCATE and MEMDEALLOCATE idea though.

Cheers,

------------------
Dale

[Michael Mattias]

[quote]
(Hum, a database that can have variable length fields? Is that an idea for a sellable DLL??
[/quote}

Sorry, there's no money in this idea.. the world has been there and done that.

Lots of databases support variable-length fields. Even the much-maligned Microsoft Jet (Access) DBMS has supported variable-length records for about 5 major releases and ten+ years.

Heck, even I created a variable-length fields (and records) database for use with my 837 API product; I even index that using "A certain Florida USA BASIC Compiler publisher's 'tree' product."

Had you had this idea maybe 25-30 years ago it might have worked out better for you...

[Mike Trader]

2nd that request for Dynamic strings in TYPEs

While we are a it, why not some slick BASIC way to avoid that
nast string concatentaion like STRINGADD( )

------------------
Kind Regards
Mike

[Kev Peel]

Coincidentally, I will be releasing a variable-length database manager within the next week. Still working on the samples at the moment though (those C headers are a real pain, even when using MAKLIB.EXE!)

------------------
contact me
kgpsoftware.com - Free and Commercial Software

[Robert DeBolt]

(Hum, a database that can have variable length fields? Is that an idea for a sellable DLL??

Tsunami


------------------
Regards,
Bob
--------
Composed with EZ-Post!

[Michael Mattias]

real men don't need no stinkin' dynamic strings in udts.

real men use asciiz ptr members, and allocate and deallocate their own strings using malloc, realloc, free for pb/win32

(i'll (heroically) resist pointing out the contradiction inherent in attempting to use something with 'variable length members' in a programming tool designed specifically to provide a fixed-length variable).

[Walt Decker]

While we're talking about wishes, constants to hold real numbers would be a nice addition.

------------------
Walt Decker
UPLA

[Michael Mattias]

why not some slick BASIC way to avoid that nasty string concatentaion like STRINGADD( )

???

I must be missing something.

C$ = A$ & B$

sure doesn't seem 'nasty.'

[Paul Squires]

Real Men don't need no stinkin' dynamic strings in UDTs.
Real Men use ASCIIZ PTR members, and allocate and deallocate their
own strings using malloc, realloc, free for PB/Win32

As I pointed out in my post, that is exactly what I am doing now.

(I'll (heroically) resist pointing out the contradiction inherent
in attempting to use something with 'variable length members' in a
programming tool designed specifically to provide a fixed-length variable).

...and I will point out that the notion that a 'TYPE' must be fixed
length is just a restriction currently imposed by the compiler. It
does not correspond to the concept of what a TYPE should be or what
a TYPE represents in theory. There is no reason why a TYPE should
not be extended to allow variable length strings (and variable
length 'arrays' for that matter).

The following is from the PB help file:

Arrays are useful when you need to treat a set of similar variables
as a unit. For instance, ten test scores or ten student names.
But what if you need to store several unrelated data types and
be able to treat them as a unit? That is where User-Defined Types
come in. When you define a User-Defined Type (UDT), you are
actually defining a template for a new variable Type.

So it is clear that the benfit of a TYPE is to provide an easy way
to store a collection of data types that as a whole provides meaning.
... all data types except for dynamic strings that is. A TYPE is
supposed to be a 'record' or a collection of related data. Imposing
a restriction on the allowed data types ruins the concept in favor of
trying to fit the concept within the restrictions of the compiler.

The only downside of using dynamic strings in a TYPE is when you
want to output the TYPE directly to a disk file. In those cases
you would design your program using fixed length strings anyway.
Leave it to the programmer to decide when dynamic vs. fixed length
strings are appropriate.

Once you have used dynamic strings in TYPEs, it is hard to go back
to the old method. The additional code needed to accomplish dynamic
strings in TYPEs is a burden to the programmer who chooses BASIC
because memory allocation and deallocation is normally taken care
of by the compiler.




------------------
Paul Squires
FireFly Visual Designer, Cheetah Database System, JellyFish Pro Editor
www.planetsquires.com

[Michael Mattias]

It does not correspond to the concept of what a TYPE should be or what a TYPE represents in theory.

???

TYPE is a PowerBASIC Inc - specific programming tool and syntax construct. Ergo, PowerBASIC Inc defines the rules. Those rules say a TYPE is a fixed-length entity.

I'm clearly avoiding the "should be" aspects of "type" , but what do you want for less than two hundred bucks?

MCM

[Chuck Hicks]

Originally posted by Michael Mattias:
what do you want for less than two hundred bucks?

Hmmm... Let's not talk about all the drastically more capable
compilers out there that are available for free, from gcc to jdk...



------------------

[Michael Mattias]

>..drastically more capable compilers out there

It's not the paintbrush, it's the artist.

[Paul Squires]

I'm clearly avoiding the "should be" aspects of "type"

That's the problem. The point of this whole thread is a "wishlist"
for what the TYPE "should be". We all know what a TYPE is now as
defined by PB - that's the obvious.

Maybe instead of arguing that TYPEs should be expanded, I should be
arguing that Classes should be implemented. That will fix it.



------------------
Paul Squires
FireFly Visual Designer, Cheetah Database System, JellyFish Pro Editor
www.planetsquires.com

[Michael Mattias]

Maybe instead of arguing that TYPEs should be expanded, I should be
arguing that Classes should be implemented. That will fix it.

Fix what?

"What we have he-yah," said the warden, "is a fail-yuh to comm-une-ee-cate."

Maybe we need to define what is wanted... which, correct me if I'm wrong (like I have to ask!), is " a single-variable name reference to variable-size data."

That is, what is wanted may be represented <U>conceptually</U> by a UDT supporting dynamic strings; but would not necessarily need to take that form.

Frankly, I can't think of anything indigenous to the PowerBASIC language which supports that, other than an array of dynamic strings which would have to be manipulated back to TYPEs and UNIONs and/or incorporate length words in some kind of 'stream.'

Of course, there's always VARIANTs, and arrays (another PB-specific syntax construct) of VARIANTS... which just might do the job for you. (I've never really played with variants, but they look pretty promising for this)

MCM

[Ken Myers]

For what it is worth...

I would also like to have dynamic strings available to us as
members of a TYPE. It would actually make it a bit easier for
those of us who frequently port Visual Basic (mostly 6.0) code.
Like Paul, I make frequent use of asciiz ptr today, but it would
be nice if PB did this for me under the hood.

In regards to classes and OOP constructs in general... I would
use them if they were available to me, but I think there is quite
a bit involved in implementing that properly (like java or .NET).

Just my 2 cents...

-Ken



------------------

[Ron Dunn]

I'm having a bit of trouble understanding this one, probably
because I'm not used to working with structures containing
variable-length elements in any other language.

Can someone give me a few examples of circumstances in which
variable length strings are required in user-defined types,
and why a fixed-length string will not work in these examples?

------------------

[Ron Dunn]

[QUOTE]Originally posted by Dale Yarker:
... (Hum, a
database that can have variable length fields? Is that an idea for
a sellable DLL?? (If somebody does this, I'd like one free copy in
in trade for the idea.)) ...
www.microsoft.com www.oracle.com www.sybase.com www.ibm.com www.pervasive.com

Microsoft, Oracle, Sybase and IBM certainly have free downloads
of their DBMS for developers. They've all supported variable
length fields for many years.


------------------

[Chuck Hicks]

Originally posted by Ken Myers:

In regards to classes and OOP constructs in general... I would
use them if they were available to me, but I think there is quite
a bit involved in implementing that properly (like java or .NET).

Just my 2 cents...

Ken,

Your 2 cents is always worth a lot more...

Perhaps not so involved - the Ruby language is fully OOP, and was
written by a single developer. RealBasic has been completely revamped
as an OOP language, including classes, dot notation, and full support
for stream I/O, both file and network - fundamental things that should
be a part of every language. If my current PB project pans out, and
sufficient money starts coming in, the first thing I plan to do is
purchace a copy of RealBasic and port the app to it.

I was encouraged when PB7 added modern error handling (try/catch/finally),
and held out some hope that PB's designers were moving in the right
direction. PB8, however, went in a completely different direction,
with nothing of significance added, IMHO.


------------------

[Richard Angell]

The issue seems to be more than "porting in "for some folks, other's just want to port from VB more easily. Unfortunately no one seems to have thoroughly answered the question, re. other BASIC's, posed first by Dale Yorker, "Did they actually use dynamic strings in structures, or hide the use of STRPTRs from you?"

In VB this seems to be the case. That is to say with a couple truckloads of VB wrappers the average user is insulated from the fact that the so called dynamic string member field of the TYPE, is really a pointer to the string. Take the length of an assigned type with some hefty strings, and this will become apparent in an instant. The STRING members are 4 bytes each ... a pointer.

The same thing can be accomplished in PB, but it's roll your own, and handle the details yourself too. So the bottom line is some folks want PB to handle the extra baggage, er ... "wrapping" ... to invisibly create and store the pointer to access the memory to store/modify/retrieve "dynamic string members"

Some would wish, to be sure, that such feature should only have such wrapping added when used, and also any additional wrapping to save such TYPEd variables and arrays of them, as well as expanded versions of the SIZEOF and/or LEN functions. Primarily, PB'ers do not want code bloated without reason, so this would be the middle ground ... use expanded functions and type support only when used.

There are the other thoughts in the mix here, These concern emulating the C++ use for TYPE structures, and allowing both function and data members, and then class-naming, inheritance and object lists .... and then OOP comes into focus again ... and that controversial subject has seen the light of many discussions in the forums ...



------------------
Rick Angell