Is this actually possible?

Is this actually possible?

[Lucretia]

Hi,

I was thinking about extensible records recently (not tagged types), and thought to try to export a tagged type to C, not C++. It compiles, but the results aren't quite right, so wondering if it's possible or not.

The idea is to export an array of tagged types as a C array to either a function or a variable / struct element. i.e.

struct Blah {
    My_Array *Array;
};

or in this case (Array below):

#include <stdio.h>

typedef struct {
    int One;
    float Two;
} Packet;

void Dump (int First, int Last, Packet *Array) {
    printf ("Dump (%d .. %d)\n", First, Last);
    printf ("Array => %p\n", Array);
    
    for (int I = First; I < Last + 1; I++) {
        printf ("\tOne => %d\n", Array[I].One);
        printf ("\tTwo => %f\n", Array[I].Two);
    }
}

So, I tried a few things, including Holders, which I never knew existed, but this is where I am currently:

with Interfaces.C;
-- with Ada.Containers.Bounded_Holders;
with System;

package Datums is
   package C renames Interfaces.C;

   --  Force a size, we kind of want a variant like array of records, but with unknown element types, but always of
   --  the same number and size of elements.
   type Root_Packet is abstract tagged null record with
     Size => C.int'Size + C.C_float'Size;

   -- package Root_Holders is new Ada.Containers.Bounded_Holders (Element_Type => Root_Packet'Class);
   type Storage_Element is mod 2 ** System.Storage_Unit with
     Convention => C;

   type Storage_Array is array (Positive range <>) of Storage_Element with
     Convention => C;

   type Root_Holder is
      record
         Data : Storage_Array (1 .. Root_Packet'Max_Size_In_Storage_Elements);
      end record with
        Convention => C;

   type Packet_Array is array (C.size_t range <>) of aliased Root_Holder with --  Root_Holders.Holder with
     Convention => C;

   type Packet_Array_Ptr is access all Packet_Array with
     Convention => C;

   type Packet_1 is new Root_Packet with
      record
         One : C.int;
         Two : C.C_float;
      end record with
        Convention => C;

   type Packet_2 is new Root_Packet with
      record
         Banana : C.int;
         Mango  : C.C_float;
      end record with
        Convention => C;
end Datums;

with Ada.Text_IO; use Ada.Text_IO;
with Ada.Unchecked_Conversion;
with System.Address_Image;
with Datums; use Datums;

procedure Testing is
   -- use Root_Holders;

   function To_Holder is new Ada.Unchecked_Conversion (Source => Packet_1, Target => Root_Holder);
   function To_Holder is new Ada.Unchecked_Conversion (Source => Packet_2, Target => Root_Holder);

   A : aliased Packet_Array := (1 => To_Holder (Packet_1'(One => 10, Two => 3.14)),
                                2 => To_Holder (Packet_2'(Banana => 50, Mango => 4.5)));

   procedure Dump (First, Last : in C.int; Data : in Packet_Array_Ptr) with
     Convention    => C,
     Import        => True,
     External_Name => "Dump";
begin
   Put_Line ("A'Address => " & System.Address_Image (A'Address));

   Dump (C.int (A'First), C.int (A'Last), A'Unchecked_Access);
end Testing;

project T is
    for Source_Dirs use (".");
    for Languages use ("C", "Ada");
    for Main use ("testing.adb");

    package Compiler is
        for Default_Switches ("Ada") use ("-g");
        for Default_Switches ("C") use ("-g");
    end Compiler;
end T;

Re: Is this actually possible?

[Dmitry A. Kazakov]

On 2019-12-11 17:43, Lucretia wrote:

> I was thinking about extensible records recently (not tagged types), and thought to try to export a tagged type to C, not C++. It compiles, but the results aren't quite right, so wondering if it's possible or not.
> 
> The idea is to export an array of tagged types as a C array to either a function or a variable / struct element. i.e.

Ada objects of tagged types have varying size and keep tag inside. Both 
make them utterly incompatible with C.

>     type Storage_Array is array (Positive range <>) of Storage_Element with
>       Convention => C;

This type cannot be used with C because an object of will have bounds 
inside.

If you need an array compatible with C, it must a "flat" array:

    type C_Storage_Array is array (size_t) of Storage_Element;

Naturally you will never declare such objects in your program. You will 
get them from C or allocate raw memory and then having the address of 
the first element do:

    A : C_Storage_Array;
    pragma Import (Ada, A);
    for A'Address use The_Address_Of_A;

It is your responsibility not to index it outside the bounds. Just like 
in C.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Is this actually possible?

[Lucretia]

On Wednesday, 11 December 2019 17:38:40 UTC, Dmitry A. Kazakov  wrote:
> On 2019-12-11 17:43, Lucretia wrote:
> 
> > I was thinking about extensible records recently (not tagged types), and thought to try to export a tagged type to C, not C++. It compiles, but the results aren't quite right, so wondering if it's possible or not.
> > 
> > The idea is to export an array of tagged types as a C array to either a function or a variable / struct element. i.e.
> 
> Ada objects of tagged types have varying size and keep tag inside. Both 
> make them utterly incompatible with C.

I know this, but as the compiler let it go through, I wondered if the tag would be stored elsewhere and not with the tagged type. Otherwise, shouldn't the compiler complain?
 
Luke.

Re: Is this actually possible?

[Randy Brukardt]

"Lucretia" <laguest9000@googlemail.com> wrote in message 
news:69c7677b-4aec-4db2-b240-de6b69f762b9@googlegroups.com...
> On Wednesday, 11 December 2019 17:38:40 UTC, Dmitry A. Kazakov  wrote:
>> On 2019-12-11 17:43, Lucretia wrote:
...
>> > The idea is to export an array of tagged types as a C array to either a 
>> > function or a variable / struct element. i.e.
>>
>> Ada objects of tagged types have varying size and keep tag inside. Both
>> make them utterly incompatible with C.
>
> I know this, but as the compiler let it go through, I wondered if the tag 
> would be stored elsewhere and not with the tagged type. Otherwise, 
> shouldn't the compiler complain?

I don't know of any reason that a tagged record couldn't be compatible with 
C. It's just a record with an extra component for the tag, so if an untagged 
record would be compatible, then the same tagged record would be, too. (Of 
course, C couldn't do anything with the tag.)

Many Ada compilers let one move the tag to other locations (by using a 
record rep. clause to put the other components in specific places). I don't 
believe that GNAT supports that, however. But the C could use a junk field 
to take up the space of the tag to get the representations to match.

I'm not aware of any Ada compilers that can store the tag outside of the 
record. The need for tag re-emergence makes that nearly impossible (one 
would have to prove that no one ever will convert the type to a class-wide 
type anywhere in the program before it would be safe to put the tag outside 
of the object).

One can argue about the wisdom of requiring re-emergence in these cases, but 
we're stuck it (and some people think it is a good thing).

                                Randy.

Re: Is this actually possible?

[Dmitry A. Kazakov]

On 2019-12-11 18:54, Lucretia wrote:
> On Wednesday, 11 December 2019 17:38:40 UTC, Dmitry A. Kazakov  wrote:
>> On 2019-12-11 17:43, Lucretia wrote:
>>
>>> I was thinking about extensible records recently (not tagged types), and thought to try to export a tagged type to C, not C++. It compiles, but the results aren't quite right, so wondering if it's possible or not.
>>>
>>> The idea is to export an array of tagged types as a C array to either a function or a variable / struct element. i.e.
>>
>> Ada objects of tagged types have varying size and keep tag inside. Both
>> make them utterly incompatible with C.
> 
> I know this, but as the compiler let it go through, I wondered if the tag would be stored elsewhere and not with the tagged type.

Not with tagged types which have T <-> T'Class view conversions.

> Otherwise, shouldn't the compiler complain?

No idea.

If you need objects that could be packed into C arrays use a variant 
record with the choice discriminant having a default.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Is this actually possible?

[Randy Brukardt]

"Lucretia" <laguest9000@googlemail.com> wrote in message 
news:36d45c82-2a6b-4c60-baeb-1a4aef5189c7@googlegroups.com...
...
> So, I tried a few things, including Holders, which I never knew existed, 
> but this is where I am currently:
>
> with Interfaces.C;
> -- with Ada.Containers.Bounded_Holders;

There no Bounded_Holders in Ada (any version). Perhaps your compiler has 
invented it (they're allowed to add containers).

Ada 202x has Bounded_Indefinite_Holders.

                  Randy.

Re: Is this actually possible?

[Lucretia]

On Wednesday, 11 December 2019 19:58:54 UTC, Dmitry A. Kazakov  wrote:
> On 2019-12-11 18:54, Lucretia wrote:
> > On Wednesday, 11 December 2019 17:38:40 UTC, Dmitry A. Kazakov  wrote:
> >> On 2019-12-11 17:43, Lucretia wrote:
> >>
> >>> I was thinking about extensible records recently (not tagged types), and thought to try to export a tagged type to C, not C++. It compiles, but the results aren't quite right, so wondering if it's possible or not.
> >>>
> >>> The idea is to export an array of tagged types as a C array to either a function or a variable / struct element. i.e.
> >>
> >> Ada objects of tagged types have varying size and keep tag inside. Both
> >> make them utterly incompatible with C.
> > 
> > I know this, but as the compiler let it go through, I wondered if the tag would be stored elsewhere and not with the tagged type.
> 
> Not with tagged types which have T <-> T'Class view conversions.
> 
> > Otherwise, shouldn't the compiler complain?
> 
> No idea.
> 
> If you need objects that could be packed into C arrays use a variant 
> record with the choice discriminant having a default.

But in my cases, a variant cannot be used.

Re: Is this actually possible?

[Dmitry A. Kazakov]

On 2019-12-11 22:12, Lucretia wrote:
> On Wednesday, 11 December 2019 19:58:54 UTC, Dmitry A. Kazakov  wrote:

>> If you need objects that could be packed into C arrays use a variant
>> record with the choice discriminant having a default.
> 
> But in my cases, a variant cannot be used.

Why? You must know all variants in order to compute the array element 
size. In Ada you cannot have it either:

    type Not_an_Array is array (Positive range <>) of T'Class;

This is illegal.

Are you sure you want an array of objects, rather than an array of 
pointers to objects?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Is this actually possible?

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:qsrncj$u95$1@gioia.aioe.org...
> On 2019-12-11 22:12, Lucretia wrote:
...
> Why? You must know all variants in order to compute the array element 
> size. In Ada you cannot have it either:
>
>    type Not_an_Array is array (Positive range <>) of T'Class;
>
> This is illegal.

This is the purpose of the Bounded_Indefinite_Holders, because this is a 
useful thing to do sometimes.

    package My_Holders is new Ada.Containers.Bounded_Indefinite_Holders 
(T'Class, 100);

    type An_Array is array (Positive range <>) of My_Holders.Holder;

Here, a Holder will hold up to 100 storage units. If some extension of 
T'Class is bigger than that, setting the holder to a value of that extension 
raises Program_Error. (As with most checks, this one can be suppressed, and 
if it would fail and is suppressed, the program is erroneous - presumably 
some other object memory would be overwritten. So don't do that. ;-)

This is probably one of the best (and simplest) ideas of Ada 202x. Thanks to 
Niklas Holsti for the original idea (although I think the actual resulting 
package isn't much like Niklas' original idea).

                         Randy.

Re: Is this actually possible?

[Niklas Holsti]

On 2019-12-12 4:00, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:qsrncj$u95$1@gioia.aioe.org...
>> On 2019-12-11 22:12, Lucretia wrote:
> ...
>> Why? You must know all variants in order to compute the array element
>> size. In Ada you cannot have it either:
>>
>>     type Not_an_Array is array (Positive range <>) of T'Class;
>>
>> This is illegal.
> 
> This is the purpose of the Bounded_Indefinite_Holders, because this is a
> useful thing to do sometimes.
> 
>      package My_Holders is new Ada.Containers.Bounded_Indefinite_Holders
> (T'Class, 100);
> 
>      type An_Array is array (Positive range <>) of My_Holders.Holder;
> 
> Here, a Holder will hold up to 100 storage units. If some extension of
> T'Class is bigger than that, setting the holder to a value of that extension
> raises Program_Error. (As with most checks, this one can be suppressed, and
> if it would fail and is suppressed, the program is erroneous - presumably
> some other object memory would be overwritten. So don't do that. ;-)
> 
> This is probably one of the best (and simplest) ideas of Ada 202x. Thanks to
> Niklas Holsti for the original idea (although I think the actual resulting
> package isn't much like Niklas' original idea).

Thanks for the credit, Randy.

I wanted a way to statically allocate a "max size" for class-wide 
objects, just as many compilers currently use an "allocate max size" for 
variant records with a default discriminant. My suggestion would also 
have needed the ability to change the tag of such a class-wide object, 
just as the discriminant of a variant-record object can be changed by 
assigning to the whole object.

The wise heads of the ARG introduced the Bounded_Indefinite_Holder, 
giving just this effect: a bounded size, allowing static storage 
allocation, but also letting me change the tag by replacing the object 
being held with another object.

My only worry about the present solution is if there is a lot of memory 
overhead in the Bounded_Indefinite_Holder. I don't see why there should 
be, but I guess I'll have to wait for an implementation to find out.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Is this actually possible?

[Lucretia]

On Wednesday, 11 December 2019 21:34:15 UTC, Dmitry A. Kazakov  wrote:
> On 2019-12-11 22:12, Lucretia wrote:
> > On Wednesday, 11 December 2019 19:58:54 UTC, Dmitry A. Kazakov  wrote:
> 
> >> If you need objects that could be packed into C arrays use a variant
> >> record with the choice discriminant having a default.
> > 
> > But in my cases, a variant cannot be used.
> 
> Why? You must know all variants in order to compute the array element 
> size. In Ada you cannot have it either:

Because it's a binding to a C record: https://github.com/Lucretia/aplug/blob/master/ladspa/src/ladspa.ads#L113

Re: Is this actually possible?

[Dmitry A. Kazakov]

On 2019-12-12 11:17, Lucretia wrote:
> On Wednesday, 11 December 2019 21:34:15 UTC, Dmitry A. Kazakov  wrote:
>> On 2019-12-11 22:12, Lucretia wrote:
>>> On Wednesday, 11 December 2019 19:58:54 UTC, Dmitry A. Kazakov  wrote:
>>
>>>> If you need objects that could be packed into C arrays use a variant
>>>> record with the choice discriminant having a default.
>>>
>>> But in my cases, a variant cannot be used.
>>
>> Why? You must know all variants in order to compute the array element
>> size. In Ada you cannot have it either:
> 
> Because it's a binding to a C record: https://github.com/Lucretia/aplug/blob/master/ladspa/src/ladspa.ads#L113

I cannot recognize problem there.

P.S. You can take a look at GtkAda design. It deploys a typical model. C 
API have a user data void * field allocated in all C objects. GtkAda 
creates an Ada object, creates a C object. Sets the user field in the C 
object to point to the Ada object and passes the C object to GTK. That 
way the hierarchy of C objects has a parallel hierarchy of tagged Ada 
objects.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Is this actually possible?

[Lucretia]

On Thursday, 12 December 2019 14:32:21 UTC, Dmitry A. Kazakov  wrote:
> On 2019-12-12 11:17, Lucretia wrote:
> > On Wednesday, 11 December 2019 21:34:15 UTC, Dmitry A. Kazakov  wrote:
> >> On 2019-12-11 22:12, Lucretia wrote:
> >>> On Wednesday, 11 December 2019 19:58:54 UTC, Dmitry A. Kazakov  wrote:
> >>
> >>>> If you need objects that could be packed into C arrays use a variant
> >>>> record with the choice discriminant having a default.
> >>>
> >>> But in my cases, a variant cannot be used.
> >>
> >> Why? You must know all variants in order to compute the array element
> >> size. In Ada you cannot have it either:
> > 
> > Because it's a binding to a C record: https://github.com/Lucretia/aplug/blob/master/ladspa/src/ladspa.ads#L113
> 
> I cannot recognize problem there.

That's a predefined struct, it's referenced in the Descriptors below it. It cannot be changed. The API is too cyclic AFAIK to make generics out of it all.

Re: Is this actually possible?

[Lucretia]

On Thursday, 12 December 2019 15:14:33 UTC, Lucretia  wrote:


> > >> Why? You must know all variants in order to compute the array element
> > >> size. In Ada you cannot have it either:
> > > 
> > > Because it's a binding to a C record: https://github.com/Lucretia/aplug/blob/master/ladspa/src/ladspa.ads#L113
> > 
> > I cannot recognize problem there.
> 
> That's a predefined struct, it's referenced in the Descriptors below it. It cannot be changed. The API is too cyclic AFAIK to make generics out of it all.

At the programmer's level, i.e. building a plug-in using the LADSPA API, they define ranges for their ports using that record above. Each port can have different ranges.

Re: Is this actually possible?

[Dmitry A. Kazakov]

On 2019-12-12 16:15, Lucretia wrote:
> On Thursday, 12 December 2019 15:14:33 UTC, Lucretia  wrote:
> 
> 
>>>>> Why? You must know all variants in order to compute the array element
>>>>> size. In Ada you cannot have it either:
>>>>
>>>> Because it's a binding to a C record: https://github.com/Lucretia/aplug/blob/master/ladspa/src/ladspa.ads#L113
>>>
>>> I cannot recognize problem there.
>>
>> That's a predefined struct, it's referenced in the Descriptors below it. It cannot be changed. The API is too cyclic AFAIK to make generics out of it all.
> 
> At the programmer's level, i.e. building a plug-in using the LADSPA API, they define ranges for their ports using that record above. Each port can have different ranges.

Can you post the C struct type and where it is used.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Is this actually possible?

[Lucretia]

On Thursday, 12 December 2019 18:24:55 UTC, Dmitry A. Kazakov  wrote:
> On 2019-12-12 16:15, Lucretia wrote:
> > On Thursday, 12 December 2019 15:14:33 UTC, Lucretia  wrote:
> > 
> > 
> >>>>> Why? You must know all variants in order to compute the array element
> >>>>> size. In Ada you cannot have it either:
> >>>>
> >>>> Because it's a binding to a C record: https://github.com/Lucretia/aplug/blob/master/ladspa/src/ladspa.ads#L113
> >>>
> >>> I cannot recognize problem there.
> >>
> >> That's a predefined struct, it's referenced in the Descriptors below it. It cannot be changed. The API is too cyclic AFAIK to make generics out of it all.
> > 
> > At the programmer's level, i.e. building a plug-in using the LADSPA API, they define ranges for their ports using that record above. Each port can have different ranges.
> 
> Can you post the C struct type and where it is used.

In ladspa.h and in exactly the same place as the Ada.

https://www.ladspa.org/ladspa_sdk/ladspa.h.txt

Here is the struct on a gh mirror: https://github.com/adsr/ladspa-sdk/blob/master/src/ladspa.h#L337

and it is used here: https://github.com/adsr/ladspa-sdk/blob/master/src/ladspa.h#L419

Re: Is this actually possible?

[Dmitry A. Kazakov]

On 2019-12-12 19:30, Lucretia wrote:
> On Thursday, 12 December 2019 18:24:55 UTC, Dmitry A. Kazakov  wrote:
>> On 2019-12-12 16:15, Lucretia wrote:
>>> On Thursday, 12 December 2019 15:14:33 UTC, Lucretia  wrote:
>>>
>>>
>>>>>>> Why? You must know all variants in order to compute the array element
>>>>>>> size. In Ada you cannot have it either:
>>>>>>
>>>>>> Because it's a binding to a C record: https://github.com/Lucretia/aplug/blob/master/ladspa/src/ladspa.ads#L113
>>>>>
>>>>> I cannot recognize problem there.
>>>>
>>>> That's a predefined struct, it's referenced in the Descriptors below it. It cannot be changed. The API is too cyclic AFAIK to make generics out of it all.
>>>
>>> At the programmer's level, i.e. building a plug-in using the LADSPA API, they define ranges for their ports using that record above. Each port can have different ranges.
>>
>> Can you post the C struct type and where it is used.
> 
> In ladspa.h and in exactly the same place as the Ada.
> 
> https://www.ladspa.org/ladspa_sdk/ladspa.h.txt
> 
> Here is the struct on a gh mirror: https://github.com/adsr/ladspa-sdk/blob/master/src/ladspa.h#L337
> 
> and it is used here: https://github.com/adsr/ladspa-sdk/blob/master/src/ladspa.h#L419

Maybe I am dense, but what I see is this:

    typedef struct _LADSPA_PortRangeHint {

      /* Hints about the port. */
      LADSPA_PortRangeHintDescriptor HintDescriptor;

      /* Meaningful when hint LADSPA_HINT_BOUNDED_BELOW is active. When
         LADSPA_HINT_SAMPLE_RATE is also active then this value should be
         multiplied by the relevant sample rate. */
      LADSPA_Data LowerBound;

      /* Meaningful when hint LADSPA_HINT_BOUNDED_ABOVE is active. When
         LADSPA_HINT_SAMPLE_RATE is also active then this value should be
         multiplied by the relevant sample rate. */
      LADSPA_Data UpperBound;

    } LADSPA_PortRangeHint;

and

    typedef int LADSPA_PortRangeHintDescriptor;
    typedef float LADSPA_Data;

Where is a problem?


-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Is this actually possible?

[Lucretia]

On Thursday, 12 December 2019 19:09:25 UTC, Dmitry A. Kazakov  wrote:
> On 2019-12-12 19:30, Lucretia wrote:
> > On Thursday, 12 December 2019 18:24:55 UTC, Dmitry A. Kazakov  wrote:
> >> On 2019-12-12 16:15, Lucretia wrote:
> >>> On Thursday, 12 December 2019 15:14:33 UTC, Lucretia  wrote:
> >>>
> >>>
> >>>>>>> Why? You must know all variants in order to compute the array element
> >>>>>>> size. In Ada you cannot have it either:
> >>>>>>
> >>>>>> Because it's a binding to a C record: https://github.com/Lucretia/aplug/blob/master/ladspa/src/ladspa.ads#L113
> >>>>>
> >>>>> I cannot recognize problem there.
> >>>>
> >>>> That's a predefined struct, it's referenced in the Descriptors below it. It cannot be changed. The API is too cyclic AFAIK to make generics out of it all.
> >>>
> >>> At the programmer's level, i.e. building a plug-in using the LADSPA API, they define ranges for their ports using that record above. Each port can have different ranges.
> >>
> >> Can you post the C struct type and where it is used.
> > 
> > In ladspa.h and in exactly the same place as the Ada.
> > 
> > https://www.ladspa.org/ladspa_sdk/ladspa.h.txt
> > 
> > Here is the struct on a gh mirror: https://github.com/adsr/ladspa-sdk/blob/master/src/ladspa.h#L337
> > 
> > and it is used here: https://github.com/adsr/ladspa-sdk/blob/master/src/ladspa.h#L419
> 
> Maybe I am dense, but what I see is this:
> 
>     typedef struct _LADSPA_PortRangeHint {
> 
>       /* Hints about the port. */
>       LADSPA_PortRangeHintDescriptor HintDescriptor;
> 
>       /* Meaningful when hint LADSPA_HINT_BOUNDED_BELOW is active. When
>          LADSPA_HINT_SAMPLE_RATE is also active then this value should be
>          multiplied by the relevant sample rate. */
>       LADSPA_Data LowerBound;
> 
>       /* Meaningful when hint LADSPA_HINT_BOUNDED_ABOVE is active. When
>          LADSPA_HINT_SAMPLE_RATE is also active then this value should be
>          multiplied by the relevant sample rate. */
>       LADSPA_Data UpperBound;
> 
>     } LADSPA_PortRangeHint;
> 
> and
> 
>     typedef int LADSPA_PortRangeHintDescriptor;
>     typedef float LADSPA_Data;
> 
> Where is a problem?

You didn;'t look at both links I posted.

Re: Is this actually possible?

[Dmitry A. Kazakov]

On 2019-12-12 21:54, Lucretia wrote:
> On Thursday, 12 December 2019 19:09:25 UTC, Dmitry A. Kazakov  wrote:
>> On 2019-12-12 19:30, Lucretia wrote:
>>> On Thursday, 12 December 2019 18:24:55 UTC, Dmitry A. Kazakov  wrote:
>>>> On 2019-12-12 16:15, Lucretia wrote:
>>>>> On Thursday, 12 December 2019 15:14:33 UTC, Lucretia  wrote:
>>>>>
>>>>>
>>>>>>>>> Why? You must know all variants in order to compute the array element
>>>>>>>>> size. In Ada you cannot have it either:
>>>>>>>>
>>>>>>>> Because it's a binding to a C record: https://github.com/Lucretia/aplug/blob/master/ladspa/src/ladspa.ads#L113
>>>>>>>
>>>>>>> I cannot recognize problem there.
>>>>>>
>>>>>> That's a predefined struct, it's referenced in the Descriptors below it. It cannot be changed. The API is too cyclic AFAIK to make generics out of it all.
>>>>>
>>>>> At the programmer's level, i.e. building a plug-in using the LADSPA API, they define ranges for their ports using that record above. Each port can have different ranges.
>>>>
>>>> Can you post the C struct type and where it is used.
>>>
>>> In ladspa.h and in exactly the same place as the Ada.
>>>
>>> https://www.ladspa.org/ladspa_sdk/ladspa.h.txt
>>>
>>> Here is the struct on a gh mirror: https://github.com/adsr/ladspa-sdk/blob/master/src/ladspa.h#L337
>>>
>>> and it is used here: https://github.com/adsr/ladspa-sdk/blob/master/src/ladspa.h#L419
>>
>> Maybe I am dense, but what I see is this:
>>
>>      typedef struct _LADSPA_PortRangeHint {
>>
>>        /* Hints about the port. */
>>        LADSPA_PortRangeHintDescriptor HintDescriptor;
>>
>>        /* Meaningful when hint LADSPA_HINT_BOUNDED_BELOW is active. When
>>           LADSPA_HINT_SAMPLE_RATE is also active then this value should be
>>           multiplied by the relevant sample rate. */
>>        LADSPA_Data LowerBound;
>>
>>        /* Meaningful when hint LADSPA_HINT_BOUNDED_ABOVE is active. When
>>           LADSPA_HINT_SAMPLE_RATE is also active then this value should be
>>           multiplied by the relevant sample rate. */
>>        LADSPA_Data UpperBound;
>>
>>      } LADSPA_PortRangeHint;
>>
>> and
>>
>>      typedef int LADSPA_PortRangeHintDescriptor;
>>      typedef float LADSPA_Data;
>>
>> Where is a problem?
> 
> You didn;'t look at both links I posted.

That was from the linked header file. Could you simply post C code of 
what you mean?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Is this actually possible?

[Lucretia]

On Thursday, 12 December 2019 21:12:34 UTC, Dmitry A. Kazakov  wrote:
> On 2019-12-12 21:54, Lucretia wrote:
> > On Thursday, 12 December 2019 19:09:25 UTC, Dmitry A. Kazakov  wrote:
> >> On 2019-12-12 19:30, Lucretia wrote:
> >>> On Thursday, 12 December 2019 18:24:55 UTC, Dmitry A. Kazakov  wrote:
> >>>> On 2019-12-12 16:15, Lucretia wrote:
> >>>>> On Thursday, 12 December 2019 15:14:33 UTC, Lucretia  wrote:
> >>>>>
> >>>>>
> >>>>>>>>> Why? You must know all variants in order to compute the array element
> >>>>>>>>> size. In Ada you cannot have it either:
> >>>>>>>>
> >>>>>>>> Because it's a binding to a C record: https://github.com/Lucretia/aplug/blob/master/ladspa/src/ladspa.ads#L113
> >>>>>>>
> >>>>>>> I cannot recognize problem there.
> >>>>>>
> >>>>>> That's a predefined struct, it's referenced in the Descriptors below it. It cannot be changed. The API is too cyclic AFAIK to make generics out of it all.
> >>>>>
> >>>>> At the programmer's level, i.e. building a plug-in using the LADSPA API, they define ranges for their ports using that record above. Each port can have different ranges.
> >>>>
> >>>> Can you post the C struct type and where it is used.
> >>>
> >>> In ladspa.h and in exactly the same place as the Ada.
> >>>
> >>> https://www.ladspa.org/ladspa_sdk/ladspa.h.txt
> >>>
> >>> Here is the struct on a gh mirror: https://github.com/adsr/ladspa-sdk/blob/master/src/ladspa.h#L337
> >>>
> >>> and it is used here: https://github.com/adsr/ladspa-sdk/blob/master/src/ladspa.h#L419
> >>
> >> Maybe I am dense, but what I see is this:
> >>
> >>      typedef struct _LADSPA_PortRangeHint {
> >>
> >>        /* Hints about the port. */
> >>        LADSPA_PortRangeHintDescriptor HintDescriptor;
> >>
> >>        /* Meaningful when hint LADSPA_HINT_BOUNDED_BELOW is active. When
> >>           LADSPA_HINT_SAMPLE_RATE is also active then this value should be
> >>           multiplied by the relevant sample rate. */
> >>        LADSPA_Data LowerBound;
> >>
> >>        /* Meaningful when hint LADSPA_HINT_BOUNDED_ABOVE is active. When
> >>           LADSPA_HINT_SAMPLE_RATE is also active then this value should be
> >>           multiplied by the relevant sample rate. */
> >>        LADSPA_Data UpperBound;
> >>
> >>      } LADSPA_PortRangeHint;
> >>
> >> and
> >>
> >>      typedef int LADSPA_PortRangeHintDescriptor;
> >>      typedef float LADSPA_Data;
> >>
> >> Where is a problem?
> > 
> > You didn;'t look at both links I posted.
> 
> That was from the linked header file. Could you simply post C code of 
> what you mean?

I already did.

Re: Is this actually possible?

[Alejandro R. Mosteo]

I apologize for unearthing this old topic; I just came around to it.

On 12/12/19 3:00, Randy Brukardt wrote:

> This is the purpose of the Bounded_Indefinite_Holders, because this is a
> useful thing to do sometimes.
> 
>      package My_Holders is new Ada.Containers.Bounded_Indefinite_Holders
> (T'Class, 100);
> 
>      type An_Array is array (Positive range <>) of My_Holders.Holder;
> 
> Here, a Holder will hold up to 100 storage units. If some extension of
> T'Class is bigger than that, setting the holder to a value of that extension
> raises Program_Error. (As with most checks, this one can be suppressed, and
> if it would fail and is suppressed, the program is erroneous - presumably
> some other object memory would be overwritten. So don't do that. ;-)
> 
> This is probably one of the best (and simplest) ideas of Ada 202x. Thanks to
> Niklas Holsti for the original idea (although I think the actual resulting
> package isn't much like Niklas' original idea).

I tried to use the GNAT CE 2019 Bounded_Holders once and got bitten by 
them being implemented with casts/address wizardry. This meant that 
storing controlled types and copying them while in bounded disguise 
broke finalization internals. (I don't remember the specifics, sorry).

Is this an implementation allowance? I see note 13/5 at 
http://www.ada-auth.org/standards/2xrm/html/RM-A-18-32.html#I8180 that 
implies that Finalization should work.

But then I also realize that the ARM package name is 
Bounded_Indefinite_Holders and not Bounded_Holders, so maybe the version 
I used is an early implementation.

(This is what I have: 
https://github.com/gcc-mirror/gcc/blob/master/gcc/ada/libgnat/a-coboho.ads)