Re: [boost] database library (was Report from Berlin C++ Standards Committee meeting)

From: Jeff Garland (jeff_at_[hidden])
Date: 2006-04-16 12:17:35

On Sun, 16 Apr 2006 14:25:25 +0200, Yuval Ronen wrote
> Jeff Garland wrote:
> 
> What I'm trying to understand is what will be *required* by 
> compiler/std-lib vendors, if they want to call themselves standard 
> C++. One possible answer is to say "nothing is required". Everything 
> is optional. 

I'm personally ok with the "nothing is required" approach because I really
think that if the committee adopts a good interface everything will flow from
that.  For example, no standard library vendor is going to deliver a database
library that can't work at least one database.  And the database vendor  won't
want to be left out of working with standard C++ implementations, so they will
want to deliver high performance versions.  There will be Boost versions that
work with all the common databases, etc.  So even if the details of how the
vendors do this is left unspecified I think from a developer/user perspective
the need would be met because the vendors have several possible approaches to
work it out.

All that said, I suppose it's possible that some companies won't see it that
way. There's a couple companies I can think of that could decide to only
support the databases they make -- thus encouraging use of only their database
products.  If I were a customer of such a company and wanted to use a
different database with C++ I'd be upset and complain, switch vendors, or use
and open source standard library that doesn't have the restriction.

> Note that saying that it's TR so it's optional anyway 
> doesn't quite cut it in the long run. I'm talking about acceptance 
> to the stantard itself some day. So saying "nothing is required" 
> means there's no plan to *ever* require it, even when the TR is 
> merged into the stantard.

Yep, but as the TR gets into practice there is time to learn and make final
adjustments before it is adopted into the standard.  So the TR version doesn't
set everything into stone.

> However, if the plan is to require this interface some day as part 
> of the stantard library, something that a std-lib vendor can't omit 
> if it wants to be compliant, then I don't know what can be required 
> that is implementable by std-lib vendors.

Nor do I, although I suspect that this issue is very similar to what Beman has
been pushing with respect to the C++ standard pointing to other existing
standards (eg: posix) so the standard committee doesn't try to specify
everything.  While the database standards aren't quite as clean as Posix, I'd
think that 'common standards' like ODBC and 20+ years of development and usage
would be enough...

Jeff