C vs. Ada - strings

C vs. Ada - strings

[Wes Groleau]

> In fact, C-style strings are quite primitive, and quite painful to work
> with, even compared to Ada 83 strings.

Two offices adjoining mine are occupied by persons
fond of saying "Ada strings suck"  Much as I prefer 
Ada in general, if it weren't for the Ada 95 string
packages, I'd have to agree with them on this point.

I've had to twice write packages similar to the Ada 95
string packages to avoid imitating other folks who
continually re-invent the same string handling logic
over and over.  I even saw one Ada file that had
three different algorithms IN THE SAME FILE for removing
leading and trailing blanks from a string.

-- 
Wes Groleau
http://freepages.genealogy.rootsweb.com/~wgroleau

Re: C vs. Ada - strings

[Ted Dennison]

In article <390F0D93.F835FAD9@ftw.rsc.raytheon.com>,
  Wes Groleau <wwgrol@ftw.rsc.raytheon.com> wrote:
>
> > In fact, C-style strings are quite primitive, and quite painful to work
> > with, even compared to Ada 83 strings.
>
> Two offices adjoining mine are occupied by persons
> fond of saying "Ada strings suck"  Much as I prefer
> Ada in general, if it weren't for the Ada 95 string
> packages, I'd have to agree with them on this point.

"if it weren't for the ...string packages"? Without the string handling
functions in C's standard library, C strings suck even worse....

--
T.E.D.

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


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

Re: C vs. Ada - strings

[Larry Kilgallen]

In article <390F0D93.F835FAD9@ftw.rsc.raytheon.com>, Wes Groleau <wwgrol@ftw.rsc.raytheon.com> writes:
> 
>> In fact, C-style strings are quite primitive, and quite painful to work
>> with, even compared to Ada 83 strings.
> 
> Two offices adjoining mine are occupied by persons
> fond of saying "Ada strings suck"  Much as I prefer 
> Ada in general, if it weren't for the Ada 95 string
> packages, I'd have to agree with them on this point.

That is the message, of course, from people who insist that
the meaning of "Ada" is now "Ada95" by default --
shortcomings in Ada83 have been recognized and addressed.

Re: C vs. Ada - strings

[Robert A Duff]

Wes Groleau <wwgrol@ftw.rsc.raytheon.com> writes:

> > In fact, C-style strings are quite primitive, and quite painful to work
> > with, even compared to Ada 83 strings.
> 
> Two offices adjoining mine are occupied by persons
> fond of saying "Ada strings suck"  Much as I prefer 
> Ada in general, if it weren't for the Ada 95 string
> packages, I'd have to agree with them on this point.

But surely not as compared to C!  If you say Ada strings suck compared
to, say, Java or Smalltalk or Common Lisp, I could agree.  But C strings
are far worse than Ada strings in pretty much every regard.  Even just
Ada 83!

- Bob

Re: C vs. Ada - strings

[Tarjei Tj�stheim Jensen]

Wes Groleau wrote:
> 
> Perhaps one needs to clarify "C strings are ... painful to work with."
> 
> I agree.  BUT, as clumsy as the C string functions are, at least they
> existed.  Ada 83 had NO standard string handling features.


And despite how limited they are supposed to be people seem to be able
to do all sorts of interesting things with them.

Somehow I think the C strings and I got along fairly well. It is about
the only thing in C which I didn't routinely screw up on. I happily
admit that from a computer science point of view they are not wonderful,
but they work. Stangely enough they work remarkably well. At least for
me.


Greetings,

Re: C vs. Ada - strings

[Ted Dennison]

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

In article <391082D9.14A9D91A@online.no>,
  "Tarjei Tj�stheim Jensen" <tarjei@online.no> wrote:
> Somehow I think the C strings and I got along fairly well. It is about
> the only thing in C which I didn't routinely screw up on. I happily
> admit that from a computer science point of view they are not
> wonderful, but they work. Stangely enough they work remarkably well.
> At least for me.

When I was first starting with C I had loads of problems with missing or
overwritten string terminators causing my programs to go off into la-la
land. It still happens to me on occasion.

--
T.E.D.

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


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

Re: C vs. Ada - strings

[Keith Thompson]

"Pascal Obry" <p.obry@wanadoo.fr> writes:
[...]
> But where did you see a C string ? In C you have a pointer to a memory
> space terminated by 'nul' !
> 
> This is not a string to me. And because C does not have strings, there is
> no operator on them you have to use strcmp, strcpy, strcat, strncmp...
> 
> Is that what a string is for C programmers :)

Serious answer: yes.

The C90 standard's definition of the term "string" is

    A string is a contiguous sequence of characters terminated by and
    including the first null character.  A "pointer to" a string is a
    pointer to its initial (lowest addressed) character.  The "length"
    of a string is the number of characters preceding the null
    character and its "value" is the sequence of the values of the
    contained characters, in order.

As for the lack of built-in operators, it's certainly nice to have "=",
":=", "<", "&", and so forth, but the fact that these are implemented
as function calls in C isn't really that big a deal.  (In other areas,
C is criticized for being too terse.)

This isn't to say that C's string handling isn't flawed.  Once of
the biggest problems is that, though a function can return a pointer
to a (variable-length) string, there's no standard way to manage the
associated memory.

-- 
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Welcome to the last year of the 20th century.

Re: C vs. Ada - strings

[Tarjei T. Jensen]

Robert A Duff wrote in message ...
>But surely not as compared to C!  If you say Ada strings suck compared
>to, say, Java or Smalltalk or Common Lisp, I could agree.  But C strings
>are far worse than Ada strings in pretty much every regard.  Even just
>Ada 83!

Whether strings suck is a matter of how easy it is to work with them, not the
number of fancy operations you can perform on them.


I'm not too keen on ada strings. I think the problem is that they do not work
the way programmers want them to work.

UCSD-Pascal (turbo pascal) got it right, Ada didn't. Ada  has a lot of other
things that is right. To a degree that compensates for what is not so
wonderful.

Greetings,

Re: C vs. Ada - strings

[Charles Hixson]

"Tarjei T. Jensen" wrote:

> ...
>
> Whether strings suck is a matter of how easy it is to work with them, not the
> number of fancy operations you can perform on them.

    ...
True within limits.  Range slices are very nice.  But so would be dynamic
resizing!  And the ability to compare different varieties.
It seems to me, that in the context of Ada it would make sense to have two kinds
of string defined initially:
Type 1, fixed would be a range of characters (<> for the range).  This would be
able to compare all subtypes.  Of course, it wouldn't allow resizing.
Type 2, Unbounded strings.  This would allow dynamic resizing, assignment, and
comparisons and assignment from the first type.
All other (system library defined) strings would be defined as subtypes of these
two.  I suppose that one could argue that there should be another two of type
wide_character...But I really want there to be only two types of string, so
instead I would want to go back and redefine the base type of the character that
the string was built on to be the ancestor of Character and Wide_Character.

A problem exists here, in that Character uses half the storage space of
Wide_Character.  I don't think that subtyping would be a good way to proceed, but
I don't want to loose the type conformance.  It's reasonably easy to define
comparison mappings between Character and Wide_Character, and even assignment
mappings aren't impossible, though one does end up with a many-to-one mapping.
But the word length requirements just don't mesh.

Now it's pretty obvious how one could define the strings if one didn't worry
about the character width issue, but how should they be defined to allow for
this?

(Just in case:  No, I'm not enrolled in a class.  This is not an assignment.  I'm
just trying to figure out how to design things in Ada [which, to me, equates to
Ada95].)

Re: C vs. Ada - strings

[Wes Groleau]

> "if it weren't for the ...string packages"? Without the string handling
> functions in C's standard library, C strings suck even worse....

Correct.  But the original statement was something like "even Ada 83
strings are better than C strings."  When criticizing C, it's not fair
to criticize it for what it is when you take away its standard
libraries.
Throughout my Ada-83 career, I have had to make extensive use of 
home-brewed code very similar to the Ada 95 sting packages.  If for some
perverted reason, I insisted on doing low-level character-twiddling all
over the place, I would have persuaded a lot of people that C is better
than Ada.

Re: C vs. Ada - strings

[Wes Groleau]

