List:MySQL++« Previous MessageNext Message »
From:Chris Frey Date:July 8 2005 2:12am
Subject:Re: static globals in SSQL macro expansion -> multiple definition linker errors
View as plain text  
On Wed, Jul 06, 2005 at 08:24:08PM -0600, Warren Young wrote:
> 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.

It is the syntax, I must admit (it's so top-heavy with markup), plus needing
some other dependency on my system to build.  It's like the boost build
process which used to require a whole other make (Jam).  Fortunately their
tarballs come with Jam source, so it is easy to compile it on pretty much
any system with a decent compiler.

I also like that the macros are part of C++ code.  It's not some new
language that's added to a project.  I'm reminded of Microsoft's special
interface language here.

Also, the idea of generating code usually tells me that something is
broken in the design or abstraction somewhere.  The macro is code generation
too, but I consider it broken in the same respect.  The downside is that
I can think of no other way to get SSQLS functionality other than using
some kind of code generation, so it is a necessary evil.

But overall, I guess my arguments against XML are more prejudices than
valid reasons.  I'm not totally against code generation: I'm pondering
it myself for my own CPPHP project.

Doing it in XML may make it easier to GUI-ify or automate this.
The syntax makes me shudder, but it's the best in the field so far,
it seems. :-)


> A middle 
> ground would be to write a translator from the SSQLS syntax to the new one.

This could be done as a macro itself. :-)


> > 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?

If we go with XML, it would be nice to keep the macros around for a major
version cycle, even if marked deprecated with no guarantee that they would
keep up with their XML cousins.  Would be easier to compare the advantages
that way.

I've sifted my way though the macros before, so I don't mind supporting
them for a while, even deprecated.  They are pretty stable anyway.

If Wolfram sends a patch, I hope it is included, even if XML is the new
direction.

- Chris

Thread
static globals in SSQL macro expansion -> multiple definitionlinker errorsWolfram Arnold6 Jul
  • Re: static globals in SSQL macro expansion -> multiple definition linker errorsChris Frey6 Jul
    • Re: static globals in SSQL macro expansion -> multiple definitionlinker errorsWolfram Arnold6 Jul
    • Re: static globals in SSQL macro expansion -> multiple definitionlinker errorsWarren Young6 Jul
      • Re: static globals in SSQL macro expansion -> multiple definition linker errorsChris Frey6 Jul
        • Re: static globals in SSQL macro expansion -> multiple definitionlinker errorsWarren Young6 Jul
          • Re: static globals in SSQL macro expansion -> multiple definition linker errorsChris Frey7 Jul
            • Re: static globals in SSQL macro expansion -> multiple definitionlinker errorsWarren Young7 Jul
              • Re: static globals in SSQL macro expansion -> multiple definition linker errorsChris Frey8 Jul
                • Re: static globals in SSQL macro expansion -> multiple definitionlinker errorsWarren Young8 Jul
              • Unresolved External SymbolBrian Farmer14 Jul
                • Re: Unresolved External SymbolWarren Young14 Jul
                • Connection always on and field namesAnkur G35 Saxena17 Jul
                  • Re: Connection always on and field namesWarren Young18 Jul
  • Re: static globals in SSQL macro expansion -> multiple definitionlinker errorsWarren Young6 Jul