Re: more to ada paper critic

Re: more to ada paper critic

[Grein, Christoph]

> >       -- Define the number of cards in a standard deck.
> >    subtype Deck_Index is integer range 1..52;
> 
> AFAIK this means a Deck_Index IS A integer, right? So maybe I would prefer
> "type Deck_Index is new integer range 1..52;", because an index is not
> normaly an integer. What do you say?

or even better:
    type Deck_Index is range 1..52;

> 
> > Note that this package specification defines the types Card and Deck
> > as private types. This allows another compilation unit to know that
> > there are types called Card and Deck, but not to know their
> > structure. The Ada package provides encapsulation and namespace.
> 
> Hm, but the other programmers still SEE the current structure.

No, they don't see it. Visibility is a technical term defined in the RM, and to 
be able to see something (i.e. something being visible) does not mean that you 
(as a human) can read the declaration in the Ada specification. It comes after 
the keyword private, so its invisible.

> IMHO if the
> structure should be hidden, it would be better to only declare the names of
> the types so that even other _coders_ does not know the structure.
> Like C/C++ 's header-declaration approach (if you do it right in C).

If you want to do this, you have to use access types.

> > The definitions are placed in a separate
> > file called the package body.
> 
> HAS they to be in a seperate file? I think not so. (But it is good, that
> they CAN ;-)

Depends on you compiler. E.g. Gnat wants them in separate files, Aonix doesn't.

> Are there any swap - template (or "generic" ;-) in the standard-library?

No, it's so simple.

> The difference between procedure and function seem to be, that procedure has
> in/out modifiers while function has a return-value, right? What is the
> default for functions? Are the parameter all "in" or "in out" ?

Default mod (if omitted) is in. Function can only have in.

> > Variable initialization is performed during an elaboration step
> > which is performed before normal program execution begins. This
> > ensures that the All_Decks variable is properly initialized with
> > no race conditions.
> 
> Oh come. Arent there race conditions when initializing more than these
> "before the main"s. This solution seems quite similar to C++'s problem of
> initializing global statics. Example: (forgive any syntax-errors I havent
> got GNAT to run until now ;-)
> 
> 
> function Prob1 return integer is
> begin
>   return Var2;
> end Prob1;
> 
> function Prob2 return integer is
> begin
>   return Var1;
> end Prob2;
> 
> Var1 : constant integer := Prob1;  -- Var2 unitialized, will return
                                     -- unspecified value
> Var2 : constant integer := Prob2;  -- ditto

Elaboration is done sequentially, no race condition.

> >       Cards.Deal(The_Card => This_Card, From => My_Deck);
> 
> looks funny :)

Admittedly in this case, named notation is not very useful. If you get used to 
Ada, you'll find places where it helps:

Drive (My_Car, True);

does not say you what it True. If you used named notation:

Drive (My_Car, Restricted_Use => True);

> What happens if you do not catch the exception? Will then some kind of
> terminate() be called (similar to C++?) or just reported and step on (like
> Java)?
> 
> Can I declare exceptions, so that user of my functions MUST catch the
> exception?

You need not handle the exception. If you don't your program (more exactly, the 
actual task) will die.

> > You can also see another feature of Ada syntax in this example. That is
> > the ability to pass parameters to functions and procedures by name. You
> > also see instances where they are passed by position.
> 
> Yes. But this is really only sugar and does not improve calling security.
> The most important thing about order of Parameters is, when a library
> supporter has to decide to swap Parameters of functions. Since he cannot
> decide this safely (because there might be callings without naming) it is
> almost useless to know, that user of libraries MIGHT call with secure
> naming...
> 
> The only advantage comes from more readible code.

This is more than sugar, think of arctan (y, x) versus arctan (x => y, y => x)

Confused?
 
> Or are there possibilities to force the parameter-naming? This would be
> great!

No

Re: more to ada paper critic

[Gautier direct_replies_not_read]

Immanuel Scholz:

# I havent got GNAT to run until now ;-)