> > > In fact, C-style strings are quite primitive, and quite painful to work
> > > with, even compared to Ada 83 strings.
> >
> > Two offices adjoining mine are occupied by persons
> > fond of saying "Ada strings suck"  Much as I prefer
> > Ada in general, if it weren't for the Ada 95 string
> > packages, I'd have to agree with them on this point.
> 
> But surely not as compared to C!  If you say Ada strings suck compared
> to, say, Java or Smalltalk or Common Lisp, I could agree.  But C strings
> are far worse than Ada strings in pretty much every regard.  Even just
> Ada 83!

Perhaps one needs to clarify "C strings are ... painful to work with."

I agree.  BUT, as clumsy as the C string functions are, at least they
existed.  Ada 83 had NO standard string handling features.

-- 
Wes Groleau
http://freepages.genealogy.rootsweb.com/~wgroleau

Re: C vs. Ada - strings

[Ted Dennison]

In article <391061AF.A15CE59C@ftw.rsc.raytheon.com>,
  Wes Groleau <wwgrol@ftw.rsc.raytheon.com> wrote:
>
> Correct.  But the original statement was something like "even Ada 83
> strings are better than C strings."  When criticizing C, it's not fair
> to criticize it for what it is when you take away its standard
> libraries.
> Throughout my Ada-83 career, I have had to make extensive use of
> home-brewed code very similar to the Ada 95 sting packages.  If for

That's true. I'd still argue that *orignial* statement was right too.
But I'm probably treading the grounds of opinion there. Its a much more
debatable point.

In Ada 83's defense, I hardly ever felt like I missed better string
handling at the time. I usually had access to Ada.String.Unbounded -
like packages, and never used them. The only thing I think it really
*had* to have added was the case-conversion routines. Just about
everything else I can do fairly easily with slices, "&", and declare
blocks.

On the other hand, C's lack of these features pretty much
*required* it to come with standard string handling. Otherwise C users
would have been forced to write loops to perform even the most minor of
operations (like they are for every other type of array).

Folks who complain bitterly about Ada's strings usually never figured
out how to properly work with them (or perhaps never *bothered* to
figure it out). The mindset is very much different from C's.

So how do I summarize this? If we are talking about comparing the
languages themselves, C's strings clearly suck. If we include the
standard libraries in our comparison, they only suck when compared to
Ada 95. :-)

And no matter how you look at it, C's arrays suck.

--
T.E.D.

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


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

Re: C vs. Ada - strings

[Pascal Obry]

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


Ted Dennison a �crit dans le message <8en5o9$ihe$1@nnrp1.deja.com>...
>In article <390F0D93.F835FAD9@ftw.rsc.raytheon.com>,
>"if it weren't for the ...string packages"? Without the string handling
>functions in C's standard library, C strings suck even worse....
>


But where did you see a C string ? In C you have a pointer to a memory
space terminated by 'nul' !

This is not a string to me. And because C does not have strings, there is
no operator on them you have to use strcmp, strcpy, strcat, strncmp...

Is that what a string is for C programmers :)

Pascal.

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--|
--| "The best way to travel is by means of imagination"

Re: C vs. Ada - strings

[Wes Groleau]

> This isn't to say that C's string handling isn't flawed.  Once of
> the biggest problems is that, though a function can return a pointer
> to a (variable-length) string, there's no standard way to manage the
> associated memory.

Another is that it's easy to feed an array of char
with no null terminator to a string function.


-- 
Wes Groleau
http://freepages.genealogy.rootsweb.com/~wgroleau

Re: C vs. Ada - strings

[Robert Dewar]

In article <t7em7icn8e.fsf@calumny.jyacc.com>,
  Hyman Rosen <hymie@prolifics.com> wrote:

> Actually, it's unspecified. Some could be true and some could
be false
> within the same program. (We're talking about C (or C++), of
course.)


unspecified = implementation dependent (just a different set
of terminology, but the equivalence is precise -- note that
I did NOT write implementation defined, which is different).



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

Re: C vs. Ada - strings

[Charles Hixson]

Robert Dewar wrote:

> ...
>
> Personally, I think the string packages in Ada are far more
> flexible and useful than those in Turbo Pascal, for many
> reasons (in particular the lack of control over heap
> allocation), but it would be interesting to be more specific
> about what *you* personally don't like, than making general
> statements with no basis about what all programmers like :-)
> ....

But the real improvement of Ada Strings over TurboPascal strings is
that if you don't like the current implementation, it's easier to
define your own (without loss of capability).

Re: C vs. Ada - strings

[Robert A Duff]

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

> Strings in Ada are too boring, it's much more exciting to code
> in a language where
> 
>   if ("abc" == "abc")
> 
> has implementation dependent semantics, and keeps you in
> suspense on the outcome :-)

"Exciting", eh?  Are you trying to demonstrate the truth of what I said
in another thread:

> ...  I think there are lots of programmers who like
> languages for reasons other than the quality of the resulting programs.

?

;-)

> At least I think it's impl dependent -- perhaps I remembered
> wrong, and it's always false :-)

I think you remembered correctly.

- Bob

Re: C vs. Ada - strings

[Robert Dewar]

In article <wcc7lda9qzc.fsf@world.std.com>,
  Robert A Duff <bobduff@world.std.com> wrote:
> > At least I think it's impl dependent -- perhaps I remembered
> > wrong, and it's always false :-)
>
> I think you remembered correctly.
>
> - Bob


I guess it's always false in K&R, unspecified in ANSI, is that
right?


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

Re: C vs. Ada - strings

[Jon S Anthony]

Hyman Rosen wrote:
> 
> Robert Dewar <robert_dewar@my-deja.com> writes:
> > Strings in Ada are too boring, it's much more exciting to code
> > in a language where
> >   if ("abc" == "abc")
> > has implementation dependent semantics, and keeps you in
> > suspense on the outcome :-)
> > At least I think it's impl dependent -- perhaps I remembered
> > wrong, and it's always false :-)
> 
> Actually, it's unspecified. ...

That's what implementation dependent _means_.

/Jon

-- 
Jon Anthony
Synquiry Technologies, Ltd. Belmont, MA 02478, 617.484.3383
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: C vs. Ada - strings

[Ole-Hjalmar Kristensen]

Ted Dennison <dennison@telepath.com> writes:

> In article <390F0D93.F835FAD9@ftw.rsc.raytheon.com>,
>   Wes Groleau <wwgrol@ftw.rsc.raytheon.com> wrote:
> >
> > > In fact, C-style strings are quite primitive, and quite painful to work
> > > with, even compared to Ada 83 strings.
> >
> > Two offices adjoining mine are occupied by persons
> > fond of saying "Ada strings suck"  Much as I prefer
> > Ada in general, if it weren't for the Ada 95 string
> > packages, I'd have to agree with them on this point.
> 
> "if it weren't for the ...string packages"? Without the string handling
> functions in C's standard library, C strings suck even worse....
> 
> --
> T.E.D.

Yes, but the C standard library *is* there. The Ada 95 string packages
aren't there in Ada 83.

> 
> http://www.telepath.com/~dennison/Ted/TED.html
> 
> 
> Sent via Deja.com http://www.deja.com/
> Before you buy.

-- 
E pluribus Unix

Re: C vs. Ada - strings

[Gautier]

Ole-Hjalmar Kristensen:

> Yes, but the C standard library *is* there. The Ada 95 string packages
> aren't there in Ada 83.

NB: the operators for type String are in Ada 83 also in Standard
package (no need of "with/use")

In Ada 83 you can write things like

  get_line( s, l );
  s1(1..n):= s2 & '-' & s3(1..5);
  return "Result " & integer'image( n );
  declare img_tag: constant string:= "<img src=" & srcname & " >";

or use s( a..b ) as a variable (to pass as out parameter) and so on...

That's not nothing...

_____________________________________________
Gautier  --  http://members.xoom.com/gdemont/

Re: C vs. Ada - strings

[Robert Dewar]

In article <wccg0s066nn.fsf@world.std.com>,
  Robert A Duff <bobduff@world.std.com> wrote:
> But surely not as compared to C!  If you say Ada strings suck
compared
> to, say, Java or Smalltalk or Common Lisp, I could agree.  But
C strings
> are far worse than Ada strings in pretty much every regard.
Even just
> Ada 83!


Strings in Ada are too boring, it's much more exciting to code
in a language where

  if ("abc" == "abc")

has implementation dependent semantics, and keeps you in
suspense on the outcome :-)

At least I think it's impl dependent -- perhaps I remembered
wrong, and it's always false :-)



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

Re: C vs. Ada - strings

[Robert Dewar]

