Ok, I've seen more updates in the last few months that there have been
in the last two years, and I have two questions..
1: Right now, which release is stable?
2: Do you guys need a hand with anything? Something simple to start off
with, I havnt delved into the mysql++ code before.
>>> Warren Young <mysqlpp@stripped> 11/04/04 10:47 PM >>>
Chris Frey wrote:
> Has this resulted in a cleaner header file layout? I.e. does it
> more solid? :-)
The main advantage, for me, is that I will now know, in advance, where
to look for a particular definition or declaration. Previously, one
could not predict which of the 3 to 5 files per module would contain
what you were looking for.
The fact that I've broken several unnecessary circular dependencies also
feels good. These dependencies were the major reason this release was
not a one-hour hacking session. The dependencies made the previous
organization brittle in the face of change.
And finally, the previous organization was just plain ugly. Look at all
the '3' files whose only content was to #include the '2' file, and the
'2' which only #included the '1'. To me, this indicates a discipline
Several times while doing this update, I found myself wondering about
the mental capacity of those who designed the file layout. Perhaps they
were just raving loonies, in which case good riddance to their product.
Perhaps they were absolutely brilliant, able to keep all the state
represented in the file layout in their minds at once; in this case,
good riddance again, because it shouldn't take brilliance to hack on a
library whose concept is this straightforward. And it's also possible
that they were roughly as smart as me, and they also found themselves
lost when wading into the sqlplusint jungle, but simply lacked the
intestinal fortitude to clean the mess up. No matter how I slice it, I
can't help but see the previous file layout as broken, so I'm glad I
> I remember reading the README file that explained the meaning of the
> header files (which btw is still there)
Ah yes, I forgot about that. Nuked.
> and thinking that it was a
> rather innovative way to layout the headers.
There are a lot of innovative software engineering practices out there
that are more a pain than a benefit when followed slavishly. A few
times, I was tempted to leave some of the '2' headers alone, but in all
cases I was able to find a way to collapse even those into the main
header file or the .cc file.
> Maybe you
> can point me at particular header that illustrates things, and I can
> Read The Mighty Fine Source Code myself. :-)
Tell you what: if you want to get an appreciation for what I did, try
replicating just a fraction of it: move the code from fields2.hh into
fields1.hh, delete the '2' file and change all the references to the '2'
file to the '1' file. You'll find it doesn't compile. Now, try to find
out why, and see what other changes you have to make in order to make it
If you want a real challenge, try the same thing with the row?.hh
If you go through this exercise, I think you'll agree with my charge of
"brittle in the face of change".