Tsss! What went wrong ?
It's (say on Windows): download it, install, click furiously on every
"okay", "I agree", "I'm happy" and so on until it is finished,
eventually download AdaGIDE, install, "Yes", "I have read", etc.
Nice, isn't it ?
You can do the same with ObjectAda, a long download (~77) but
a very sexy programming environment...

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

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


_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com

Re: more to ada paper critic

[Immanuel Scholz]

Gautier direct_replies_not_read wrote:

> # I havent got GNAT to run until now ;-)
> 
> Tsss! What went wrong ?
> It's (say on Windows): download it, install, click furiously on every
> "okay", "I agree", "I'm happy" and so on until it is finished,
> eventually download AdaGIDE, install, "Yes", "I have read", etc.
> Nice, isn't it ?

The problem lies not within "GNAT", but within "Windows" ;-) I have no 
windows at home.

But nevertheless, I got it to work - at least with gnatmake, not within gcc 
who still complains that no ada compiler is installed.


> You can do the same with ObjectAda, a long download (~77) but
> a very sexy programming environment...

Can you recommend an eviroment (other than emacs or vi) to use under unix?

Immanuel Scholz

Re: more to ada paper critic

[Steve O'Neill]

Immanuel Scholz wrote:
> The problem lies not within "GNAT", but within "Windows" ;-) I have no
> windows at home.

Lucky you! :)

> Can you recommend an eviroment (other than emacs or vi) to use under unix?

There are versions of GRASP for Unix (or you could try the Java
version).  Try here:

http://www.eng.auburn.edu/department/cse/research/grasp/

Re: more to ada paper critic

[Christoph Schlegel]

"Immanuel Scholz" <news@kutzsche.net> wrote

> Can you recommend an eviroment (other than emacs or vi) to use under unix?

have a look at TIA (console ide)

http://www.vaxxine.com/pegasoft/tia.html

Christoph

Re: more to ada paper critic

[Immanuel Scholz]

Christoph Schlegel wrote:

> 
> "Immanuel Scholz" <news@kutzsche.net> wrote
> 
>> Can you recommend an eviroment (other than emacs or vi) to use under
>> unix?
> 
> have a look at TIA (console ide)

