Re: Unbounded Strings

Re: Unbounded Strings

[Andrew Carroll]

I read one of the list messages a few days ago about Unbounded_Strings.
I used to post here frequently about Unbounded_String and String.
If I remember correctly the post I read was about having a "universal"
string
in Ada or something like that.  I might have agreed with them a few months
ago, but now, I think it would be overkill.

I have been working with Ada for about 8 months now.  At first I struggled
with the concept of the Ada String type and the Unbounded and Bounded
length strings.  The first month or so I thought to myself "what a whacked
out language" because of all the "apparent" hassle of converting a string
to an unbounded string or vice versa and etcetera.

Then I was writting a sort of "hello world" C++ Common gateway interface
program and for the life of me I couldn't figure out why strings in C/C++
were so easy.  char * made it all clear.

I did some experimenting, thanks to Cohen's book and persistance I found
that I can define a pointer to a string type in Ada and allocate a new
string when
I want one of a different size, sort of like char* in C/C++, with the
benefits of
Ada bounds checking (if that still exist by default) and the memory
management I briefly scanned over in the last comp.lang.ada email.

So now I am using Ada like I never thought I could before and it's just as
easy,
if not easier at times than C/C++.  Once I leaned my way around the packages
that come with GNAT a bit I found myself wanting to use Ada with the Unix
Visual Editor (VI) more and my fancy GUI IDE with C++ less.

I found myself desingning more and debugging less.  There were still
problems
of course, such as pass by value or pass by reference; I didn't know what to
use
nor did I know if I had to specify it.  I found out when I created my first
graph,
you have to specify out paramter or in and out for the parameter or you get
a
copy instead of the actual "thing".

Anyway, I'm babling about the success and pleasure I have had with Ada.
I really just wanted to put my two cents in on the string thing.  I don't
think they
need to be changed.  It's the mindset of the programmer/designer that needs
to changed.

I remember wanting to switch to Ada because of a software engineering
article
I read that said Ada cut 40% off of some portion of software projects.
Maybe
it was 60%, I don't quite remember.  Anyone know of that article?  Pretty
slim
chance with my specific description of it eh?

Well, take care Ada people.

Andrew

Re: Unbounded Strings

[Preben Randhol]

On 2003-10-08, Andrew Carroll <andrew@carroll-tech.net> wrote:

First I agree with you on Strings.

> Once I leaned my way around the packages that come with GNAT a bit I
> found myself wanting to use Ada with the Unix Visual Editor (VI) more
> and my fancy GUI IDE with C++ less.

If you use Vim (Vi Improved, http://www.vim.org) you may benifit by
looking at these very useful scripts that exists for vim.

   http://vim.sourceforge.net/script.php?script_id=69
   http://vim.sourceforge.net/script.php?script_id=31
   http://vim.sourceforge.net/script.php?script_id=294
   http://vim.sourceforge.net/script.php?script_id=42
   http://vim.sourceforge.net/script.php?script_id=39
   http://vim.sourceforge.net/script.php?script_id=21
   http://vim.sourceforge.net/script.php?script_id=58
   http://vim.sourceforge.net/script.php?script_id=273

For more scripts and tips see: http://vim.sf.net

For screenshot of how my Vim looks like when I edit Ada source:

http://www.pvv.org/~randhol/vim/

(under screenshot)

Regards,

Preben
-- 
"In Ada you model the problem space, not the solution space."
                                          -- Robert I. Eachus

Re: Unbounded Strings

[Marin David Condic]

Pointers to strings are certainly possible in Ada, but that's kind of a 
sign of a C/C++ programmer trying to utilize all their C/C++ idioms in a 
different language. I remember quite a while back watching a C guy 
struggling with Ada and trying to use 'Address everywhere in passing 
parameters like strings to subroutines. He was convinced he needed to do 
that to get a "by reference" parameter because he was so conditioned to 
think that way by C. Obviously, you *can* do it that way - its just not 
necessary and really makes your life harder.

If you learn to utilize Ada's features with "Ada Idioms", you really 
don't need the pointers and dynamic allocation - at least not for normal 
string manipulation. You always *can* do it, but you don't have to do 
it. That tends to reduce the risks of dangling pointers and memory 
leaks, so you might want to try to learn "The Ada Way". :-)

MDC


Andrew Carroll wrote:
> 
> I did some experimenting, thanks to Cohen's book and persistance I found
> that I can define a pointer to a string type in Ada and allocate a new
> string when
> I want one of a different size, sort of like char* in C/C++, with the
> benefits of
> Ada bounds checking (if that still exist by default) and the memory
> management I briefly scanned over in the last comp.lang.ada email.
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Unbounded Strings

