Re: RFC C++ Interface
От | Randy Jonasz |
---|---|
Тема | Re: RFC C++ Interface |
Дата | |
Msg-id | Pine.BSF.4.30.0012132026180.51433-100000@nietzsche.jaded.net обсуждение исходный текст |
Ответ на | Re: RFC C++ Interface (ncm@zembu.com (Nathan Myers)) |
Список | pgsql-hackers |
Thanks for responding. I've made some comments below. On Wed, 13 Dec 2000, Nathan Myers wrote: > On Wed, Dec 13, 2000 at 03:16:28PM -0500, Randy Jonasz wrote: > > On Tue, 12 Dec 2000, Nathan Myers wrote: > > > On Tue, Dec 12, 2000 at 05:28:46PM -0500, Bruce Momjian wrote: > > > > > I was co-architect of the Rogue Wave Dbtools.h++ interface design > > > > > ... The design is really showing its age. > > > > Can you suggest areas that should be changed? > > > As I recall, we were much more fond of operator overloading then than is > > > considered tasteful or wise today. Also, there was no standard for how > > > iterators ought to work, then, whereas today one needs unusually good > > > reasons to depart from the STL style. > > > > Interesting comments. I can see using the STL framework for iterating > > through result sets being one way to go. Would something like: > > > > vector<pgrows>table = pgdb.exec("Select * from foo"); > > vector<pgrows>::iterator row; > > vector<pgrows>::iterator end = table.end(); > > > > for( row = table.begin(); row != end; ++row ) { > > *row >> field1 >> field2; > > //do something with fields > > } > > > > be along the lines you were thinking? > > No. The essence of STL is its iterator interface framework. > (The containers and algorithms that come with STL should be seen > merely as examples of how to use the iterators.) A better > example would be > > Postgres::Result_iterator end; > for (Postgres::Result_iterator it = pgdb.exec("Select * from foo"); > it != end; ++it) { > int field1; > string field2; > *it >> field1 >> field2; > // do something with fields > } > > (although this still involves overloading ">>"). > The points illustrated above are: > The above I like very much although it implies a synchronous connection to the back end. This can be worked around though by providing both a synchronous and an asynchronous interface rather than using just one. I don't see any problems with overloading ">>" or "[]" to obtain the value of a column. > 1. Shoehorning the results of a query into an actual STL container is > probably a Bad Thing. Users who want that can do it themselves > with std::copy(). On further thought I agree with you here. Returning an iterator to a result container would be much more efficient than what I originally proposed. > > 2. Lazy extraction of query results is almost always better than > aggressive extraction. Often you don't actually care about > the later results, and you may not have room for them anyhow. > > Rather than the generic result iterator type illustrated above, with > conversion to C++ types on extraction via ">>", I would prefer to use > a templated iterator type so that the body of the loop would look more > like > > // do something with it->field1 and it->field2 > > or > > // do something with it->field1() and it->field2() > This creates the problem of having public member variables and/or having a mechanism to clone enough variables as there were columns returned in an SQL statement. I much prefer the earlier methods of accessing these values. > However, it can be tricky to reconcile compile-time type-safety with > the entirely runtime-determined result of a "select". Probably you > could put in conformance checking where the result of exec() gets > converted to the iterator, and throw an exception if the types don't > match. > > Nathan Myers > ncm@zembu.com > > > Cheers, Randy Jonasz Software Engineer Click2net Inc. Web: http://www.click2net.com Phone: (905) 271-3550 "You cannot possibly pay a philosopher what he's worth, but try your best" -- Aristotle
В списке pgsql-hackers по дате отправления: