Kevin Atkinson在1998年创建了MySQL++。最初，MySQL++是为MySQL“量身定制”的C++ API，但是作者很早就开始努力尝试使它从特定的数据库引擎（MySQL）中独立出来，成为相对通用的数据库访问API，并称它为“SQL++”——这也就是为什么旧版本的库文件夹被命名为“sqlplus”。这也使老版本让一些类有了“Mysql”的前缀但不是全部，因为其余的部分负担着“通用化”访问各种数据库引擎的工作。所有Kevin发布的MySQL++版本号中都含有“pre-1.0”。
1999年，MySQL AB接手了MySQL++库的开发。在这之后，Monty Widenius（MySQL源代码的主要作者、MySQL AB的发起人之一）独自做了一些工作，但是很快此项目被转给另一个MySQL雇员：Sinisa Milivojevic。MySQL++发布了版本1.0和1.1，而Kevin正式将MySQL++的代码维护工作移交给Sinisa的时候已经是1.2了（这里“正式移交”应该指的是一些形式上的手续和文件，如上文所述，Sinisa应该在1.0之前就开始了MySQL++的维护工作），并终止了与MySQL++相关的维护。Sinisa持续维护了此项目一段时间，直到2001年中期才停止，此时MySQL++版本已是1.7.9。在此期间，Kevin的多数据库兼容的想法破灭了，原因相当明显！
后1.7.9时代对于MySQL++来说是停滞期，这个状态持续了超过三年。（也许是因为新千年后互联网泡沫破灭导致的大规模缩减使开发者失去了兴趣。）这期间Sinisa维持着MySQL++邮件列表的运行并为用户提供技术支持，但并没有发布新版本；用户贡献的补丁没有得到官方允许，所以被忽略了，也没有上传到MySQL++的网站上让其他用户去使用。
对于MySQL++来说，最大的障碍在于2001年流行的C++编译器并不是很兼容C++标准。这就造成了MySQL++使用了太多非标准架构，去兼容那些老旧但是流行的编译器。之后的几年，新发布的编译器对C++标准架构的遵从程度在不断提高——不管是警告信息还是通过pre-Standard架构拒绝代码。GCC成为当时大量从“EGCS分歧事件”涌现出的编译器里特别“潮”的那一个。官方的说法是，EGCS的分歧在1999年结束，但总有一些延迟，这体现在新发布的GCC与其他版本的编译器之间。现在回到MySQL++的历史，也就是当2001年MySQL++的开发停滞之后，结束了分歧的GCC才开始流行。结果，在新编译器下使用MySQL++干净利落地编译变得越来越困难。因为MySQL++大量地使用了模板，这使用户收到了严重的影响：MySQL++的一部分是作为头文件包含在预编译过程中的，所以库问题就直接造成程序出问题。
对于前面提到的，MySQL++项目停滞期间用户贡献的补丁大部分都是为了使程序能遵从C++标准架构。因为当时没有官方人员被要求去测试并认证这些补丁，你将会遇到bazzar开发模式中最坏的结果：你可以完全自由地去开发，但是没有用户手册来告诉你哪些补丁是可用的哪些应该放弃。这些补丁中许多是不能互相兼容的，而一些是在另一些的基础上建立所以你还得弄清它们之间的顺序，还有一些确实不错，但又没有给出一个功能完整的MySQL++版本……随着时间的推移，找出并使用正确的不补丁变得困难重重——这时候GCC好像更加流行起来了。
时间终于到了2004年8月初，Warren Young觉得自己受够了MySQL++这种境况并开始接手去处理。在这个月之后的一个时间里，他发布了MySQL++ 1.7.10，当然这个版本的贡献不仅仅是使代码兼容于GCC 3.3。从那以后，在互联网上的朋友们的帮助下，MySQL++修复了一些bug，增加了一些新特性，又产生了一些bug，又不断地被修复——不管怎样现在的MySQL++是鲜活并且健康的！
/
本文翻译自：
http://tangentsoft.net/mysql++/doc/html/userman/index.html#history
终于翻译完了……考虑到阅读、个人英语水平以及涉及到的历史，本文不是完完全全的直译。
如果你看到翻译上出现什么问题或者不妥当的地方，非常希望你能在评论中提出来，网友们会很感谢你的。另外，我觉得文中讲编译器分歧那一段很有意思，这算是互联网泡沫破灭大环境是的一个角落吧，现在看起来就像从一个小战场去读懂一场战争一样。
下面给出原文供参考：
MySQL++ was created in 1998 by Kevin Atkinson. It started out MySQL-specific, but there were early efforts to try and make it database-independent, and call it SQL++. This is where the old library name “sqlplus” came from. This is also why the old versions prefixed some class names with “Mysql” but not others: the others were supposed to be the database-independent parts. All of Kevin’s releases had pre-1.0 version numbers.
Then in 1999, MySQL AB took over development of the library. In the beginning, Monty Widenius himself did some of the work, but later gave it over to another MySQL employee, Sinisa Milivojevic. MySQL released versions 1.0 and 1.1, and then Kevin gave over maintenance to Sinisa officially with 1.2, and ceased to have any involvement with the library’s maintenance. Sinisa went on to maintain the library through 1.7.9, released in mid-2001. It seems to be during this time that the dream of multiple-database compatibility died, for obvious reasons.
With version 1.7.9, MySQL++ went into a period of stasis, lasting over three years. (Perhaps it was the ennui and retrenchment following the collapse of the bubble that caused them to lose interest.) During this time, Sinisa ran the MySQL++ mailing list and supported its users, but made no new releases. Contributed patches were either ignored or put up on the MySQL++ web site for users to try, without any official blessing.
The biggest barrier to using MySQL++ during this period is that the popular C++ compilers of 2001 weren’t all that compatible with the C++ Standard. As a result, MySQL++ used many nonstandard constructs, to allow for compatibility with older compilers. Each new compiler released in the following years increased compliance, either warning about or rejecting code using pre-Standard constructs. In particular, GCC was emerging from the mess following the EGCS fork during this time. The fork was healed officially in 1999, but there’s always a delay of a few years between the release of a new GCC and widespread adoption. The post-EGCS versions of GCC were only beginning to become popular by 2001, when development on MySQL++ halted. As a result, it became increasingly difficult to get MySQL++ to build cleanly as newer compilers came out. Since MySQL++ uses templates heavily, this affected end user programs as well: MySQL++ code got included directly in your program, so any warnings or errors it caused became your program’s problem.
As a result, most of the patches contributed to the MySQL++ project during this period were to fix up standards compliance issues. Because no one was bothering to officially test and bless these patches, you ended up with the worst aspects of a bazaar development model: complete freedom of development, but no guiding hand to select from the good stuff and reject the rest. Many of the patches were mutually incompatible. Some would build upon other patches, so you had to apply them in the proper sequence. Others did useful things, but didn’t give a fully functional copy of MySQL++. Figuring out which patch(es) to use was an increasingly frustrating exercise as the years wore on, and newer GCCs became popular.
In early August of 2004, Warren Young got fed up with this situation and took over. He released 1.7.10 later that month, which did little more than make the code build with GCC 3.3 without warnings. Since then, with a little help from his friends on the Net, MySQL++ has lost a lot of bugs, gained a lot of features, gained a few more bugs, lost them again... MySQL++ is alive and healthy now.
