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

[Warren Young]

Chris Frey wrote:
> 
> This is a big disadvantage in my view.  It adds a dependency to the
> user's build process, not just to mysql++'s.

Yes, it's a problem.  But we are beset by problems currently, too.  I am 
proposing trading a large problem set for a smaller one.

> I would not be keen on writing XML in order to get C++.

...even if the library comes with good examples for you to hack up to 
meet your personal requirements?  I can't imagine it needing a syntax 
more complicated than:

	<ssqls name="MyStruct">
		<int name="MyNumber"/>
		<mysqlpp:Date name="MyDate"/>
		...
	</ssqls>

Pretty much the same as the current syntax.

Another advantage I forgot to mention is that you could put several of 
these declarations into a single file, and the tool would be able to 
spit out as many source files as needed.

And another advantage just popped out of the XML syntax I just invented: 
because the types are tags, we can verify in advance that the caller is 
using appropriate types.  Currently, nothing stops someone from saying:

	sql_create_3(doomed,
		1, 3,
		char*, x,
		std::complex, y,
		MyOwnStrangeType, z)

This will generate a perfectly legal C++ structure.  But, using it will 
at best cause the compiler to barf in the middle of some hideous macros. 
  Even worse, the code may compile, and then cause who knows what kind 
of run-time havoc when trying to do the type conversions.

If the syntax is all that bugs you, we could make the generator accept 
the current SSQLS macro syntax.  It's pretty straightforward.  The main 
reasons not to are that it rules out several classes of tools (e.g. 
XSLT) and it makes the parser more complex than it has to be.  A middle 
ground would be to write a translator from the SSQLS syntax to the new one.

 > I'm uncomfortable
> going in the other direction toward code generators, even with the above
> advantages.

If those advantages aren't sufficient, what would it take?