|
| From: | Brian Tiffin |
| Subject: | Re: [open-cobol-list] future Developments, Brain Storming |
| Date: | Fri, 15 Mar 2013 13:33:48 -0400 |
| User-agent: | Opera Mail/12.14 (Linux) |
Hi Brian Thanks for all your great feedback.Since all C is valid C++ code, it shouldn't be so hard to rework the build system to compile the presently generated C code as C++. I will need to read up on autotools a bit but if you want me crate a modified build system I can?
Yeah we can do that. One large hurdle is adding to the dependency chain. More target have gcc than g++ and then we get into the baggage that comes with STL or Boost etc. But yes, in theory this will not be an overly heinous thing to do, but it may not be overly practical from a cross platform point of view.
I don't know anything about the function ALL but I will read up on it and see if this is something I can tackle.
It'll be challenging.
I really like Ada but the one thing that was driven me from it to open Cobol is the compiler. It is about 400K lines of code. It's too much for me to handle. I will never understand it and that leaves me pretty much stuck with where Adacore wants to take the language. >10 years after most people moved to ARM for embedded design, Adacore is now working on a port. It's crazy that an embedded language can hardly be used with any embedded targets(as in no OS). They are moving to ARM now that their customer base is. If it was me, I would have done that 10 years ago so that I would have a larger customer base but any-who, you get the point. OC has a small compiler and is hackable. I think I should be able to use OC in most of the places that I wanted to use Ada and if I was backed into a corner I could probably do this autonomously.
I may pester the GNAT team again, see if OpenCOBOL wouldn't make a good reference implementation for the Ada B.4 (Interfacing with COBOL) specification appendix.
I have looked at the Vala sources. They intimated me a bit like GNAT. the source code seems to be about 100K lines. I would like to figure out what parts I could look at to see how vapigen works internally but it could take me some time.
It'll be challenging. :-)
I like FLTK. It uses a small subset of C++. It sounds like even many professional "day-coders" use a subset of C++. Do you think we could use a very small subset of C++ to implement the 2002 features?
I'll try and find the sources I used for an experimental FLTK linkage. I never published it, but it coincided with embedding the Falcon scripting engine. FLTK was on the list of potential GUI toolkits for Falcon, but GTK seems to have won out in the end.
Yes, we likely will use a subset of features when we add Object COBOL support. Plus Sergey has a pretty good idea with using C++ templates to alleviate some run-time edge case issues with the various COBOL datatypes. So, I don't want to close the door on OpenCOBOL generating C++, but I'd prefer it was a conditional, so we don't require all OpenCOBOL developers to have to buy into C++, and still provide a path for progress. C++ source won't be a drop-in-replacement, as Sergey mentioned, there are quite a few technical issues to worry about.
Just as an aside. LLVM OpenCOBOL works the beauty with clang. I haven't seen it fail yet. We have that base covered "for free".
-Patrick
Keep it up Patrick. These are good posts. Simon is setting up a pretty good foundation for the Community Edition fork on SourceForge, and I'd like to see that open up even more in the near future.
Cheers, Brian
| [Prev in Thread] | Current Thread | [Next in Thread] |