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

#1

On Wed, Jul 06, 2005 at 01:15:33AM -0700, Wolfram Arnold wrote:

Quote:

Could the macro be split into two or take an extra flag to optionally
not generate the definition for the globals? I'd be glad to give this a
shot, but I wanted to hear from the community if there is any reason
other than lack of volunteers. This has come up before; I found mailing
list articles as far back as 2001 on this.

Personally, I'd say go for it. Keeping all the logic in one macro / header
(i.e. custom-macros.h) is probably the most maintenance friendly, since the
macro needs to be expanded for the names anyway, and you don't want to
duplicate it anywhere.

Something like this might be useful:

// file: tables.h - define it
sql_create_5(stock, ..... );

// file: stock.cpp - the only file that has the static data
#define SSQLS_GENERATE_STATICS
#include "tables.h"

// file: client.cpp - simple user module
#include "tables.h"

Might take some creativity to do that, but I think it's possible.

- Chris

--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

#2

On Wed, Jul 06, 2005 at 02:51:20PM -0600, Warren Young wrote:

Quote:

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.

Quote:

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

--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

#3

On Wed, Jul 06, 2005 at 08:24:08PM -0600, Warren Young wrote:

Quote:

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. :-)

Quote:

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. :-)

Quote:

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

--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

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

mailing.database.mysql-plusplus mailing.database.mysql-plusplus

Re: static globals in SSQL macro expansion -> multiple definition linker errors - 07-06-2005 , 05:40 AM

Re: static globals in SSQL macro expansion -> multiple definition linker errors - 07-06-2005 , 05:25 PM

Re: static globals in SSQL macro expansion -> multiple definition linker errors - 07-07-2005 , 09:12 PM