Reading the Featurelist, I thought it would be good, but after the first 5 
Minutes of playing with it I disliked it very much :-(.

- Most of the keys do not work or do not work correctly like HOME, END or 
DELETE (either using xterm or console).
- Under xterm the font is messed up from non-unicode-chars.
- Stupid CVSROOT-warning at begin (doesn't recognize that my CVSROOT points 
to an other host)
- Anoying colors - seems not to be easy configurable.

Will this become better when using it for some time?

Immanuel Scholz

Re: more to ada paper critic

[Christoph Schlegel]

Immanuel Scholz wrote:

> - Most of the keys do not work or do not work correctly like HOME, END or
> DELETE (either using xterm or console).
did not have any problems

> - Under xterm the font is messed up from non-unicode-chars.
have never used TIA with X

> - Anoying colors - seems not to be easy configurable.
never wanted to have custom-colors

> Will this become better when using it for some time?
when first using it, the program reminded me of older versions of
ms-dos-word -
the handling definitely has to be rated "individualist".
when getting used to it, it's a quite fast ide. and you get used to it
extremely fast
compared to learning vi or emacs.

anyway, maybe TIA is just not what you were looking for?

compared to Grasp it's open source (I'm not an open-source-junky,
but this may explain why some less-common errors do appear -
if there aren't enough people who at leat report errors...)

I'm using it, cause it's the only console-ide concentrating on gnat
I know of, and it's doing a pretty good job.

Christoph

Re: more to ada paper critic

[Britt Snodgrass]

Immanuel Scholz <news@kutzsche.net> wrote in message news:<aenci3$8e569$1@ID-100557.news.dfncis.de>...

> Can you recommend an eviroment (other than emacs or vi) to use under unix?
> 
> Immanuel Scholz

I like nedit (www.nedit.org).  It supports Ada syntax highlighting.
Grasp or Jgrasp would be another good option.

Britt

Re: more to ada paper critic

[Gautier direct_replies_not_read]

Immanuel Scholz:

>Oh come. Arent there race conditions when initializing more than these
>"before the main"s. This solution seems quite similar to C++'s problem
>of initializing global statics. Example: (forgive any syntax-errors I
>havent got GNAT to run until now ;-)

>function Prob1 return integer is
>begin
>   return Var2;
>end Prob1;
>
>function Prob2 return integer is
>begin
>   return Var1;
>end Prob2;
>
>Var1 : constant integer := Prob1;
>Var2 : constant integer := Prob2;

This obviously don't pass the compilation,
since Var1 and Var2 are undefined: this is the
one-pass design of Ada (like Pascal, unlike C or Fortran)

Anyway it is interesting to try.

-- -- -- -- -- -- -- -- --
procedure kiki1 is

  function Prob1 return integer is
  begin
    return Var2;
  end Prob1;

  function Prob2 return integer is
  begin
    return Var1;
  end Prob2;

  Var1 : constant integer := Prob1;
  Var2 : constant integer := Prob2;

begin
  null;
end;
-- -- -- -- -- -- -- -- --
GNAT says:
kiki1.adb:5:12: "Var2" is undefined
kiki1.adb:10:12: "Var1" is undefined

If I push a bit more and "forward" the definition of Prob1, Prob2:
-- -- -- -- -- -- -- -- --
procedure kiki2 is

  function Prob1 return integer;
  function Prob2 return integer;

  Var1 : constant integer := Prob1;
  Var2 : constant integer := Prob2;

  function Prob1 return integer is
  begin
    return Var2;
  end Prob1;

  function Prob2 return integer is
  begin
    return Var1;
  end Prob2;

begin
  null;
end;
-- -- -- -- -- -- -- -- --
GNAT compiles, but says:
kiki2.adb:6:30: warning: cannot call "Prob1" before body seen
kiki2.adb:6:30: warning: Program_Error will be raised at run time
kiki2.adb:7:30: warning: cannot call "Prob2" before body seen
kiki2.adb:7:30: warning: Program_Error will be raised at run time

Running kiki2 produces:
raised PROGRAM_ERROR : kiki2.adb:6

____________________________________________________________
Gautier  --  http://www.mysunrise.ch/users/gdm/index.htm#Ada

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


_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx

more to ada paper critic

[Immanuel Scholz]

Hi,

here a (permitted) post from an email with Jim Rogers. Maybe any of you 
find this interesting ;-) 



On Sun, Jun 16, 2002 at 10:34:15PM -0600, Jim Rogers wrote:
> Immanuel Scholz,
>
> I was thinking about some of your questions about Ada.
> I suspect you will be able to more accurately write your paper
> if you are familiar with Ada. Towards that end I have decided
> to share a small Ada programming example with you, including some
> explanations of the syntax.

Err, maybe I should not have highlighted the "paper" so much.. Actually it
is more some kind of report for my superior. I have already done this, but
unhappily I do not expect him to choose Ada as language for the project he
is planning. I think it will come up to the end with Java (except I can
persuade him that this is too slow, which will probable mean C++ - the world
is bad, 'cause you have to do things knowing they have no influence in the
last :-( ).

But personally I think I will look at Ada more closely (and maybe if I
convince one or two more members of my coding stuff to be aware of Ada, our
next project will be one ;-)

It simple looked very unprofessional, if I report a collection of languages
where Ada, likely even not known to my chief, get the best price and C got
worsest. (But I think I have prevented the worst two things: C and VB ;-)


...
>    type Card is private;
...
>    type Deck is private;

So private is not the default? Is there a default (to public?)


>       -- Define the number of cards in a standard deck.
>    subtype Deck_Index is integer range 1..52;

AFAIK this means a Deck_Index IS A integer, right? So maybe I would prefer
"type Deck_Index is new integer range 1..52;", because an index is not
normaly an integer. What do you say?


>          Deal_Next  : Deck_Index := Deck_Index'First;

I like these auto-attributes very much (like in Java the .length of array)
:-)


