About to give up...

About to give up...

[i96danma]

Hi all!

I've been programming in Ada 95 for a while and like the language because of
it's strong type checking, OO-friendly style and clean and understandable
code.

Just recently I stepped into the world of Win32-programming and got hold of
the Win32Ada binding, which I after some effort and a lot of help (thanks
Jesper!) finally got working.

The first steps were no problem and I quickly got used to the API. The worst
problems though were the type conversions, where Ada's type checking suddenly
was an obstacle to overcome, and the fact that you always have to take care of
the return values, even if you don't care. And it seems as Win32 returns a lot
of values that are, most of the time, unimportant.

Then I wanted to go further and use the IShellFolder interface to access the
shell namespace. What do you know, the binding new nothing about that!
Besides, the binding is incomplete in a lot of other areas and I've had to
implement some functions myself.

Altogether I see these drawbacks as (almost) impossible to overcome and have
been thinking of starting to use C/C++ instead, after all it's the "native
language" of Win32. I'd like to stick to Ada, but...

I'd like some comments on the subject, is there anybody who is in the same
situation as myself, does anybody have an "easy" solution?

Regards,

Dan

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: About to give up...

[Robert Dewar]

Dan, if you are having troubles with the Win32 binding, you should report
them to your compiler vendor, assuming that they indeed support this
binding.

Robert Dewar
Ada Core Technologies

Re: About to give up...

[Dan Mattsson]

Well, since I'm on a quite tight budget (student...:) and only doing it
because it's fun and to fill my own software needs, my software (GNAT
3.10p & Win32Ada w/ Pascal Obry's patches) isn't supported.

If I was a pro, I doubt I would stick to this config.

/dan

Robert Dewar wrote:
> Dan, if you are having troubles with the Win32 binding, you should report
> them to your compiler vendor, assuming that they indeed support this
> binding.
> 
> Robert Dewar
> Ada Core Technologies

Re: About to give up...

[Robert Dewar]

Dan said

<<Well, since I'm on a quite tight budget (student...:) and only doing it
because it's fun and to fill my own software needs, my software (GNAT
3.10p & Win32Ada w/ Pascal Obry's patches) isn't supported.

If I was a pro, I doubt I would stick to this config.
>>


That configuration is most certainly NOT intended for professional use indeed.
but rather for student use. But in that mode, why not contribute a bit. Add
the missing functionality you need!

Re: About to give up...

[dennison]

In article <6qbt86$dh$1@nnrp1.dejanews.com>,
  i96danma@my-dejanews.com wrote:
> The first steps were no problem and I quickly got used to the API. The worst
> problems though were the type conversions, where Ada's type checking suddenly
> was an obstacle to overcome, and the fact that you always have to take care of
> the return values, even if you don't care. And it seems as Win32 returns a lot
> of values that are, most of the time, unimportant.

I will typically write my own binding for OS routines which returns an object
of the type I want to deal with. Bindings aren't that tough to write. Just 2
lines of code (not counting any special types you declare for them). Then
I'll write a "thick" binding which provides an Ada-like interface to the OS
routine, and doesn't burden the caller with those useless input and return
values.

Often times in dealing with OS routines written for users of type-unsafe
languages you will have to make use of Unchecked_Conversions. That's ok. Just
be careful.

As for the useless values, just put them into "Trash" variables. No big deal.

T.E.D.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: About to give up...

[i96danma]

In article <6qcblu$f60$1@nnrp1.dejanews.com>,
  dennison@telepath.com wrote:
> In article <6qbt86$dh$1@nnrp1.dejanews.com>,
>   i96danma@my-dejanews.com wrote:
>
> I will typically write my own binding for OS routines which returns an object
> of the type I want to deal with. Bindings aren't that tough to write. Just 2
> lines of code (not counting any special types you declare for them). Then
> I'll write a "thick" binding which provides an Ada-like interface to the OS
> routine, and doesn't burden the caller with those useless input and return
> values.

I've been thinking about that, but it's just such a enormous task, in small
prog without any functionality there are loads of calls just to get things
going. I want to learn _using_ the binding, not _writing_ one (although one
day I just might do that :).

> Often times in dealing with OS routines written for users of type-unsafe
> languages you will have to make use of Unchecked_Conversions. That's ok. Just
> be careful.

But, then there's no point of having strong typing at all, when half of my
time is spent getting around the typing, a new Unchecked_Allocation for every
unique combination. Phew!

> As for the useless values, just put them into "Trash" variables. No big deal.

True but tedious...

/Dan

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: About to give up...

[Robert Dewar]

Dan said

<<> As for the useless values, just put them into "Trash" variables. No big deal.

True but tedious...
>>


Tedious for who? the reader, or the writer. 

Remember that we don't care two hoots about the writer in the Ada design if
the writer's interest conflict with those of the reader.

(or maintainer!)

In fact the ease of accidentally ignoring returned values is one of the
great weaknesses in C. C almost invites programs to avoid taking the 
effort to deal with error indications.

