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=0.4 required=5.0 tests=BAYES_00,FORGED_MUA_MOZILLA autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,9625531bdb853f2a X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.68.213.68 with SMTP id nq4mr12869444pbc.2.1328588311401; Mon, 06 Feb 2012 20:18:31 -0800 (PST) Path: lh20ni269181pbb.0!nntp.google.com!news1.google.com!news4.google.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: what is current status of OpenGL and Ada? Date: Tue, 07 Feb 2012 06:18:30 +0200 Organization: Tidorum Ltd Message-ID: <9pbn0lFhotU1@mid.individual.net> References: Mime-Version: 1.0 X-Trace: individual.net J5y8IpTVF+rUTvuAS+EnZAwFn4qkPR7wUVU9bNBf1ek9LzJM+u Cancel-Lock: sha1:8WBc3sN0ObmbKu89Cghen7hbzaQ= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0) Gecko/20120129 Thunderbird/10.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: 2012-02-07T06:18:30+02:00 List-Id: On 12-02-07 03:33 , BrianG wrote: > You could also try GLOBE; it's not OpenGL, but a higher-level library. > However, it contains an OpenGL binding. I haven't looked at it recently, > except to see that it gets updates, but it should be more recent than > 2003. It's also the only Ada binding I've seen that doesn't blindly > follow the C nature of the typical OpenGL function set (every function > has different named versions for the different parameter sets - which > even the OpenGL spec 'Red Book' recognizes as not needed for languages > that allow overloading "like C++ and Ada"). > > (I occasionally return to my attempt to build a binding, based on the > 'Red Book', but it doesn't hold enough interest for me to keep at it > very long. I did learn that you can't use a single name for all versions > of a function - because then you can't call it with all literal > parameters {there's no way to resolve the short/long or float/double > versions}. "No way"? Is there some reason why you cannot qualify the literals, as in Float'(3.14) versus Long_Float'(3.14)? > At a minimum, you need 2 names; I prefer to use the 2nd for > the literal case, but never came up with a reasonable naming convention.) If there are many parameters that can (all together) be either Float or Long_Float, and many calls with all-literal parameters, it is of course briefer to write a few extra letters in the function name, than to write all the type qualifiers around the literals. (In principle it is not necessary to qualify all the literal parameters; it is enough to qualify only as many as are needed to resolve the overloading, but that looks unsymmetric and unsystematic.) I know next to nothing about OpenGL or GLOBE. Are all-literal calls so sommon that writing them in a qualified form is very bad? -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .