You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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.)
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.
Activity
EchoPouet commentedon Dec 2, 2021
Do you mean C++ right ? Because the readme indicates C support.
treeform commentedon Dec 2, 2021
We are about 99% on the C support. We still have like 1% more to do.
EchoPouet commentedon Dec 3, 2021
For the C++ support it will be a simple formality ?
treeform commentedon Dec 3, 2021
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 commentedon Dec 4, 2021
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 commentedon Aug 9, 2022
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.cstringis called ininternal.nim). What is the lifetime of this memory? Isn't the parentstringvulnerable to garbage collection at Nim's will, and doesn't this affect thecstring's storage? Isn't it necessary to export memory management procs to accompany it (somewhat likesystem/allocCStringArray)?(I also noticed when experimenting that
GC_refandGC_unrefdon't seem to work forstringunder--gc:orc, but seem to under--gc:refcwhich genny doesn't support.)treeform commentedon Aug 18, 2022
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.
treeform commentedon May 25, 2026
I have fixed the last remaining issue with the returning string support and who owns the memory. I think C backend is now well tested. #66