> Note that this package specification defines the types Card and Deck
> as private types. This allows another compilation unit to know that
> there are types called Card and Deck, but not to know their
> structure. The Ada package provides encapsulation and namespace.

Hm, but the other programmers still SEE the current structure. IMHO if the
structure should be hidden, it would be better to only declare the names of
the types so that even other _coders_ does not know the structure.
Like C/C++ 's header-declaration approach (if you do it right in C).


> The types defined in this specification are not declared to
> be "tagged" types. This prohibits any subclassing of these
> types.

Which may be a pain in future. Better had done tagged as default and needed
a "final" or something similar to forbid subclassing? Normally a class isn't
sensitive to subclassing. This is juse the exception.


> Note that none of the subprograms (functions and procedures) is yet
> defined. The package specification acts as an interface definition
> for the entire package. The definitions are placed in a separate
> file called the package body.

HAS they to be in a seperate file? I think not so. (But it is good, that
they CAN ;-)


>    ------------
>    -- Procedure Swap
>    -- Exchange two Deck_Index values
>    --------------
>    procedure Swap(Left, Right : in out Deck_Index) is
>       Temp : Deck_Index := Left;
>    begin
>       Left := Right;
>       Right := Temp;
>    end Swap;

Are there any swap - template (or "generic" ;-) in the standard-library?


>       Max_Search : Deck_Index := Deck_Index'Pred(Deck_Index'Last);

What will happen if the deck was empty?


>    procedure Deal(The_Card : out Card; From : in out Deck) is
>    function Cards_Left(In_Deck : Deck) return Natural is

The difference between procedure and function seem to be, that procedure has
in/out modifiers while function has a return-value, right? What is the
default for functions? Are the parameter all "in" or "in out" ?


> Variable initialization is performed during an elaboration step
> which is performed before normal program execution begins. This
> ensures that the All_Decks variable is properly initialized with
> no race conditions.

Oh come. Arent there race conditions when initializing more than these
"before the main"s. This solution seems quite similar to C++'s problem of
initializing global statics. Example: (forgive any syntax-errors I havent
got GNAT to run until now ;-)


function Prob1 return integer is
begin
  return Var2;
end Prob1;

function Prob2 return integer is
begin
  return Var1;
end Prob2;

Var1 : constant integer := Prob1;
Var2 : constant integer := Prob2;



>       Cards.Deal(The_Card => This_Card, From => My_Deck);

looks funny :)


> When I attempt to deal from an empty deck above I expect to encounter
> the Deck_Empty exception I defined for the Cards package. I
> execute the erroneous deal attempt within an unnamed block so that
> I can specify an exception handler for the expected exception.
> Ada exceptions are identified by name.

What happens if you do not catch the exception? Will then some kind of
terminate() be called (similar to C++?) or just reported and step on (like
Java)?

Can I declare exceptions, so that user of my functions MUST catch the
exception?


> You can also see another feature of Ada syntax in this example. That is
> the ability to pass parameters to functions and procedures by name. You
> also see instances where they are passed by position.

Yes. But this is really only sugar and does not improve calling security.
The most important thing about order of Parameters is, when a library
supporter has to decide to swap Parameters of functions. Since he cannot
decide this safely (because there might be callings without naming) it is
almost useless to know, that user of libraries MIGHT call with secure
naming...

The only advantage comes from more readible code.

Or are there possibilities to force the parameter-naming? This would be
great!


--
Immanuel Scholz,   PGP: (Work 0x9216F1E7, Home 0x3B5DC02D)

Re: more to ada paper critic

[Ted Dennison]

Immanuel Scholz <news@kutzsche.net> wrote in message news:<aekdir$7oos6$1@ID-100557.news.dfncis.de>...
> here a (permitted) post from an email with Jim Rogers. Maybe any of you 
> find this interesting ;-) 
...
> is more some kind of report for my superior. I have already done this, but
> unhappily I do not expect him to choose Ada as language for the project he

