Overloading procedures with Float and Long_Float types

Overloading procedures with Float and Long_Float types

[Luke A. Guest]

Hi,

Is there a safe way to do this? I'm playing with the adaopengl bindings
and have created the following:

subtype GLfloat is Float;
subtype GLdouble is Standard.Long_Float;

procedure Vertex(X, Y, Z : in GLdouble);
procedure Vertex(X, Y, Z : in GLfloat);

But the compiler (GNAT - Gentoo's 5.02w version) throws up ambiguity
problems.

Is there a nice way to have these two procedures co-exist without having to
rename them? I have currently renamed them, but this does defeat the whole
purpose of this experiment.

Thanks,
Luke.

Re: Overloading procedures with Float and Long_Float types

[James Rogers]

"Luke A. Guest" <laguest@n_o_p_o_r_k_a_n_d_h_a_m.abyss2.demon.co.uk>
wrote in
news:pan.2004.03.08.00.17.32.527941@n_o_p_o_r_k_a_n_d_h_a_m.abyss2.demon.
co.uk: 

> Hi,
> 
> Is there a safe way to do this? I'm playing with the adaopengl
> bindings and have created the following:
> 
> subtype GLfloat is Float;
> subtype GLdouble is Standard.Long_Float;
> 
> procedure Vertex(X, Y, Z : in GLdouble);
> procedure Vertex(X, Y, Z : in GLfloat);
> 
> But the compiler (GNAT - Gentoo's 5.02w version) throws up ambiguity
> problems.
> 
> Is there a nice way to have these two procedures co-exist without
> having to rename them? I have currently renamed them, but this does
> defeat the whole purpose of this experiment.

This appears to be a problem with your version. The version 3.15P
has no problems with this code.

Jim Rogers

Re: Overloading procedures with Float and Long_Float types

[Luke A. Guest]

On Mon, 08 Mar 2004 03:49:03 +0000, James Rogers wrote:

> This appears to be a problem with your version. The version 3.15P
> has no problems with this code.
> 
> Jim Rogers

Sorry, but it doesn't, this is the output of my installed 3.15p version
which is the same as my 5.02w version:

example.adb:228:19: ambiguous expression (cannot resolve "Translate")
example.adb:228:19: possible interpretation at gl.ads:1153
example.adb:228:19: possible interpretation at gl.ads:1151
example.adb:288:19: ambiguous expression (cannot resolve "Translate")
example.adb:288:19: possible interpretation at gl.ads:1153
example.adb:288:19: possible interpretation at gl.ads:1151
gnatmake: "example.adb" compilation error

Luke.

Re: Overloading procedures with Float and Long_Float types

[Preben Randhol]

On 2004-03-08, Luke A. Guest <laguest@n_o_p_o_r_k_a_n_d_h_a_m.abyss2.demon.co.uk> wrote:
> On Mon, 08 Mar 2004 03:49:03 +0000, James Rogers wrote:
>
>> This appears to be a problem with your version. The version 3.15P
>> has no problems with this code.
>> 
>> Jim Rogers
>
> Sorry, but it doesn't, this is the output of my installed 3.15p version
> which is the same as my 5.02w version:
>
> example.adb:228:19: ambiguous expression (cannot resolve "Translate")
                                            ^^^^^^^^^^^^^^^^^^^^^^^^^^

                                            What is Translate?

-- 
Rox-Filer; *the* file manager => http://rox.sf.net/

Re: Overloading procedures with Float and Long_Float types

[Luke A. Guest]

On Mon, 08 Mar 2004 08:20:19 +0000, Preben Randhol wrote:

> On 2004-03-08, Luke A. Guest <laguest@n_o_p_o_r_k_a_n_d_h_a_m.abyss2.demon.co.uk> wrote:
>> On Mon, 08 Mar 2004 03:49:03 +0000, James Rogers wrote:
>>
>>> This appears to be a problem with your version. The version 3.15P
>>> has no problems with this code.
>>> 
>>> Jim Rogers
>>
>> Sorry, but it doesn't, this is the output of my installed 3.15p version
>> which is the same as my 5.02w version:
>>
>> example.adb:228:19: ambiguous expression (cannot resolve "Translate")
>                                             ^^^^^^^^^^^^^^^^^^^^^^^^^^

Translate is another st of overloaded functions with the same signature as
Vertex;

	procedure Translate(X, Y, Z : in GLdouble);
	procedure Translate(X, Y, Z : in GLfloat);

It's just that I've 3 Translate calls and about 40 Vertex calls in my test
program.

Luke.

Re: Overloading procedures with Float and Long_Float types

[Dmitry A. Kazakov]

On Mon, 08 Mar 2004 09:06:00 +0000, "Luke A. Guest"
<laguest@n_o_p_o_r_k_a_n_d_h_a_m.abyss2.demon.co.uk> wrote:

>On Mon, 08 Mar 2004 08:20:19 +0000, Preben Randhol wrote:
>
>> On 2004-03-08, Luke A. Guest <laguest@n_o_p_o_r_k_a_n_d_h_a_m.abyss2.demon.co.uk> wrote:
>>> On Mon, 08 Mar 2004 03:49:03 +0000, James Rogers wrote:
>>>
>>>> This appears to be a problem with your version. The version 3.15P
>>>> has no problems with this code.
>>>> 
>>>> Jim Rogers
>>>
>>> Sorry, but it doesn't, this is the output of my installed 3.15p version
>>> which is the same as my 5.02w version:
>>>
>>> example.adb:228:19: ambiguous expression (cannot resolve "Translate")
>>                                             ^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>Translate is another st of overloaded functions with the same signature as
>Vertex;
>
>	procedure Translate(X, Y, Z : in GLdouble);
>	procedure Translate(X, Y, Z : in GLfloat);
>
>It's just that I've 3 Translate calls and about 40 Vertex calls in my test
>program.

This is only possible if you are using literals:

   Translate (1.0, 1.0, 1.0);  -- This is ambiguous

The compiler does not knwo which kind of Float you mean.

   Translate (GLfloat (1.0), 1.0, 1.0); -- This is OK

Now the compiler has a hint.

--
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Overloading procedures with Float and Long_Float types

[David C. Hoos]

Your procedure specifications raise an interesting question, viz.:

What is the result of this procedure?  There are no out or "in out"
parameters.  I would expect something like this to either be a
function returning some kind of composite type, or to have one or
more out parameters.  Now if the "result of the procedure is some
kind of action (e.g., on the display), then these could be
legitimate procedure specifications, but in that case, it would be
better if they were given a name that describes the action taken,

As a matter of good practice, I would not use the type "Float",
but would explicitly make the two subtypes Short_Float and
Long_Float.

Some years ago, one of the Ada 83 compilers decided on the occasion
of a version upgrade to change Float from Long_Float to Short_Float
or vice-versa, I don't remember. I just remember the massive chaos
caused by the fact that many programmers (it was a large project)
had not used the project-defined types (Short_Real and Long_Real),
using Float instead.  Thins which worked with the previous
compiler version suddenly worked no more.


"Luke A. Guest" <laguest@n_o_p_o_r_k_a_n_d_h_a_m.abyss2.demon.co.uk> wrote
in message
news:pan.2004.03.08.00.17.32.527941@n_o_p_o_r_k_a_n_d_h_a_m.abyss2.demon.co.uk...
> Hi,
>
> Is there a safe way to do this? I'm playing with the adaopengl bindings
> and have created the following:
>
> subtype GLfloat is Float;
> subtype GLdouble is Standard.Long_Float;
>
> procedure Vertex(X, Y, Z : in GLdouble);
> procedure Vertex(X, Y, Z : in GLfloat);
>
> But the compiler (GNAT - Gentoo's 5.02w version) throws up ambiguity
> problems.
>
> Is there a nice way to have these two procedures co-exist without having
to
> rename them? I have currently renamed them, but this does defeat the whole
> purpose of this experiment.
>
> Thanks,
> Luke.
>
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada-france.org
> http://www.ada-france.org/mailman/listinfo/comp.lang.ada
>
>

Re: Overloading procedures with Float and Long_Float types

[Luke Guest]

> What is the result of this procedure?  There are no out or "in out"
> parameters.  I would expect something like this to either be a

It doesn't need them, this is OpenGL!

Translate calls an imported glTranslate[fd] procedure depending on the
parameter types.

> As a matter of good practice, I would not use the type "Float",
> but would explicitly make the two subtypes Short_Float and
> Long_Float.

Would this allow the compiler to determine whichprocedure to call based
purely on numbers?

Translate(1.0, 0.0, 0.0); -- Is this Short_Float or Long_Float?

Luke.

Re: Overloading procedures with Float and Long_Float types

[Luke Guest]

> >Translate is another st of overloaded functions with the same signature
as
> >Vertex;
> >
> > procedure Translate(X, Y, Z : in GLdouble);
> > procedure Translate(X, Y, Z : in GLfloat);
> >
> >It's just that I've 3 Translate calls and about 40 Vertex calls in my
test
> >program.
>
> This is only possible if you are using literals:
>
>    Translate (1.0, 1.0, 1.0);  -- This is ambiguous
>
> The compiler does not knwo which kind of Float you mean.
>
>    Translate (GLfloat (1.0), 1.0, 1.0); -- This is OK
>
> Now the compiler has a hint.

It seems that Outlook Express crap, didn't send my last reply *sigh*

It's a shame that you would have to type GLfloat(1.0) to give the compiler a
hint, is there some float notation that can differentitate bewteen FLoat's
and Long_Float's?

Basically, it just seems to be wasting a good opportunity for overloading
here.

Thanks,
Luke.

Re: Overloading procedures with Float and Long_Float types

[Preben Randhol]

On 2004-03-08, Luke Guest <lguest@bubball.com> wrote:
>
> Basically, it just seems to be wasting a good opportunity for overloading
> here.

I really don't understand why one have a Float and a Long_Float in the
first place? Why not simply have a Long_Float?


-- 
Rox-Filer; *the* file manager => http://rox.sf.net/

Re: Overloading procedures with Float and Long_Float types

[Dmitry A. Kazakov]

On Mon, 8 Mar 2004 14:05:27 -0000, "Luke Guest" <lguest@bubball.com>
wrote:

>> >Translate is another st of overloaded functions with the same signature
>as
>> >Vertex;
>> >
>> > procedure Translate(X, Y, Z : in GLdouble);
>> > procedure Translate(X, Y, Z : in GLfloat);
>> >
>> >It's just that I've 3 Translate calls and about 40 Vertex calls in my
>test
>> >program.
>>
>> This is only possible if you are using literals:
>>
>>    Translate (1.0, 1.0, 1.0);  -- This is ambiguous
>>
>> The compiler does not knwo which kind of Float you mean.
>>
>>    Translate (GLfloat (1.0), 1.0, 1.0); -- This is OK
>>
>> Now the compiler has a hint.
>
>It seems that Outlook Express crap, didn't send my last reply *sigh*
>
>It's a shame that you would have to type GLfloat(1.0) to give the compiler a
>hint, is there some float notation that can differentitate bewteen FLoat's
>and Long_Float's?

GLfloat (1.0) or better GLfloat'(1.0) is exactly that hint. It tells
that the numeric literal 1.0 has to be converted to (the first case),
or expected to be of (the second case) the designated type. How could
it be otherwise? Carefully observe that the type of 1.0 is neither
Float nor Long_Float. It is Universal_Real. (see ARM 2.4)

However, you can also *imagine* 1.0 as a set of overloaded functions:

function "1.0" return Float;
function "1.0" return Long_Float;
... -- + many others in presense of other floating/fixed-point types

as you see there is no way to decide which one you mean!

>Basically, it just seems to be wasting a good opportunity for overloading
>here.

Surely not.

Generally, oveloading is not a very brilliant idea in the case like
yours. Overloading is a way to make different things look similar.
(polymorphic as it called in OO) And what is a difference between
Float and Long_Float? The length of mantissa? This is a pure
implementation detal, which has to be hidden. IMO the actual problem
here is bad design. If you are witting an OpenGL application you have
to choose which precision is suitable for this concrete application.
If you are designing bindings to OpenGL, then it is better to place
float and double things in two different [paths of] packages. And
finally, calling subroutines with "magic" numeric literals is the most
obscure way of programming.

--
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Overloading procedures with Float and Long_Float types

[Georg Bauhaus]

Luke Guest <lguest@bubball.com> wrote:
: 
: Would this allow the compiler to determine whichprocedure to call based
: purely on numbers?
: 
: Translate(1.0, 0.0, 0.0); -- Is this Short_Float or Long_Float?

Do the numeric literals have a meaning that can be said in a word?
In this case you could declare typed constants, instead of placing
literals somewhere in a program?


-- Georg

Re: Overloading procedures with Float and Long_Float types

[Luke Guest]

"Preben Randhol" <randhol+valid_for_reply_from_news@pvv.org> wrote in
message
news:slrnc4ovhc.2eu.randhol+valid_for_reply_from_news@k-083152.nt.ntnu.no...
> On 2004-03-08, Luke Guest <lguest@bubball.com> wrote:
> >
> > Basically, it just seems to be wasting a good opportunity for
overloading
> > here.
>
> I really don't understand why one have a Float and a Long_Float in the
> first place? Why not simply have a Long_Float?

In OpenGL, there are a number of different ways to specify translations,
scales, vertices, normals, etc. GLfloat is normal single precision real
numbers, useful for games. GLdouble is useful for scientific visualisation.

Basically, it allows the programmer to pick which one to use. Games require
speed, so GLfloat is enough, scientific apps don't.

If I only provide one, the Long_Float/GLdouble variant, I'll either have to
cast it down to GLfloat and use the fast function or use the slower
function. Not an option. It's designed that way for a reason.

Luke.

Re: Overloading procedures with Float and Long_Float types

[Luke Guest]

> GLfloat (1.0) or better GLfloat'(1.0) is exactly that hint. It tells
> that the numeric literal 1.0 has to be converted to (the first case),
> or expected to be of (the second case) the designated type. How could
> it be otherwise? Carefully observe that the type of 1.0 is neither
> Float nor Long_Float. It is Universal_Real. (see ARM 2.4)

Fair enough.

> >Basically, it just seems to be wasting a good opportunity for overloading
> >here.
>
> Surely not.
>
> Generally, oveloading is not a very brilliant idea in the case like
> yours. Overloading is a way to make different things look similar.
> (polymorphic as it called in OO) And what is a difference between
> Float and Long_Float? The length of mantissa? This is a pure
> implementation detal, which has to be hidden. IMO the actual problem
> here is bad design. If you are witting an OpenGL application you have
> to choose which precision is suitable for this concrete application.
> If you are designing bindings to OpenGL, then it is better to place
> float and double things in two different [paths of] packages. And
> finally, calling subroutines with "magic" numeric literals is the most
> obscure way of programming.

Hmmm, this will also mean, that glVertex[234][is] wil cause problems here
(integer vertices). I also don't think it makes sense design wise to move
them into separate packages for int, short, float, double, as some apps
would like to mix them.

Maybe a good compromise here would be to either:

1) Not use overloading, and postfix the procedure call with the type, a la
OpenGL [FD], or
2) Move into separate packages and overload on number of parameters, a la
OpenGL [234].

Thanks,
Luke.

Re: Overloading procedures with Float and Long_Float types

[Luke Guest]

"Georg Bauhaus" <sb463ba@l1-hrz.uni-duisburg.de> wrote in message
news:c2i1f2$9d1$1@a1-hrz.uni-duisburg.de...
> Luke Guest <lguest@bubball.com> wrote:
> :
> : Would this allow the compiler to determine whichprocedure to call based
> : purely on numbers?
> :
> : Translate(1.0, 0.0, 0.0); -- Is this Short_Float or Long_Float?
>
> Do the numeric literals have a meaning that can be said in a word?
> In this case you could declare typed constants, instead of placing
> literals somewhere in a program?

Yup, good point. Some of these things will be automated, i.e. on a keypress.

Luke.

Re: Overloading procedures with Float and Long_Float types

[David C. Hoos]

----- Original Message ----- 
From: "Luke Guest" <lguest@bubball.com>
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada-france.org>
Sent: Monday, March 08, 2004 8:03 AM
Subject: Re: Overloading procedures with Float and Long_Float types


> > What is the result of this procedure?  There are no out or "in out"
> > parameters.  I would expect something like this to either be a
> 
> It doesn't need them, this is OpenGL!
> 
> Translate calls an imported glTranslate[fd] procedure depending on the
> parameter types.
>
Ah, you're calling a function with no return type which modifies a
hidden matrix, in place -- not a very good software design, IMHO.

But, if you're binding to software with a poor design, I guess you
have no choice,
 
> > As a matter of good practice, I would not use the type "Float",
> > but would explicitly make the two subtypes Short_Float and
> > Long_Float.
> 
> Would this allow the compiler to determine whichprocedure to call based
> purely on numbers?
>
No, it wouldn't -- it would just give a further measure of
compiler-independence -- a good thing.

Incidentally, in your example, you're not calling "purely with numbers."
you're calling with character representations of numbers which have, in Ada
the type Universal_Real.  You need to call with values of the type with
which you wish to select the overloaded procedure to be called.

To do this, my choice would be to use a qualified expression (RM 4.7),
rather than use a type conversion as others have suggested.

> Translate(1.0, 0.0, 0.0); -- Is this Short_Float or Long_Float?
>
Neitheer -- it's Universal_Real
 
> Luke.
> 
> 
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada-france.org
> http://www.ada-france.org/mailman/listinfo/comp.lang.ada
> 

Re: Overloading procedures with Float and Long_Float types

[Luke Guest]

> > Translate calls an imported glTranslate[fd] procedure depending on the
> > parameter types.
> >
> Ah, you're calling a function with no return type which modifies a
> hidden matrix, in place -- not a very good software design, IMHO.

Hang on. Do you know anything about OpenGL? The matrix is in hardware (or
software if the implementation is software) so, it's actually good design as
it abstracts out the matrix.

> But, if you're binding to software with a poor design, I guess you
> have no choice,

See above.

> > Would this allow the compiler to determine whichprocedure to call based
> > purely on numbers?
> >
> No, it wouldn't -- it would just give a further measure of
> compiler-independence -- a good thing.
>
> Incidentally, in your example, you're not calling "purely with numbers."
> you're calling with character representations of numbers which have, in
Ada
> the type Universal_Real.  You need to call with values of the type with
> which you wish to select the overloaded procedure to be called.
>
> To do this, my choice would be to use a qualified expression (RM 4.7),
> rather than use a type conversion as others have suggested.
>
> > Translate(1.0, 0.0, 0.0); -- Is this Short_Float or Long_Float?
> >
> Neitheer -- it's Universal_Real

Ok.

Luke.

Re: Overloading procedures with Float and Long_Float types

[Preben Randhol]

Luke Guest <lguest@bubball.com> wrote on 08/03/2004 (16:25) :
> If I only provide one, the Long_Float/GLdouble variant, I'll either have to
> cast it down to GLfloat and use the fast function or use the slower
> function. Not an option. It's designed that way for a reason.

And the reason is? How does this work in C/C++ that doesn't even have
types...

I think the design is flawed.

Either it should be:

   Translate_Double ( );

   or

   Double.Translate ( );

etc...

-- 
Preben Randhol -------------- http://www.pvv.org/~randhol/Ada95 --
                 �For me, Ada95 puts back the joy in programming.�

Re: Overloading procedures with Float and Long_Float types

[Preben Randhol]

"David C. Hoos" <david.c.hoos.sr@ada95.com> wrote on 08/03/2004 (17:05) :
> But, if you're binding to software with a poor design, I guess you
> have no choice,

Well you can do whatever you like *in* the binding to improve matters...

-- 
Preben Randhol -------------- http://www.pvv.org/~randhol/Ada95 --
                 �For me, Ada95 puts back the joy in programming.�

Re: Overloading procedures with Float and Long_Float types

[Luke Guest]

"Preben Randhol" <randhol+abuse@pvv.org> wrote in message
news:mailman.77.1078762820.327.comp.lang.ada@ada-france.org...
> Luke Guest <lguest@bubball.com> wrote on 08/03/2004 (16:25) :
> > If I only provide one, the Long_Float/GLdouble variant, I'll either have
to
> > cast it down to GLfloat and use the fast function or use the slower
> > function. Not an option. It's designed that way for a reason.
>
> And the reason is? How does this work in C/C++ that doesn't even have

Not my bindings, the original C API of OpenGL.

> types...

It works, (again) by using distinct names.

> I think the design is flawed.
>
> Either it should be:
>
>    Translate_Double ( );
>
>    or
>
>    Double.Translate ( );

So, you would have GL.Double.Translate()?

Hmmm.

Re: Overloading procedures with Float and Long_Float types

[Hyman Rosen]

Preben Randhol wrote:
> And the reason is? How does this work in C/C++ that doesn't even have types...

Don't be silly. I think everyone here has concluded that the problematic
case is where the function is being called with just literals. In Ada,
literals are univeral reals, but in C/C++ a literal like 1.0 has type
double. That means that in C++, overloading will disambiguate the call
to refer to the GLdouble version (assuming that GLdouble is double).

Re: Overloading procedures with Float and Long_Float types

[Luke Guest]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1078764620.277793@master.nyc.kbcfp.com...
> Preben Randhol wrote:
> > And the reason is? How does this work in C/C++ that doesn't even have
types...
>
> Don't be silly. I think everyone here has concluded that the problematic
> case is where the function is being called with just literals. In Ada,
> literals are univeral reals, but in C/C++ a literal like 1.0 has type
> double. That means that in C++, overloading will disambiguate the call

Hmmm, I thought that it had type float and double when 1.0lf? I *always* use
1.0f or 1.0lf depending on my needs anyway.

> to refer to the GLdouble version (assuming that GLdouble is double).

It is.

Also, the GL types would probably have to be changed to Ada types anyway to
make it easier (read "more Ada like") to use ;-)

