Stylistic question: returning strings vs. pointers to strings

Stylistic question: returning strings vs. pointers to strings

[Kenneth Almquist]

Here's a question about programming style for you to debate.  I have a
package which accesses command line arguments.  My current implementa-
tion is for systems without the concept of a command line arguments;
it reads the command arguments from the standard input.  The interface
to the package consists of two functions:

	nargs - returns the number of command line arguments.
	arg(i) - returns the i'th command line argument.

Being a former C programmer, I naturally made arg(i) return a pointer
to a string, using a separate package named mytypes to contain the
definition of a pointer to a string:

	package mytypes is
	    type string_ptr is access string;
	end mytypes;

	with mytypes; use mytypes;
	package args is
	    function nargs return integer;
	    function arg(index: integer) return string_ptr;
	end args;

Since I haven't been exposed to a lot of Ada programming styles, I'd
be curious to hear from people who would specify the interface differ-
ently, for example making arg(i) return a string rather than a pointer
to a string, or making "arg" a procedure with an "out" argument like
"get_line".
				Kenneth Almquist

Re: Stylistic question: returning strings vs. pointers to strings

[Andy DeFaria]

>/ hpclapd:comp.lang.ada / ka@cs.washington.edu (Kenneth Almquist) /  3:19 pm  Mar  5, 1990 /

>Being a former C programmer, I naturally made arg(i) return a pointer
>to a string, using a separate package named mytypes to contain the
>definition of a pointer to a string:
>
>	package mytypes is
>	    type string_ptr is access string;
>	end mytypes;
>
>	with mytypes; use mytypes;
>	package args is
>	    function nargs return integer;
>	    function arg(index: integer) return string_ptr;
>	end args;

My question would be why the package mytypes?  Why not:

package ARGS is

   type ARG_PTR is access STRING;

   function NARGS                return integer;
   function ARG (index: integer) return ARG_PTR; 
 
end ARGS;

It is a tendency for C programmers to  use packages as #include files.   In
my opinion this  causes confusion.  This  example creates a  string pointer
called  ARG_PTR but by   its usage it  can   only  point to an command line
arguement. 

Re: Stylistic question: returning strings vs. pointers to strings

[Robert I. Eachus]

In article <920019@hpclapd.HP.COM> Andy DeFaria writes:

>   My question would be why the package mytypes?  Why not:

>   package ARGS is

>     type ARG_PTR is access STRING;

>     function NARGS                return integer;
>     function ARG (index: integer) return ARG_PTR; 

>  end ARGS;

     Why not return a string?  This is not the I/O case where
successive calls (for example to GET_LINE) return different values so:

  package COMMAND_LINE is

    function NARGS                return Integer;
    function ARG (Index: Integer) return String; 

  end COMMAND_LINE;

   This is conceptually much cleaner, and if it is necessary to assign
an argument string to a slice of a fixed length string it can be
easily done:

   Path: String(1..80);
   ...
 begin
   Path(1..Command_Line.Arg(1)'LENGTH) := Command_Line.Arg(1);
   ...

   This looks a little messy, but only because it is fighting the
language, which would perfer that you write:

   Path: constant String := Command_Line.Arg(1);

   this is one of those features/tricks in the language which makes
perfect sense, but only to a compiler writer.  A compiler can easily
allocate a dynamically sized object on the stack, but only if its size
never changes.  And compilers have to be able to handle Ada functions
which return values whose size cannot be determined at compile time,
because certain language primitives such as "&" work that way.  So in
Ada objects (other than records with default descriminant values) must
be constrained, but values and constants need not be.

    If the user needs to use strings designated by pointers, he can
now do it himself:

   type Pointer is access String;
   Path: Pointer;
   ...
 begin
   Path := new String'(Command_Line.Arg(1));
   ...

   This way the package need not export a new type, and need not
depend on a particular library package to provide a pointer type.  The
other alternative would be to make the string pointer type a generic
formal (and the package a generic package, but that would be overkill
in this case.

--

					Robert I. Eachus

with STANDARD_DISCLAIMER;
use  STANDARD_DISCLAIMER;
function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...

Re: Stylistic question: returning strings vs. pointers to strings

[Terry J. Westley]

In article <EACHUS.90Mar7172539@aries.aries.mitre.org> eachus@aries.mitre.org (Robert I. Eachus) writes:
>
>  package COMMAND_LINE is
>
>    function NARGS                return Integer;
>    function ARG (Index: Integer) return String; 
>
>  end COMMAND_LINE;
>

This is precisely what we have built during our evaluation of Telesoft and
Verdix compilers on Sun 4s.  Both of these compilers have Unix command line
interface packages in Ada.  But, they are different!  I love the fact that I
can build one spec (as above) with two different bodies which perform the
necessary calls to the vendor-specific packages.  Besides, neither Verdix or
Telesoft came up with something as clean and clear as Mr. Eachus shows us.

Terry J. Westley
Arvin/Calspan Advanced Technology Center
P.O. Box 400, Buffalo, NY 14225
acsu.buffalo.edu!planck!westley@hercules

Re: Stylistic question: returning strings vs. pointers to strings

[Bryce Bardin]

Come on, guys!  It should be:

  package COMMAND_LINE is

    function NARGS return Natural;
    function ARG (Index : in Positive) return String; 

  end COMMAND_LINE;