In an effort to provide some ideas for replacing the current macro-
tized ssqls here's an idea.
I use boost heavily in my code and I completely forgot about this
It's not a part of boost yet but I met Joel at BoostCon and was
really impressed. Not only does he document well, but he has done
some pretty amazing things with the spirit library.
On Aug 14, 2007, at 5:11 PM, Warren Young wrote:
> Graham Reitz wrote:
>> I also stated mysql++ has many very nice features.
> What's wanted here isn't more praise, but more ideas.
>> 1) Macros are very difficult to debug.
> Yes, that's well understood. If you'll read the Wishlist, you'll
> see that the proposed SSQLS replacement already addresses this.
>> I had to go through a ssqls 50 columns in length and eliminate
>> each column one by one to figure out what the offending type was.
> Learn binary search, love binary search.
>> Compile time errors are always more desirable than segmentation
> None of what I wrote was related to your uninitialized variable
> segfault issue. That's a pure bug report, and is totally fine.
> We're talking about design errors here, not plain ol' bugs. The
> distinction is this: if fixing it requires changing an interface,
> it's a design error. I can fix this problem inside the ColData
> class itself. It's just a bug.
>> If blob types need to be initialized ahead of time the compiler
>> should indicate that requirement, not a seg. fault.
> No, a default-initialized ColData should have reasonable defaults,
> so when you access it, it doesn't blow up on you.
>> 2) It is common to have tables > 50 columns in length.
> Sigh...proof by assertion.
> The question was, "what kind of design requires this?" The only
> way you can answer that to my satisfaction is to show me your
> schema, and defend it. If you're not willing to do that, that's
> fine. I will just go on believing that it's probably wrong, due to
> lack of evidence to the contrary.
>> 3) The need to use the MYSQLPP_SSQLS_NO_STATICS macro is undesirable
> ....and you would do what instead?
>> 4) Using namespaces to workaround an issue with auto increment fields
> You must not have understood my reply to Jim, or didn't read it.
> Go read it [again].
> It tells you that you can have two SSQLSes in the same namespace
> for the same table, with different C++ structure names.
>> 5) Exceptions might be overused, depending upon the author's
>> definition of what is an exceptional circumstance.
> You're acknowledging that this is a taste issue, so the only change
> that can satisfy more than just yourself would be something like a
> pluggable exception policy framework. And if that's the solution,
> I have only one response: patches thoughtfully considered.
>> Any library even the c++ standard libraries should be able to and
>> eager to receive criticism from time to time. It is not a
>> personal attack in any sense. I am sorry if it seemed that way.
> No, actually, plain old criticism never receives a warm welcome,
> not anywhere, from anyone. This fact of human interaction is so
> basic that most people figure it out before they leave elementary
> What is welcome is *constructive* criticism.
> Plain old criticism is "X sux." Constructive criticism is "X sux,
> but you can fix it with Y," where Y is more than just a buzzword.
> In the context of MySQL++, Y needs to be an actual design, if not a
> code patch.
> The closest thing to constructive criticism you've offered so far
> amounted to "fix it with RAII". This is about as helpful as
> answering "wash more often and stop copulating" when asked what to
> do about the African health crisis.
> If you want to be helpful, you're going to have to offer more than
> just vague prescriptions.
> MySQL++ Mailing List
> For list archives: http://lists.mysql.com/plusplus
> To unsubscribe: http://lists.mysql.com/plusplus?