Re: Ada Core Technologies announces GNATCOM

Re: Ada Core Technologies announces GNATCOM

[Ted Dennison]

In article <8ckqv5$maq$1@nnrp1.deja.com>,
  Robert Dewar <robert_dewar@my-deja.com> wrote:

> I hope people find it useful and appropriate for me to post
> such announcements here on CLA. We have discussed this in the
> past and people have said that they are interested in initial
> announcements of this kind, since it helps keep track of what
> is available.

Damn straight! Although with all the new stuff anounced in the last
month, I'm beginning to wonder if you folks at ACT have any social lives
at all.

Give eveyone there a vacation sometime soon, ok? They need to go home
and remind themselves what their families look like while they still
remember the way there. :-)

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Ada Core Technologies announces GNATCOM

[Vladimir Olensky]

Robert Dewar wrote in message <8ckqv5$maq$1@nnrp1.deja.com>...
>
>      The first general release of GNATCOM
>
>Ada 95 COM/DCOM/COM+ Development Framework and Tools
>        New York & Paris, April 7, 2000

<..>
>Thanks to GNATCOM the incredible wealth of technologies on


And thanks to David Botton who started this project one year ago
and who's efforts and devotion made this possible.

>the Windows 9X, NT and 2000 platforms become immediately
>available to Ada 95 applications

Ada Core Technologies announces GNATCOM

[Robert Dewar]

      The first general release of GNATCOM

Ada 95 COM/DCOM/COM+ Development Framework and Tools

        New York & Paris, April 7, 2000

Ada Core Technologies and ACT Europe announce the
pre-release of GNATCOM, the Ada 95 COM/DCOM/COM+ development
framework and tools.  GNATCOM is a complete kit for the
development and binding of OLE, Automation, COM, DCOM, COM+,
and ActiveX objects on all 32 bit Microsoft Windows
platforms.  As usual a public version will be made available
in the future.

GNATCOM comprises a framework covering binding and creation
of all COM (Component Object Model) technology based objects
and four powerful tools, MakeGUID, COMScope, BindCOM, and
CreateCOM.

MakeGUID generates GUIDs (Global Unique IDs).  COMScope
generates documentation from type libraries (binary headers
embedded in most COM objects).  BindCOM generates bindings
from type libraries embedded in COM objects or that describe
DLLs (frequently developers package type libraries with
regular DLLs.)  CreateCOM generates a complete COM object
from type libraries requiring only function bodies to be
filled in.

The GNATCOM framework allows for the creation of fully
compliant COM objects providing full VTBL (virtual function
table) support for custom interfaces in addition to the more
limited automation (dynamic dispatch support through the COM
interface IDispatch) used in most ActiveX controls.
Additionally, BindCOM generates bindings to both automation
and custom (VTBL based) interfaces offering the same
performance boost of C++ over other languages using COM
objects but with Ada's careful type safety features.

Thanks to GNATCOM the incredible wealth of technologies on
the Windows 9X, NT and 2000 platforms become immediately
available to Ada 95 applications.  To name just a few, XML
parsers, full control over Internet Explorer including
integration and binding to its DHTML model, Microsoft
Message Queuing, integration with Visual Basic Forms, OLEDB
and ADO (Active Data Objects), MAPI, and more.

Ada's unique combination of object-oriented, high-level
real-time control and concurrency features, coupled with the
fundamental distinction between interface and implementation
allows building the feature-rich and highly reliable objects
required by component based development.

GNATCOM tools are being distributed under the GNU GPL
licensing scheme and the GNATCOM framework is being
distributed under the GNAT modified GNU GPL used by GNATs
runtime library.

If you are considering using GNATCOM in commercial
applications, please contact our sales offices given below
for our no-cost GNATCOM evaluation package which will give
you further directions on reporting feedback on this
release.

In the U.S., contact Ada Core Technologies at:  Tel:  +1
(212) 620 7300 ext 117 Fax:  +1 (212) 807 0162 Email:
sales@gnat.com

In Europe and elsewhere, contact ACT Europe at:  Tel:  +33 1
49 70 67 16 Fax:  +33 1 49 70 05 52 Email:
sales@act-europe.fr

Robert Dewar
Ada Core Technologies

I hope people find it useful and appropriate for me to post
such announcements here on CLA. We have discussed this in the
past and people have said that they are interested in initial
announcements of this kind, since it helps keep track of what
is available.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Ada Core Technologies announces GNATCOM

[Tom Hargraves]

Please continue to post these 'announcements' to keep us up to date... but
please provide a link to more details, especially any detailed
documentation.

(a 'free download' link would be even better :-)

It might be me, but I've rummaged around the ACT web site and can't find any
reference to GNATCOM. The 'search' facility returned nothing.

Is it on another web site?

Regards,
Tom H.

Re: Ada Core Technologies announces GNATCOM