If you *do* want to completely ignore returned result, I find a useful
notation to be

	Discard (func (params));

where Discard is an inlined null procedure that ignores its parameter.

But very often you will do better to do something like

        Check_Error (func (params));

where Check_Error checks that the returned result is OK, and raises an
exception if not.

Re: About to give up...

[Matthew Heaney]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> In fact the ease of accidentally ignoring returned values is one of the
> great weaknesses in C. C almost invites programs to avoid taking the 
> effort to deal with error indications.
> 
> If you *do* want to completely ignore returned result, I find a useful
> notation to be
> 
> 	Discard (func (params));
> 
> where Discard is an inlined null procedure that ignores its parameter.

One thing you can do in C is to explicitly cast away the return value

  (void) func (params);

This at least tells your reader that you didn't accidently ignore the
return value.

Re: About to give up...

[Robert Dewar]

Matthew says

<<One thing you can do in C is to explicitly cast away the return value

  (void) func (params);

This at least tells your reader that you didn't accidently ignore the
return value.
>>


which is of course a standard idiom, that is always used by C programmers
when they want to discard such a value :-) :-)

Re: About to give up...

[Matthew Heaney]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> Matthew says
> 
> <<One thing you can do in C is to explicitly cast away the return value
> 
>   (void) func (params);
> 
> This at least tells your reader that you didn't accidently ignore the
> return value.
> >>
> 
> 
> which is of course a standard idiom, that is always used by C programmers
> when they want to discard such a value :-) :-)

I guess you've figured out that I do most of my programming in another
language...

Re: About to give up...

[Dan Mattsson]

Robert Dewar wrote:
> 
> Dan said
> True but tedious...
> >>
> 
> Tedious for who? the reader, or the writer.
<snip> 
> If you *do* want to completely ignore returned result, I find a useful
> notation to be
> 
>         Discard (func (params));
> 
> where Discard is an inlined null procedure that ignores its parameter.
> 
> But very often you will do better to do something like
> 
>         Check_Error (func (params));
> 
> where Check_Error checks that the returned result is OK, and raises an
> exception if not.

You are right, the return codes are meant to be taken care of, but my
point is while writing the program, I want things to get things going as
quickly as possible. Then, when I'm satisfied with the structure, I
complete it with error handling and taking care of return parameters. I
am to impatient to take care of every possible event in the beginning of
a project. I implement a feature; if it works, fine, if it doesn't I add
error handling code and figure out what went wrong.

I suppose you will now say that impatience is the last quality any
programmer should have, perhaps thats true but this is how I do things.

My main problem, though, is then incompleteness of Win32Ada. I'm not
sure if either comp.lang.ada or gnatchat is the right forum for those
issues, does anybody know another mailinglist or newsgroup that deals
with them?

/Dan

Re: About to give up...

[Tom Moran]

CLAW (www.rrsoftware.com) turns Windows error return values into
exceptions.  Your first cut could certainly implement minimal
exception handlers that just open a message box or something, and you
could promise on a stack of bibles to later go back and make them do
"the right thing".  @.@

Re: About to give up...

[Robert Dewar]

>You are right, the return codes are meant to be taken care of, but my
>point is while writing the program, I want things to get things going as
>quickly as possible. Then, when I'm satisfied with the structure, I
>complete it with error handling and taking care of return parameters. I
>am to impatient to take care of every possible event in the beginning of
>a project. I implement a feature; if it works, fine, if it doesn't I add
>error handling code and figure out what went wrong.

This is a reciple for unreliable code. You are depending on testing to 
verify that your code is free of defects, but unless you do extraordinarily
extensive test backed by a formal discipline (e.g. MCDC) testing is a
notoriously bad way of showing that your code is correct. The key to
high quality code is to learn how to write correct code in the first place.

Of course there are many environments in which code does not have to be
reliable (most of the Microsoft type applications envrionment is like
that -- it is not so terrible if your system bombs every now and then, just
irritating). 

But we are talking in the Ada world of a completely different environment
in which we are aiming at large complex highly reliable programs, and 
making it easier for an impatient programmer to throw things together
fast is NOT one of the design goals of Ada :-)

About to give up...

[i96danma]

Hi all!

I've been programming in Ada 95 for a while and like the language because of
it's strong type checking, OO-friendly style and clean and understandable
code.

Just recently I stepped into the world of Win32-programming and got hold of
the Win32Ada binding, which I after some effort and a lot of help (thanks
Jesper!) finally got working.

The first steps were no problem and I quickly got used to the API. The worst
problems though were the type conversions, where Ada's type checking suddenly
was an obstacle to overcome, and the fact that you always have to take care of
the return values, even if you don't care. And it seems as Win32 returns a lot
of values that are, most of the time, unimportant.

Then I wanted to go further and use the IShellFolder interface to access the
shell namespace. What do you know, the binding new nothing about that!
Besides, the binding is incomplete in a lot of other areas and I've had to
implement some functions myself.

