On Wed, Jul 06, 2005 at 02:51:20PM -0600, Warren Young wrote:
> 1. It generates code you can read. (It doesn't _have to_, I know, but
> it will be a design requirement.)
>
> 2. It generates code you can debug. Ever gotten compiler errors on the
> final line of an SSQLS declaration, because of an error in the expanded
> macro? I have. These messages are almost completely useless. And
> heaven help you should try single-stepping into an SSQLS method call.
>
> 3. It gives us the opportunity to trade C macro punctuationitis
> (trailing backslashes, token pasting syntax...) for a better syntax. I
> don't expect the boilerplate code to ever be as readable as pure C++
> code, but it can be more readable than it is now.
>
> 4. The generated macro concept forces you into generating too much code.
> custom.pl generates macros for up to N-member SSQLSes, even if you
> never use all the {1..N-1} instances. The library maintainer's
> incentive is to make N large, so the end user never has to increase N,
> even though most programs will never have SSQLSes approaching N members.
> Complier limits and good sense, on the other hand, argue for lower
> values of N. The closest you can come to a happy medium is when the
> minimum number of compilers and bits of end-user code break when
> upgrading the library.
>
> 5. Last but not least, it solves the static member problem naturally.
I like all those points too. In addition, the fewer macros there are,
the easier it is to separate things into C++ namespaces. When there
are naming conflicts with macros, the choices for fixing them are
limited.
> My only objection to it is that it requires special setup in the build
> environment, or a separate by-hand step for those environments that
> don't allow you to set up special build rules. To get those advantages,
> I can live with this.
This is a big disadvantage in my view. It adds a dependency to the
user's build process, not just to mysql++'s.
I would not be keen on writing XML in order to get C++. That would seem
a step backwards to me, compared to the usability we currently have
with macros. An sql_create() is pretty straightforward.
Every so often I ponder methods to get rid of the macros, but the direction
I would prefer to take would be some C++ method that is as easy to
use as the macros (not sure that's possible though). I'm uncomfortable
going in the other direction toward code generators, even with the above
advantages.
- Chris
