* Re: Mixing Ada and C++. Is a good idea?
@ 1997-11-20 0:00 Robert Dewar
1997-11-21 0:00 ` Larry Kilgallen
1997-11-24 0:00 ` Anonymous
0 siblings, 2 replies; 16+ messages in thread
From: Robert Dewar @ 1997-11-20 0:00 UTC (permalink / raw)
Joe Gwinn says
<<That's what all language folk say, for all languages.
Details aside, simpler is usually better, for all languages. I don't
doubt that some probelms have been solved, but the history of
inter-language bindings isn't exactly smooth. Pardon me if I don't
believe that Ada95 is any different in this.
Joe Gwinn
>>
No, that's plain wrong. I can only guess it comes from a lack of familiarity
with Ada 95. In fact Ada 95 is quite different from other languages in this
respect, I have no idea what silly things people do or do not say about
languages, but Ada 95 is quite unique among standardized languages in
paying considerable attention to providing high level language features
at an appropriate level of abstraction for interfacing to C, Fortran,
and COBOL in the standard.
I am almost certain that Joe is simply unfamiliar with these features, and
we can pardon him for not knowing Ada 95, but I don't think we can pardon
him for making plainly incorrect statements based on this ignorance :-)
For example, the declaration for a record type X
pragma Convention (C, X);
that says "lay this record out exactly the way C would lay it out", has no
analog in any other standardized language (actually I don't know of *any*
language in which it has an anolog, but surely among the hundreds of
non-standard languages there must be similar examples).
Joe, I really think you should take the time to read chapter 13 and annex B
of the reference manual to see if your statement seems supportable *to you*
once you know the facts.
I am perfectly sympathetic to your experiences of difficulties in this area,
they are very common. I am even sympathetic to your induction that Ada must
be no different, but unfortunately, Ada is the exception that proves the
rule here (yes, yes, I know that is not what this phrase means :-)
Once on comp.lang.cobol, someone asked how to portably interface between
COBOL and C, and basically the answer, from many contributors, was that
there was no way.
I pointed out that there was a way, although a vey peculiar one. By writing
glue code in Ada 95, it is possible to write a tri-lingual program containing
Ada, COBOL, and C units, since the interface between Ada and COBOL is
well defined and the interface between Ada and C is well defined. For instance
here is the code to convert a recvord from the storage format used by C to
the storage format used by COBOL.
type x is record ...
...
end record;
type y is new x;
pragma Convention (C, X);
pragma COnvention (COBOL, Y);
VX : X;
VY : Y;
VX := X (VY); -- convert from COBOL format to C format
Robert Dewar
Ada Core Technologies
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Mixing Ada and C++. Is a good idea? 1997-11-20 0:00 Mixing Ada and C++. Is a good idea? Robert Dewar @ 1997-11-21 0:00 ` Larry Kilgallen 1997-11-21 0:00 ` Robert Dewar 1997-11-24 0:00 ` Anonymous 1 sibling, 1 reply; 16+ messages in thread From: Larry Kilgallen @ 1997-11-21 0:00 UTC (permalink / raw) In article <dewar.880074788@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes: > > Joe Gwinn says > > <<That's what all language folk say, for all languages. > > Details aside, simpler is usually better, for all languages. I don't > doubt that some probelms have been solved, but the history of > inter-language bindings isn't exactly smooth. Pardon me if I don't > believe that Ada95 is any different in this. > > Joe Gwinn >>> > > > No, that's plain wrong. I can only guess it comes from a lack of familiarity > with Ada 95. In fact Ada 95 is quite different from other languages in this > respect, I have no idea what silly things people do or do not say about > languages, but Ada 95 is quite unique among standardized languages in > paying considerable attention to providing high level language features > at an appropriate level of abstraction for interfacing to C, Fortran, > and COBOL in the standard. Although that feature of Ada 95 may be helpful, it is a shame it is required, rather than having compilers for all languages interface with each other automatically on a given platform. That does require that devotees of all languages agree that there might be a place for other languages in the world, and so far even Ada does not have that attribute across all its fans. Larry Kilgallen ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Mixing Ada and C++. Is a good idea? 1997-11-21 0:00 ` Larry Kilgallen @ 1997-11-21 0:00 ` Robert Dewar 0 siblings, 0 replies; 16+ messages in thread From: Robert Dewar @ 1997-11-21 0:00 UTC (permalink / raw) Larry says <<Although that feature of Ada 95 may be helpful, it is a shame it is required, rather than having compilers for all languages interface with each other automatically on a given platform. That does require that devotees of all languages agree that there might be a place for other languages in the world, and so far even Ada does not have that attribute across all its fans. >> First, one cannot speak for "Ada and all its fans" at any time. Given the many ludicrous postings to CLA, one could never expect the supposed fans of Ada to agree unanimously on anything sensible :-) However, it clearly is the case that Ada 95 very much takes the position that other languages have an important place. A great deal of effort went into refining the already superior features of Ada 83 in this area. At no time did any of those involved give any other signal than that this was an extremely important part of the language. So I think you can definitely say that Ada 95 and its knowledgable advocates absolutely agree that there are places for other languages, most notably in regard to reuse of existing libraries. As to Larry's "shame it is required", you cannot possibly expect "automatic" interface. In fact it is this completely ill-thought out wish that leads to some of the weaknesses in the Ada 83 model. These are weaknesses of under-specification *at the language level*. The thought in Ada 83 was that if you provide pragma Import (C, xxx), then procedure xxx will indeed automatically interface with C on that platform. But that is sloppy thinking. The trouble is that the parameter passing model is different at the semantic level between C and Ada. This means that a correspondence has to be established which involves choices that show up at a high level of abstraction in the user code, and cannot be buried in the code generation. As an example, if we have a C formal parameter that is of a struct type (NOT a pointer to struct), then how should it be modeled on the Ada side. There are two possibilities: As a record type As a pointer to record type Ada 83 had nothing to say in this area, Ada 95 chooses the pointer approach (though this particular case is a tricky one, and the ARA agreed on the additional pragma C_Pass_By_Copy to resolve the trickiness. The fact that the ARA considers the specification of the mapping in this case to be of sufficient importance to warrant inter-vendor agreement on an appropriate pragma to resolve a remaining insufficiently specified point should of itself be an indication of the importance attached to this issue). Actually this seems to be the only case not 100% handled in C, Fortran, and COBOL interface protocols in Ada 95 (and with the new pragma, which is implemented by all Ada 95 vendors, or should be!, that little hole is plugged). Now C++ and Java interface issues are not yet resolved (a reflection of the fact that C++ was not standardized, and Java did not exist, at the time of the Ada 95 design completion), but work proceeds on to work out the best possible common interface for Ada 95 (e.g. at Tri-Ada, Intermetrics and Ada Core Technologies agreed to work together on trying to achieve maximum practical commonality in interface to Java). There simply is no such focussed concern on this issue when it comes to other languages. If you want to level a charge against fans of a language of ignoring other languages, that charge lies much more accurately when applied to other languages than Ada 95! Robert Dewar Ada Core Technologies ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Mixing Ada and C++. Is a good idea? 1997-11-20 0:00 Mixing Ada and C++. Is a good idea? Robert Dewar 1997-11-21 0:00 ` Larry Kilgallen @ 1997-11-24 0:00 ` Anonymous 1 sibling, 0 replies; 16+ messages in thread From: Anonymous @ 1997-11-24 0:00 UTC (permalink / raw) On 20 Nov 1997 20:22:02 -0500, dewar@merv.cs.nyu.edu (Robert Dewar) wrote: > > Joe Gwinn says > > <<That's what all language folk say, for all languages. > > Details aside, simpler is usually better, for all languages. I don't > doubt that some probelms have been solved, but the history of > inter-language bindings isn't exactly smooth. Pardon me if I don't > believe that Ada95 is any different in this. > > Joe Gwinn > >> > > > No, that's plain wrong. Sorry, Robert, but we can't call another's beliefs "wrong." Joe can believe whatever he wants, no matter how contrary to fact it may be. Jeff Carter PGP:1024/440FBE21 My real e-mail address: ( carter @ innocon . com ) "Son of a window-dresser." Monty Python & the Holy Grail Posted with Spam Hater - see http://www.compulink.co.uk/~net-services/spam/ ^ permalink raw reply [flat|nested] 16+ messages in thread
* Mixing Ada and C++. Is a good idea? @ 1997-11-04 0:00 Arantza Diaz de Ilarraza 1997-11-11 0:00 ` Joe Gwinn 0 siblings, 1 reply; 16+ messages in thread From: Arantza Diaz de Ilarraza @ 1997-11-04 0:00 UTC (permalink / raw) 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 a good idea? Can I share data structures between then two sides? Another factor is that I am using object-oriented programation in two sides. I must import and export all methods or can I export all then class from one side to another?. Thank for the response. Aitor Maritxalar University of the Basque Country ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Mixing Ada and C++. Is a good idea? 1997-11-04 0:00 Arantza Diaz de Ilarraza @ 1997-11-11 0:00 ` Joe Gwinn 1997-11-12 0:00 ` Robert Dewar ` (2 more replies) 0 siblings, 3 replies; 16+ messages in thread From: Joe Gwinn @ 1997-11-11 0:00 UTC (permalink / raw) In article <345F7489.A10@si.ehu.es>, Arantza Diaz de Ilarraza <jipdisaa@si.ehu.es> 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Mixing Ada and C++. Is a good idea? 1997-11-11 0:00 ` Joe Gwinn @ 1997-11-12 0:00 ` Robert Dewar 1997-11-14 0:00 ` Ed Falis 1997-11-15 0:00 ` Matthew Heaney 2 siblings, 0 replies; 16+ messages in thread From: Robert Dewar @ 1997-11-12 0:00 UTC (permalink / raw) Joe says <<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.>> Robert replies This is a highly implementation dependent issue. GNAT alone among current Ada 95 compilers goes to a great deal of effort to allow the possibility of direct interface to C++. In particular, GNAT allows for specifying the format used for tagged types using a runtime library procedure. This procedure can be specialized so that the format used for GNAT tagged types is *absolutely identical* to the format used for classes in C++. If this specialization is done, theb (classes/tagged types) are fully interfacable, for example, a C class can be imported into Ada, primitive opertoins (methods) added to extend the type on the Ada side, and the extended type used directly in the original C code. So far we have demonsrated interopability at this level using g++ and using Delta C++ on SGI Irix. The latter capability is a key part of the technology made available in the GNAT-based Ada product from SGI, which includes bindings to their C++ graphics libraries that make use of this interfacing capability. As for problems with organization of "run-time heaps", I don't see any problems here, at least not for a compiler like GNAT, which rigorously adheres to the ABI for the target machine. Robert Dewar Ada Core Technologies ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Mixing Ada and C++. Is a good idea? 1997-11-11 0:00 ` Joe Gwinn 1997-11-12 0:00 ` Robert Dewar @ 1997-11-14 0:00 ` Ed Falis 1997-11-14 0:00 ` Joe Gwinn 1997-11-15 0:00 ` Matthew Heaney 2 siblings, 1 reply; 16+ messages in thread From: Ed Falis @ 1997-11-14 0:00 UTC (permalink / raw) 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 ><jipdisaa@si.ehu.es> 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Mixing Ada and C++. Is a good idea? 1997-11-14 0:00 ` Ed Falis @ 1997-11-14 0:00 ` Joe Gwinn 1997-11-14 0:00 ` Robert Dewar 1997-11-14 0:00 ` Robert Dewar 0 siblings, 2 replies; 16+ messages in thread From: Joe Gwinn @ 1997-11-14 0:00 UTC (permalink / raw) In article <EJnFDo.68y@sd.aonix.com>, "Ed Falis" <falis@ma.aonix.com> wrote: > 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. Some call it experience. I have worked in many environments and languages, some better than others, and have over the years become enamoured of simplicity. > Since what I'm most familiar with is the win32 environment, I'll offer some > counter-interpretations from that context. OK. A datapoint. > Joe Gwinn wrote in message ... > >In article <345F7489.A10@si.ehu.es>, Arantza Diaz de Ilarraza > ><jipdisaa@si.ehu.es> 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. No performance and/or realtime issues were raised by the questioner, who appeared to be more concerned with getting the code written and working, so it isn't obvious that an added process is too heavy in this case. My advice was therefore directed towards designing as much complexity as possible out, right from the start. > >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. As I said elsewhere, it's not really a good idea to attempt cross dispatch of methods, unless you wish to learn a great great deal about how both languages and langauge runtime systems work. This may not be what the questioner came for. Almost anything would be less painful than 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 its 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. Sounds like a good idea to me, if it's comprehensive enough. > >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. See above. I guess my experience over many languages is that interfaces between languages are best kept simple because the programming models of those languages are always somewhat or even radically different. Something always manages to bite you. > Then how do you explain the successful use of large bindings like win32ada? I don't think the questioner has available the resources that were applied to produce the win32ada binding, so the existence of such a binding gives no information on how difficult an individual or small team will find it to bind unrelated languages, especially ones as complex as Ada95 and C++. > >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. True enough, but a common enough problem to be worth the warning the questioner was clearly asking for, and not something would guess from the language manuals. > >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. Yes, and that too is well worth the warning. When I said you could waste project weeks on this, I wasn't talking about something I read about somewhere. The root cause was only discovered by assembly-level debugging of generated code after the development team had stalled, their fancy source-level debuggers having proved useless. > >> Another factor is that I am using object-oriented programming on > >> both 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. OK. I do recall that. I did see people get terribly tangled up with varient records, so it was worth a warning, especially in view of the expressed desire to use OO. > >> 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, unless one can make use of an existing binding, typically produced at great expense in blood and treasure, it's best to keep the two worlds apart to the extent possible within the needs of the project at hand. Why bite such a thing off if you don't have to? > >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. > > 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. The questione has some problem he wants to solve using Ada and C++, but he does not appear to wish to become a languages guru. Thus, the advice to keep it simple, unless there is a compelling reason to do otherwise. He appears to be more interested in the house than the hammer and saw used to build the house. Joe Gwinn ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Mixing Ada and C++. Is a good idea? 1997-11-14 0:00 ` Joe Gwinn @ 1997-11-14 0:00 ` Robert Dewar 1997-11-14 0:00 ` Robert Dewar 1 sibling, 0 replies; 16+ messages in thread From: Robert Dewar @ 1997-11-14 0:00 UTC (permalink / raw) Joe said <<See above. I guess my experience over many languages is that interfaces between languages are best kept simple because the programming models of those languages are always somewhat or even radically different. Something always manages to bite you. >> It begins to be clear that Joe is offering general advice across all languages, rather than specific advice for Ada 95. In that context, his otherwise surprising advice is not at all surprising, because it is most certainly true that for other languages, his advice is appropriate. I would guess that Joe has not used pragma Convention and the other important features of Ada 95, and does not appreciate the extent to which this problem has been successfully solved in Ada 95. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Mixing Ada and C++. Is a good idea? 1997-11-14 0:00 ` Joe Gwinn 1997-11-14 0:00 ` Robert Dewar @ 1997-11-14 0:00 ` Robert Dewar 1997-11-20 0:00 ` Joe Gwinn 1 sibling, 1 reply; 16+ messages in thread From: Robert Dewar @ 1997-11-14 0:00 UTC (permalink / raw) <<Yes, and that too is well worth the warning. When I said you could waste project weeks on this, I wasn't talking about something I read about somewhere. The root cause was only discovered by assembly-level debugging of generated code after the development team had stalled, their fancy source-level debuggers having proved useless. >> Debuggers are a poor substitute for knowing the languages that you work with properly. Sure I can see how poorly trained programmers could be confused about the semantics of sizeof and 'Size, but this is the kind of error that good programmers avoid in the first place. How such an error could take weeks to find is beyond me. But I guess people can be arbitrarily non-productive when they get dragged into the debugger mire. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Mixing Ada and C++. Is a good idea? 1997-11-14 0:00 ` Robert Dewar @ 1997-11-20 0:00 ` Joe Gwinn 0 siblings, 0 replies; 16+ messages in thread From: Joe Gwinn @ 1997-11-20 0:00 UTC (permalink / raw) In article <dewar.879560344@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote: > <<Yes, and that too is well worth the warning. When I said you could waste > project weeks on this, I wasn't talking about something I read about > somewhere. The root cause was only discovered by assembly-level debugging > of generated code after the development team had stalled, their fancy > source-level debuggers having proved useless. > >> > > Debuggers are a poor substitute for knowing the languages that you work > with properly. Sure, I can see how poorly trained programmers could be > confused about the semantics of sizeof and 'Size, but this is the kind > of error that good programmers avoid in the first place. How such an > error could take weeks to find is beyond me. But I guess people can be > arbitrarily non-productive when they get dragged into the debugger mire. Well, we don't usually compiler experts for plow-the-fields coding, and it's an easy mistake to make, especially if one believes that Ada's error checking will catch all such problems, especially in a large-scale project. No matter how careful we are, it always comes down to debugging at midnight. We wish it weren't so, but it is so, has always been so, and probably will always be so. My gripe is with programmers so ill trained that they cannot debug at the assembly level, when necessary. Nobody claimed it was pretty. Joe Gwinn ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Mixing Ada and C++. Is a good idea? 1997-11-11 0:00 ` Joe Gwinn 1997-11-12 0:00 ` Robert Dewar 1997-11-14 0:00 ` Ed Falis @ 1997-11-15 0:00 ` Matthew Heaney 1997-11-20 0:00 ` Joe Gwinn 2 siblings, 1 reply; 16+ messages in thread From: Matthew Heaney @ 1997-11-15 0:00 UTC (permalink / raw) In article <gwinn-1111972003010001@dh5055060.res.ray.com>, gwinn@res.ray.com (Joe Gwinn) wrote: >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. If you're recompiling the world every day, then something is wrong with the design of the application, not with the language. This phenomenon often occurs when a "common types" package is being used, that contains a lot of low-cohesion type declarations that everyone with's. Add another type, and everyone who touches that package needs to be recompiled. You need to break the single, large, low-cohesion package up into several smaller packages, that each contains a set a high-cohesion types. That way, when you add another type, only that corner of the application that depends on that specific package needs to be recompiled. If you're doing a message passaging (perhaps the common types package declares a variant record containing all message types), then use the streams facility, so a package only depends on the predefined streams packages. You might even consider deriving message types from a Root_Message tagged type, so that message tags will be determined by the compiler. Better still is to use the distributed systems annex. -------------------------------------------------------------------- Matthew Heaney Software Development Consultant <mailto:matthew_heaney@acm.org> (818) 985-1271 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Mixing Ada and C++. Is a good idea? 1997-11-15 0:00 ` Matthew Heaney @ 1997-11-20 0:00 ` Joe Gwinn 1997-11-21 0:00 ` Robert Dewar 0 siblings, 1 reply; 16+ messages in thread From: Joe Gwinn @ 1997-11-20 0:00 UTC (permalink / raw) In article <mheaney-ya023680001511971659520001@news.ni.net>, mheaney@ni.net (Matthew Heaney) wrote: > In article <gwinn-1111972003010001@dh5055060.res.ray.com>, > gwinn@res.ray.com (Joe Gwinn) wrote: > > >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. > > If you're recompiling the world every day, then something is wrong with the > design of the application, not with the language. > > This phenomenon often occurs when a "common types" package is being used, > that contains a lot of low-cohesion type declarations that everyone with's. > Add another type, and everyone who touches that package needs to be > recompiled. You need to break the single, large, low-cohesion package up > into several smaller packages, that each contains a set a high-cohesion > types. That way, when you add another type, only that corner of the > application that depends on that specific package needs to be recompiled. It was a nice theory, one that we never did get to work in a project of any size, because the inherent cohesiveness of the variables was not all that high. This has been true in all projects past some critical size, regardless of language, from the days of assembly on to the present. Having never gotten such a thing to work in the past, in any language, I have simply given up on the approach. Another nice theory. > If you're doing a message passaging (perhaps the common types package > declares a variant record containing all message types), then use the > streams facility, so a package only depends on the predefined streams > packages. You might even consider deriving message types from a > Root_Message tagged type, so that message tags will be determined by the > compiler. Better still is to use the distributed systems annex. Streams? In Ada83? I don't think so. In my current project, now in Ada95, we cannot use the streams because we are using a COTS middleware package to implement damage-tolerant realtime communications, and this middleware package has its own APIs. Joe Gwinn ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Mixing Ada and C++. Is a good idea? 1997-11-20 0:00 ` Joe Gwinn @ 1997-11-21 0:00 ` Robert Dewar 1997-11-21 0:00 ` Matthew Heaney 0 siblings, 1 reply; 16+ messages in thread From: Robert Dewar @ 1997-11-21 0:00 UTC (permalink / raw) Joe says <<It was a nice theory, one that we never did get to work in a project of any size, because the inherent cohesiveness of the variables was not all that high. This has been true in all projects past some critical size, regardless of language, from the days of assembly on to the present. Having never gotten such a thing to work in the past, in any language, I have simply given up on the approach. Another nice theory. >> And yet, many programmers, who understand abstraction reasonably well, *have* got this approach to work fine, in very large projects. Could your failure be related to the same factors that make you think that all programming ultimately ends up in midnight debugging sessions? ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Mixing Ada and C++. Is a good idea? 1997-11-21 0:00 ` Robert Dewar @ 1997-11-21 0:00 ` Matthew Heaney 0 siblings, 0 replies; 16+ messages in thread From: Matthew Heaney @ 1997-11-21 0:00 UTC (permalink / raw) In article <dewar.880118394@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote: >Joe says > ><<It was a nice theory, one that we never did get to work in a project of >any size, because the inherent cohesiveness of the variables was not all >that high. This has been true in all projects past some critical size, >regardless of language, from the days of assembly on to the present. > >Having never gotten such a thing to work in the past, in any language, I >have simply given up on the approach. Another nice theory. >>> > >And yet, many programmers, who understand abstraction reasonably well, >*have* got this approach to work fine, in very large projects. I'm with Robert on this one, Joe. If you understand abstraction, and if you're _smart_ about how to use Ada packages to capture those abstractions, then all is well. Yes, you can have very real problems with Ada when you're not smart about how you use packages, but this isn't a language issue per se. If that's your situation, get some help from an Ada consultant. -------------------------------------------------------------------- Matthew Heaney Software Development Consultant <mailto:matthew_heaney@acm.org> (818) 985-1271 ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~1997-11-24 0:00 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1997-11-20 0:00 Mixing Ada and C++. Is a good idea? Robert Dewar 1997-11-21 0:00 ` Larry Kilgallen 1997-11-21 0:00 ` Robert Dewar 1997-11-24 0:00 ` Anonymous -- strict thread matches above, loose matches on Subject: below -- 1997-11-04 0:00 Arantza Diaz de Ilarraza 1997-11-11 0:00 ` Joe Gwinn 1997-11-12 0:00 ` Robert Dewar 1997-11-14 0:00 ` Ed Falis 1997-11-14 0:00 ` Joe Gwinn 1997-11-14 0:00 ` Robert Dewar 1997-11-14 0:00 ` Robert Dewar 1997-11-20 0:00 ` Joe Gwinn 1997-11-15 0:00 ` Matthew Heaney 1997-11-20 0:00 ` Joe Gwinn 1997-11-21 0:00 ` Robert Dewar 1997-11-21 0:00 ` Matthew Heaney
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox