Re: Question on bounded / unbounded strings

["Randy Brukardt" <randy@rrsoftware.com>]

"Maciej Sobczak" <see.my.homepage@gmail.com> wrote in message 
news:625e3d31-1a45-4308-8122-e7ccac0b3e13@googlegroups.com...

>Sorry Dmitry, but I don't think that this discussion is interesting for 
>anybody else here.

I find it interesting, to see you defend the indefensible. ;-)

Needless to say, I agree with Dmitry. For instance, Split (in terms of a 
string type, which is what is being talked about) is an operation that takes 
one string and produces several. (Getting substrings is a different 
operation altogether.) You very rarely want an actual Split operation (which 
is all Dmitry said initially); you're much more likely to use some sort of 
substring of the original string.

Ada bounded strings are nearly useless; as Dmitry said, you rarely have a 
hard bound and the fact that all of the objects of the type have to have the 
same bound just compounds the problem. Just forget them and use either 
Unbounded_Strings or String.

And the Ada.Strings packages are filled with cool subprograms that are 
almost never used. Even if you remember one exists, you have to go look it 
up to figure out the name and parameters and usage -- by that time, you 
could have written the operation yourself with basic operations (admittedly, 
with a slightly higher chance of introducing bugs).

I wrote my spam filter exclusively with unbounded strings in part to 
demostrate how much easier that would be. Needless to say, that failed 
miserably. I did get the experience I was looking for, but it was mostly 
bad. :-)

There is one use for unbounded strings that comes up in the spam filter that 
probably couldn't have been usefully programmed any other way. One wants to 
search the text of messages for problem phrases unencombered by irrelvant 
stuff (like encodings and line endings). I did that by putting the decoded 
(and stripped of HTML markup) text into an unbounded string, and then search 
that. That is way cheaper than searching multiple lines and somehow allowing 
blanks to be matched by line ends as well as separately dealing with 
decoding and markup.

Still, this seems to be a rare case; I've never encountered anything else 
like it. Most of the operations I encounter would be better off written (in 
Ada, no one here should care about any other language. ;-) using plain 
String. The extra work is usually not that much (and most of the cool 
operations are available for plain String in Ada.Strings.Fixed, in case one 
is exacly what is needed - I use Index and Find_Token a lot).

                                   Randy.