Luke.

Re: Overloading procedures with Float and Long_Float types

[Hyman Rosen]

Luke Guest wrote:
> Hmmm, I thought that it had type float and double when 1.0lf? I *always* use
> 1.0f or 1.0lf depending on my needs anyway.

Unadorned floating literals have type double. Suffix f makes them float,
and suffix l makes them long double. There is no lf suffix.

Re: Overloading procedures with Float and Long_Float types

[Preben Randhol]

Luke Guest <lguest@bubball.com> wrote on 08/03/2004 (18:21) :
> 
> It works, (again) by using distinct names.

So in C it is called Double_Translate or something similar?
 
> So, you would have GL.Double.Translate()?

Yes. So if I use Double for a scientific application I

with GL.Double; (and possibly use GL.Double)

while in a game I would do:

with GL.Float;


-- 
Preben Randhol -------------- http://www.pvv.org/~randhol/Ada95 --
                 �For me, Ada95 puts back the joy in programming.�

Re: Overloading procedures with Float and Long_Float types

[Gautier Write-only]

Luke Guest:

> Hmmm, this will also mean, that glVertex[234][is] wil cause problems here
> (integer vertices). I also don't think it makes sense design wise to move
> them into separate packages for int, short, float, double, as some apps
> would like to mix them.
> 
> Maybe a good compromise here would be to either:
> 
> 1) Not use overloading, and postfix the procedure call with the type, a la
> OpenGL [FD], or
> 2) Move into separate packages and overload on number of parameters, a la
> OpenGL [234].

