Re: static globals in SSQL macro expansion -> multiple definition linker errors

[Warren Young]

Chris Frey wrote:

> You can define other sub macros conditionally though, and call them from
> the first.  

True...

What do you think of the idea of generating separate .cpp and .h files 
for each SSQLS from an XML input file?  I like it because:

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.

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.