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-Thread: 103376,73975695cdfcb86f X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.68.129.169 with SMTP id nx9mr4355420pbb.2.1333661578067; Thu, 05 Apr 2012 14:32:58 -0700 (PDT) MIME-Version: 1.0 Path: r9ni22746pbh.0!nntp.google.com!news1.google.com!goblin1!goblin2!goblin.stu.neva.ru!newsfeed.x-privat.org!news.jacob-sparre.dk!munin.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Dispatching callback handed over to C Date: Thu, 5 Apr 2012 16:32:49 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <6fb83c74-b2a4-4ae8-9c89-d755b737198f@v22g2000vby.googlegroups.com> <85d1ad51-c02b-44fa-87b6-02aa1d8ba1b2@x17g2000vba.googlegroups.com> <62246369-6b9f-4a96-9c67-fd1774c02e78@k24g2000yqe.googlegroups.com> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1333661575 18450 69.95.181.76 (5 Apr 2012 21:32:55 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Thu, 5 Apr 2012 21:32:55 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Date: 2012-04-05T16:32:49-05:00 List-Id: "Maciej Sobczak" wrote in message news:a236ccdb-e8b8-4b13-9e93-a2596f54ddcb@l7g2000vbw.googlegroups.com... > On 4 Kwi, 21:16, "Randy Brukardt" wrote: > >> > Interestingly, this is also the intent of void*. >> >> But that's impossible. In general, data memory and code memory are >> different >> things and require different access. > > But we are talking about using void* as a data pointer here (a class- > wide object). That's the point. "void *" is a data pointer (only). System.Address has to be both a code and data pointer. So it may not have the same representation as "void *". >> If all you want to do is store them, just stick them in the record as >> "access-to-class-wide" and don't even worry about having a C counterpart. >> You need some c-compatible type in the C-side, but it is just a >> "bucket-of-bits". > > I use void* as bit bucket with the indication that what is inside is, > well, a pointer. > Ironically, contrary to your insistence of using type information > correctly, I find my use of void* as a bit bucket for a pointer value > somewhat more typed (at least in the sense of being self-documenting) > than your DWORD, which is a bit bucket completely devoid of any self > description and even exposing wrong set of operations (arithmetic? bit > shifting? silent integer conversion? is it a set of flags or > something?). We used DWord in CLAW because that's what Win32 used for that parameter. Otherwise, I think we would have done something more in line with the "Opaque_Access" suggestion made elsewhere in this thread, which is #2 here.] But we also could have removed the arithmetic operations, if we were using this as a stand-alone solution, as they're harmful in this case. Indeed, it's often the case that modular types are not used as numeric, and it's annoying that they are that way by default. (Making them private doesn't really solve anything here, because these are already only used in the private part.) > Sorry, you are not convincing. I'll stick to void* when pointers are > involved. You can't write "void *" in Ada! And this is the wrong forum to care at all about how to write C. In particular, we're talking about the mapping of C to Ada here, and not the underlying design of the C API (which is out of our control anyway). The question is how to map "void *" to Ada? 1) Some convention C access type designating an appropriate Ada type. 2) Some convention C access type designating a dummy Ada type (use unchecked_conversion as needed on the real types). 3) A constrained array of stream elements (also using U_C). 4) An explicitly declared modular type with the arithmetic operations removed (also using U_C). ... 674) System.Address, using Access_to_Address_Conversions to get to/from the real type. 675) System.Address, using U_C to get to/from the real type. >> System.Address is the wrong type to use for a "bucket-of-bits". > > It is a proper type to use for a "bucket-of-pointer-bits" in the sense > that I have no doubts about the intent when I see it later in code. Well, I doubt that clarity of intent extends to other Ada programmers. Perhaps not to you, either, years in the future. Randy.