With 1) you can overload on the number of parameters, too.
What I do for OpenGL with is not to use a suffix for
'd' and 'i' (used more) and keep them for 's' and 'f'.

________________________________________________________
Gautier  --  http://www.mysunrise.ch/users/gdm/gsoft.htm

NB: For a direct answer, e-mail address on the Web site!

Re: Overloading procedures with Float and Long_Float types

[Gautier Write-only]

David C. Hoos:

> Ah, you're calling a function with no return type which modifies a
> hidden matrix, in place -- not a very good software design, IMHO.
> 
> But, if you're binding to software with a poor design, I guess you
> have no choice,

1/ I really would hesite before trashing so quickly OpenGL as a poor design...
2/ There is a choice (see my other reply).

________________________________________________________
Gautier  --  http://www.mysunrise.ch/users/gdm/gsoft.htm

NB: For a direct answer, e-mail address on the Web site!

Re: Overloading procedures with Float and Long_Float types

[Luke A. Guest]

On Mon, 08 Mar 2004 20:52:40 +0100, Gautier Write-only wrote:

> With 1) you can overload on the number of parameters, too.
> What I do for OpenGL with is not to use a suffix for
> 'd' and 'i' (used more) and keep them for 's' and 'f'.

Good point. Hmmm, myself and another are thinking about getting people
together to sort this OpenGL/Ada binding out once and for all.

