From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-0.9 required=3.0 tests=BAYES_00,XPRIO autolearn=no autolearn_force=no version=3.4.6 Path: eternal-september.org!reader02.eternal-september.org!gandalf.srv.welterde.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Custom Storage Pool questions Date: Wed, 13 Oct 2021 20:21:42 -0500 Organization: JSA Research & Innovation Message-ID: References: Injection-Date: Thu, 14 Oct 2021 01:21:44 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="29711"; mail-complaints-to="news@jacob-sparre.dk" X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 Xref: reader02.eternal-september.org comp.lang.ada:62989 List-Id: "Dmitry A. Kazakov" wrote in message news:sjbq96$3cl$1@gioia.aioe.org... > On 2021-10-03 06:33, Randy Brukardt wrote: ... > Yes, but static monolithic linking is even more fragile. Typically a > customer orders software off the shelf. It means that he says I need, e.g. > HTTP client, ModBus master, CANOpen etc. It is simply impossible to > re-link everything for each customer and run integration tests. ??? When you are dynamically loading stuff, you simply are assuming everything is OK. (Which is usually nonsense, but for the sake of argument, assume that it is OK to do.) When you statically link, you surely can make the same assumption. It doesn't make sense to say you have to run integration tests when you statically link and not do the same when you dynamically load stuff. Of course, when you statically link Ada code, you can include that code in your static analysis (including, of course, the various guarantees that the Ada language and compiler bring). When you dynamically load, you can have none of that. > So the software is organized as a set of plug-in relocatable libraries, > each of them maintained, versioned and tested separately. You cannot turn > clock 20 years back. And you still have to do integration testing when using them together -- or you could have done the same at the Ada source code level (that is, version, maintain, and test separately) and still have the advantages of Ada checking. ... >> Of course you can. > > How? Ada does not determine the way you link an executable. If I put a > package in a library it is there. If the package derives from a tagged > type This I don't understand at all. A dynamically loaded library necessarily has a C interface (if it is generally useful, if not, it might as well be maintained as Ada source code, there's no advantage to dynamic linking in that case and lots of disavantages), and that can't export a tagged type. In any case, a tagged type extension is a compile-time thing -- the compiler has to know all of the details of the type. >> The only thing you need to be compatible with is a C interface, which >> is the only thing you need to interface to existing libraries that >> you can't avoid. > > That would kill most of Ada libraries. There's no use to an Ada dynamic library -- if it's only for your organization's use, static linking is way better. And if it is for everyone's use, it has to have a C interface, thus no tagged types. >>> So getting rid of nesting tagged types will ease nothing. >> >> The problem is tagged types not declared at the library level. >> Relocatable librarys are still library level (they have their own global >> address space). > > When the library is loaded dynamically, there is no way to know in the > executable the tag of the extension or prepare an extension of the > dispatching table. I think it is far worse than a nested declaration, when > is you have some information. Ignoring that fact that this is useless construct, it is not at all hard to do, because you have to know that the tag and subprograms are declared in the dynamically loaded thing. Thus, one has to use a wrapper to call them indirectly, but that's easy to do when everything is library level. It's essentially the same as shared generics, which Janus/Ada has been doing for decades -- including tagged type derivation. The problem comes about when you have things whose lifetime is limited and need to have a static link or display to access them. Managing that is a nightmare, no matter how you try to do it. Randy.