Out of the initial problem, i whish tell that i hope you will keep
mysql++ independent from the boost library and from any other external
libraries.
The boost library is not a part of our project and for some reasons, we
don't want include it. We choosed mysql++ for "its nondependence". If
you have to include this iterator patch, please try to keep out the
boost library.
To do short, one of our developer breaked our include rule recently(
"don't use an external library that need a 'thousand' other external
libraries" ) and we gone on a wall ! The problem was that the external
library was using an another external library defining a class with the
same name as a visual studio internal class we use. And we get a build
error conflict and some runtime errors after a "fix"!
This case is hard to diagnostic : who is making the conflict and why ?
Now, if you want include the boost library i will accept it :) ( i don't
want turn to the mysql C api Oo ).
Tank.
Paul a écrit :
> Hi list, Alan, Warren,
>
> Definately not std::auto_ptr<>
>
> Try reading here for a start:
> http://www.boost.org/libs/utility/operators.htm#deref
> and
> http://www.boost.org/libs/iterator/doc/iterator_facade.html#id2
>
> I understand Warren's position on including Boost libraries, but
> usually you can just extract out the key technique from the boost
> header files and use it for your own purposes. The advantage of
> depending on Boost is that you wouldn't have to worry about making
> that technique work with various compilers. The disadvantage of
> depending on Boost is that its an extra dependency thats not terribly
> useful in this case.
>
> Also check out TR1, it is bits of Boost that have been approved to be
> included in the C++ standard libraries in the near future.
>
> the operator->() is a tricky problem, but there are solutions.
>
> Personally I'd just (*iterator).whatever() in the meantime.
>
> Paul
>
>
> Warren Young wrote:
>
>> alan.alvarez@stripped wrote:
>>
>>> Would saving a std::auto_ptr in the iterator object save this problem?
>>
>>
>>
>> I don't see how this solves the problem. Even if it did work, it
>> would be arm-twisting the very purpose of auto_ptr, so I think you're
>> looking in the wrong place. auto_ptr is not a universal smart
>> pointer; there's a very limited scope within which it makes sense.
>>
>> I suggest you study the 1.7.40 version with the erroneous arrow
>> operator. Once you can see what the error is, you will be in a
>> better position to propose fixes. I guess you should also look at
>> the Boost stuff Paul refered to.
>>
>> Beware: if the fix introduces a mandatory dependency on Boost, that
>> alone might be grounds for rejection. At the moment, all I've talked
>> myself into are optional features that may depend on Boost.
>> Mandatory dependencies make configuration much more complex,
>> particularly given some of the weirdnesses of Boost itself.
>>
>> P.S. You keep replying to me personally. Again: keep this traffic on
>> the mailing list.
>>
>
>
