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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.224.172.66 with SMTP id k2mr10861462qaz.4.1372682513248; Mon, 01 Jul 2013 05:41:53 -0700 (PDT) X-Received: by 10.49.3.104 with SMTP id b8mr653935qeb.25.1372682513232; Mon, 01 Jul 2013 05:41:53 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!mx05.eternal-september.org!feeder.eternal-september.org!news.bbs-scene.org!border4.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!j2no1930904qak.0!news-out.google.com!f7ni121qai.0!nntp.google.com!j2no3165557qak.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Mon, 1 Jul 2013 05:41:53 -0700 (PDT) In-Reply-To: <5m9o5ouj1e2i.1h3w3i0aa3938$.dlg@40tude.net> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=155.253.16.227; posting-account=uPViEgkAAACC04vaTYL5Kyk76brV1MA_ NNTP-Posting-Host: 155.253.16.227 References: <1fxsf70zl2ckq.aysy7d9c8jkl$.dlg@40tude.net> <40bf5a31-b09a-4106-a57a-7ac3dd5f951e@googlegroups.com> <5m9o5ouj1e2i.1h3w3i0aa3938$.dlg@40tude.net> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <6b49164e-2740-4f0d-9379-964a56e8ae27@googlegroups.com> Subject: Re: Thick bindings to a C library and gnattest: suggestions? From: Maurizio Tomasi Injection-Date: Mon, 01 Jul 2013 12:41:53 +0000 Content-Type: text/plain; charset=ISO-8859-1 Xref: news.eternal-september.org comp.lang.ada:16009 Date: 2013-07-01T05:41:53-07:00 List-Id: On Monday, July 1, 2013 2:32:27 PM UTC+2, Dmitry A. Kazakov wrote: > The first point is that it is not the objective of bindings to manage > memory. Of course, there could be bindings which do that, in which case you > would allocate objects transparently to the caller and have some garbage > collection schema behind opaque handles to the objects. This is a possible > design but it is not what you probably wanted. So let us take for granted > that it is the client's responsibility to allocate objects. In this case > the bindings shall work for any kind of objects allocated in any possible > memory pool, stack included. Thanks a lot for your long and detailed answer, Dmitry! Your suggestion of letting the client do all the memory management stuff is very reasonable and flexible. I'll try to do that. Cheers, Maurizio.