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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,2e11aa5522d5cc28 X-Google-Attributes: gid103376,public From: gwinn@res.ray.com (Joe Gwinn) Subject: Re: Mixing Ada and C++. Is a good idea? Date: 1997/11/11 Message-ID: X-Deja-AN: 288751102 References: <345F7489.A10@si.ehu.es> Organization: Raytheon Electronic Systems Newsgroups: comp.lang.ada Date: 1997-11-11T00:00:00+00:00 List-Id: In article <345F7489.A10@si.ehu.es>, Arantza Diaz de Ilarraza wrote: > Hello > > First: Sorry because my English is very poor!! I am learning so be > patient please ;). Second: the problem. I wish make a program mixing C++ > libraries and Ada packages. The mixture will be total: the C++ side will > call some Ada functions and the Ada side will call some C++ methods. > Is this a good idea? Probably not. Both Ada and C++ have very definite ideas about how their runtime heaps should be organized, and it may prove difficult to keep them from killing each other. Nor will the debuggers work well, or at all. The devil is in the details. It may be better to have two worlds, one to a language, exchanging messages (perhaps in shared memory). Thus, each linked process image is pure, being of one language or the other, and each is master of its own private heap. It's lots easier to mix ANSI C with Ada95 (not Ada83) than C++ with anything, simply because C is much simpler than C++. Is C++ really necessary? For that matter, is Ada really necessary? Fewer languages will be much simpler. Greenhills has claimed for at least two years to be able to handle mixed-language developments, with Ada95 and C/C++ in hybrid processes; it works, but it isn't smooth. Rational only recently began to claim full support for mixed-language processes. I don't have any experience with GNAT Ada95 with Gnu C and I have heard no claims either way. > Can I share data structures between the two sides? Yes, but be *very* careful with data structures that are seen by both languages. Each language can generate data structures that cannot be directly expressed in the other. For data structures and/or messages that cross the border from Ada to C, in either direction, it is necessary to nail each and every bit down, so messages and/or data structures can be converted by a simple unchecked conversion involving the casting (unchecked conversion) of a pointer only. So, the Ada (and C) must be *very* simple in this border region. Even if the communications is Ada to Ada, if different linked images are communicating (via messages or shared data structures), it's necessary that nothing be left to the compiler's imagination. This is especially necessary if the communication code resides on different processors (such as 68040, 68060, PowerPC for today). Tick size beartrap: Where an Ada-coded module passes a buffer (specified by its address and size) to a C-coded module, and the C module causes data to be either read from or written to that user-supplied buffer, there is a potential beartrap. In Ada, all sizes are given in bits; while, in C, all sizes are in bytes. The classic bug is to forget, and ask the C to read data into a buffer sized in bits, which the C interprets as the length in bytes, returning eight times as much data as expected, clobbering all manner of unrelated but nearby data structures. It can take weeks to track the cause down. The hell of it is that the read itself works just fine, and something with no obvious connection to the read dies, sometime later, and for no obvious reason. In many realtime operating systems, the victim may be a different task than the culprit. All in all, a Very Bad Scene. A good policy is to use sizes in bits (not bytes) in the Ada world, and convert to bytes in the interface rroutines, so that mistakes will cause too little data to be transferred, a simpler and more localized bug to find and fix. > Another factor is that I am using object-oriented programming in two > sides. Beware variant records in OO. Ada83 variant records have the well-known property that if anything in any record in the variant set changes, everybody who uses any member of that set must recompile. In practice, in a project of any size, this means one recompiles the world just about every day. Variant records were an issue in the Ada95 language design deliberations. The issue was that variant records in effect inherit upwards, the exact opposite of what's required both for object-oriented code and for the decsription of messages as specializations of a universal message type. Because a major requirement for Ada95 was support of object-oriented designs, Ada95 changed how variant records work, so we may have a Ada83-Ada95 portability issue here. I don't recall if variant records themselves were changed, or a new variant of variant records was added. > Must I import and export all methods, or can I export all then > class from one side to another?. I'm not quite sure I understand the question, but I will say that the Ada methods will generally work only with Ada datastructures, and C++ methods only with C++ data structures. One could probably get cross access to work, but it would be difficult and the result fragile. As I said above, it's best to keep the Ada-C++ interface painfully simple, and to keep the two worlds separated, with clean interfaces. Good luck. Joe Gwinn