From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,45afe5f0a76ee29c X-Google-Attributes: gid103376,public From: John Walker Subject: Re: Ada Foundation Classes Date: 1996/08/06 Message-ID: #1/1 X-Deja-AN: 172521134 distribution: world x-nntp-posting-host: jswalker.demon.co.uk references: <31FE15A6.53A@comm.hq.af.mil> <00001a73+0000309b@msn.com> organization: JSW Technology mime-version: 1.0 newsgroups: comp.lang.ada Date: 1996-08-06T00:00:00+00:00 List-Id: In article <31FF7844.2C4E@comm.hq.af.mil>, Chad Bremmon writes >KenIf we were only concerned with making applications >work on the Microsoft platform, a binding to the >currently existing MFCs would be the answer. When >I do that, however, I blow portability out of the >water. If we can get non OS specific at some >level. It may require 2 api's: One for the >standard interface and one beneath the standard >interface for the non-standard OS interface. So >what I'm saying is we're not re-inventing the >wheel, just making it turn. . .in a standard way. > I don't think you should consider the MFCs as a single lump. I would divide them into two, and possibly three, classifications. First there are classes which support data structures such as lists and dynamic arrays. These do not sit comfortably with Ada because of the different semantics for pointers and arrays and because some of these classes are offered as templates. However a standard approach to the support of similar structures in Ada would be useful with an Ada interface and a portable Ada implementation. Second there are the classes which encapsulate the Windows API. Both the MFC interface and its implementation seem to be a moving target. I am building a technology to generate and maintain an Ada binding to MFC. I think this is the only viable way at present to use these classes in Ada. I don't know how feasible it would be to map the MFC interface to a different OS API. However it didn't take me long to decide that re- implementing the MFC classes for Windows in Ada would be a maintenance nightmare and that a binding offered the only viable solution. Thirdly there are a few classes like CObject and CArchive which might be useful in Ada. An Ada solution could adopt an Ada interface which is compatible with MFC so that MFC would provide the implementation for the Microsoft platform. Alternatively the same functionality could be provided by a different Ada interface and implementation as for the data structures. -- John Walker Email: john@jswalker.demon.co.uk Tel: +44(1734)403749