Re: String filtering

[Jacob Sparre Andersen <sparre@nbi.dk>]

David Trudgett wrote:
> Dmitry A. Kazakov wrote:
>> On Tue, 27 Sep 2005 19:13:17 +1000, David Trudgett wrote:

>>>        New_Str : Unbounded_String
>>>          := To_Unbounded_String(Count(Str, Alphanumeric_Set));
>>
>> If you do this, then use String (1..Count (...));
>
> If I did that then I would need to convert back to unbounded_string
> when I return the function result. Would that be significantly
> faster than working on a pre-allocated unbounded string?

I think it would, but it clearly depends on the implementation of
Ada.Strings.Unbounded.

>> Either, you need a character *stream* filtering, 
>
> Possibly, but I'm not using a socket stream interface at the current
> time. The socket library I'm using right now doesn't do streams.

It definitely looks like an ideal example for the use of streams.  Is
there something that makes it a bad idea to switch to a stream-capable
socket package?

>> Especially in text parsing etc. It is quite uncommon to change a
>> string content there.

I do it quite often, but I've never pretended to be common.

>> In your example you don't do it either. You create a new string.
>
> Yes, well, functions work that way in Ada (fortunately, or
> unfortunately, I don't know). I could have made it a procedure with
> an "in out" parameter, but I like functional programming better.
> Unfortunately, I haven't been able to do proper functional style
> programming in Ada so far, having been thwarted by strong typing and
> lack of "out" parameters in functions.

You should use the programming styles supported by Ada, when you're
programming in Ada.  Otherwise it may be very frustrating to program
in Ada.  For functional programming you should use SML, Erlang, OCaml
or another "proper" functional programming language.

>> Also both the source and the result strings have *known* length.
>
> Known but variable, with no particular bounds.

That's not enough to force you to use unbounded strings.  If you were
doing in-place modifications of the string, you could argue for
unbounded strings, but what you've shown us so far does not support
the use of unbounded strings for your problem.

Greetings,

Jacob
-- 
xsnow | xshovel > /dev/null