Why do you care that much about BASIC part in the name of a language?

[Aurel]

[

[Mike Lobanovsky]

... as we are adding BASIC string function support along with math.

John, I followed your link and had a quick look at your (nsilva's, to be exact) set of proposed string function translations.

You're falling into a monumental trap. I remember I pointed that out a couple years ago: you can't get away with strings as easily as you do with #defines. Those will be leaking memory like hell, especially in loops.

Matter is, almost all of them are calloc'ing memory chunks from the process heap but none of them is actually freeing anything, ever. You must implement some sort of transparent memory management to match that would collect and free temporary and function-local string var allocations similar to the ring allocator of BCX/UBX/MBC (haven't I overlooked anyone?), or else design a full blown memory manager with garbage collection similar to the one used in Script BASIC itself to also cater for the memory discardable by global string vars at the moment when their string values are reassigned for whatever purpose -- concatenation, trimming, etc.

That done, you'll end up with perhaps 75% of a new BASIC-to-C (BCX??) translator reincarnation in your lap.

There is absolutely no other way out of this blind alley.

[ScriptBasic]

That done, you'll end up with perhaps 75% of a new BASIC-to-C (BCX??) translator reincarnation in your lap.

C BASIC isn't a translator. It's a preprocessor trick making C look more like BASIC.

I know. I had to fight to get him to make the start of a string 1 instead of 0. 

I'm thinking of using Script BASIC's MyAlloc if I can't find something else.

AIR already has a C BASIC  with string support but it's for C++ called JADE.

[Mike Lobanovsky]

It's a preprocessor trick making C look more like BASIC.

If that's what you intend it to stay in the future, then you'll have to keep track of string calloc's throughout your pseudo-BASIC sources yourself exactly like in C programming and encode all the appropriate deallocations manually. Might be a good exercise for a BASIC-er to learn one or two things about memory management though...

[cvirus]

It's a preprocessor trick making C look more like BASIC.

If that's what you intend it to stay in the future, then you'll have to keep track of string calloc's throughout your pseudo-BASIC sources yourself exactly like in C programming and encode all the appropriate deallocations manually. Might be a good exercise for a BASIC-er to learn one or two things about memory management though...

I have seen the project and in the c string file does have a function like

Code: [Select]

void destroy(char *str)
{
    free(str);
}

This way it can be called in the end n times to release the mem alloc, or is there a best way of doing that?
How would you implement it?

Thanks.

[Mike Lobanovsky]

@cvirus:

destroy(char *str) is the only one on the list that doesn't have to be implemented as a function. It would only add function call overhead to the resultant C code. It had better be implemented as a macro:

#define destroy(s) free((void*)(s))

C provides two ways to create a function local string:

1) directly on the function stack in the form of a fixed size character array, e.g.
char s[128] = "bla-bla";
in which case it needs no special freeing because it's going to be destroyed together with the function stack automatically on function return; and

2) as a character pointer on the function stack that would point to a memory chunk allocated elsewhere, e.g.
char *s = (char*)malloc(128); // => uninitialized; (char*)calloc(128,1) => initialized with 0's
in which case it must be freed explicitly before the function returns if only the pointer value s isn't returned by the function itself for use somewhere else in the program code. If this isn't done, then the pointer value s will be lost together with the function stack on function return but the chunk will still hang in memory forever unallocatable due to the exact value having been irrevocably lost.

Variant 1 is seldom used because the default stack size is typically 1MB for the entire program and it can be exhausted very quickly if the function calls are nested deeply in one another or are recursive, especially if the character arrays are large.

In short, the C-Basic programmer should behave exactly like a C programmer would following the rules of proper memory management. Further reference materials on this topic are likely to be found in C programming manuals. You may very well start here.

[ScriptBasic]

Mike,

Is what we have now fixable of should we start over from scratch?

John

[Mike Lobanovsky]

John,

Just replace the destroy() function with the macro and off you go. But the user will be supposed to keep track of their strings' visibility scope and lifetime manually like a mature low-level C programmer, not a BASIC beginner.