Altogether I see these drawbacks as (almost) impossible to overcome and have
been thinking of starting to use C/C++ instead, after all it's the "native
language" of Win32. I'd like to stick to Ada, but...

I'd like some comments on the subject, is there anybody who is in the same
situation as myself, does anybody have an "easy" solution?

Regards,

Dan

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: About to give up...

[Dale Stanbrough]

Mr i96danma@my-dejanews.com wrote:

" I've been programming in Ada 95 for a while and like the language because of
  it's strong type checking, OO-friendly style and clean and understandable
  code.
  
  Just recently I stepped into the world of Win32-programming and got hold of
  the Win32Ada binding, which I after some effort and a lot of help (thanks
  Jesper!) finally got working.
  
  The first steps were no problem and I quickly got used to the API. The worst
  problems though were the type conversions, where Ada's type checking suddenly
  was an obstacle to overcome, and the fact that you always have to take care of
  the return values, even if you don't care. And it seems as Win32 returns a lot
  of values that are, most of the time, unimportant."

I view this as being a good thing. The functions are returning a value for 
a reason (i presume!). Surely it is ignore at your peril?
If you really don't like it, or don't want an if statement at each step
you can either

   write a wrapper function to give it a procedure call syntax, which
   can either ignore the return result, or raise an exception

or

   do...

      dummy : integer range 0..0;

      dummy := some_function_call (...);

and have a constraint error exception if the function returns a dud value
(presuming 0 = ok).

 
" Altogether I see these drawbacks as (almost) impossible to overcome and have
  been thinking of starting to use C/C++ instead, after all it's the "native
  language" of Win32. I'd like to stick to Ada, but..."
  
Perhaps using the automatic bindings generator would a good way to go. Certainly
handcrafting Ada bindings is a long and laborious task.

Dale

Re: About to give up...

[Peter Amey]

Dale Stanbrough wrote:
> 
> Mr i96danma@my-dejanews.com wrote:
> 
> " I've been programming in Ada 95 for a while and like the language because of
>   it's strong type checking, OO-friendly style and clean and understandable
>   code.
> 
>   Just recently I stepped into the world of Win32-programming and got hold of
>   the Win32Ada binding, which I after some effort and a lot of help (thanks
>   Jesper!) finally got working.
> 
>   The first steps were no problem and I quickly got used to the API. The worst
>   problems though were the type conversions, where Ada's type checking suddenly
>   was an obstacle to overcome, and the fact that you always have to take care of
>   the return values, even if you don't care. And it seems as Win32 returns a lot
>   of values that are, most of the time, unimportant."
> 

I don't have any direct experience of it but doesn't CLAW from the Janus people 
provide a sensible Ada view of the Win32 world?  This might be a way of preserving 
the sanity of the original poster...

Peter

-- 
---------------------------------------------------------------------------   
      __         Peter Amey, Product Manager
        )                    Praxis Critical Systems Ltd
       /                     20, Manvers Street, Bath, BA1 1PX
      / 0        Tel: +44 (0)1225 466991
     (_/         Fax: +44 (0)1225 469006
                 http://www.praxis-cs.co.uk/
 --------------------------------------------------------------------------

Re: About to give up...

[Tom Moran]

>doesn't CLAW from the Janus people provide a sensible Ada view of the Win32 world?
That's certainly the intent of CLAW.  See www.rrsoftware.com for
description, downloadable demo (old and soon to be replaced) for
several compilers, and TriAda '97 paper giving the philosophy.

Re: About to give up...

[Oliver.Kellogg]

In article <6qbtl7$v6$1@nnrp1.dejanews.com>,
  i96danma@my-dejanews.com wrote:

> The first steps were no problem and I quickly got used to the API. The worst
> problems though were [...], and the fact that you always have to take care of
> the return values, even if you don't care. And it seems as Win32 returns a lot
> of values that are, most of the time, unimportant.

I once did a Terminal_IO package  (with procedures like
Put_At (Row,Col, Text)) where the underlying system calls
were functions that always returned a success/error status.
Since this is not usually interesting, I introduced a body-global
status flag and a function in the Terminal_IO package spec,
Get_Last_Status. That way I could turn the Terminal_IO
user level functions into procedures, and one could call
Get_Last_Status for finding out the status of the last call if
need be.

-- $0.02, Oliver

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: About to give up...

[Tarjei Tj�stheim Jensen]

Oliver.Kelloggwrote :
>I once did a Terminal_IO package  (with procedures like
>Put_At (Row,Col, Text)) where the underlying system calls
>were functions that always returned a success/error status.
>Since this is not usually interesting, I introduced a body-global
>status flag and a function in the Terminal_IO package spec,
>Get_Last_Status. That way I could turn the Terminal_IO
>user level functions into procedures, and one could call
>Get_Last_Status for finding out the status of the last call if
>need be.


I thought that this is the problems exception was intended to solve. If the low
level routine discovers an error, then throw an exception. What could be
easier?


Greetings,