Is there a specific reason why subscript_iterator doesn't have a -> operator? Would it be possible or how hard would it be to implement one?

I'm not very familiar with the inside structure of mysql++, but if it could be done I'd definetly implement it myself if I had to.


Alan Alvarez.

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

alan.alvarez (AT) us (DOT) army.mil wrote:
From the ChangeLog, v2.0.0:

o Removed arrow operator (->) for iterator returned by Fields,
Result and Row containers. It was inherently buggy, because
a correct arrow operator must return the address of an
object, but the underlying element access functions in these
classes (e.g. at()) return objects by value, of necessity.
Therefore, this operator could only return the address of
a temporary, which cannot be safely dereferenced.

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

Check boost.org, there are techniques to work around this problem by
returning a small proxy-class or something like that.

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

Paul wrote:
I have a better idea. How about you prepare a patch implementing this,
and we'll evaluate the concept in situ.

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

I have an even better idea: alan.alvarez might like to do this since he
was the one who wanted the feature, I was merely correcting an error
that read:

<quote>
Therefore, this operator could only return the address of
a temporary, which cannot be safely dereferenced.
</quote>

I was just pointing out that there are other solutions to this problem,
I wasn't asking Warren to do anything.

thanks,
Paul


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

----3ac12531ae67278
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

I'm sorry. I sent this to you directly instead of the list.
Re-sent just to make sure everybody else gets it.

Respectfully,
Alan Alvarez.
----3ac12531ae67278
Content-Type: message/rfc822
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Received: from [10.240.32.46] (Forwarded-For: [214.13.150.1]) by
akomail1.int.dr1.us.army.mil (mshttpd); Sat, 07 Jan 2006 18:49:42
+0300
From: <alan.alvarez (AT) us (DOT) army.mil>
To: Warren Young <mysqlpp (AT) etr-usa (DOT) com>
Message-ID: <492c690492ae93.492ae93492c690 (AT) us (DOT) army.mil>
Date: Sat, 07 Jan 2006 18:49:42 +0300
X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.02 (built Oct 21 2004)
MIME-Version: 1.0
Content-Language: en
Subject: Re: subscript_iterator -> operator.
X-Accept-Language: en
Priority: normal
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Would saving a std::auto_ptr in the iterator object save this problem?
When the iterator is destroyed though, the object will no longer exist of course.
But it gives the user more time to use the data.

Let me know what you think.

Respectfully,
Alan Alvarez.

----- Original Message -----
From: Warren Young <mysqlpp (AT) etr-usa (DOT) com>
Date: Thursday, January 5, 2006 6:01 pm
Subject: Re: subscript_iterator -> operator.


----3ac12531ae67278
Content-Type: text/plain; charset=us-ascii


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

alan.alvarez (AT) us (DOT) army.mil wrote:
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.

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

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/d...acade.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:

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

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 :

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