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=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,67748e866d067110 X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!postnews.google.com!c65g2000hsa.googlegroups.com!not-for-mail From: Maciej Sobczak Newsgroups: comp.lang.ada Subject: Re: SOCI-Ada: The Database Access Library for Ada Date: Fri, 8 Aug 2008 08:31:54 -0700 (PDT) Organization: http://groups.google.com Message-ID: <88a4c984-53e3-4909-ace9-19c3cedf4851@c65g2000hsa.googlegroups.com> References: <9fa4c3e0-86bc-4a7d-98fb-6be76cb8aa68@d1g2000hsg.googlegroups.com> <6g0hikFdkv5oU1@mid.individual.net> <21f1f8b4-8e25-4b3f-90fa-004595237c1a@e39g2000hsf.googlegroups.com> <6g313lFe18jnU1@mid.individual.net> NNTP-Posting-Host: 128.141.45.203 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: posting.google.com 1218209514 23518 127.0.0.1 (8 Aug 2008 15:31:54 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Fri, 8 Aug 2008 15:31:54 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: c65g2000hsa.googlegroups.com; posting-host=128.141.45.203; posting-account=bMuEOQoAAACUUr_ghL3RBIi5neBZ5w_S User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9) Gecko/2008061004 Firefox/3.0,gzip(gfe),gzip(gfe) Xref: g2news1.google.com comp.lang.ada:1554 Date: 2008-08-08T08:31:54-07:00 List-Id: On 8 Sie, 15:47, "Alex R. Mosteo" wrote: > I see your reasoning, and I agree it's a good idea to adapt to the particular > culture surrounding a language, albeit I'm not so sure what's a "valid" Ada > way. For me, as long as there are no pointers around, it's kinda enough. :-) > I personally don't mind some operator overloading in well-defined > contexts Note that in the C++ version of SOCI there is also a lot contributed by temporary objects. For example, here: int salary; int id = 123; sql << "select salary from persons where id = :id", into(salary), use(id); there is a temporary (and invisible) object that has lifetime spanning to the end of the full expression and that provides a hook for actual statement execution. The statement cannot be executed before gathering all the information, including variable binding, and the temporary object is a nice way to "subscribe" the the end-of-expression point. This is possible because temporary objects are part of the language and they have well-defined lifetimes. I see no way to even come close with Ada. Another issue is that in Ada operators produce results that need to be "consumed" (either assigned to something or used in bigger expressions). This excludes the use of operators at the "top level" of the statement. Even something as simple as this: cout << "Hello"; cannot have a simple equivalent in Ada. Note that I do not want to imply that C++ is better than Ada in these examples - everything has its price and the issues with temporary objects or the ability of the expression results to be silently ignored create lots of opportunities for problems to creep in. I have just read a coding standard that forbids operator overloading whatsoever - and it was justified. These are just two different language cultures. I don't think it makes sense to cram one into another - the resulting bricolage might be indigestible and this is certainly not in the interest of the library. But I'm open for any suggestions. I just cannot come up with anything reasonable on my own. > If I were idle, for example, I'd like some controlled type for > automatically scoped transactions Yes, this is a natural candidate. > and a matrix view of results Why would you ever want it? The database rowset is not a random-access- thingy. Note that at least in theory it might be possible for the database to produce the result without actually having the full span on the resulting rowset (and without possibility to rewind back). If you need a matrix, copy the result (using the batch idiom) to the matrix created specifically for this purpose. > I always end > implementing something like that. And I've never seen any need for this. > I have a small project with only a few database queries that now are really > ugly (because the library I'm using can't bind vars to values and thus there's > a lot of string concatenation). Probably it also introduces some security issues. > It would be a good opportunity for me to clean > it up and get a feel for SOCI; I'll tell you how it goes if I do it. Don't hesitate to ask questions if you have any. -- Maciej Sobczak * www.msobczak.com * www.inspirel.com