C++ FBSTRING implementation

[segin]

I am working on a C++ implementation of FreeBASIC's first class String type. The FreeBASIC compiler, when using OOP features, mangles symbols to the Itanium C++ ABI, which is the same C++ ABI used by gcc 3.4 and later (on all architectures, not just Itanium), as well as Intel C++ Compiler on Linux (same as gcc, but only the Linux version). The FreeBASIC compiler can, then, compile FreeBASIC classes that can be directly used from C++ code compiled by gcc, or icc Linux, in the same way C libraries can be used. With some work, this can probably also be extended to Java code compiled by the GNU Compiler for Java.

FreeBASIC declares it's String class as an "FBSTRING" to C++ symbols. As such, I intend to write a first-class implementation of the FBSTRING class in C++ that provides an alternative to std::string, providing direct conversion from FBSTRING to std::string and vice-versa, and supporting as many of std::strings methods as feasibly possible. The intention is to make writing class libraries in C++ that can be directly used from FreeBASIC easier, first by providing a class type that provides simple conversion to and from std::string, and secondly by providing a full string type, providing most, if not all features of std::string, to facilitate manipulating the FreeBASIC strings directly without forcing a conversion to std::string to manipulate and process the contents of FBSTRINGs.

While FBSTRING is defined in rtlib (which is written in C) as a struct, in C++, a class is essentially a struct with magically included functions that are called members. This should match the mangled symbols from the FreeBASIC compiler.

I will be hosting my source in my segin-utils SVN repository, at http://code.google.com/p/segin-utils/so ... /fbstring/. If you can write decent C++ with a good grasp of OOP concepts, I would appreciate your help. You will also need a good understanding of classical C memory management, as an independent string type for C++, we will be preforming our own low-level management of string memory allocation..

[dani.user]

Sorry if this doesn't sound to optimistic, but someone who is willing to mix C++ and FB at such a level is highly likely to just use C++ and drop FB, at least from an OOP standpoint.

[marcov]

. With some work, this can probably also be extended to Java code compiled by the GNU Compiler for Java.

(one of the problems for that will probably be BY REF parameters of valuetypes )

[segin]

. With some work, this can probably also be extended to Java code compiled by the GNU Compiler for Java.

(one of the problems for that will probably be BY REF parameters of valuetypes )

This is mentioned mostly as a possibility, since gcj compiles to the same ABI as the g++, and allows intermixing by virtue of the Compiled Native Interface.

However, the focus is intermixing FreeBASIC and C++,

Sorry if this doesn't sound to optimistic, but someone who is willing to mix C++ and FB at such a level is highly likely to just use C++ and drop FB, at least from an OOP standpoint.

True, but this would allow for easier wrappers around C++ libraries, which almost never can be used directly due to differences between C++ and FreeBASIC, especially the inability to initialize and use C++ objects and types.

This could also be used to write simple class libraries in FreeBASIC and use them from C++.

Finally, whether or not this is something that will be of wide use, is not really relevant. Mostly, I'm trying to see if it even can be done, and then we can start worrying about the practicality of things. Oh, and I'm interested in doing something in the area of C++ <-> FreeBASIC integration. The idea intrigues me.

[segin]

yetisoft pointed me to an implementation of the FBSTRING struct in C++ that would make a good starting point for this project.

Check around for his 'tinybasic' project, it's on the forums somewhere.

Specifically, this is the implementation in question: http://pastebin.com/raw.php?i=j5d3bHp7

[TeeEmCee]

Ah, I did the same thing a year or two ago (and also for FB arrays). However, instead of reimplementing the portion of rtlib that deals with strings, my class is mostly just a wrapper for the rtlib. That should be nearly as efficient (though certain methods -- in particular string length -- would be much more efficient if reimplemented).

I haven't inspected your implementation in detail (or looked at the rtlib's string handling for a while), but I'm concerned that you completely ignore the temporary descriptor flag. How can you to support passing temporary strings to a C++ function, or returning a string from C++ function without memory leaks without considering that flag?

Also, allocating a minimum of 4kb per string seems really excessive to me. I think you're really underestimating the efficiency of a modern memory manager, and how little time it takes to move a few bytes around when resizing.

Anyway, my implementation wasn't complete. It really needs more sophisticated handling of temporary descriptors: in particular, the ret() method sucks. Also, I wanted to add classes for fixed length and unicode strings.

I think that if we work together, we can write some classes that do it all :)

My code is here (used to have this in an svn repository, but it was corrupted):
http://tmc.castleparadox.com/freebasic/fbc++_string.h