In article <8eons4$sqj4@ftp.kvaerner.com>,
  "Tarjei T. Jensen" <tarjei.jensen@kvaerner.com> wrote:
> I'm not too keen on ada strings. I think the problem is that
> they do not work the way programmers want them to work.

Well that's obviously a bit of a specious statement. The string
packages in Ada were designed by programmers who made them work
EXACTLY as they wanted them to work.

Now different people may have different ideas, but the idea you
imply of a string package coming from who-knows-where that is
universally at odds with what "programmers" want is silly.

What would be more useful is to specifically say what "you"
would like to see.

Personally, I think the string packages in Ada are far more
flexible and useful than those in Turbo Pascal, for many
reasons (in particular the lack of control over heap
allocation), but it would be interesting to be more specific
about what *you* personally don't like, than making general
statements with no basis about what all programmers like :-)


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

Re: C vs. Ada - strings

[Hyman Rosen]

Robert Dewar <robert_dewar@my-deja.com> writes:
> Strings in Ada are too boring, it's much more exciting to code
> in a language where
>   if ("abc" == "abc")
> has implementation dependent semantics, and keeps you in
> suspense on the outcome :-)
> At least I think it's impl dependent -- perhaps I remembered
> wrong, and it's always false :-)

Actually, it's unspecified. Some could be true and some could be false
within the same program. (We're talking about C (or C++), of course.)

Re: C vs. Ada - strings

[Robert Dewar]

In article <87k8h9v1iy.fsf@deneb.cygnus.argh.org>,
  Florian Weimer <fw-usenet@deneb.cygnus.argh.org> wrote:

> A direct Ada translation would be a bit more complicated
> because you would have to keep track both of the start and the
> end of the tokens.

Why? there is nothing wrong with using a string terminator
in an Ada context if that is convenient. Indeed you can take
the C "string" facility, and map it into Ada in a pretty
direct fashion if you like (the inclusion in the language
of aliased and 'Access was motivated precisely by this kind
of example!)



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

Re: C vs. Ada - strings

[Ted Dennison]

In article <87k8h9v1iy.fsf@deneb.cygnus.argh.org>,
  Florian Weimer <fw-usenet@deneb.cygnus.argh.org> wrote:

> I have only worked with the GNAT implementation of the standard Ada
> strings, and two things annoy me particularly: First, the bounded
> strings tend to increase code size and compile time considerably.  The
> string package Gautier mentioned could be used as a replacement in
> places where this is a concern, and perhaps the bounded strings can be
> implemented on top of it, reducing code bloat.

I went away from bounded strings in OpenToken for just that reason.
You'd think that they'd be similar in speed to using stack-allocated
strings with an associated length variable. But in Gnat at least that is
not even close to true. It almost seemed as if every simple operation
was causing the whole string to get copied.

--
T.E.D.

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


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

Re: C vs. Ada - strings

[Florian Weimer]

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

> In article <wcc7lda9qzc.fsf@world.std.com>,
>   Robert A Duff <bobduff@world.std.com> wrote:
> > > At least I think it's impl dependent -- perhaps I remembered
> > > wrong, and it's always false :-)
> >
> > I think you remembered correctly.

> I guess it's always false in K&R, unspecified in ANSI, is that
> right?

I'm sure that back in the old days, C didn't have string constants.
Occasionally, you still see things like

        mktemp("/tmp/fileXXXXXX"),

and mktemp() does write to the array argument.  (Of course, you should
never-ever use mktemp(), tmpnam() or tempnam().  Note that there is at
least one Ada implementation which uses tmpnam() internally to create
a name name for Ada temporary files, so be careful there as well.)

Of course, nowadays, there are compilers which merge identical string
constants, and linkers which put string constants into read-only data
sections, and C99 says indeed:

| It is unspecified whether these arrays are distinct provided their
| elements have the appropriate values.  If the program attempts to
| modify such an array, the behavior is undefined.

Re: C vs. Ada - strings

[Florian Weimer]

Wes Groleau <wwgrol@ftw.rsc.raytheon.com> writes:

> Two offices adjoining mine are occupied by persons
> fond of saying "Ada strings suck"

I've just written a parser for small, regular language -- in C.  For
these kind of jobs, C strings are quite handy, and I even think that
the code is easy to read (it reuses the same idiom many times: keep
a pointer to the beginning of the token, iterate over the token and
replace the character delimiting it from the next token by a '\0', and
finally skip additional delimiters).  Of course, this only works if
you're dealing with text strings, if you are dealing with binary data,
you can't use in-band signalling of string terminators.

A direct Ada translation would be a bit more complicated because you
would have to keep track both of the start and the end of the tokens.
Copying the token to a different, unbounded string variable is perhaps
a translation which is more appropriate and even more readable than
the C solution.  Obviously, you can't do this in standard C because
there are no unbounded strings.  Each time you have to create strings
whose maximum length is not given at compile time, you have to use
heap allocation and worry about all the consequences.  I find this
rather unacceptable because unbounded strings are quite common.

> I've had to twice write packages similar to the Ada 95
> string packages to avoid imitating other folks who
> continually re-invent the same string handling logic
> over and over.

Most probably, I'll write my own string package some day, but entirely
due to efficiency considerations.  In fact, I'm going mimic the
standard Ada interface as closely as possible.

I have only worked with the GNAT implementation of the standard Ada
strings, and two things annoy me particularly: First, the bounded
strings tend to increase code size and compile time considerably.  The
string package Gautier mentioned could be used as a replacement in
places where this is a concern, and perhaps the bounded strings can be
implemented on top of it, reducing code bloat.

Second, the unbounded strings are inefficient to a degree that it
starts to irritate people.  (There even was a thread with this topic
a few weeks ago.)  A reference-count based implementations could
be considerably faster: you could preallocate storage so that you
don't have to use an allocator and copy the entire string each time
you add a character to the string, you could take into account that
storage is allocated in chunks of certain sizes (for example, the
smallest data chunck allocated by GNU malloc is 12 bytes large on
32 bit platforms), you don't have to use allocators constantly if
you pass around strings, and so on.  I'm sure such an implemention
will greatly increase overall performance, although it is much more
complicated than the current one.

Unfortunately, it is difficult to exactly duplicate the semantics
of the standard Ada unbouded strings.  Standard Ada strings are
immutable, but with some reference count tricks, you can even do
in-place modification without losing immutability.  Another issue is
perhaps more problematic: At first, reference counts are not task
at all.  But a task-safe implementation does not require extensive
locking if the hardware provides atomic load-increment-store and
load-decrement-store-compare-to-zero operations on integers of a
suitable size (e.g., 32 bits and more).  The x86 architecture does
have these operations (and for this kind of application, they are even
completely SMP-safe), but these instructions look very CISCy, so they
are probably not available on other architectures.

At the moment, I'm not sure if mimicking the Ada semantics of
unbounded strings is worth the trouble at all.  Perhaps it's better to
make the strings with reference counts mutable.  (Immutable strings
which aren't safe for tasking aren't an option.  I'm sure people tend
to forget that they're unsafe, and the resulting bugs are horribly to
debug.)

Re: C vs. Ada - strings

[Pascal Obry]

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


Florian Weimer a �crit dans le message
<87og6lv6ix.fsf@deneb.cygnus.argh.org>...
>and mktemp() does write to the array argument.  (Of course, you should
>never-ever use mktemp(), tmpnam() or tempnam().  Note that there is at
>least one Ada implementation which uses tmpnam() internally to create
>a name name for Ada temporary files, so be careful there as well.)

Can you enlight us about why one should not use tmpnam() and tempnam() ?

Just that it is not clear to me... I'am not a fan C programmer :)

Pascal.

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--|
--| "The best way to travel is by means of imagination"

Re: C vs. Ada - strings

[Hyman Rosen]

"Pascal Obry" <p.obry@wanadoo.fr> writes:
> Can you enlight us about why one should not use tmpnam() and tempnam() ?

Because they just give you a filename without opening it. A file by that
name did not exist at the moment when tmpnam() decided that it was OK to
return it to you, but that gives you no information about its existence
at the time you actually want to use that filename.

Re: C vs. Ada - strings

[Tarjei Tj�stheim Jensen]

Robert Dewar wrote:
> 
>Tarjei T. Jensen wrote:
>> I'm not too keen on ada strings. I think the problem is that
>> they do not work the way programmers want them to work.
>
> What would be more useful is to specifically say what "you"
> would like to see.
> 

I think we have covered that quite extensively in this and the
"desirability of C++ thread.


Greetings,

Re: C vs. Ada - strings

[Tarjei Tj�stheim Jensen]

Florian Weimer wrote:
> 
> 
> I'm sure that back in the old days, C didn't have string constants.
> Occasionally, you still see things like
> 
>         mktemp("/tmp/fileXXXXXX"),
> 
> and mktemp() does write to the array argument. 

It horrifies me that you are absolutely right.

>  (Of course, you should
> never-ever use mktemp(), tmpnam() or tempnam(). 

One should keep away from mktemp(), but the Ansi C functions are
perfectly usable and sensible to use.


Greetings,

Re: C vs. Ada - strings

[Florian Weimer]

"Tarjei Tj�stheim Jensen" <tarjei@online.no> writes:

> One should keep away from mktemp(), but the Ansi C functions are
> perfectly usable and sensible to use.

tmpnam() is broken as designed (the information is already outdated
when it is returned, and on Unix systems, an attacker could have
created a symlink linking to some interesting file), tmpfile() has
the correct interface, but you can't be sure that it's correctly
implemented on all systems. :-/

Re: C vs. Ada - strings

[Robert Dewar]

In article <87hfcct911.fsf@deneb.cygnus.argh.org>,
  Florian Weimer <fw-usenet@deneb.cygnus.argh.org> wrote:

> tmpnam() is broken as designed (the information is already
outdated
> when it is returned, and on Unix systems, an attacker could
have
> created a symlink linking to some interesting file), tmpfile()
has
> the correct interface, but you can't be sure that it's
correctly
> implemented on all systems. :-/


Now there's FUD if I ever saw it!

Advice: Don't use function xxxx

Question: That's odd, why not?

Answer: It may be implemented wrong.

To the extent that this is an effective argument, it can
presumably be used for all xxxx :-)



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

Re: C vs. Ada - strings

[Florian Weimer]

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

[Don't use tmpfile()]

> Now there's FUD if I ever saw it!

Certainly it is, but it is appropriate in this case, I think.

For example, the GNU/Linux implementation of tmpfile() had a race
condition which permitted every local user to open the temporary file,
and this bug was not fixed until GNU libc 2.0.6 (and it is still there
in libc4/libc5).  This bug is very hard to spot on a running system
(unless someone is actually exploiting it or you have a system call
logger), and obviously, nobody looked at the source code.

> To the extent that this is an effective argument, it can
> presumably be used for all xxxx :-)

The temporary file generation functions are very critical, many
security breaches (by local users) are due to insecure temporary
files.  The problem is very subtle, and you can tell a broken
implementation from a correct one only by looking at the source code
or at a verbose system call trace.  In fact, I believe that tmpfile()
is implemented wrong on a number of additional platforms, but I
couldn't check because I neither have source code nor a system call
tracer for these platforms!

-- 
Florian Weimer 	                  Florian.Weimer@RUS.Uni-Stuttgart.DE
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898
http://ca.uni-stuttgart.de:11371/pks/lookup?op=get&search=0xC06EC3B5

Re: C vs. Ada - strings

[Pete]

really both versions aren't that great. java strings are much better. if s
and t are strings of different lengths, suppose
s = "junk";
t = "garbage". it should make sense to write s = s + t; and your result is
"junkgarbage" as java does. you should definitely not have to make sure that
s is big enough to hold a string of length s and t or call any function to
reallocate memory. it should happen automatically, under the covers. the
most annoying thing in ada is the output messages. if you write
Positive'Image("5"). You get back
" 5", with a space for an optional - sign, even though it is a positive
number! or even worse, instantiate a generic package to handle printing of
numbers, instead of
System.out.println("This is junk " + i); (where i is a numeric type).

- pete
"Keith Thompson" <kst@cts.com> wrote in message
news:yec1z3jkq9z.fsf@king.cts.com...
> "Pascal Obry" <p.obry@wanadoo.fr> writes:
> [...]
> > But where did you see a C string ? In C you have a pointer to a memory
> > space terminated by 'nul' !
> >
> > This is not a string to me. And because C does not have strings, there
is
> > no operator on them you have to use strcmp, strcpy, strcat, strncmp...
> >
> > Is that what a string is for C programmers :)
>
> Serious answer: yes.
>
> The C90 standard's definition of the term "string" is
>
>     A string is a contiguous sequence of characters terminated by and
>     including the first null character.  A "pointer to" a string is a
>     pointer to its initial (lowest addressed) character.  The "length"
>     of a string is the number of characters preceding the null
>     character and its "value" is the sequence of the values of the
>     contained characters, in order.
>
> As for the lack of built-in operators, it's certainly nice to have "=",
> ":=", "<", "&", and so forth, but the fact that these are implemented
> as function calls in C isn't really that big a deal.  (In other areas,
> C is criticized for being too terse.)
>
> This isn't to say that C's string handling isn't flawed.  Once of
> the biggest problems is that, though a function can return a pointer
> to a (variable-length) string, there's no standard way to manage the
> associated memory.
>
> --
> Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
> San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
> Welcome to the last year of the 20th century.