Would you be interested (and anyone else for that matter)?

Luke.

Re: Overloading procedures with Float and Long_Float types

[Dmitry A. Kazakov]

On Mon, 8 Mar 2004 15:18:15 -0000, "Luke Guest" <lguest@bubball.com>
wrote:

>> Generally, oveloading is not a very brilliant idea in the case like
>> yours. Overloading is a way to make different things look similar.
>> (polymorphic as it called in OO) And what is a difference between
>> Float and Long_Float? The length of mantissa? This is a pure
>> implementation detal, which has to be hidden. IMO the actual problem
>> here is bad design. If you are witting an OpenGL application you have
>> to choose which precision is suitable for this concrete application.
>> If you are designing bindings to OpenGL, then it is better to place
>> float and double things in two different [paths of] packages. And
>> finally, calling subroutines with "magic" numeric literals is the most
>> obscure way of programming.
>
>Hmmm, this will also mean, that glVertex[234][is] wil cause problems here
>(integer vertices). I also don't think it makes sense design wise to move
>them into separate packages for int, short, float, double, as some apps
>would like to mix them.

No problem, they can always "use" the packages. In case of ambiguity
full names would resolve the problem:

GL.Long.Translate (...) vs. GL.Short.Translate (...)

>Maybe a good compromise here would be to either:
>
>1) Not use overloading, and postfix the procedure call with the type, a la
>OpenGL [FD], or
>2) Move into separate packages and overload on number of parameters, a la
>OpenGL [234].

