On Sun, Dec 22, 2013 at 10:36:56AM -0800, Chris Brannon wrote: > Adam Thompson <[email protected]> writes: > > > "SpiderMonkey now provides a fully C++ interface, > > so embedders relying on embeddability in C projects will have to convert to > > C++, or implement their own adapter code." > > Thank you ever so much for doing the research.
That's ok, I've been thinking of looking at this for a while, though it's not until now that I've had the time. > Years ago, we batted around the idea of rewriting edbrowse in C++. Yeah, I noticed it in the todo. > Those string objects would sure be nice, and after all, edbrowse is very > string-intensive. We also use lists in some places, and we could use > STL's list container instead. But it never happened. C++ is a > complicated beast. The people who work on edbrowse are more comfortable > with C. I used to be decent with C++, but I've managed to forget most > of what I knew. So I'm not chomping at the bit to do this. I also prefer working in C, but have been forced to become fairly decent in c++ in order to use certain c++-only libraries. Honestly, although the string objects would be nice in terms of moving code out of edbrowse, and the same for stl lists, personally I've never really minded handling this kind of thing in C. Also as you said c++ brings its own set of complications. > I wonder how difficult the adapter code will be? I assume it'll just be > tedious. I've got an idea how to do it whilst hopefully minimising the changes. I think the main files to alter are jsdom.c and jsloc.c. I'd then provide a jsdom.h and jsloc.h (or something) which is included in the rest of the program. This, with a few more changes, should *hopefully* allow the c++ code to be isolated to these 2 files. In the makefile, these would then be built with the c++ compiler, with the rest of the project still built using the c compiler. This assumes of course that there aren't additional functions in other files which require bits of the javascript library. If so, they'd have to be added to the adapter api. This approach'd also have the nice side-effect that, if in the future we decide to abandon SpiderMonkey altogether, we'd only have to change the implementation of the api exposed to edbrowse. At least that's the theory. Does this sound sensible? Anything I've missed? Cheers, Adam. _______________________________________________ Edbrowse-dev mailing list [email protected] http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev
