Extension Header Files.
I am looking for the up to date versions of the extension header files. As far as I know there are two of them - reb-c.h and reb-x.h.
posted by: Tyrone 26-Jun-2015/18:40:37-7:00
Hi @Tyrone ...
No one's chimed in yet, so I'll post. Yet among things I don't know too much about in practice it's old Rebol extension techniques. (Despite recently delving into a lot of the C sources, I only picked up the project in the post-Rebol3 era, and I've stayed away from the GUI as much as I can so far.)
But here is a version of reb-c.h you might want to look up from something called "Coherence One". You can read up on what that is, and it's not a completed effort. But the annotations in the comments might at least shed some light into what reb-c.h is and where I'm taking that, because I am wordy:
https://github.com/metaeducation/ren-c/blob/coherence-one/src/include/reb-c.h
(It's not terribly relevant to extensions, other than that Rebol's baseline definitions do contaminate the global namespace in C programs.)
I don't know of reb-x.h and Google doesn't bring it up. But I've actually mentally "marked most of the extension code I've seen for death, because what I've seen looks like an error on the side of duplicating type hierarchies and black-boxing things during the closed source era. @ShixinZeng seemed to agree it probably needed trimming out.
(You can take anything like the structure definition for what's in a REBVAL and ask "just how much actual gain is there in creating another API that could survive a change in what specific integer constant is used to indicate a value cell is an INTEGER! vs a STRING!" Now we have `#define REB_INTEGER 1` and `#define REB_HMM_INTEGER_MAY_CHANGE_SOMEDAY 42`. There's *some* value, but a diminishing return when Rebol systems are focused on compiling together in a hardened single binary...if Rebol changes, you probably want to recompile that one binary.
(And the separation seemed motivated largely by the thought that Rebol itself couldn't be open sourced, as opposed to the idea that there was great intrinsic value to writing every C API twice...just one with newer weirder names for constants and structs that is missing a lot of stuff.)
So you might take a look at Ren/C++ and (forthcoming) Ren/C. For instance, here is an example of using Rebol's PARSE from C++:
https://github.com/metaeducation/ren-cpp/blob/develop/examples/parse-1.cpp
Here is a slightly different take with the same problem:
https://github.com/metaeducation/ren-cpp/blob/develop/examples/parse-2.cpp
That's the C++ version, and Ren/C will just be more low-level and easy to make a mistake with. One kind of grumbly thing about C is that the lack of namespaces means things do start polluting a bit... so Ren/C might have to be wrapped or otherwise worked around to keep it from saturating the identifier namespace, for some applications.
Another thing to consider in extension techniques is what's being done with ROUTINE! and STRUCT!, and here are some notes on that:
https://github.com/metaeducation/ren-c/blob/atronix-split/src/core/t-routine.c#L27
I probably didn't answer your question, but maybe something in there was useful to know anyway. :-)
posted by: Fork 29-Jun-2015/14:24:05-7:00
|