From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.157.60.8 with SMTP id q8mr3229102otc.84.1474743599062; Sat, 24 Sep 2016 11:59:59 -0700 (PDT) X-Received: by 10.157.34.41 with SMTP id o38mr1158314ota.6.1474743599023; Sat, 24 Sep 2016 11:59:59 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!news.glorb.com!x192no4141997itb.0!news-out.google.com!w143ni11443itb.0!nntp.google.com!x192no4141983itb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sat, 24 Sep 2016 11:59:58 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=50.250.26.106; posting-account=AvekzAoAAABj-TclKcOWQmXwA49MFPGX NNTP-Posting-Host: 50.250.26.106 References: <11ee98f5-d373-4c72-8562-c310cc76817d@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <5560c627-b10b-4693-adc0-662776cbdb6c@googlegroups.com> Subject: Re: Question on bounded / unbounded strings From: John Smith Injection-Date: Sat, 24 Sep 2016 18:59:59 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:31878 Date: 2016-09-24T11:59:58-07:00 List-Id: On Saturday, September 24, 2016 at 1:45:14 PM UTC-4, Dmitry A. Kazakov wrot= e: > >>> If you need to separate a large string into a bunch smaller ones > >>> that do not have a pre-determined size, using a fixed string does no= t make > >>> any sense. > >> > >> I *never* need that. It was discussed already. > > > > If a file is read in (the format is non-standard) and you now need > > to sift through the details of the file, you will need this. >=20 > Searching for a pattern / skipping irrelevant parts of the input do not= =20 > require that. No need to split anything. >=20 Then how would you accomplish this? > >>> When you do need to build a string, it is far easier to have one > >>> unbounded string that is added on to and then written out. > >> > >> No, it is easier with fixed strings. > > > > How? > > > > I've tried going to the example on your website, but it seems that that= is down. >=20 > Hmm, it is not down: >=20 > http://www.dmitry-kazakov.de/ada/strings_edit.htm > http://www.dmitry-kazakov.de/ada/components.htm#Parsers_etc >=20 I'll have a look when I get home. > >>> Having a > >>> fixed string means that I woul need something along the lines of a > >>> recursive solution, since I can't extent the size of the string after > >>> it's been instantiated. > >> > >> The output length for formatted output is always known. Normally the > >> parts of a composite string are statically known, that precludes > >> iteration or recursion. In other cases, like building a directory path > >> from some structure, I first calculate the length and then declare the > >> result string. > > > > No, it is almost always unknown in my experience :-). If I'm putting > > together a report that needs to be e-mailed out, I have no idea how lon= g > > it will be. I would first need to do my thing, get the string returned > > from it, append it to an accumulator string and after all of that was > > done, I can now know its length. >=20 > But a mail body is not a string! If you send a MIME attachment the=20 > natural way to do it is to use a stream as the source. String can be=20 > used, but for short text mails only. >=20 > I believe AWS takes streams for attachment. My implementation of SMTP=20 > certainly does: >=20 > http://www.dmitry-kazakov.de/ada/components.htm#GNAT.Sockets.SMTP.Client.= Attach_Stream >=20 Sure it is. This is especially true when it comes to sending out a string = e-mail (and a bunch of HTML can be put on a single line.) But the e-mail e= xample is just one that I could think of on a dime. I'll have a look at what you did when I get home. > > If I were to first run my analysis, get the length of the string > > (which is the result that will go out), then keep doing this until I'm > > finished (at which point I will be able to figure out how big my > > accumulator is supposed to be.) Now, I would have to re-run my analysis > > again and then copy in the results into the my newly allocated > > accumulator string. That would make for some needlessly complex logic i= n > > my application (as opposed to just dump everything to an unbounded stri= ng.) >=20 > I would use a stream on top of a segmented buffer, e.g. >=20 > http://www.dmitry-kazakov.de/ada/components.htm#Storage_Streams >=20 > Or a FIFO if the producer of the content and the SMTP client are run by= =20 > different tasks. >=20 > You don't need to build all attachment in the memory in order to be able= =20 > to send it. >=20 I disagree. If I write out the attachment to disk and then e-mail it, that= 's even more overhead. Why do this? Create a neat package in memory, e-ma= il it out and then forget about it. Doing this operation in memory would b= e easier and faster. And I don't have to worry about temporary files or an= y other files (as well as deleting the files, testing this additional logic= , etc.) > > However, if I ever need string functionality that I'm used to in > > Python or C++, Unbounded strings are the only reasonable solution. >=20 > You used to use dynamic strings. But there is no evidence they really=20 > simpler to use. In my code which varies from network protocols to=20 > compiler developing tools and AI you will find almost no=20 > Unbounded_Strings. Would it be simpler with Unbounded_Strings? I doubt it= . >=20 When I get home, I'll have a look at what you've written.