Re: C vs. Ada - strings

[dale]

Pete wrote:

> really both versions aren't that great. java strings are much better. if 
> s
> and t are strings of different lengths, suppose
> s = "junk";
> t = "garbage". it should make sense to write s = s + t; and your result 
> is
> "junkgarbage" as java does. you should definitely not have to make sure 
> that
> s is big enough to hold a string of length s and t or call any function 
> to
> reallocate memory. it should happen automatically, under the covers.

You should try unbounded_strings, as this gives you the flexibility
that you seem to want.

the
> most annoying thing in ada is the output messages.

i'm not sure what you mean by "output messages".

if you write
> Positive'Image("5"). You get back
> " 5", with a space for an optional - sign, even though it is a positive
> number! or even worse,

(should read Positive'Imge (5))
i've always thought of attributes such as these as rather low level
features good for debugging, but not really of much use for fancy
formatting. Still it can be annoying. You have to apply the trim
function, or slice the array yourself, which is annoying.

instantiate a generic package to handle printing 
> of
> numbers, instead of
> System.out.println("This is junk " + i); (where i is a numeric type).

Yes, but with this simplicity you get a very real problem - the
inability to define new distinct numeric types. Which do you think
is the bigger problem - having to choose b/w int and long for almost
all integer work (without the ability to have unsigned ints), 
or having to instantiate (or do a type conversion) to get output?
Note that you could always include your own package of functions
to get exactly the same behaviour as you see above in Java.


Dale

Re: C vs. Ada - strings

[Robert A Duff]

dale <dale@cs.rmit.edu.au> writes:

> Pete wrote:
> if you write
> > Positive'Image("5"). You get back
> > " 5", with a space for an optional - sign, even though it is a positive
> > number! or even worse,
> 
> (should read Positive'Imge (5))
> i've always thought of attributes such as these as rather low level
> features good for debugging, but not really of much use for fancy
> formatting. Still it can be annoying. You have to apply the trim
> function, or slice the array yourself, which is annoying.

The annoying extra blank is certainly a mistake.  So is the verbose
syntax.  Why can't you say X'Image instead of Integer'Image(X)?
After all, you can say "X + 1" (as opposed to something like
Integer'Add(X, 1)).  It's not necessary or helpful to mention the type
every time you want to do something to an object or value.

> instantiate a generic package to handle printing 
> > of
> > numbers, instead of
> > System.out.println("This is junk " + i); (where i is a numeric type).
> 
> Yes, but with this simplicity you get a very real problem - the
> inability to define new distinct numeric types.

I don't agree.  It's quite easy to design a language in which it is
possible to define convenient output procedures, and still have multiple
user-defined integer types.  And I don't mean by making all the output
primitives built-in, either (as in Pascal) -- I/O should be done in
library packages, not as built-in primitives.

>... Which do you think
> is the bigger problem - having to choose b/w int and long for almost
> all integer work (without the ability to have unsigned ints), 
> or having to instantiate (or do a type conversion) to get output?

The former.  But I think it's possible to get the best of both worlds,
so I think it's a legitimate complaint to say that Text_IO is a pain in
the neck compared to Java's primitives.  On the other hand, Java has its
own problems with strings.  Eg, the fact that the equality comparison is
pointer comparison.  And "+" is a poor choice for the concatenation
operator.

> Note that you could always include your own package of functions
> to get exactly the same behaviour as you see above in Java.

I don't see how.  Not if you have lots of user-defined integer types --
you have to declare something extra for every integer type, which does
not match the convenience of the Java routines.

- Bob

Re: C vs. Ada - strings

[dale]

Robert A Duff wrote:

> > Yes, but with this simplicity you get a very real problem - the
> > inability to define new distinct numeric types.
> 
> I don't agree.  It's quite easy to design a language in which it is
> possible to define convenient output procedures, and still have multiple
> user-defined integer types.  And I don't mean by making all the output
> primitives built-in, either (as in Pascal) -- I/O should be done in
> library packages, not as built-in primitives.

I was really just restricting myself to commenting on Java, rather than
making a more generalised statment on language design (i.e. _if_ you 
choose Java, you don't get to define distinct numeric types).
I hadn't thought about getting I/O "for free" (i.e. no instantiation)
in a language which permitted multiple distinct integer types (I presume
this is what you are saying).



> > Note that you could always include your own package of functions
> > to get exactly the same behaviour as you see above in Java.
> 
> I don't see how.  Not if you have lots of user-defined integer types --
> you have to declare something extra for every integer type, which does
> not match the convenience of the Java routines.

Again i was only comparing this to Java. If you want to restrict
yourself to the primitives that Java provides, then you can easily
make a package that implements "+" functions to make concatenation
easier.


Dale

Re: C vs. Ada - strings

[Geoff Bull]

Pete wrote:
> java strings are much better.
Only some aspects are better, many are much worse!
E.g., they're horribly slow, especially if you need to change them -
since they're immutable you have to create a new one.
(Being immutable allows getting substrings to be fast, among other
things).
A StringBuffer only partially solves this problem.

Re: C vs. Ada - strings

[mike]

In article <3924B730.AFB52C1C@acenet.com.au>, Geoff says...

>
>Pete wrote:
>> java strings are much better.

>Only some aspects are better, many are much worse!
>E.g., they're horribly slow, especially if you need to change them -
>since they're immutable you have to create a new one.
>(Being immutable allows getting substrings to be fast, among other
>things).

being immutable also means you can not modify them ;)

>A StringBuffer only partially solves this problem.

how so? what is wrong with StringBuffer? (please, no performance
stuff, Java is pretty fast these days, almost as fast as C++ and C
for most applications).

only problem I see with java stringbuffers, is that it is easier to
convert them to arrays first whenever you need to do scanning
and replacments on them. it is always easier to write a[i], than
a.elementAt(i), etc.. then covert the array back to string at the end.

other than that, they are ok.

mike

Re: C vs. Ada - strings

[Robert Dewar]

In article <wcc8zx7ua2y.fsf@world.std.com>,
  Robert A Duff <bobduff@world.std.com> wrote:
> So is the verbose
> syntax.  Why can't you say X'Image instead of
Integer'Image(X)?

Note that GNAT provides the attribute Img, which can be used
precisely in this manner (e.g. X'Img instead of
Integer'Image (X)). Very useful for simple debug output


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

Re: C vs. Ada - strings

[Robert Dewar]

In article <3924B730.AFB52C1C@acenet.com.au>,
  Geoff Bull <gbull@acenet.com.au> wrote:
> Pete wrote:
> > java strings are much better.
> Only some aspects are better, many are much worse!
> E.g., they're horribly slow, especially if you need to change
them -
> since they're immutable you have to create a new one.


The slowness is a matter of implementation, not the language.
Have a look at SPITBOL to see the efficiency that can be
achieved with string processing, even if you have very
elaborate string semantics.


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

Re: C vs. Ada - strings

[Robert A Duff]

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

> In article <wcc8zx7ua2y.fsf@world.std.com>,
>   Robert A Duff <bobduff@world.std.com> wrote:
> > So is the verbose
> > syntax.  Why can't you say X'Image instead of
> Integer'Image(X)?
> 
> Note that GNAT provides the attribute Img, which can be used
> precisely in this manner (e.g. X'Img instead of
> Integer'Image (X)). Very useful for simple debug output

Yes, of course, I anticipated that you would mention GNAT's 'Img -- to
the point where I have already written a reply in my head.  ;-)

Of course the main drawback is that 'Img is not standard.
If you don't care about that, then 'Img is fine.

My other (minor) complaint is that Img is an ugly abbreviation for
Image.  Robert will reply that it's standard Ada style to use
abbreviations for attribute names.  And I will reply that that's true,
but it's not standard Ada style to use *ugly* abbreviations for
attribute names.  ;-) I'm not allergic to abbreviations for commonly
used things: 'Pred is OK because (1) there's precedent (from Pascal) so
folks are used to it, (2) it's a prefix, (3) it's pronouncable, (4) it's
unlikely to cause confusion, and (5) there's a high payoff in terms of
how much less code you have to read ("Pred" vs "Predecessor").  'Img, on
the other hand, abbreviates by leaving out all the vowels, something
which I find uncivilized, compared to using a prefix of the word.  And
it only saves two letters.

Of course, GNAT has no choice -- it would be illegal to call it 'Image,
and 'Img is the obvious alternative.

Oh, one other thing: 'Img, being a GNAT invention, *could* have
eliminated the annoying extra blank.  Why didn't you?

- Bob

Re: C vs. Ada - strings

[Keith Thompson]

Robert A Duff <bobduff@world.std.com> writes:
[...]
> Oh, one other thing: 'Img, being a GNAT invention, *could* have
> eliminated the annoying extra blank.  Why didn't you?

TeleSoft's old TeleGen2 compiler had a set of extended attributes:
'Extended_Image, 'Extended_Value, 'Extended_Width, etc.  The
'Extended_Image attribute, for example, could be applied to any scalar
type, including floating-point (this was Ada 83, so there was no
Float'Image), and had several extra parameters with reasonable
defaults.  Integer'Extended_Image(X) would give you the image of X
with no leading spaces; Integer'Extended_Image(X, 10) would give you
the image of X padded with leading blanks to 10 characters.  They were
provided mostly to be used in the implementation of Text_IO, but they
were very useful in their own right.  I was disappointed that
something like this wasn't included in the Ada 95 standard.

There were two problems: named parameters weren't supported, and the
fact that Integer'Extended_Image and Enum'Extended_Image had different
parameter profiles cause an ambiguity when used with a generic
discrete type.

-- 
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Welcome to the last year of the 20th century.

'img

[Peter Hermann]

Robert A Duff <bobduff@world.std.com> wrote:
> Oh, one other thing: 'Img, being a GNAT invention, *could* have
> eliminated the annoying extra blank.  Why didn't you?

                       with text_io ;
procedure imgtst is
      x : integer := 7;
begin
      text_io.put_line( "[" & x'img & "]" );
end imgtst ;

yes, I was frustrated too to see the result [ 7] and not [7]
which is often useful.   :-(


-- 
Peter Hermann Tel+49-711-685-3611 Fax3758 ica2ph@csv.ica.uni-stuttgart.de
Pfaffenwaldring 27 Raum 114, D-70569 Stuttgart Uni Computeranwendungen
http://www.csv.ica.uni-stuttgart.de/homes/ph/
Team Ada: "C'mon people let the world begin" (Paul McCartney)

Re: 'img

[Robert Dewar]

In article <8ggjg3$hbq$1@infosun2.rus.uni-stuttgart.de>,
  Peter Hermann <ica2ph@iris16.csv.ica.uni-stuttgart.de> wrote:
> Robert A Duff <bobduff@world.std.com> wrote:
> > Oh, one other thing: 'Img, being a GNAT invention, *could*
> > have eliminated the annoying extra blank.  Why didn't you?

Simple answer, no customer has requested this feature, and we
have LOTS of things to work on that people do want. This is
indeed on our enhancement list, as is the even more useful
feature of being able to use Img on other types (e.g. records
and arrays).

> yes, I was frustrated too to see the result [ 7] and not [7]
> which is often useful.   :-(

Think how much less frustrated you would be if you were a
supported customer, and when you made enhancement suggestions
like this, they automatically had high priority :-)

Robert Dewar
Ada Core Technologies


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

Re: 'img

[Ted Dennison]

In article <8gh9lr$ppe$1@nnrp1.deja.com>,
  Robert Dewar <robert_dewar@my-deja.com> wrote:
> indeed on our enhancement list, as is the even more useful
> feature of being able to use Img on other types (e.g. records
> and arrays).

Oooh! That *would* be cool.


Hmmm. Even neater would be to make it a primitive operator attribute
that can be overidden with a "for" clause, like 'Write. Then folks could
derive a new integer type and make its 'Img format the output however
they like.


--
T.E.D.

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


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

Re: 'img

[Peter Hermann]

Ted Dennison <dennison@telepath.com> wrote:
> Hmmm. Even neater would be to make it a primitive operator attribute
> that can be overidden with a "for" clause, like 'Write. Then folks could
> derive a new integer type and make its 'Img format the output however
> they like.

All the attributes could be some more polymorphic, user inheritable, etc.

break

I could imagine, that integer'image(x) and x'image could easily
live together, mmh?

-- 
Peter Hermann Tel+49-711-685-3611 Fax3758 ica2ph@csv.ica.uni-stuttgart.de
Pfaffenwaldring 27 Raum 114, D-70569 Stuttgart Uni Computeranwendungen
http://www.csv.ica.uni-stuttgart.de/homes/ph/
Team Ada: "C'mon people let the world begin" (Paul McCartney)

Re: 'img

[Keith Thompson]

Peter Hermann <ica2ph@iris16.csv.ica.uni-stuttgart.de> writes:
[...]
> I could imagine, that integer'image(x) and x'image could easily
> live together, mmh?

No, I don't think an implementation-defined attribute is allowed to
have the same name as a predefined attribute.

A way to do what was suggested would be to define <type>'Img(<expr>),
and allow "for <type>'Img use <function>;".  The biggest advantage,
IMHO, is that it would establish a precedent for specifying 'Image in
the next revision of the language.

For symmetry, of course, you'd want 'Vlu and 'Wdth.

-- 
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Welcome to the last year of the 20th century.

Re: 'img

[Ted Dennison]

In article <yecaehexucx.fsf@king.cts.com>,
  Keith Thompson <kst@cts.com> wrote:

> For symmetry, of course, you'd want 'Vlu and 'Wdth.

You are an evil man. :-)

--
T.E.D.

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


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

Re: 'img

[Robert Dewar]

In article <8ghcbh$rnj$1@nnrp1.deja.com>,
  Ted Dennison <dennison@telepath.com> wrote:
> Hmmm. Even neater would be to make it a primitive operator
attribute
> that can be overidden with a "for" clause, like 'Write. Then
folks could
> derive a new integer type and make its 'Img format the output
however
> they like.


Even neater?

This is of course easy to implement, but not particularly
useful, since the difference between writing X'Img and Img(X)
is small, and the advantage of the latter is that it can be
used with expressions which of course the attribute cannot.


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

Re: 'img

[dmitry]

In article <8gj50o$igs$1@infosun2.rus.uni-stuttgart.de>,
  Peter Hermann <ica2ph@iris16.csv.ica.uni-stuttgart.de> wrote:
> Ted Dennison <dennison@telepath.com> wrote:
> > Hmmm. Even neater would be to make it a primitive operator attribute
> > that can be overidden with a "for" clause, like 'Write. Then folks could
> > derive a new integer type and make its 'Img format the output however
> > they like.
>
> All the attributes could be some more polymorphic, user inheritable, etc.

As well as constructor, destructor and assignment (for untagged types),
aggregate (for non-records), 'access attribute (for GC?) and etc. (:-))

Regards,
Dmitry Kazakov


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

Re: 'img

[Brian Rogoff]

On Fri, 26 May 2000 dmitry@gandalf.atm.fh-luebeck.de wrote:
> In article <8gj50o$igs$1@infosun2.rus.uni-stuttgart.de>,
>   Peter Hermann <ica2ph@iris16.csv.ica.uni-stuttgart.de> wrote:
> > Ted Dennison <dennison@telepath.com> wrote:
> >
> > All the attributes could be some more polymorphic, user inheritable, etc.
> 
> As well as constructor, destructor and assignment (for untagged types),
> aggregate (for non-records), 'access attribute (for GC?) and etc. (:-))

I agree that extending assignment and finalization to untagged types would 
be nice, but I don't think its quite as easy as "for ... use" clauses on
attributes :-). And, to be truthful, while I love proposing Ada extensions 
as much as the next guy, I haven't found this lack to be particularly
painful, nor have I found the general crumminess of 'Image to be that bad. 
I roll my own and use functional syntax for Image. I guess everyone has
their own set of "rough edges" that they feel need polishing :-).

-- Brian

Re: 'img

[Robert Dewar]

In article <8glmf7$usg$1@nnrp1.deja.com>,
  dmitry@gandalf.atm.fh-luebeck.de wrote:
> > All the attributes could be some more polymorphic, user
inheritable, etc.
>
> As well as constructor, destructor and assignment (for
untagged types),
> aggregate (for non-records), 'access attribute (for GC?) and
etc. (:-))


Ouch! That has huge semantic consequences, not at ALL easy
to work out. I doubt it is practical.


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

Re: 'img

[Robert Dewar]

In article
<Pine.BSF.4.21.0005261106490.23036-100000@shell5.ba.best.com>,
  Brian Rogoff <bpr@shell5.ba.best.com> wrote:
 nor have I found the general crumminess of 'Image to be that
 bad.


It seems to me that Image is perfectly fine for the purpose
for which it was designed (quick output where formatting is
unimportant).


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

Re: C vs. Ada - strings

[Pete]

    I see your point. But suppose in Java, I have
Srting ar[] = new String[] { "have", "a", "good", "day" };
// assume some processing.
ar[2] = "junk";

I think the Ada way to do this would be much more complicated. I may be
wrong, can this be done so simply in Ada *without having to create new
types, or making function calls*? If so, I am interested in seeing how to do
this.

- pete



"Geoff Bull" <gbull@acenet.com.au> wrote in message
news:3924B730.AFB52C1C@acenet.com.au...
> Pete wrote:
> > java strings are much better.
> Only some aspects are better, many are much worse!
> E.g., they're horribly slow, especially if you need to change them -
> since they're immutable you have to create a new one.
> (Being immutable allows getting substrings to be fast, among other
> things).
> A StringBuffer only partially solves this problem.

Re: C vs. Ada - strings

[Ken Garlington]

"Pete" <tyrone@nowhere.org> wrote in message
news:GW8_4.8869$kf5.45098@typhoon.nyroc.rr.com...
>     I see your point. But suppose in Java, I have
> Srting ar[] = new String[] { "have", "a", "good", "day" };
> // assume some processing.
> ar[2] = "junk";
>
> I think the Ada way to do this would be much more complicated. I may be
> wrong, can this be done so simply in Ada *without having to create new
> types, or making function calls*? If so, I am interested in seeing how to
do
> this.

Does "new" count as a function call?

Java vs. Ada - strings (was: C vs. Ada - strings)

[Ted Dennison]

Pete wrote:

>     I see your point. But suppose in Java, I have
> Srting ar[] = new String[] { "have", "a", "good", "day" };
> // assume some processing.
> ar[2] = "junk";
>
> I think the Ada way to do this would be much more complicated. I may be
> wrong, can this be done so simply in Ada *without having to create new
> types, or making function calls*? If so, I am interested in seeing how to do
> this.

You are asking if you can create an object of a new type in Ada without creating
a new type? Of course not.

But that's pretty much equivalent to

type String_Ptr is access String;
type String_List is array (Natural range <>) of String_Ptr;
AR : constant String_List := (new String'("have"), new String'("a"), new
String'("good"), new String'("day"));

...without function calls. Although what your aversion to function calls buys
you is beyond me. One could easily create a custom type for ragged string arrays
perhaps using "and" as a constructor, which would clean this up to:

AR : constant Ragged_String_Array := "have" and "a" and "good" and "day";

This would also allow you to combine catenated strings and string arrays in one
expression into this type of construction

AR : constant Ragged_String_Array := "have" and Integer'image(Some_Var) & "
straight" and "good" and "days";

Which I believe would look a bit uglier in Java due to lack of a catenation
operator.

I've never done this myself because in 11 years of Ada work I've never had a
much need for ragged string arrays. That's probably why Ada doesn't come with a
type for them. :-)

--
T.E.D.

Home - mailto:dennison@telepath.com  Work - mailto:dennison@ssd.fsi.com
WWW  - http://www.telepath.com/dennison/Ted/TED.html  ICQ  - 10545591

Re: C vs. Ada - strings

[Ted Dennison]

Ken Garlington wrote:

> Does "new" count as a function call?

That'd be quite a stretch, as its a reserved word. You might as well say "type"
... "is" is a function call. I think we're stretching it far enough just
accepting the "no function call" restricion to begin with. The only reason I
can see for it is an attempt to constrain the possible answers in a way that
selectively hampers one language over another.

We might as well say "you can't use anything *but* function calls, and no infix
operations are allowed", so that Lisp comes out as the superior string handling
language.

--
T.E.D.

Home - mailto:dennison@telepath.com  Work - mailto:dennison@ssd.fsi.com
WWW  - http://www.telepath.com/dennison/Ted/TED.html  ICQ  - 10545591

Re: Java vs. Ada - strings (was: C vs. Ada - strings)

[Pete]

> 2) The Java syntax is nice - only at initialisation time. You have no
aggregates in Java, so the corresponding
syntax would not be
> allowed if you wanted to put other values in the array after
initialisation.

    i'm not sure what you mean...if i wanted to change an element of the
