On Thu, May 12, 2005 at 03:54:14PM -0600, Warren Young wrote:
> I was able to rewrite this to be a lot clearer, I think. Some of it was
> just straight rewriting, but I also moved a lot of it to more
> appropraite places, so only the salient bits remain in type_info.cpp.
> The "opinion" block is now a Wishlist item, and the explanation of
> type()'s inner workings became the seed of a Doxygen comment in type_info.h.
> >Also in type_info.cpp, I changed part of the type lookup table, to match
> I didn't study it deeply enough to know whether this is the right thing,
> so I've decided to trust that you know what you're doing here. :)
If you can hold off the next release for a couple days, I can be even
more definite I'm right, and can post a little test to prove it.
I only changed the initializers for the "_default" member. This variable
is only used in the lookup class, in its constructor (grep proves this).
The for loop cycles through the entire list, and adds any item marked
true in _default to the lookup std::map. Since there are some entries
with identical typeid() info, and set to true, the last one will end up
in the lookup table. That's why I left the last item set to true, and
disabled the rest.
> >+ o Document the header layout, and which headers can be included
> >+ and which can't. Do this to optimize compile times, and allow
> >+ users to do the same.
> Have you read Lakos's "Large Scale C++" book (probably got the title
> wrong)? Are you proposing optimization of that sort?
Afraid I haven't read it. The optimization I'm proposing is just based
on my experience. Including everything is often not necessary.
If the user only needs connection and query objects, some headers may
not be needed.
> - A smarter way to go is to wrap each #include with the idempotency
> guard for that header, so it is never included from mysql++.h if a
> previous header already included it. You can push this concept further
> by doing the same in the other headers, but just doing it at the top
> level will probably save a significant chunk of time, and there's no
> sense cluttering the code for small gains. Unless I'm very wrong, the
> case we want to optimize for is end users building their own programs,
> not build time for MySQL++. Putting mysql++.h in order should recover
> most of the wasted time for the end-user case.
This is more like what I had in mind, but it seems you have already
tried this and nothing changed. I don't fully know the whole inter-
dependencyes of the headers, so maybe using Query does pull everything
in anyway, but I figured it might be worth a look.
The other change would be to replace any unnecessary #includes with
forward declarations. You probably did this when you did the
Giant Header Reorg, so maybe none of this is that useful. :-)
I just notice the examples take a while to compile on my system (PII) and
thought something could be done. If I do manage an increase, I'll just
post the patch when I have something, and stop talking about it for now.
You don't have to add it to the wishlist, since I'm probably the only
guy with a slow enough system that cares, and will remember myself. :-)