On Fri, May 25, 2012 at 11:28 AM, Mateusz Loskot <[email protected]> wrote:
> On 25 May 2012 09:28, Neil Morgenstern <[email protected]>
> wrote:
> > Incidentally SOCI is using a very poor implementation of auto_ptr.
>
> It is used in single place, locally in the rowset.
> It is not part of SOCI public interface.
> This particular usage, does not really suffer due to auto_ptr issues.
> If we decide to bump min. required C++ implementation,
> we will replace it with unique_ptr.
>
> > If auto_ptr is bad enough, SOCI doesn't even get that right.
>
> Would you care to elaborate it?
> Are you referring to the pimpl'ed rowset with auto_ptr?
>
It's actually difficult to remember now fully because I don't have the
source here. I had it at work where I am no longer working and made a fix
for it.
When we were binding parameters, we collected first all the parameters that
were being used then did all the binds at the end. Thus in statement I
think we called the function exchange() manually. I seem to recall it is
when you create the "use" that underneath it uses some kind of auto_ptr but
it doesn't have the copy and assign semantics implemented and is therefore
technically reliant on RVO. Of course with move semantics you could use
those instead.
You have to remember too that we were using it for something that you claim
is not supported - stored procedures with ODBC backend. But we got it
working.
We had to write a brand new library that would work with the old code with
minimal change. We also had to use named parameters in the syntax of
execute procname @param1=?, @param2=?
etc.
where the named parameters are not neceesarily the order they appear in the
procedure. (This is permitted if done this way).
We also had to support output parameters and we had to bind those manually
as we couldn't find a way to do that with SOCI.
> > SOCI doesn't use shared_ptr because it doesn't force you to be using it.
> > There are some features of boost you can optionally use. shared_ptr is
> > standard in C++11 but we are not C++11 compliant yet.
>
> Generally, this has been discussed countless of times, on soci-devel
> and here too, I guess.
>
> If we, the community of users, contributors and developers of SOCI,
> decide to tighten up relation with Boost, use of boost::shared_ptr will be
> possible. Alternatively, if min. required C++ implementation is C++03 +
> TR1,
> we will get std::tr1::shared_ptr.
> (Although, I wouldn't mind to jump straight to C++11. :))
>
If you were going to use shared_ptr in the code, one option is to use a
template alias and then within the configuration you would say what
namespace has shared_ptr and which header. Everywhere else it is used it
would be using the template alias. This is the primary advantage that
template aliases in C++ provides.
>
> Anyhow, as a reminder, SOCI has lost the project manager
> (For those who missed the announcement, regrettably Maciej has left
> the project [1], [2])
>
> So, it is not far from truth to consider the project is now
> community-managed.
> IMHO, anyone here who wants to step up and take ignite any motion in the
> SOCI
> development, be encouraged to do so and let's discuss it here.
>
> [1]
> http://sourceforge.net/mailarchive/[email protected]&forum_name=soci-users
> [2] http://mateusz.loskot.net/2011/11/07/new-soci-project-leader-needed/
>
>
My problem is where I was working previously it was hard enough to get
permission to use SOCI but we managed to get it as long as we maintained it
ourselves. I couldn't just take my changes home with me or submit them here.
I could download SOCI but I would need to find a database to test it on
using ODBC as the backend. And at present I am starting a new job on
Tuesday and therefore don't really have time, especially as I am unlikely
to be using it.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Soci-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/soci-users
