It's taken me a while, but I've got round to getting the latest
version out of svn and getting it to compile on Windows. I had a couple of
minor problems which I'll supply patches for, but there's an issue with
exporting classes that I wanted your thoughts on.

If you turn the warning level up to 3, you get a bunch of warnings
similar to:

....\connection.h(570) : warning C4251:
'mysqlpp::Connection:ending_options_' : class 'std::deque<_Ty>' needs to
have dll-interface to be used by clients of class 'mysqlpp::Connection'
with
[
_Ty=mysqlpp::Connection::OptionInfo
]

See http://msdn2.microsoft.com/en-us/library/esew7y1w.aspx for
warning details. This basically is warning that the stl class
instantiations in the mysqlpp exported classes haven't been exported from
the dll. I'm not sure what the effects of not exporting the stl classes
are, but my best guess is that private members are ok, but classes derived
from stl classes or that have public / protected members should be exported.

There are a couple of solutions, disable the warning or export the
classes as described here
http://support.microsoft.com/default...b;en-us;168958 . There's
only one problem with that solution, apparently it's not possible to export
some of the classes as they rely on other non-exported classes. In fact the
only container class you can export is vector<xxx>.

I also found this page, where someone had the same problem and
discussed the solutions they'd found
http://www.unknownroad.com/rtfm/Visu...ningC4251.html . Anyone
know the correct thing to do?


Cheers,

Matt.


-----Original Message-----
From: Warren Young [mailto:mysqlpp (AT) etr-usa (DOT) com]
Sent: 11 October 2006 23:47
To: MySQL++ Mailing List
Subject: Re: mysql++ memory usage

It sounds like you're in an excellent position to supply a patch.
Please make it against svn (as opposed to 2.1.1), so it's easy for me to
evaluate, merge and test.




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

Matt Dargavel wrote:
Don't be guilty about that. Any help is appreciated, and dropped balls
are stoically ignored.

It's not clear to me whether this bunch of warnings is all about
pending_options_, or if all members of that class (or others!) are also
being complained about. More data would help me to understand the
common source of the problem.

Unfortunately, there are four different cases where this warning appears.

The only thing common among them is that there seems to be some problem
with static data. Since pending_options_ isn't static itself and is
never accessed through inline methods, it would seem that the only thing
it can be complaining about is that deque has a static member. It seems
to me that it would be madness for that to be anything other than a
write-once, read-many variable, kept for optimization; a pointer to a
singleton, perhaps. Unless VC++'s STL has locks within it, you'd
completely wreck thread safety if it were otherwise, and that's one of
the (few) strengths of VC++. (Be nice, Warren.) (And stop talking to
yourself.)

If I've guessed right, it should be safe to ignore the warning. It'd be
nice to know for sure before doing that, however.

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

I think the warnings are all for different instantiations of the STL
classes. Either where there is an STL member variable, or where a class is
derived from an STL class. Although as there's 83 warnings in total I
haven't checked them all. :-)

My understanding of the warning is that code within an application that uses
the library can't access the type referenced in the warning reliably. This
is because it's not exported, but is contained within an exported class. If
the application uses the non-exported class there may well be linker errors
due to different compilers / name mangling and the like. The reason the
errors only pop up for STL member variables is that the other classes have
all been marked as exported. In summary, I think you have to export
std::deque<OptionInfo> in the same way you do Query.

What I don't understand is why it warns in the case where it's a private
member variable that's not accessed from inline code. Although, as you've
probably guessed, I'm no expert in dlls and exporting!


Ah, you must be a VB fan? ;-)




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