string array, i would just assign it
via s[i] = <whatever>
you could also resize the array, without any looping statements
(System.arrayCopy)
>

 also
suppose the ada array (1 based)

AR : constant String_List := (new String'("have"), new String'("a"), new
String'("good"), new String'("day"));

i hope that i can say ar(2) := <variable length string> without having to
worry about contraint errors, or having to free the old ar(2) first, the
compiler should be smart enough to figure it out.

Re: C vs. Ada - strings

[Dale Stanbrough]

Ted Dennison wrote:

> That'd be quite a stretch, as its a reserved word. You might as well say 
> "type"
> ... "is" is a function call.

I would disagree, as there are implied semantics for "new", but none for
"type". The matter is irrelavent though, as static calls to "new" can 
be optimised away to preallocated memory (this was mentioned in c.l.a.
some 6 - 12 months ago).


Dale

Re: Java vs. Ada - strings (was: C vs. Ada - strings)

[Robert I. Eachus]

Ted Dennison wrote:
> 
> Pete wrote:
> 
> >     I see your point. But suppose in Java, I have
> > Srting ar[] = new String[] { "have", "a", "good", "day" };
> > // assume some processing.
> > ar[2] = "junk";
  ... 
> I've never done this myself because in 11 years of Ada work I've never had a
> much need for ragged string arrays. That's probably why Ada doesn't come with a
> type for them. :-)

   Actually, there are uses for ragged string arrays, and that is one