How frequently are you going to use only "magic numbers" parameters?
If you are creating thick bindings, then for frequently used calls on
vectors like (1, 0, 0), you can give some meaningful names. Further,
thick bindings should have vector types, rather than co-ordinate
parameters:

package GL.Long is
   type Real is ...;
   type Vector is record
      X, Y, Z : Real;
   end record;
   procedure Translate (Translation_Vector : Vector);

package GL.Short is
   type Real is ...;
   type Vector is record
      X, Y, Z : Real;
   end record;
   procedure Translate (Translation_Vector : Vector);

Of course these could be instantiations of some generic package with
some floating point type as a parameter.

--
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Overloading procedures with Float and Long_Float types

[Dmitry A. Kazakov]

On Mon, 8 Mar 2004 18:58:11 +0100, Preben Randhol
<randhol+abuse@pvv.org> wrote:

>Luke Guest <lguest@bubball.com> wrote on 08/03/2004 (18:21) :
>> 
>> It works, (again) by using distinct names.
>
>So in C it is called Double_Translate or something similar?

They are called glTranslated and glTranslatef, the suffix 'd' vs. 'f'
indicates the type of the arguments.

--
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Overloading procedures with Float and Long_Float types

[Dmitry A. Kazakov]

On Mon, 8 Mar 2004 16:17:42 -0000, "Luke Guest" <lguest@bubball.com>
wrote:

>> > Translate calls an imported glTranslate[fd] procedure depending on the
>> > parameter types.
>> >
>> Ah, you're calling a function with no return type which modifies a
>> hidden matrix, in place -- not a very good software design, IMHO.
>
>Hang on. Do you know anything about OpenGL? The matrix is in hardware (or
>software if the implementation is software) so, it's actually good design as
>it abstracts out the matrix.

I does not, because it cannot. The operation has a side effect on the
graphic context, no matter whether it is a hardware or sofware one.
This side effect is the only thing the operation actually does. So
clearly, the context has to be exposed as a parameter. A good design
would have the context (or a handle to it) as an in out parameter.
Then a good design would also clarify all things concerning multiple
contexts, concurrent access to a context etc. Further a good design
would never use both float and double, provided that probably either
both are same for the underlying hardware or one of them (float?) is
extremely inefficient.

--
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de