I have been recently discussing an idea with Warren concerning support
in the insert method for collections for creating the associated SQL
generated by the call according to a policy object passed in with the
call. This will allow MySQL++ calls to insert collections of object to
be mindful of MySQL's "maximum packet size" for queries transparently
such that the user does not need to worry about the size of the
collection to be inserted. The policy object could have other uses as
well, and will be open-ended in its design to allow to for new ideas.
Upon retrieving the code, and going through some iterations with the IT
guys to get our ancient OS up to date in order to support the MySQL++
build environment, I discovered that after running the "bootstrap"
script and doing a plain-vanilla build I was getting a compilation error
concerning usleep( ) in one of the example programs.
Similarly, in the past when building the multithread-aware version of
MySQL++, which is used in our project, I found that while the library
built just fine, one of the examples did not build because of the sleep(
) function. The multithread-aware version of MySQL++ can be built with
"./configure --enable-thread-check" which allows MySQL++ to run properly
in a multi-threaded application.
However, all these problems can be eliminated using the POSIX standard
nanosleep( ) function, which I'd never heard of until I did some Googlin'.
My question to my learned and esteemed listmates is: Are there any
reasons you know why this function would be unsuitable for use in the
MySQL++ example apps?