[David]

In article <38ef4a6b@rsl2.rslnet.net>,
  "Tom Hargraves" <tharg@vtcinet.com> wrote:
> Please continue to post these 'announcements' to keep us up to
date... but
> please provide a link to more details, especially any detailed
> documentation.
>
> (a 'free download' link would be even better :-)
>
> It might be me, but I've rummaged around the ACT web site and can't
find any
> reference to GNATCOM. The 'search' facility returned nothing.
>
> Is it on another web site?

As stated in the last sentence of the first paragraph of the
announcement:

"As usual a public version will be made available
in the future."




Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Ada Core Technologies announces GNATCOM

[David Starner]

On Sat, 8 Apr 2000 08:12:35 -0700, Tom Hargraves <tharg@vtcinet.com> wrote:
>Please continue to post these 'announcements' to keep us up to date... but
>please provide a link to more details, especially any detailed
>documentation.
>
>(a 'free download' link would be even better :-)

Wait until the public release. ACT releases most things as a private
release (where you can get it if you contact sales@gnat.com and hand 
over large sums of money (i.e. not practical for an individual, usually) 
to them), and latter as a public release, where you can get the program
and the documentation. If you're looking to spend the money, I'm sure
sales@gnat.com will be happy to clarify anything you want.

-- 
David Starner - dstarner98@aasaa.ofe.org
Only a nerd would worry about wrong parentheses with
square brackets. But that's what mathematicians are.
   -- Dr. Burchard, math professor at OSU

Re: Ada Core Technologies announces GNATCOM

[Robert Dewar]

In article <n8vH4.490$uE2.169608@news.pacbell.net>,
  tmoran@bix.com wrote:
> Does GNATCOM still require Gnat specific pragmas like
C_Pass_By_Copy
> or Unchecked_Union, and if so, what is the status of those as
official
> modifications to the Ada standard?


These are not exactly GNAT specific, they are implemented
in most Ada 95 compilers, in fact we copied the definition
of C_Pass_By_Copy from the Intermetrics compiler (even though
we really dislike the design, especially since it is fixing
a clear error in the RM in a kludgy way :-)

Similarly, Unchecked_Union is implemented by most Ada 95
compilers, and again we did not invent this pragma!



Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Ada Core Technologies announces GNATCOM

[Robert Dewar]

In article <38ef4a6b@rsl2.rslnet.net>,
  "Tom Hargraves" <tharg@vtcinet.com> wrote:
> Please continue to post these 'announcements' to keep us up to
date... but
> please provide a link to more details, especially any detailed
> documentation.

The release of GNATCOM includes the detailed documentation

> (a 'free download' link would be even better :-)

A public version will be made available later on.
>
> It might be me, but I've rummaged around the ACT web site and
> can't find any reference to GNATCOM. The 'search' facility
> returned nothing.

We will probably put up some more information on the web site
in the near future.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Ada Core Technologies announces GNATCOM

[David Botton]

Certain COM types require use of these pragmas. GNATCOM is for the time
being GNAT specific, but not necessarily do to these pragmas which happen to
be found on other compilers.

There are defects in the current Aonix compiler that prevent parts of the
GNATCOM binding from working properly with Object Ada. I have heard rumors
from people outside of Aonix that the next version when it will be released
may address some of those issues.

Other NT based compilers I have had access to either do not support the
pragmas and/or use different pointer models that make porting of GNATCOM
difficult.

David Botton

tmoran@bix.com wrote in message ...
>Does GNATCOM still require Gnat specific pragmas like C_Pass_By_Copy
>or Unchecked_Union, and if so, what is the status of those as official
>modifications to the Ada standard?

Re: Ada Core Technologies announces GNATCOM

[Robert Dewar]

In article <sesdk21hrfg27@corp.supernews.com>,
  "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote:

> And thanks to David Botton who started this project one year
> ago and who's efforts and devotion made this possible.

Indeed, as I assume everyone knows, David is a consultant for
Ada Core Technologies, and is indeed the prime mover behind
GNATCOM.

Robert Dewar
Ada Core Technologies


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Ada Core Technologies announces GNATCOM

[tmoran]

Does GNATCOM still require Gnat specific pragmas like C_Pass_By_Copy
or Unchecked_Union, and if so, what is the status of those as official
modifications to the Ada standard?

Re: Ada Core Technologies announces GNATCOM

[tmoran]

> > C_Pass_By_Copy or Unchecked_Union ...
>
> These are not exactly GNAT specific, they are implemented
> in most Ada 95 compilers, ...

What is the status of those as *official* modifications to the
Ada standard?

Re: Ada Core Technologies announces GNATCOM

[Larry Kilgallen]