[Steve O'Neill]

Marin David Condic wrote:
> 
> Pointers to strings are certainly possible in Ada, but that's kind of a
> sign of a C/C++ programmer trying to utilize all their C/C++ idioms in a
> different language. I remember quite a while back watching a C guy
> struggling with Ada and trying to use 'Address everywhere in passing
> parameters like strings to subroutines. He was convinced he needed to do
> that to get a "by reference" parameter because he was so conditioned to
> think that way by C. Obviously, you *can* do it that way - its just not
> necessary and really makes your life harder.

My favorite abuse of 'address though still has to be code I reviewed
where
the developer had many routines where he was passing addresses of
locally
declared variables out of procedures.  This was code for a device driver
and, of course, the reasoning was that "this would be faster".

The good news was that this was caught during a review and never made it 
to the point of attempting to be run... although it would have been 
interesting to see the results.

Steve O'Neill

Re: Unbounded Strings

[Jeffrey Carter]

Andrew Carroll wrote:

> I did some experimenting, thanks to Cohen's book and persistance I found
> that I can define a pointer to a string type in Ada and allocate a new
> string when
> I want one of a different size, sort of like char* in C/C++, with the
> benefits of
> Ada bounds checking (if that still exist by default) and the memory
> management I briefly scanned over in the last comp.lang.ada email.

Basically, you have reinvented the wheel. What you have is 
Unbounded_String, but with its guts hanging out all over the place, 
instead of using information hiding as a software engineer should, and 
as Ada.Strings.Unbounded does.

> I found myself desingning more and debugging less.  There were still
> problems
> of course, such as pass by value or pass by reference; I didn't know what to
> use
> nor did I know if I had to specify it.  I found out when I created my first
> graph,
> you have to specify out paramter or in and out for the parameter or you get
> a
> copy instead of the actual "thing".

This represents a serious misunderstanding of Ada parameter modes. All 
elementary types are passed by copy, regardless of the parameter mode. 
All tagged and limited types are passed by reference, regardless of the 
parameter mode. For all other types, the compiler chooses the parameter 
mode best suited to the type. Mode in means the subprogram receives a 
value from the caller, and cannot modify it; out means the subprogram 
provides a value to the caller, and in out means the caller provides a 
value which the subprogram may modify. Parameter modes have nothing to 
do with parameter passing mechanisms. See ARM 6.2.

-- 
Jeff Carter
"I blow my nose on you."
Monty Python & the Holy Grail
03

Re: Unbounded Strings

[Mark Lorenzen]

Jeffrey Carter <spam@spam.com> writes:

> Andrew Carroll wrote:
>

[snip]

>
>> I found myself desingning more and debugging less.  There were still
>> problems
>> of course, such as pass by value or pass by reference; I didn't know what to
>> use
>> nor did I know if I had to specify it.  I found out when I created my first
>> graph,
>> you have to specify out paramter or in and out for the parameter or you get
>> a
>> copy instead of the actual "thing".
>
> This represents a serious misunderstanding of Ada parameter modes. All
> elementary types are passed by copy, regardless of the parameter
> mode. All tagged and limited types are passed by reference, regardless
> of the parameter mode. For all other types, the compiler chooses the
> parameter mode best suited to the type. Mode in means the subprogram
> receives a value from the caller, and cannot modify it; out means the
> subprogram provides a value to the caller, and in out means the caller
> provides a value which the subprogram may modify. Parameter modes have
> nothing to do with parameter passing mechanisms. See ARM 6.2.
>

Hint to Andrew: Don't think about _how_ parameters are passed (i.e. by
copy or by reference) for "For all other types" as Jeffrey says
above. Use "in", "in out" and "out" to express your _intentions_ with
the parameters. Don't worry about efficientcy - the compiler will do
"the right thing".

- Mark

Re: Unbounded Strings

[Craig Carey]

On Wed, 08 Oct 2003 18:46:18 GMT, Jeffrey Carter <spam@spam.com> wrote:
>Andrew Carroll wrote:
>> I did some experimenting, thanks to Cohen's book and persistance I found
Is that book online?
...
>All elementary types are passed by copy, regardless of the parameter mode. 
>All tagged and limited types are passed by reference, regardless of the 
>parameter mode. For all other types, the compiler chooses the parameter 
>mode best suited to the type.

Other candidates for the by-reference type include:
 * records with an aliased field
 * records with a field that is a type that is either Volatile or Atomic.

Once tagged is used, then a type can't be renamed without having to
rename all of its procedures which is adverse to my idea of a language
that ought provide strong type checking. No procedures beneath/above this
line.

Use of the limited reserved word can stop the assigning of records which
can be too inconvenient.

This is what I do: use aliased fields, and if it results in a few extra
procedures, maybe they get inlined correctly:

   ---------
   type UST is Ada.Strings.Unbounded.Unbounded_String;

   type UST_Rec is tagged
      record
         Val   : aliased UST;
      end record;

   type UST_Ptr is access constant UST;

   function Access_To (X : UST_Rec) return UST_Ptr;
   ---------

By some method, the function returns a pointer to the field.

So the parameter is aliased and the term by-reference is not getting
properly explained when there is no consideration of what it means when
there is background garbage collecting.




Craig Carey