Add C Support.

[treeform]

C Support is nearly there as python has to talk though a C like interface.

[EchoPouet]

Do you mean C++ right ? Because the readme indicates C support.

[treeform]

We are about 99% on the C support. We still have like 1% more to do.

[EchoPouet]

For the C++ support it will be a simple formality ?

[treeform]

Well C++ can use C APIs yes, but I would not call them C++ APIs. For C++ APIs I expect name spaces, classes, operator overloading, polymorphism, exception throwing and maybe RAII. C++ should be treated as a different language. More like Nim or Java.

[EchoPouet]

I totally agree with you. I hope your project will motivate developers to use Nim to create powerful libraries for other languages. And finally enlarge the community.

[jdf-id-au]

Thank you again for your incredible contributions.

This is probably a naïve question. A proc returning a string gives a char* return type in the generated C header (after .cstring is called in internal.nim). What is the lifetime of this memory? Isn't the parent string vulnerable to garbage collection at Nim's will, and doesn't this affect the cstring's storage? Isn't it necessary to export memory management procs to accompany it (somewhat like system/allocCStringArray)?

(I also noticed when experimenting that GC_ref and GC_unref don't seem to work for string under --gc:orc, but seem to under --gc:refc which genny doesn't support.)

[treeform]

We are aware of the problem with returning strings. We will probably implement some sort of buffer type or make ref/unref work with strings.

For now it happens to work because pixie is single threaded, returning the string still keeps the data around for C to deal with. But yes as soon as you make another call the data can get clobbered.

We will fix this.