gnucobol-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [open-cobol-list] Representing C enumerations & other stuff


From: Jeffrey Chimene
Subject: Re: [open-cobol-list] Representing C enumerations & other stuff
Date: Tue, 05 Feb 2013 09:45:32 -0700
User-agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2

On 02/05/2013 08:03 AM, Patrick wrote:
> On 13-02-03 10:40 AM, vince wrote:
>> You wrote:
>>
>>> BTW I don't what to clutter everyone's inboxes with another post.... Is
>>> there any technical reason why cobc could not be written in open cobol?
>>> I don't have the time or skills right now but maybe one day I could help
>>> with this.
>> If you look at the code it is reasonably tight and OC does NOT generate code
>> anywhere close as it does make use of a lot of routines to handle tasks.
>>
>> This is fine for app code and is the model used in most if not all commercial
>> compilers eg, Microfocus, but is far too slow for use in the runtime code.
>>
>> I would be more interested in converting all generated code to C++ as a first
>> step to introducing OO coding abet in far future version.
>>
>>   
> Hi Vince
>
> So you've been coding in Cobol since before I was born and I haven't 
> really written anything yet. I am not second guessing you but I was 
> wondering about something. Right now, cobc looks to be about 25K lines 
> of C. A runtime should be very fast and yes, maybe deploying a runtime 
> built from open Cobol is not a good idea but do you have any guesses on 
> how much of the 25K lines is runtime?
>
> It looks like we have two developers Keisuke and Roger. If larger parts 
> of the code base were written in a language easier to read then C, we 
> might be able to get more people involved.

To me, the choice to translate COBOL to C is a pragmatic one, in that it
leverages the C compiler's ongoing ability to produce
platform-independent, highly optimized code. I use the term "on-going"
in the sense that it's far more likely that improvements will be made to
the GCC compiler (and, apparently, OC to Clang) than the COBOL translator.

Language bindings to scripting languages are a great way to reduce the
impedance mismatch between a target operating environment and a specific
project's goals. I'm not really interested in a Pascal binding to COBOL,
but that has more to do with data marshaling issues. It's certainly the
case that Pascal presents a far better environment for expressing
complex processing logic than COBOL.

I think Vince is on the right track when he posits that translating to
C++ is a better direction in the long run.
>
> I personally have trouble with C's type system. Once people start 
> defining their own types and using macros, it becomes pretty hard for me 
> to read it.
>
>
> Hi Everyone,
>
> To update the GTK thing, I am looking into writing a GTK binding built 
> on gobject introspection. Language bindings for Lua, Python, Pascal and 
> others are under 5K lines using this technique. I don't think I am a 
> very good C programmer but at under 5K lines I think it is within my 
> competence.
>
> -Pat
>
>
>
> ------------------------------------------------------------------------------
> Free Next-Gen Firewall Hardware Offer
> Buy your Sophos next-gen firewall before the end March 2013 
> and get the hardware for free! Learn more.
> http://p.sf.net/sfu/sophos-d2d-feb
> _______________________________________________
> open-cobol-list mailing list
> address@hidden
> https://lists.sourceforge.net/lists/listinfo/open-cobol-list



reply via email to

[Prev in Thread] Current Thread [Next in Thread]