:-(
I once had to do a compiler selection report that I was ordered to
redo (with different feature empahsis) 3 times, due to the fact that
my supervisor didn't like the implied decisions. However, that
supervisor was commonly known to be a moron, and didn't last out the
year.

So I'm not unsympathetic.

> It simple looked very unprofessional, if I report a collection of languages
> where Ada, likely even not known to my chief, get the best price and C got
> worsest. (But I think I have prevented the worst two things: C and VB ;-)

Frankly, I'd consider it unprofessional to munge the data in a report
to fit someone's preferred outcome. I know it happens all the time,
but as technical people it is critical that we present an accurate
technical picture to our managers, because we are the only place they
can possibly get it from. If they end up making a choice based on
non-technical factors, fine. There are often good reasons for that.
But its *their* job to consider those factors, not ours.



> So private is not the default? Is there a default (to public?)

True. You can sort of think of it as like C++ structs (really no
different than classes, except the default is public). I don't think
that's really a big issue, either in C++ or Ada though. The common
idiom in Ada is to put everything you can in the private part, and the
common idiom in C++ seems to be to explicitly label the privacy level
rather that use the defaults.

> >       -- Define the number of cards in a standard deck.
> >    subtype Deck_Index is integer range 1..52;
> 
> AFAIK this means a Deck_Index IS A integer, right? So maybe I would prefer
> "type Deck_Index is new integer range 1..52;", because an index is not
> normaly an integer. What do you say?

It depends. If you are never going to use it with things that aren't
Deck_Index, then indeed you should make it its own type. On the other
hand, if you are going to use it with integers a lot and would hate
having to use type conversions all over the place to do so, then a
subtype is probably better. Array constraint checking will still
prevent accces past the array bounds, which is probably the most
important thing.

> >          Deal_Next  : Deck_Index := Deck_Index'First;
> 
> I like these auto-attributes very much (like in Java the .length of array)
> :-)

Actually, the best is with "for" loops, where you can just say to loop
through the array's indexes rather than supplying a range manually.
Not only is this convienent, it spells out your intent much better.
That non only helps maintainers, it helps optimizers.

> > Note that this package specification defines the types Card and Deck
> > as private types. This allows another compilation unit to know that
> > there are types called Card and Deck, but not to know their
> > structure. The Ada package provides encapsulation and namespace.
> 
> Hm, but the other programmers still SEE the current structure. IMHO if the
> structure should be hidden, it would be better to only declare the names of
> the types so that even other _coders_ does not know the structure.
> Like C/C++ 's header-declaration approach (if you do it right in C).

This must be a C++ idiom with which I'm unfamiliar. I thought C++
class declarations did not allow any part of the class's declaration
(like one of its fields) to be declared in a separate compilation.

I agree with your logic. I just don't see an easy way to do it. The
compiler has to know how big your type/class is, so it knows the code
to generate for reserving stack space for it.

There is one trick you can use in Ada though. If your private type is
an access type, you can defer the definition of the type it points to
until the package body.

> > The types defined in this specification are not declared to
> > be "tagged" types. This prohibits any subclassing of these
> > types.
> 
> Which may be a pain in future. Better had done tagged as default and needed
> a "final" or something similar to forbid subclassing? Normally a class isn't
> sensitive to subclassing. This is juse the exception.

It would be way more of a pain in C++ than it is in Ada. Ada doesn't
rely on tagged types nearly as much as C++ relies on classes. But if
you are worried you could always define it that way.

> > Note that none of the subprograms (functions and procedures) is yet
> > defined. The package specification acts as an interface definition
> > for the entire package. The definitions are placed in a separate
> > file called the package body.
> 
> HAS they to be in a seperate file? I think not so. (But it is good, that
> they CAN ;-)

With Gnat they do, but with most other Ada compilers they don't. They
have to be in another "compilation unit" (the package body, instead of
the spec). Gnat has a (unusual) restriction that there can be only one
compilation unit in a source file. Its not really much of a
restriction in practice, because I've never seen any code that had a
package body in the same file as the spec. That's not considered good
Ada style.

> Are there any swap - template (or "generic" ;-) in the standard-library?