In article <iqTH4.4563$Qy3.316083@news.pacbell.net>, tmoran@bix.com writes:
>> > C_Pass_By_Copy or Unchecked_Union ...
>>
>> These are not exactly GNAT specific, they are implemented
>> in most Ada 95 compilers, ...
> 
> What is the status of those as *official* modifications to the
> Ada standard?

I try to keep up with this newsgroup, and I have not heard anything
about any current official venue for creating a next generation of
the standard.

Conventional wisdom is that when a new generation of the standard
is created, those doing so should look first to widely implemented
add-ons to the current standard.

Given statements by Robert Dewar in the past, it seems unlikely
ACT has attempted to Patent any such additions :-)

Re: Ada Core Technologies announces GNATCOM

[Robert Dewar]

In article <iqTH4.4563$Qy3.316083@news.pacbell.net>,
  tmoran@bix.com wrote:

> What is the status of those as *official* modifications to the
> Ada standard?


under discussion


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Ada Core Technologies announces GNATCOM

[Robert Dewar]

In article <2000Apr9.073658.1@eisner>,
  Kilgallen@eisner.decus.org.nospam wrote:

> I try to keep up with this newsgroup, and I have not heard
> anything about any current official venue for creating a next
> generation of the standard.

No no, that's not what we are talking about here at all, no
official new standard activity has been started. However, the
ARG is considering individual AI's that discuss recommended
extensions, including e.g. useful pragmas and attributes as
this case.

These recommendations will be approved by WG2.1, but do not
constitute an official modification of the standard (the
word official in Tom's post was confused).

However, in practice, there is sufficient vendor and user
input into the process that once they are approved, they
are likely to be implemented in a reasonably uniform way.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Ada Core Technologies announces GNATCOM

[Robert Dewar]

In article <2000Apr9.073658.1@eisner>,
  Kilgallen@eisner.decus.org.nospam wrote:
> Conventional wisdom is that when a new generation of the
> standard is created, those doing so should look first to
> widely implemented add-ons to the current standard.

Exactly, and the ARG activity is simply a forum for trying
to provide a little structure so that these additions are
carefully discussed, and uniformly implemented, making it
more likely that the above process will work right.

> Given statements by Robert Dewar in the past, it seems
> unlikely ACT has attempted to Patent any such additions :-)

Right, definitely no patents here. Actually in the case of
these two particular extensions (Unchecked_Union and
C_Pass_By_Copy, Ada Core Technologies was not the originator
of the names or the ideas).


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Ada Core Technologies announces GNATCOM

[tmoran]

> >> > C_Pass_By_Copy or Unchecked_Union ...
> > What is the status of those as *official* modifications to the
> > Ada standard?
>
> I try to keep up with this newsgroup, and I have not heard anything
> about any current official venue for creating a next generation of
> the standard.
  I'm not concerned at this point with Ada 0X, rather with AIs or
whatever that trys to herd compiler vendors in the same direction.

>Given statements by Robert Dewar in the past, it seems unlikely
>ACT has attempted to Patent any such additions :-)
  or restrictive Copyrights :-)   But given:
> and again we did not invent this pragma!
that seems safe enough!

Re: Ada Core Technologies announces GNATCOM

[tmoran]

> ... in fact we copied the definition
> of C_Pass_By_Copy from the Intermetrics compiler (even though
> we really dislike the design, especially since it is fixing
> a clear error in the RM in a kludgy way :-)
  It does seem strange to designate a *type* as C_Pass_By_Copy
when of course it's a particular parameter to a particular
function that needs to be passed by value.  Is that your
complaint, or a different one.   What would be your
preferred solution?

Re: Ada Core Technologies announces GNATCOM

[Brian Rogoff]

On Sun, 9 Apr 2000, Marin D. Condic wrote:
> Is there some planned ISO committee or some such to start taking
> revision suggestions to the language? If Ada holds to the original model
> of a new standard every 10 or so years, I'd think now would be the time
> to start discussions.

I don't think the DOD will fund it :-(.

> Actually, I don't think Ada95 needs a whole lot of revision. 

I agree.

> The new language plugged most, if not all, of the flaws in Ada83 and I
> don't see any major new programming theories that need language support
> in which you can't get there from here. 

I'd like to see a solution to the "withing problem", convenient MI of 
interface, and downward funargs. An out mode for functions would be
great but we'll never see it, so I just hope the Rosen Trick isn't
outlawed even if it is a (very clever) hack. 

There are some restrictions on protected types that I find annoying, but
as I use mostly the sequential subset of Ada I'll let someone else whine. 

