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 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,1116ece181be1aea X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-10-06 10:05:03 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!nntp.cs.ubc.ca!cyclone.bc.net!news.alt.net!sjc72.webusenet.com!news.webusenet.com!wn14feed!wn13feed!worldnet.att.net!207.35.177.252!nf3.bellglobal.com!nf1.bellglobal.com!nf2.bellglobal.com!news20.bellglobal.com.POSTED!not-for-mail Message-ID: <3F819C99.6080904@cogeco.ca> From: "Warren W. Gay VE3WWG" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030716 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Is the Writing on the Wall for Ada? References: <3F7AC5B0.9080108@noplace.com> <3F7B7641.9030908@noplace.com> <3F7C8482.20102@comcast.net> <3F7D69EA.5030707@noplace.com> <3F7E2740.1050703@comcast.net> <3F7EBD85.8080205@noplace.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 06 Oct 2003 12:47:21 -0400 NNTP-Posting-Host: 198.96.223.163 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1065458999 198.96.223.163 (Mon, 06 Oct 2003 12:49:59 EDT) NNTP-Posting-Date: Mon, 06 Oct 2003 12:49:59 EDT Organization: Bell Sympatico Xref: archiver1.google.com comp.lang.ada:319 Date: 2003-10-06T12:47:21-04:00 List-Id: Marin David Condic wrote: > Right. O.K. Fine. How many databases out there support Ada's > Bounded_String? I don't do much database programming anymore but back > when I did, I didn't notice much support for Ada - beyond maybe a vendor > gave you an Ada pre-processor so you could put SQL into your code. The > data types *maybe* aligned with the more primitive Ada types, but > typically, if the database had some variety of string/text data, you had > to provide a buffer of type String. Maybe its different now - does MySQL > provide something compatible with Bounded_String? This is my big chance to say... APQ supports Bounded_String! ;-) See http://home.cogeco.ca/~ve3wwg/software.html#APQ The database need not support it by name, because a CHAR(n) or VARCHAR(n) can easily translate into/out of a Bounded_String, which is exactly what APQ does within a OO framework. Mind you, I've personally not had much reason to use Bounded_String, but within a package for general use, you try not to set policy. Rather you leave it up to the user to decide if a data type or interface is useful to him or not. So it is there, whether it gets used or not, is another matter ;-) > So I'm back to where I started: The database has a field that is an > array of 80 characters. I declare something like Person_Address: String > (1..80) ; I read it in. I scan it to determine where it stops and keep a > Person_Address_Last count lying around somewhere. I can now use that > with Text_IO to display to a file or use the 'Image on some numeric > value to add some info to it, or use all the usual attributes of 'First, > 'Last 'Range, etc. It was automatically limited by the language to no > more than 80 characters. It couldn't have buffer-overflowed and provided > a security leak. I've got Ada.Strings.Fixed to do a variety of parsing > things for me that are basically the same as those in > Ada.Strings.Bounded. How is it I get more value out of Bounded_String? It really only gives you the advantage of Unbounded_Strings, with the limitation applied. APQ also allows you to retrieve a column value as a normal string of any length, using the function call syntax. However, the disadvantage of that is that the caller is not limiting the maximum length of the data being returned (it might overflow the stack for example). Unbounded_String might permit the heap to be overflowed, although both of these scenarios are unlikely unless the user is misusing the interface to retrieve some large BLOB-like data. > Granted, I've got to do a bit more work by keeping some kind of Last > counter around and Bounded_String would have done that for me - once I > went to some effort to figure out where the actual string stopped when I > read it into my String (1..80). But for that little bit of extra work, > I've got visibility to the field as a String - compatible with all the > other language features. Bounded_String means extra with's, > instantiation, conversions, etc. What do I get in exchange that isn't > already there for type String? > > MDC > > Robert I. Eachus wrote: >> I totally agree! ;-) But if you use a database interface that uses >> Bounded_Strings for such datatypes then youy wrap it all up in one >> package and instantiate that to get everything. The advantaga, again >> is when you have queries that return an array of whatever. An array >> of some instance of Bounded_String is much easier to work with than an >> array of records, containing both name length and a String. One of the things that discourages me from using Bounded_Strings is the number of instantiations that you end up making (for each different string size). I would have preferred one instantiation, and then a discriminant that set the maximum size on the object. But that may have problems of its own. Warren. -- http://home.cogeco.ca/~ve3wwg