2 messages in com.mysql.lists.plusplusRe: Status of MySQL++
FromSent OnAttachments
David B. Held06 Dec 2001 23:23 
The Lazy Fox07 Dec 2001 09:01 
Subject:Re: Status of MySQL++
From:The Lazy Fox (lazy@foxden.dhs.org)
Date:12/07/2001 09:01:39 AM
List:com.mysql.lists.plusplus

Hi!

"David B. Held" wrote:

You know what? I don't know if MySQL++ is still being worked on. [...] I poked around on sourceforge.net and found that someone, Murray, has made a branch of MySQL++. You can look at Murray's reasons for doing this here:

http://mysqlcppapi.sourceforge.net/ [...] One more point is that even Murray's branch isn't very active. There hasn't been a commit in many months, and the last email message was in October. All indications show that branch to be pretty much dead as well.

If nobody is maintaining a C++ API for MySQL, then let's pick up wherever the last person left off. I only used MySQL++ for a little bit, then came back, only to find that it was broken on gcc 3.0. I gave up on it (since it was a personal project)

I am the maintainer of the Visual C++ port of MySQL++. Due to the fact that there are lots of ports of MySQL++ for different purposes on its download page, it was decided that these ports should be merged into the main package. A couple of months ago I finished porting MySQL++ 1.7.9 to VC++ and integrating it. I sent my stuff to Sinisa in the beginning of October, who replied that he would start testing it soon. My guess was that he would upload that version as soon as he had tested it. However, since then I haven't heard from him anymore.

I have no idea what Sinisa is doing currently, but have you tried to email Michael Widenius (mon@mysql.com)? He appears to have worked on MySQL++ as well. If you still don't get any replies, try mailing somebody else at MySQL AB and ask what the status is.

Are there really so few people who would prefer a C++ API for MySQL?

I certainly hope not.

Given the amount of emails I get from people asking how to use my VC++ port I'd say the VC++ port is reasonably popular.

Maybe there's a lack of interest because the MySQL++ documentation is rather sparse (sorry Sinisa!) and riddled with grammatical errors.

Then let's start a documentation project on a branch, that addresses both end users and potential maintainers.

That's a very good idea. Something like a code guide would've helped me much during porting. Instead, I had to go through the code right away. Also, most of the functionality of MySQL++ either isn't listed in the current documentation or only vaguely, without enough examples. I think that with more documentation most newbie questions on this list would also be prevented.

I only use the basic features offered by the API, but I was able to get code running in a short amount of time and I haven't run into any problems since then.

I couldn't get it to work with gcc 3.0, and couldn't figure out how to apply the patch (it didn't look like a legit patch file, and I wasn't about to try to patch it by hand).

I think Sinisa was also busy integrating that patch into the newest MySQL++ version.

So, should we branch Murray's version, and try to clean things up as much as possible? I think if we documented everything, made the code readable and maintainable, and used the latest C++ idioms and techniques, we could convince MySQL AB to promote a new, modern branch of MySQL++. Is anyone else interested in doing this?

This way you might end up with a dozen different (and likely incompatible) MySQL++ API's. Besides, since the old MySQL++ is still the official API it is also more widely spread, which means that a change of API might not be appreciated by users. Of course, I realize that Murray's version has certain advantages. I guess it's a much cleaner version, much better portable to other platforms than MySQL++ which has a lot of macros and weird template construction which makes some compilers (like VC++) puke. However, the problem with the latest C++ techniques, like exception handling and run-time type information, are also by far C++'s slowest features. The idea of the preprocessor and template constructions in MySQL++ was to preserve speed, and speed is exactly that which the MySQL database is based on.

c ya,

lazyfox