> Aside from maybe filing down a few burrs
> here and there, I think what Ada05 needs is merely some additional
> annexes that spell out more optional libraries. (Data structures? Math
> libraries? Bindings to specific platforms? I really like the model that
> exists now for annexes: "You don't have to do this if you don't want to,
> but if you *do* support this feature, it must conform to the
> following....")

This doesn't need to be standardized by ISO. A few widely used and
portable libraries would be good enough.
 
> Anybody heard of any activity from the group working on Ada libraries?

The silence is deafening.

-- Brian

Re: Ada Core Technologies announces GNATCOM

[David Starner]

On Sun, 9 Apr 2000 14:32:37 -0700, Brian Rogoff <bpr@shell5.ba.best.com> wrote:
>On Sun, 9 Apr 2000, Marin D. Condic wrote:
>> Is there some planned ISO committee or some such to start taking
>> revision suggestions to the language? If Ada holds to the original model
>> of a new standard every 10 or so years, I'd think now would be the time
>> to start discussions.
>
>I don't think the DOD will fund it :-(.

? Many other standards get standardized every 10 years, and the
DOD doesn't fund them.

-- 
David Starner - dstarner98@aasaa.ofe.org
Only a nerd would worry about wrong parentheses with
square brackets. But that's what mathematicians are.
   -- Dr. Burchard, math professor at OSU

Re: Ada Core Technologies announces GNATCOM

[Marin D. Condic]

Larry Kilgallen wrote:
> 
> I try to keep up with this newsgroup, and I have not heard anything
> about any current official venue for creating a next generation of
> the standard.
> 
Is there some planned ISO committee or some such to start taking
revision suggestions to the language? If Ada holds to the original model
of a new standard every 10 or so years, I'd think now would be the time
to start discussions.

Actually, I don't think Ada95 needs a whole lot of revision. The new
language plugged most, if not all, of the flaws in Ada83 and I don't see
any major new programming theories that need language support in which
you can't get there from here. Aside from maybe filing down a few burrs
here and there, I think what Ada05 needs is merely some additional
annexes that spell out more optional libraries. (Data structures? Math
libraries? Bindings to specific platforms? I really like the model that
exists now for annexes: "You don't have to do this if you don't want to,
but if you *do* support this feature, it must conform to the
following....")

Anybody heard of any activity from the group working on Ada libraries?

MDC
-- 
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

"I'd trade it all for just a little more"
    --  Charles Montgomery Burns, [4F10]
======================================================================

Re: Ada Core Technologies announces GNATCOM

[Gisle S�lensminde]

In article <8cqstt$c301@news.cis.okstate.edu>, David Starner wrote:
>On Sun, 9 Apr 2000 14:32:37 -0700, Brian Rogoff <bpr@shell5.ba.best.com> wrote:
>>On Sun, 9 Apr 2000, Marin D. Condic wrote:
>>> Is there some planned ISO committee or some such to start taking
>>> revision suggestions to the language? If Ada holds to the original model
>>> of a new standard every 10 or so years, I'd think now would be the time
>>> to start discussions.
>>
>>I don't think the DOD will fund it :-(.
>
>? Many other standards get standardized every 10 years, and the
>DOD doesn't fund them.

But at least for most of the ISO standards, some of the costs of the
standardisation work is funded by selling paper copies of the standard
document. That means no standard on the web, like we are used to,
For C++ the price is about $250 i think, and it will probably not be
much cheaper for a new Ada standard.

Probably some of the comitee members can give a better answer than 
me, which only knows that most other ISO/ANSI standards not is
given away for free.


--
Gisle S�lensminde ( gisle@ii.uib.no )   

ln -s /dev/null ~/.netscape/cookies

Re: Ada Core Technologies announces GNATCOM

[Marin D. Condic]

Brian Rogoff wrote:

> This doesn't need to be standardized by ISO. A few widely used and
> portable libraries would be good enough.
> 
Well, I'd like to see *some* standardization of the interfaces to any
package extensions to Ada. After all, C/C++ provides lots of
off-the-shelf utility code & other stuff that is fairly common to most
implementations. Some of it generated an Ada response (Ada.Strings comes
to mind) and I don't see what's wrong with specifying, for instance,
standard interfaces to various math libraries. Bindings to things might
be a problem because you can't control the other side of the binding,
but where we're talking utility code that is self-contained, it seems
like it would be useful to have the specs identical across all
implementations.

Of course it is very hard to get a general consensus going on what those
specs should be and what they should look like. I think that may have
been a problem with the Ada components working group. :-(

MDC
-- 
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

"I'd trade it all for just a little more"
    --  Charles Montgomery Burns, [4F10]
======================================================================

Re: Ada Core Technologies announces GNATCOM

[Hyman Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 229 bytes --]

gisle@struts.ii.uib.no (Gisle S�lensminde) writes:
> For C++ the price is about $250 i think, and it will probably not be
> much cheaper for a new Ada standard.

In the US, ANSI sells a PDF copy of the C++ Standard for $18.

Re: Ada Core Technologies announces GNATCOM

[Gisle S�lensminde]

In article <t7bt3hc1o2.fsf@calumny.jyacc.com>, Hyman Rosen wrote:
>gisle@struts.ii.uib.no (Gisle S�lensminde) writes:
>> For C++ the price is about $250 i think, and it will probably not be
>> much cheaper for a new Ada standard.
>
>In the US, ANSI sells a PDF copy of the C++ Standard for $18.

I saw that price (very approximatly converted from Swiss current)
some time ago, where you could order paper copies of standards from
ISO's webpages. Do you have an URL to where you could order
those PDF copies. Is it only the C++ standard or is other standards
also distributed this way.


--
Gisle S�lensminde ( gisle@ii.uib.no )   

ln -s /dev/null ~/.netscape/cookies

Re: Ada Core Technologies announces GNATCOM

[Hyman Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 605 bytes --]

gisle@apal.ii.uib.no (Gisle S�lensminde) writes:
> Do you have an URL to where you could order those PDF copies. Is it
> only the C++ standard or is other standards also distributed this
> way.

<http://webstore.ansi.org/>

They have tons of stuff, all much more expensive than C++.
C is $135, Ada is $210.

Just like the Ada standardizers fought the good fight to make the Ada
standard free, the C++ standardizers did pretty much the same thing to
make C++ cheap. Without that kind of effort, the standards are
prohibitively, or at least discouragingly, expensive for individuals,
which is a shame.

Re: Ada Core Technologies announces GNATCOM

[Tucker Taft]

Larry Kilgallen wrote:
>...
> I try to keep up with this newsgroup, and I have not heard anything
> about any current official venue for creating a next generation of
> the standard.
> 
> Conventional wisdom is that when a new generation of the standard
> is created, those doing so should look first to widely implemented
> add-ons to the current standard.

The Ada Rapporteur Group (ARG) of Working Group 9 (WG9) of SC-22
of ... of ISO is looking at individual amendments to the
Ada standard.  There is a conscious desire among most of us *not*
to create a new "generation" of the standard, but rather to periodically
release an amendment that captures the consensus thinking on critical
enhancements to the standard.  

In addition, we are actively working on 
a "corrigendum" document, which is an official update
to the standard for fixing bugs, as opposed to introducing enhancements,
in the Ada reference manual.  The corrigendum should be out within a year
or so, though most vendors will support the "fixes" sooner than that
(many already do).  The schedule for any amendments remains TBD.

The address "ada-comment@acm.org" is the official place to
send comments on the Ada standard.  The format for such comments
is given in the reference manual.  (Note the new address!)

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: Ada Core Technologies announces GNATCOM

[Robert Dewar]

In article <fg6I4.4981$Qy3.385311@news.pacbell.net>,
  tmoran@bix.com wrote:
> > ... in fact we copied the definition
> > of C_Pass_By_Copy from the Intermetrics compiler (even
though
> > we really dislike the design, especially since it is fixing
> > a clear error in the RM in a kludgy way :-)
>   It does seem strange to designate a *type* as C_Pass_By_Copy
> when of course it's a particular parameter to a particular
> function that needs to be passed by value.  Is that your
> complaint, or a different one.   What would be your
> preferred solution?


Fix the RM! The RM is plain wrong, just due to misunderstanding
of C. It is obvious that a record passed as an IN parameter
should map to a C struct passed as a value parameter.

But it's too late now for that (that was our initial solution
in GNAT, and perhaps we should have stuck with it).

The worst feature of C_Pass_By_Copy is the form with a byte
count giving the cutoff.

A bit of a mess here ...


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Ada Core Technologies announces GNATCOM

[Tarjei T. Jensen]

Robert Dewar wrote
>Fix the RM! The RM is plain wrong, just due to misunderstanding
>of C. It is obvious that a record passed as an IN parameter
>should map to a C struct passed as a value parameter.
>
>But it's too late now for that (that was our initial solution
>in GNAT, and perhaps we should have stuck with it).
>
>The worst feature of C_Pass_By_Copy is the form with a byte
>count giving the cutoff.


It is not neccessarily all bad. I would not be surprised if there exists a C
compilers which would pass a struct as value if it is smaller than 4 or 8 bytes
and pass them by reference if they are bigger. I seem to remember having read
about such a convention.

Greetings,

Re: Ada Core Technologies announces GNATCOM

[David Botton]

Turbo C did that and many compilers still do.

David Botton

Tarjei T. Jensen wrote in message <8d1paa$n0n4@ftp.kvaerner.com>...
>It is not neccessarily all bad. I would not be surprised if there exists a
C
>compilers which would pass a struct as value if it is smaller than 4 or 8
bytes
>and pass them by reference if they are bigger. I seem to remember having
read
>about such a convention.

Re: Ada Core Technologies announces GNATCOM

[Robert Dewar]

In article <8d1paa$n0n4@ftp.kvaerner.com>,
  "Tarjei T. Jensen" <tarjei.jensen@kvaerner.com> wrote:
> It is not neccessarily all bad. I would not be surprised if
> there exists a C compilers which would pass a struct as value
> if it is smaller than 4 or 8 bytes and pass them by reference
> if they are bigger. I seem to remember having read
> about such a convention.


You are confusing pass by reference (which is NEVER used in
C calling sequences) and pass by address (which is often used
in C calling sequences for large values, in fact one cannot
think of any other approach, the typical thing being to pass
the address of a copy.

But that's NOT what the Ada RM requires, it requires that
it be passed by reference, which has totally different
semantics.

Indeed the quoted paragraph above is EXACTLY the confusion
that caused this unsupportable design of the C_Pass_By_COpy
pragma in the first place.

There is a big difference between call by reference, where a
modification to the parameter in the C routine will cause
a change to the original, and call by address of a copy,
which will not have this effect.

Yes, its confusing, and this confusion is what lead to the
mistake

  a) in the RM, which requires IN records to be passed by
     reference instead of value.

  b) in the design of the C_Pass_By_Copy pragma, which
     extends the confusion.