reason why
Ada.Strings.Bounded and Ada.Strings.Unbounded were added to Ada 95:

  with Ada.Strings.Unbounded; use Ada.Strings.Unbounded;
  ...
    type String_Array is array(Natural range <>) of Unbounded_String;
    function "+"(Right: String) return Unbounded_String renames
To_Unbounded_String;
    -- You probably want to do this anyway, not just for the conditions
of contest.
    Ar: String_Array := (+"have",+"a",+"good",+"day");
    ...
    Ar(2) := +"junk";
  ...

   The Ada code generated may use the heap, or it may get clever.  In
either case you don't need to worry about storage leaks.  (RM
A.4.5(88))  Of course, in Java, you don't need to worry about a storage
leak on the assignment either, since it will eventually get garbage
collected.  If you use Ada.Strings.Bounded instead, you should expect
the compiler to avoid the heap.(RM A.4.4(106))

Re: Java vs. Ada - strings (was: C vs. Ada - strings)

[Pete]

> type String_Ptr is access String;
> type String_List is array (Natural range <>) of String_Ptr;
> AR : constant String_List := (new String'("have"), new String'("a"), new
> String'("good"), new String'("day"));

my whole point is the complexity of the syntax. compare the above to
    String st[] = new String[] { "have", "a", "good", "day"};
