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