Unfortunately, there is nothing much we can do at this stage
except live with a little mess here, luckily cases where C
programmers pass records as parameters (as opposed to pointers
to records) are rare.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Ada Core Technologies announces GNATCOM

[Robert Dewar]

In article <d41J4.4674$q8.993149@news-east.usenetserver.com>,
  "David Botton" <David@Botton.com> wrote:
> Turbo C did that and many compilers still do.
>
> David Botton

Since I see David sharing the confusion, perhaps an example
is appropriate

  int clobber (struct q m) {
      m.a++;
      return m.a;
  }

called in c passing a value of the struct type does NOT change
the value of the passed variable.

But the RM requires (well its AI, but in practice we have
treated it as a requirement for the purposes of
interoperability) the corresponding Ada function

   function clobber (m : q) return int;

to be interfaced by using call by reference, as a result of
which clobber will destroy the passed parameter.

But you can't unconditionally create a copy, since you may
want the reference semantics. Indeed the thought behind the
bad advice in the RM is that usually the C function will
look like

   int clobber (struct q *m) ....

in which case the call by reference is appropriate.

The effect of C_Pass_By_Copy is to force the appropriate C
calling sequence for a pass by value, i.e. assuming that the
value is reasonably large, create a copy on the calling side,
and then pass a pointer to the copy.