The ada code above has two new types in order to process an array of
*primitive* types.

>
> I've never done this myself because in 11 years of Ada work I've never had
a
> much need for ragged string arrays. That's probably why Ada doesn't come
with a
> type for them. :-)
i've already had a use for them in the 6 months that i started this new ada
project.

> T.E.D.
>
> Home - mailto:dennison@telepath.com  Work - mailto:dennison@ssd.fsi.com
> WWW  - http://www.telepath.com/dennison/Ted/TED.html  ICQ  - 10545591
>
>

Re: C vs. Ada - strings

[Ken Garlington]

"Ted Dennison" <dennison@telepath.com> wrote in message
news:3939602B.677BF4FF@telepath.com...
> Ken Garlington wrote:
>
> > Does "new" count as a function call?
>
> That'd be quite a stretch, as its a reserved word. You might as well say
"type"
> ... "is" is a function call. I think we're stretching it far enough just
> accepting the "no function call" restricion to begin with. The only reason
I
> can see for it is an attempt to constrain the possible answers in a way
that
> selectively hampers one language over another.
>
> We might as well say "you can't use anything *but* function calls, and no
infix
> operations are allowed", so that Lisp comes out as the superior string
handling
> language.

My point being: The original question implied that the Java solution was
better because it had no function calls. However, it used "new".  So either
(a) "new" is a function call, in which case the question doesn't appear to
make any sense, or (b) it isn't, in which case we'd need to know for sure
what _is_ a function call.

Re: Java vs. Ada - strings (was: C vs. Ada - strings)

[Jean-Pierre Rosen]

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


Pete <tyrone@nowhere.org> a �crit dans le message : LVu_4.10342$kf5.70362@typhoon.nyroc.rr.com...
>
> > type String_Ptr is access String;
> > type String_List is array (Natural range <>) of String_Ptr;
> > AR : constant String_List := (new String'("have"), new String'("a"), new
> > String'("good"), new String'("day"));
>
> my whole point is the complexity of the syntax. compare the above to
>     String st[] = new String[] { "have", "a", "good", "day"};
> The ada code above has two new types in order to process an array of
> *primitive* types.
>
1) String is not a "primitive" type in Ada. Actually, I don't know other languages where String is *not* recognized specially by the
compiler. This means that all the nice features of strings are available for any user-defined array type. There is a price for such
generality and power.
2) The Java syntax is nice - only at initialisation time. You have no aggregates in Java, so the corresponding syntax would not be
allowed if you wanted to put other values in the array after initialisation.

In short: your example is simpler in Java, in the particular case you mention. Any attempt to generalize it will result in more
complicated stuff.

--
---------------------------------------------------------
           J-P. Rosen (Rosen.Adalog@wanadoo.fr)
Visit Adalog's web site at http://pro.wanadoo.fr/adalog

Re: Java vs. Ada - strings (was: C vs. Ada - strings)

[Ted Dennison]

In article <LVu_4.10342$kf5.70362@typhoon.nyroc.rr.com>,
  "Pete" <tyrone@nowhere.org> wrote:
>
> > type String_Ptr is access String;
> > type String_List is array (Natural range <>) of String_Ptr;
> > AR : constant String_List := (new String'("have"), new String'("a"),
new
> > String'("good"), new String'("day"));
>
> my whole point is the complexity of the syntax. compare the above to
>     String st[] = new String[] { "have", "a", "good", "day"};
> The ada code above has two new types in order to process an array of
> *primitive* types.

This (a ragged array of strings) is *not* an everyday type, so its
perfectly reasonable for a language to not have built-in support for it.
Once you make the requisite declarations so that Ada has the type, the
code is not that much more complicated . As the rest of my message said,
its even *simpler* than Java if you create an abstract type for it.

> > I've never done this myself because in 11 years of Ada work I've
> > never had much need for ragged string arrays. That's probably why
> > Ada doesn't come with a type for them. :-)
> i've already had a use for them in the 6 months that i started this
> new ada

You're starting to get at my point here. Most of the "Ada's support for
XXX sucks" folks come from the perspective of trying to use techniques
designed around the features (and failings) of another language in Ada,
rather than from a sober analysis of the full benefits and drawbacks of
the supporting Ada features. If I were a betting man, I'd wager that
this approach occured to you because you are used to using this
(unusual) construct from a lanugage that makes it easy, and it would not
have occurred at all in the code of a "native" Ada person.

--
T.E.D.

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


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

Re: Java vs. Ada - strings (was: C vs. Ada - strings)

[David Botton]

The cure is to teach people to develop in many different languages and use
multiple paradigms from the very start.

In a single day I may use three to four different programming languages
something that has helped me think beyond the fold of any language and be
creative (for application development more important then engineering skill)
about how to both design and implement software.

David Botton


"Marin D. Condic" <mcondic-nospam@quadruscorp.com> wrote in message
news:393BB65D.7891F819@quadruscorp.com...