I don't think so. Its too trivial to just make yourself. :-) Anyway, a
general case one would have to worry about wierd cases like
overlapping array slices.

> >       Max_Search : Deck_Index := Deck_Index'Pred(Deck_Index'Last);
> 
> What will happen if the deck was empty?

This is just saying that Max_Search is initialized to the second to
last value in the *type* "Deck_Index". The only possible problem I can
see with this is if Deck_Index only had one value (in which case
Constraint_Error would be raised here at runtime, if the compiler
didn't catch it for you at compile time).

> >    procedure Deal(The_Card : out Card; From : in out Deck) is
> >    function Cards_Left(In_Deck : Deck) return Natural is
> 
> The difference between procedure and function seem to be, that procedure has
> in/out modifiers while function has a return-value, right? What is the
> default for functions? Are the parameter all "in" or "in out" ?

All function parameters have to be "in" or "access". This is just like
C, where all function parameters are "in" only, and if you want
something different you have to fake it with pointers. The difference
is that Ada also gives you procedures with "out" and "in out".

> > Variable initialization is performed during an elaboration step
> > which is performed before normal program execution begins. This
> > ensures that the All_Decks variable is properly initialized with
> > no race conditions.
> 
> Oh come. Arent there race conditions when initializing more than these
> "before the main"s. This solution seems quite similar to C++'s problem of
> initializing global statics. Example: (forgive any syntax-errors I havent
> got GNAT to run until now ;-)

You are quite right. Not only can there still be race conditions
(tasks can be created during elaboration), but there can be
elaboration order dependancy issues. However, Ada does have a set of
elaboration pragmas you can use to help straighten things out if they
are starting to get hairy.

> >       Cards.Deal(The_Card => This_Card, From => My_Deck);
> 
> looks funny :)

The lack of "designated reciever" notation does look a bit odd to
those who are used to it. But one thing this means is that you can
actually dispatch on *multiple* parameters (don't get too excited,
they still have to be the same type).
 
> What happens if you do not catch the exception? Will then some kind of
> terminate() be called (similar to C++?) or just reported and step on (like
> Java)?

The task in which the exception occurred (and was not handled) will be
termiated. However, the program will continue to run if there are
other tasks in it. If it happened to be the main task, you will
probably get some kind of note that this happened to stdout or stderr,
but if it was not you will most likely see nothing. This can actually
be a bit of a problem. We generally handle this in Ada by putting a
last-ditch exception handler in every task that reports the exception
info.

> Can I declare exceptions, so that user of my functions MUST catch the
> exception?

No. There's no notation for this. There's been a great deal of
discussion lately in language design circles about whether doing this
is a good thing or not, so I'm kind of glad we didn't try out this
unproven concept in Ada.

> Yes. But this is really only sugar and does not improve calling security.
> The most important thing about order of Parameters is, when a library
> supporter has to decide to swap Parameters of functions. Since he cannot
> decide this safely (because there might be callings without naming) it is
> almost useless to know, that user of libraries MIGHT call with secure
> naming...

You can only say this because you've never used a language that has
it. Without this feature, parameters of the same type (eg: X and Y
coordinates to a draw function) can easily match with the wrong
formals. If I used named association I have an extra level of checking
that this kind of thing doesn't happen. Also, it presents an extra
level of documentation to the reader of what my code is trying to
accomplish. In addition, it insulates my code from a lot of formal
parameter changes in code I'm calling. If I use named-notation in
calling, my API can rearrange the formals to his heart's content
without causing me any grief past a blind recompile.

> The only advantage comes from more readible code.

You say that like its a small deal! Readability is *huge*, and most
design decisions in Ada were based on it.

> Or are there possibilities to force the parameter-naming? This would be
> great!
Every project I've ever worked on forced it in the coding standards,
except when calling single-parameter routines. Its kind of a shame
that Gnat doesn't include that in its style checks, but I suppose if
it really bothered me I could add it.

Re: more to ada paper critic

[Hyman Rosen]

Ted Dennison wrote:
> This must be a C++ idiom with which I'm unfamiliar. I thought C++
> class declarations did not allow any part of the class's declaration
> (like one of its fields) to be declared in a separate compilation.

