Embedded Null characters and std::string

[SamuraiCrow]

Yes, 
I am working on the next version 1.8. And I think it's better to change this for yab 2.0. 

@SamuraiCrow

Then it could be a complete rewrite in c ++ so that yab can be free from the original yabasic. Also, yab works with gcc 8 or higher, so we no longer use gcc2. But you can also make a new development and name it differently. 
There is no problem.
 We can have two basic ones. I like your enthusiasm for making changes to this yab and if I understand correctly there will be little left of the original code. Only the command syntax remains the same.

I was planning on making this backward compatible with GCC 2 with optional wrappers for GCC 8 features (such as unordered_map).  My reason for this is to be able to maintain some degree of detachment between the runtimes and the transpiler.  In this way someone can try to add some cross compatibility to other platforms and therefore add to the source codes compatible with ours.  Haiku will still be the basis for it but I see Haiku as an upgrade path for other OS users from the likes of AmigaOS 4 and AROS.  They have GCC8 compilers like Haiku but their operating systems are single-threaded multitaskers and are dreadfully obsolete as a result.  (They don't have useful multicore support.)

Jan__64 has seid that he comes back if Haiku has reached R1 Status and work again on it. I don't think so. He has say a long time ago, that he think to rewrite yab with lua.

I think your way can be the better way. Did you have Version for testing?

I've worked with another project on my Amiga-like systems called Hollywood that used Lua as the basis for its runtime engine.  Lua is not consistent internally between versions and if LuaJIT is the best anyone can hope for for a compilation strategy then forget it.  I want to make my Yab2Cpp engine statically transpile using GCC as a backend.  I know how to do it but just haven't done it yet.

There are a few commands that don't support static compilation that will have to be dropped from my version:  Eval, Eval$ and Bind.  There may be one more but I hope they are all rare.

So far I'm just taking notes in my notebook about implementation and saw an opportunity to solve an old collection of bugs using GCC string routines and the C++ Standard Template Library.  Replacing all of the linked list implementations with std::list would make the code more maintainable as well, not to mention replacing all of the linear searches with hashes.

@bbjimmy
Thanks for directing me to the more up-to-date repository.  I'll switch to it and continue my observations and changes against the current fork.