I hope that makes this clear, I am surprised how many people
seem incredibly confused on this issue.

Part of the trouble historically is that C did not allow
structs to be passed by value till later on, so it is not
typical C style to use this feature.

This means that indeed the most common convention for passing
records in C is to pass them by pointer, but although this is
indeed the most common case, it was a goof in the RM to leave
Ada programs with no way of passing records by value.

Remember, call-by-address and passing-in-registers are
implementation techniques.

call-by-reference and call-by-value are high level semantic
concepts.

Don't get the two confused.



Sent via Deja.com http://www.deja.com/
Before you buy.

C_Pass_By_Value, was Re: Ada Core Technologies announces GNATCOM

[tmoran]

> Fix the RM! The RM is plain wrong, just due to misunderstanding
> of C. It is obvious that a record passed as an IN parameter
> should map to a C struct passed as a value parameter.
  In K&R C a struct cannot be passed to a function.  So why not
interpret "pragma Import(C," as "sort of K&R C as far as records are
concerned" and add "pragma Import(Ansi_C," to mean "like Ansi C,
allow record parameters, and pass such IN parameters by value".
(Granted "Ansi_StdCall" would really start looking wierd, but
"Correct_StdCall" or "StdCall_ca_1995" have problems too.)

Re: Ada Core Technologies announces GNATCOM

[Robert A Duff]

Robert Dewar <robert_dewar@my-deja.com> writes:

> Indeed the quoted paragraph above is EXACTLY the confusion
> that caused this unsupportable design of the C_Pass_By_COpy
> pragma in the first place.

I don't recall it that way.  I think the reasoning was that when people
conceptually want to pass a struct in C, they usually pass a pointer to
it, so we should mimic that.  Flawed reasoning, I admit.  But surely you
don't think that the designers of Ada 9X were confused about the
difference between passing by reference, versus passing the address of a
copy?!

> Unfortunately, there is nothing much we can do at this stage
> except live with a little mess here, luckily cases where C
> programmers pass records as parameters (as opposed to pointers
> to records) are rare.

Yes.  Somehow, "rare" became "nonexistent, so don't worry about it."
*That* was the mistake.

- Bob

Re: Ada Core Technologies announces GNATCOM

[David Botton]

I am not sure I understand how I am confused, although I may very well be.

In the Turbo C version I used (some many years ago) if struct q was large
enough doing

m.a++ in the function as you do below would in fact change the m passed in,
ie. a pass by reference.

ex.

struct q z;
z.a = 5;

clobber (z);

z.a now equals 6 (providing of course that size(q) past the compiler limit
for passing by value/copy).

I even remember a "pragma" that let me play with the minimum size for pass
by copy instead of pass by reference.

Am I missing something? (most likely. If you can explain it to me, it would
be helpful.)

David Botton



>  int clobber (struct q m) {
>      m.a++;
>      return m.a;
>  }
>
>called in c passing a value of the struct type does NOT change
>the value of the passed variable.

Re: Ada Core Technologies announces GNATCOM

[David Botton]

I may be mistaken, but I believe many pre (and I mean pre) ANSI C compilers
did this.

David Botton

Hyman Rosen wrote in message ...
>"David Botton" <David@Botton.com> writes:
>> I am not sure I understand how I am confused, although I may very
>> well be. In the Turbo C version I used (some many years ago) if
>> struct q was large enough doing m.a++ in the function as you do
>> below would in fact change the m passed in, ie. a pass by reference.
>
>But this is completely erroneous for C. If you are correctly describing
>the behavior of the compiler then the compiler was broken.

Re: Ada Core Technologies announces GNATCOM

[DuckE]

To quote K&R section 6.2:
"There are a number of restrictions on C structures.  The essential rules
are that the only operations that you can perform on a structure are take
its address with &, and accesss one of its members.  This implies that
structures may not be assigned or copied as a unit, and that they can not be
passed to or returned from functions.  (These restrictions will be removed
in forthcoming versions.)"

As I recall a number of 'C' compilers considered a structure to be more like
an array than like a single variable, so structures were implicitly passed
by reference (in the same manner as arrays still are).

BTW:  I vote for the Import(Ansi_C,...)  which should solve the problem more
easily in new code.

SteveD

Re: Ada Core Technologies announces GNATCOM

[Hyman Rosen]

"David Botton" <David@Botton.com> writes:
> I am not sure I understand how I am confused, although I may very
> well be. In the Turbo C version I used (some many years ago) if
> struct q was large enough doing m.a++ in the function as you do
> below would in fact change the m passed in, ie. a pass by reference.

But this is completely erroneous for C. If you are correctly describing
the behavior of the compiler then the compiler was broken.

Re: Ada Core Technologies announces GNATCOM

[Tarjei T. Jensen]

David Botton wrote in message ...
>I may be mistaken, but I believe many pre (and I mean pre) ANSI C compilers
>did this.


That would be consistent with how I remember things.


Greetings,

Re: Ada Core Technologies announces GNATCOM

[Robert Dewar]

In article <xi4J4.2$eF.226@news-east.usenetserver.com>,
  "David Botton" <David@Botton.com> wrote:

> In the Turbo C version I used (some many years ago) if struct
> q was large enough doing

> m.a++ in the function as you do below would in fact change the
> m passed in, ie. a pass by reference.

That's a serious bug! In C, parameters are never EVER passed
by reference.

Certainly Ada does not have to be worried about interfacing
consistently to C compilers with serious bugs in them that
affect the interfacing :-)


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Ada Core Technologies announces GNATCOM

