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: "Ed Falis" Subject: Re: Mixing Ada and C++. Is a good idea? Date: 1997/11/14 Message-ID: X-Deja-AN: 290093439 Sender: news@sd.aonix.com (USENET News Admin @flash) References: <345F7489.A10@si.ehu.es> X-Nntp-Posting-Host: 192.157.137.54 X-Mimeole: Produced By Microsoft MimeOLE V4.71.1712.3 Organization: Aonix, San Diego, CA, USA Newsgroups: comp.lang.ada Date: 1997-11-14T00:00:00+00:00 List-Id: I don't know what deployment environment we're talking about here, but I think Mr. Gwinn's interpretation of the situation is way out on the overly negative end of the spectrum. Since what I'm most familiar with is the win32 environment, I'll offer some counter-interpretations from that context. Joe Gwinn wrote in message ... >In article <345F7489.A10@si.ehu.es>, Arantza Diaz de Ilarraza > wrote: >>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. For the win32 world (at least with our compiler, ObjectAda), we use the standard operating system services of the win32 api to allocate memory. There is no conflict, provided that the Ada and C++ sides don't decide to explicitly deallocate each other's dynamically created objects. The MsDev debugger works just fine with mixed Ada, C++, assembly etc, because they all use the same debug symbol format. This is not to say that it supports special capabilities for threads (though a cross version integrated with Phar Lap ETS does), or that it necessarily represents array indexes the way an Ada programmer expects, but it remains usable and a good complement to the Ada debugger, which will only see the C++ code at the assembly level. > >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. In my opinion, it depends on the situation and on whether the functionality is naturally better supported by something as heavy as an additional process with DLL or shared memory based communication. > >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. In general, I agree: it's easier to mix Ada 95 with anything than Ada 83; it's easier to mix ANSI C with anything than C++. But the main problem area is sharing dispatching types across the language boundaries, which is probably not the best design approach to take, unless you want to step up to CORBA. >> 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. Ada 95 helps substantially in this regard relative to Ada 83, by providing standard package Interfaces.C and it child units. This leads to good uniformity with the basic C/C++ types, so that record representations corresponding to structs and so on can be laid out fairly easily. > >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. This strikes me as the court of last resort, when better techniques like using the standard definitions in the Interfaces packages are available. >So, the Ada (and C) must be *very* simple in this border region. Then how do you explain the successful use of large bindings like win32ada? >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). Sure, but this is not a language-mixing issue per se. > > >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. No argument here. > > > >> 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. > Too much to get into here, but tagged types were the solution adopted. > >> Must I import and export all methods, or can I export all then >> class from one side to another?. Currently GNAT supports inheritance across language boundaries, but it's (almost necessarily) messy. (We don't yet). So, for the gnat compiler, you could presumable import on a class basis; for our compiler on a method-by-method and data definition basis. > >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. There are an awful lot of existing bindings that provide counter-arguments to this statement, where data types associated with the binding are manipulated extensively on both sides of the binding. I will agree, though, when looking at dispatching types with compiler-specific hidden components, that there are complications that are better avoided. > >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 I think the "painfully simple" part is overstated, but agree heartily with the old high-cohesion, low-coupling philosophy. It's just not really a cross-language issue per se. - Ed Falis Aonix