To improve the situation, you will have to add some kind of a memory manager that would offload the task of track keeping and garbage collection from you, effectively turning C-Basic into a HLL.

C-Basic has stopped being a macro file the moment it hosted its first string function. I think at least some of them could also be turned into C multiline macros and thus be effectively inlined verbatim in their entirety at every spot they would occur in the script making it a little faster, albeit fatter. But the need to abstract from manual memory management will inevitably lead to adding code that shouldn't and/or couldn't be expressed with macros no matter what. Hence, no other way out but the BCX/UBX/MBC/FreeBASIC/MasmBasic way. (haven't I overlooked anyone else again?)

[cvirus]

It looks that the better aproach is to build a memory menager like Mike said, any idea on how to build one? Any links that could help out? Thanks.

[ScriptBasic]

My goal wasn't to make C BASIC another BASIC but help BASIC programmers learn C using BASIC like syntax as a mask.

[Mike Lobanovsky]

@cvirus:

First off, you'll have to cope with function locals. Those could be handled by a simple ring allocator very efficiently. BCX is an open-source GNU GPL project. If you subside to the GNU GPL with C BASIC, you can freely borrow the relevant code from BCX/UBX/MBC. You would also have at least two good potential advisors into the bargain, AIR and/or J.C.Fuller (of MBC and UBX, respectively), who could possibly help you out should anything go wrong.

By saying the BCX way, I don't mean literally becoming another BCX. I mean, building a HLL translator presupposes some standard solutions, just because if you wanna fly you're bound to have wings. Having a ring allocator doesn't mean literally taking after BCX. What you'll be able to offer as translations is what could make the real difference (or similarity, for that matter). BCX is built around functions -- try to build C BASIC around macros wherever possible, and that'll be your distinctive feature. You might even become a little faster than BCX that way and who would then care if your resultant binaries are just a little fatter?


@John:   (sorry for mis-spelling the project name)

There's nothing to prevent you from writing low-level C-like code (not inline C that's also possible!) directly in BCX bypassing its garbage collection facilities whenever you feel like it. But who would care to, given the advantages of automated GC if and when it's already built in? The projected C BASIC translator could offer just as much as well.

[jj2007]

C provides two ways to create a function local string:

1) directly on the function stack in the form of a fixed size character array, e.g.
char s[128] = "bla-bla";
in which case it needs no special freeing because it's going to be destroyed together with the function stack automatically on function return

Which is a pretty stupid use of the stack btw, because C will on each call to that function copy a global fixed size character array to the stack area. And in 99.9% of all cases, it will be read-only anyway, so you might as well use the global pointer directly, without the copy.

[Mike Lobanovsky]

This was just to exemplify that fixed size char or byte arrays on the function stack can be initialized with literal string values. They can also be initialized with string variables. Or usable as temporary buffers for various other purposes, they would often require prior initialization with zeros with the aid of a dedicated call to cdecl memset() or stdcall RtlZeroMemory() -- something that calloc() would offer out-of-the-box but using the process global heap.

So what?

I wasn't talking about efficiency here. I was talking about available memory storage areas and their pros and cons. And I was answering the question of a person who, for all I know, might be reading the words stack and heap for the first time in his life having been curtained off by beginner's BASIC that in fact knows, or lets its users know, nothing about the real basic notions like pointers, addresses or other memory-related stuff.

(wink-wink)

[ScriptBasic]

I feel the string funtionality in C BASIC should be approached the same way a C programmer would adding string support to their C code.

[Mike Lobanovsky]

John,

That would be yet another reason to try and re-implement the suggested string functions as macros (wherever possible, of course) for verbatim inlining in the resultant C-language output. A human C programmer would usually code buffer operations and associated memory allocation/deallocation in situ rather than resort to separate reusable but slower procedures like in automatic translation or interpretation.

C is essentially as low-level as the MASM macro processor with the only exception that it prefers to read and dump its variables from and to the memory rather than try and keep them in the CPU registers at all times, which would require meticulous hand crafting. That way it abstracts from the CPU particulars entirely but instead acquires the ability to improve suboptimal code pieces automatically at a higher typical code block level through its -O optimization options.