[Robert Dewar]

In article <h%4J4.690$eF.25364@news-east.usenetserver.com>,
  "David Botton" <David@Botton.com> wrote:

> I may be mistaken, but I believe many pre (and I mean pre)
> ANSI C compilers did this.

Absolutely not! This is really a very serious bug, and I
have never worked with a C compiler that had this bug. It
did not need the ANSI standard to know that C has ONLY
call by value!

Are you sure you are not confused in remembering things, and
that the situation was a struct being passed by pointer, which
is of course quite different.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Ada Core Technologies announces GNATCOM

[Robert Dewar]

In article <38f52ea8.0@news.pacifier.com>,
  "DuckE" <nospam_steved@pacifier.com> wrote:
> To quote K&R section 6.2:
> "There are a number of restrictions on C structures.  The
essential rules
> are that the only operations that you can perform on a
structure are take
> its address with &, and accesss one of its members.  This
implies that
> structures may not be assigned or copied as a unit, and that
they can not be
> passed to or returned from functions.  (These restrictions
will be removed
> in forthcoming versions.)"

Well yes, of course in the original K&R C you could not pass
struct parameters at all, so the issue does not arise.

> As I recall a number of 'C' compilers considered a structure
to be more like
> an array than like a single variable, so structures were
implicitly passed
> by reference (in the same manner as arrays still are).

I never used a C compiler this broken, although there may have
been some. It is fundamental to the C model of parameter
passing that a called function can modify the parameter without
affecting the caller. Again I wonder if you are remembering
typical C code in which structs are passed by pointer. It is
really QUITE unusual to see C code where structs are passed by
value.

