static globals in SSQL macro expansion -> multiple definition

#1

Hi,

While we're talking about wish-lists for version 2.0, I have an item to
contribute. In fact, it surprised me this hasn't been addressed yet, or
maybe I'm missing something.

The SSQL macro expansion will create static globals that are being
defined (assinged) as part of the macro. With the ssqls-pretty tool it
was easy to see that...

sql_create_7(PriceData,
6,
7,
Date, date,
int, open,
int, high,
int, low,
int, close,
int, volume,
int, suspended);

....expands into...

struct PriceData {
[...]
static const char *names[];
static const char *_table;
[...]
};

[...]

const char *PriceData::names[] = {
"date" , "open" , "high" , "low" , "close" , "volume" , "suspended" };

[...]

This is fine and dandy, as long as the SSQL macro expansion is used in
only one .cpp source file in the application. If the SSQL macro is put
into a header file and include it into multiple .cpp source files, then
the linker will invariably complain that names and _tables are multiply
defined symbols.

I've only tried this with version 1.7.35 so far, but I haven't seen
anything in the release notes since that this behavior has been changed.

Can this be fixed? Not being able to share SSQL structures across
compilation units inhibits code modularity in cases where the Database
table is the common data structure shared between many different clients
in an application.

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.

Cheers,

Wolfram

--
Wolfram Arnold <wolfram (AT) arnold (DOT) name>

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

#2

Thanks for that suggestion, Chris. I'll play with it.

-Wolfram

On Wed, 2005-07-06 at 06:39 -0400, Chris Frey wrote:

Quote:

On Wed, Jul 06, 2005 at 01:15:33AM -0700, Wolfram Arnold wrote:
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

--

Wolfram Arnold <wolfram (AT) arnold (DOT) name>

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

#3

Wolfram Arnold wrote:

Quote:

While we're talking about wish-lists for version 2.0,

News to me. Since the beta was just released, the v2.0 feature set is
frozen, as far as I'm concerned. (To me, beta means "feature-complete,
but may have bugs.")

That's not to say that I'm not accepting patches for v2.0. Just that
it's a little late...

Quote:

The SSQL macro expansion will create static globals that are being
defined (assinged) as part of the macro.

This has been on the Wishlist for a long time. The copy you have in
your 1.7.35 version has it...look for "static". I point that out
because it contains two suggestions for fixing it as well.

I added a third possibility recently:

"...redesign the SSQLS mechanism entirely. Instead of defining SSQLSes
by instantiating macros, you could declare the structure in, say, an XML
format, which could be tranformed (XSLT? Perl + SAX?) into code very
much like in the current SSQLS macros, except that it would generate
separate .cpp and .h files for each structure. In addition to solving
the static member problem, it would have other advantages, like
side-stepping the Borland C++ macro size limit."

I like this a lot better than the other two choices. The macros are
ugly and unmaintainable. We have the technology to build a better
mechanism.

This would not be a trivial patch, of course.

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

#4

Chris Frey wrote:

Quote:

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

Doesn't work. I tried it. You can't have an ifdef inside a macro.

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

#5

Chris Frey wrote:

Quote:

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.

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

#6

Chris Frey wrote:

Quote:

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.

Quote:

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

ate 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.

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?

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

#7

Chris Frey wrote:

Quote:

It is the syntax, I must admit (it's so top-heavy with markup),

XML can be ugly, but take another look at what I posted. It's very
nearly the same number of characters as current SSQLS definitions.

Quote:

plus needing
some other dependency on my system to build.

Naturally if there's a separate tool, it will be built and installed
along with the library. There may be prerequisites like xsltproc or
Perl, by they're very readily available on all common systems, if not
installed already.

The only inconvenience to the user is when setting up the build system
for their own project. And most people will probably be suitably well
served by cutting-and-pasting from the examples' build system.

Quote:

I'm reminded of Microsoft's special interface language here.

....or Motif's, or Qt's, or... There are a great many other projects
that have run into this same wall, and routed around it the same way.

Quote:

Also, the idea of generating code usually tells me that something is
broken in the design or abstraction somewhere.

We're _creating types_ here, for a statically-typed language. Code must
be generated at or before compile time, somehow. Abstractions don't
enter into it.

Quote:

I'm not totally against code generation: I'm pondering
it myself for my own CPPHP project.

Then you can consider this a prototype pass for your own effort. Steal
the result when we get it right.

Quote:

The syntax makes me shudder, but it's the best in the field so far,
it seems. :-)

Nobody likes XML for XML's sake. We like it because of all the tools
that have sprung up around it.

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

static globals in SSQL macro expansion -> multiple definition

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

static globals in SSQL macro expansion -> multiple definition - 07-06-2005 , 03:15 AM

Re: static globals in SSQL macro expansion -> multiple definition - 07-06-2005 , 10:23 AM

Re: static globals in SSQL macro expansion -> multiple definition - 07-06-2005 , 12:51 PM

Re: static globals in SSQL macro expansion -> multiple definition - 07-06-2005 , 12:52 PM

Re: static globals in SSQL macro expansion -> multiple definition - 07-06-2005 , 03:51 PM

Re: static globals in SSQL macro expansion -> multiple definition - 07-06-2005 , 09:24 PM

Re: static globals in SSQL macro expansion -> multiple definition - 07-08-2005 , 01:25 AM