List:MySQL++« Previous MessageNext Message »
From:Denis ERCHOFF Date:January 11 2006 8:43am
Subject:Re: subscript_iterator -> operator.
View as plain text  
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.
>>
>
>
Thread
subscript_iterator -> operator.alan.alvarez5 Jan
  • Re: subscript_iterator -> operator.Warren Young5 Jan
    • Re: subscript_iterator -> operator.Paul5 Jan
      • Re: subscript_iterator -> operator.Warren Young6 Jan
        • Re: subscript_iterator -> operator.Paul6 Jan
Re: subscript_iterator -> operator.Warren Young10 Jan
  • Re: subscript_iterator -> operator.Paul11 Jan
    • Re: subscript_iterator -> operator.Denis ERCHOFF11 Jan