> Perhaps some doctoral candidate in Psychology could take up this problem
> and study it? Why is it that a good Fortran programmer can write Fortran
> code no matter what language you give him? Is there a cure for this that
> doesn't involve electroshock therapy? :-)

Re: Java vs. Ada - strings (was: C vs. Ada - strings)

[Marin D. Condic]

Ted Dennison wrote:
> You're starting to get at my point here. Most of the "Ada's support for
> XXX sucks" folks come from the perspective of trying to use techniques
> designed around the features (and failings) of another language in Ada,
> rather than from a sober analysis of the full benefits and drawbacks of
> the supporting Ada features. If I were a betting man, I'd wager that
> this approach occured to you because you are used to using this
> (unusual) construct from a lanugage that makes it easy, and it would not
> have occurred at all in the code of a "native" Ada person.
> 
This is exactly the situation when you watch a native C programmer try
to null terminate Ada strings and complain that there is no support in
the language for null terminated string processing. They are used to
working this way in C and are trying to translate it directly into Ada
when The Ada Way is to use slices and attributes. Its not that the
language *can't* do the job. Its that the language won't do it with the
exact same idiom you'll find in another language. (Is there some reason
to re-think the problem and decide if a ragged array of strings is *not*
the way to solve it in Ada?)

Perhaps some doctoral candidate in Psychology could take up this problem
and study it? Why is it that a good Fortran programmer can write Fortran
code no matter what language you give him? Is there a cure for this that
doesn't involve electroshock therapy? :-)

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/

"Some people think programming Windows is like nailing jello to the 
ceiling... easy with the right kind of nails."

    --  Ivor Horton - Beginning Visual C++ 6
======================================================================

Re: Java vs. Ada - strings (was: C vs. Ada - strings)

[Jean-Pierre Rosen]

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


Pete <tyrone@nowhere.org> a �crit dans le message : qzB_4.10571$kf5.79533@typhoon.nyroc.rr.com...
>
> > 2) The Java syntax is nice - only at initialisation time. You have no
> aggregates in Java, so the corresponding
> syntax would not be
> > allowed if you wanted to put other values in the array after
> initialisation.
>
>     i'm not sure what you mean...if i wanted to change an element of the
> string array, i would just assign it
> via s[i] = <whatever>
Here you are assigning an element, not the array. I was talking about assigning the whole array; but of course, there is no such
thing as value assignment in Java...

> you could also resize the array, without any looping statements
> (System.arrayCopy)
In ada, System.arrayCopy is called ":=". Talking about conciseness...

>  also
> suppose the ada array (1 based)
>
> AR : constant String_List := (new String'("have"), new String'("a"), new
> String'("good"), new String'("day"));
>
> i hope that i can say ar(2) := <variable length string> without having to
> worry about contraint errors, or having to free the old ar(2) first, the
> compiler should be smart enough to figure it out.
String is not a variable string. If you want to have variable, unlimited strings with hidden memory allocation and automatic
recollection, use Unbounded_String!

As far as freeing (or collecting) memory is concerned, I hope you know that NO Java compilers does that. Garbage collection is a
property of the JVM, and will apply equally to all languages running on the JVM (Java, Ada, or any other)

--
---------------------------------------------------------
           J-P. Rosen (Rosen.Adalog@wanadoo.fr)
Visit Adalog's web site at http://pro.wanadoo.fr/adalog

Re: Java vs. Ada - strings (was: C vs. Ada - strings)

[Marin D. Condic]

David Botton wrote:
> 
> The cure is to teach people to develop in many different languages and use
> multiple paradigms from the very start.
> 
Certainly, a broader experience base is going to be helpful. I think
there may still be some amount of residual "human nature" though which
makes the problem tough to beat. We get used to doing things a certain
way and even when we know better, we try to make everything conform to
that with which we are comfortable. If you're very comfortable with a
hammer, you try to make everything into a nail?

BTW: I don't think this is unique to our profession. I've dealt with
medical doctors who can have exactly the same sort of myopia -
intelligent and well trained as they may be. I'm sure it can be found
wherever we'd care to look.

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/

"Some people think programming Windows is like nailing jello to the 
ceiling... easy with the right kind of nails."

    --  Ivor Horton - Beginning Visual C++ 6
======================================================================

Re: Java vs. Ada - strings (was: C vs. Ada - strings)

[Ken Garlington]

"Ted Dennison" <dennison@telepath.com> wrote in message
news:8hgb3m$bs$1@nnrp1.deja.com...
> In article <LVu_4.10342$kf5.70362@typhoon.nyroc.rr.com>,
>   "Pete" <tyrone@nowhere.org> wrote:

> > > I've never done this myself because in 11 years of Ada work I've
> > > never had much need for ragged string arrays. That's probably why
> > > Ada doesn't come with a type for them. :-)
> > i've already had a use for them in the 6 months that i started this
> > new ada
>
> You're starting to get at my point here. Most of the "Ada's support for
> XXX sucks" folks come from the perspective of trying to use techniques
> designed around the features (and failings) of another language in Ada,
> rather than from a sober analysis of the full benefits and drawbacks of
> the supporting Ada features. If I were a betting man, I'd wager that
> this approach occured to you because you are used to using this
> (unusual) construct from a lanugage that makes it easy, and it would not
> have occurred at all in the code of a "native" Ada person.

That doesn't seem very fair... how about testing the thesis with a nice,
non-language-specific requirement? For example: "Create a list of the names
of the people who participated in this thread." I hope that "list" is
reasonably well-defined as to its methods, etc. (delete an item on the list,
replace an existing item, add an item to the end of the list, select a
specific item by its location in the list). What would that look like in
Java and Ada, and what are the advantages/disadvantages of each? I could
certainly seeing a ragged string array (in any language) as a reasonable
approach to addressing this requirement...

Re: Java vs. Ada - strings (was: C vs. Ada - strings)

[Robert A Duff]

"Marin D. Condic" <mcondic-nospam@quadruscorp.com> writes:

> Ted Dennison wrote:
> > You're starting to get at my point here. Most of the "Ada's support for
> > XXX sucks" folks come from the perspective of trying to use techniques
> > designed around the features (and failings) of another language in Ada,
> > rather than from a sober analysis of the full benefits and drawbacks of
> > the supporting Ada features. If I were a betting man, I'd wager that
> > this approach occured to you because you are used to using this
> > (unusual) construct from a lanugage that makes it easy, and it would not
> > have occurred at all in the code of a "native" Ada person.
> > 
> This is exactly the situation when you watch a native C programmer try
> to null terminate Ada strings and complain that there is no support in
> the language for null terminated string processing. ...

Yeah, but the original poster wasn't asking for nul-terminated strings
-- he was asking for strings that can change their length.  He said he
wanted no type declarations or function calls, but I presume he really
meant he wanted a concise notation.

This was a pretty reasonable thing to ask for -- varying length strings
with concise notation.  So I think it's unfair to accuse him of not
knowing the One True Glorious Ada Way.

- Bob

Re: Java vs. Ada - strings (was: C vs. Ada - strings)

[Marin D. Condic]

Ken Garlington wrote:
> 
> That doesn't seem very fair... how about testing the thesis with a nice,
> non-language-specific requirement? For example: "Create a list of the names
> of the people who participated in this thread." I hope that "list" is
> reasonably well-defined as to its methods, etc. (delete an item on the list,
> replace an existing item, add an item to the end of the list, select a
> specific item by its location in the list). What would that look like in
> Java and Ada, and what are the advantages/disadvantages of each? I could
> certainly seeing a ragged string array (in any language) as a reasonable
> approach to addressing this requirement...

That's a fair enough point. From my perspective, I'd utilize unbounded
strings for the names because speed isn't a concern and its just
generally easier to use unbounded strings. Keeping an array of pointers
to unbounded strings? Probably not. I'd use either a generic linked list
package or derive the name retaining element from an OO list package. Of
course, that's working from my own library of data structure code - not
some sort of Ada standard library.

A fair criticism would be that many data structures are available
commonly for other languages within development environments even though
these data structures are not part of the language. The fact that VC++
provides the MFC or Java has its class libraries sort of makes them a de
facto part of the language and all the theoretical arguments in the
world don't change the facts on the ground.

It would serve Ada well to have a class library of data structures that
is well documented and bundled with all of the major compilers.

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/

"Some people think programming Windows is like nailing jello to the 
ceiling... easy with the right kind of nails."

    --  Ivor Horton - Beginning Visual C++ 6
======================================================================