You're right. I think he's talking about the so-called "pimpl" technique,
which isolates the implementation of a class into a file which is never
seen by the user. The user only sees a class which has a set of methods,
and one pointer to an implementation class.

//-----widget.h-------
class WidgetImpl; // forward declare class
class Widget
{
	auto_ptr<WidgetImpl> pImpl; // OK for WidgetImpl to be incomplete type
public:
	Widget();
	void method1();
	void method2();
};
//-----widget.cpp-----
class WidgetImpl
{
public:
	void method1() { }
	void method2() { }
};
Widget::Widget() : pImpl(new WidgetImpl) { }
void Widget::method1() { pImpl->method1(); }
void Widget::method2() { pImpl->method2(); }

Re: more to ada paper critic

[Ted Dennison]

Hyman Rosen wrote:
> Ted Dennison wrote:
> 
>> This must be a C++ idiom with which I'm unfamiliar. I thought C++
>> class declarations did not allow any part of the class's declaration
>> (like one of its fields) to be declared in a separate compilation.
> 
> 
> You're right. I think he's talking about the so-called "pimpl" technique,
> which isolates the implementation of a class into a file which is never
> seen by the user. The user only sees a class which has a set of methods,
> and one pointer to an implementation class.

Ahh. So this *is* just like using a private pointer to a deferred record 
type, except that we aren't as tempted to do it in Ada because we like 
to avoid pointers where possible.

Re: more to ada paper critic

[Eric G. Miller]

In <3D0E91AB.9080202@telepath.com>, Ted Dennison wrote:

> Hyman Rosen wrote:
>> Ted Dennison wrote:
>> 
>>> This must be a C++ idiom with which I'm unfamiliar. I thought C++
>>> class declarations did not allow any part of the class's declaration
>>> (like one of its fields) to be declared in a separate compilation.
>> 
>> 
>> You're right. I think he's talking about the so-called "pimpl" technique,
>> which isolates the implementation of a class into a file which is never
>> seen by the user. The user only sees a class which has a set of methods,
>> and one pointer to an implementation class.
> 
> Ahh. So this *is* just like using a private pointer to a deferred record 
> type, except that we aren't as tempted to do it in Ada because we like 
> to avoid pointers where possible.

In C:

/* opaque.h */
#ifndef OPAQUE_H
#define OPAQUE_H

typedef struct opaque * Opaque;

Opaque new_opaque (void);

void destroy_opaque (Opaque *);

/* other "public method" declarations */

#endif


/* opaque_P.h */
#ifndef OPAQUE_P_H
#define OPAQUE_P_H

#include "opaque.h"

struct opaque {
   /* stuff */
};

/* "private method" declarations */

#endif


/* opaque.c */
#include <stdlib.h>
#include "opaque_P.h"

Opaque new_opaque (void)
{
    Opaque this = malloc (sizeof *this);
    if (this != NULL) { /* initialize this */ }
    return this;
}

void destroy_opaque (Opaque *that)
{
   if (that != NULL && *that != NULL)
   {
       free (*that);
       *that = NULL;
   }
}

...


Give the user access to "opaque.h" only, and the user can't
easily peek into the structure contents, but must use the
defined interface.  Obviously, it still has safety problems,
but this is C after all...

Re: more to ada paper critic

[Immanuel Scholz]

Hyman Rosen wrote:
> //-----widget.h-------
> class WidgetImpl; // forward declare class
> class Widget
> {
> auto_ptr<WidgetImpl> pImpl; // OK for WidgetImpl to be incomplete type
> public:
> Widget();
> void method1();
> void method2();
> };
> //-----widget.cpp-----
> class WidgetImpl
> {
> public:
> void method1() { }
> void method2() { }
> };
> Widget::Widget() : pImpl(new WidgetImpl) { }
> void Widget::method1() { pImpl->method1(); }
> void Widget::method2() { pImpl->method2(); }

Yes, but I would do it with references instead of pointer ;-)

Immanuel Scholz