There were several C compilers prior to ANSI that did implement
this extension, and implemented it correctly (gcc was one such
compiler, most certainly no version of gcc has had this serious
bug!)



>
> BTW:  I vote for the Import(Ansi_C,...)  which should solve
the problem more
> easily in new code.
>
> SteveD
>
>


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Ada Core Technologies announces GNATCOM

[Robert Dewar]

In article <wccd7nvazxw.fsf@world.std.com>,
  Robert A Duff <bobduff@world.std.com> wrote:

> Robert Dewar <robert_dewar@my-deja.com> writes:
>
> > Indeed the quoted paragraph above is EXACTLY the confusion
> > that caused this unsupportable design of the C_Pass_By_COpy
> > pragma in the first place.
>
> I don't recall it that way.  I think the reasoning was that
when people
> conceptually want to pass a struct in C, they usually pass a
pointer to
> it, so we should mimic that.  Flawed reasoning, I admit.  But
surely you
> don't think that the designers of Ada 9X were confused about
the
> difference between passing by reference, versus passing the
address of a
> copy?!

I don't understand the above paragraph in relation to the
C_Pass_By_Copy pragma as opposed to the RM. My quote above
was specifically about this pragma.

> > Unfortunately, there is nothing much we can do at this stage
> > except live with a little mess here, luckily cases where C
> > programmers pass records as parameters (as opposed to
pointers
> > to records) are rare.

> Yes.  Somehow, "rare" became "nonexistent, so don't worry
about it."
> *That* was the mistake.


Again, you seem to be talking about the RM here, the
C_Pass_By_Copy is all about dealing with the rare case???


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Ada Core Technologies announces GNATCOM

[Robert A Duff]

Robert Dewar <robert_dewar@my-deja.com> writes:

> In article <wccd7nvazxw.fsf@world.std.com>,
>   Robert A Duff <bobduff@world.std.com> wrote:
> 
> > Robert Dewar <robert_dewar@my-deja.com> writes:
> >
> > > Indeed the quoted paragraph above is EXACTLY the confusion
> > > that caused this unsupportable design of the C_Pass_By_COpy
> > > pragma in the first place.
> >
> > I don't recall it that way.  I think the reasoning was that
> when people
> > conceptually want to pass a struct in C, they usually pass a
> pointer to
> > it, so we should mimic that.  Flawed reasoning, I admit.  But
> surely you
> > don't think that the designers of Ada 9X were confused about
> the
> > difference between passing by reference, versus passing the
> address of a
> > copy?!
> 
> I don't understand the above paragraph in relation to the
> C_Pass_By_Copy pragma as opposed to the RM. My quote above
> was specifically about this pragma.

Yes, I misunderstood.  I was talking about the RM.  I thought you were
saying you don't like C_Pass_By_Copy because that should be the normal
RM behavior; the pragma is to get around a bug in the RM.

So remind me: what is "unsupportable" about the design of C_Pass_By_Copy
(other than the fact that we wish it didn't have to exist at all)?

- Bob

Re: Ada Core Technologies announces GNATCOM

[dale]

Geoff Bull wrote:

> 
> The case where pass by reference or value depended on the
> size would be fun. Add a component to a struct and the whole
> behaviour of the program changes. ouch!


... programs that rely on the semantics of the parameter passing
were deemed to be erroneous in Ada83.
Not sure if that still holds in Ada (95), or whether it is a
bounded error.

Still, this doesn't help much if your program -does- depend on it.


Dale

Re: Ada Core Technologies announces GNATCOM

[Geoff Bull]

Robert Dewar wrote:
> 
> In article <h%4J4.690$eF.25364@news-east.usenetserver.com>,
>   "David Botton" <David@Botton.com> wrote:
> 
> > I may be mistaken, but I believe many pre (and I mean pre)
> > ANSI C compilers did this.
> 
> Absolutely not! This is really a very serious bug, and I
> have never worked with a C compiler that had this bug. It
> did not need the ANSI standard to know that C has ONLY
> call by value!

I am sure I remember a compiler, possibly an early version of MS C,
that passed structs by reference.
It was obviously a bug.

The case where pass by reference or value depended on the
size would be fun. Add a component to a struct and the whole
behaviour of the program changes. ouch!

Geoff

Re: Ada Core Technologies announces GNATCOM

[Robert Dewar]

In article <wcchfd57nbn.fsf@world.std.com>,
  Robert A Duff <bobduff@world.std.com> wrote:
> So remind me: what is "unsupportable" about the design of
C_Pass_By_Copy
> (other than the fact that we wish it didn't have to exist at
all)?


The form with a pragma that says small structures should be
passed by copy, and large ones by reference. This is inspired
by the standard C convention at the implementation level of
passing small records in registers, and large registers by
address of a copy. But the pragma is about semantics not
about implementation, so it is very confused


Sent via Deja.com http://www.deja.com/
Before you buy.