Re: Dispatching callback handed over to C

["Randy Brukardt" <randy@rrsoftware.com>]

"Maciej Sobczak" <see.my.homepage@gmail.com> wrote in message 
news:a236ccdb-e8b8-4b13-9e93-a2596f54ddcb@l7g2000vbw.googlegroups.com...
> On 4 Kwi, 21:16, "Randy Brukardt" <ra...@rrsoftware.com> 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.