You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stdcxx.apache.org by "Travis Vitek (JIRA)" <ji...@apache.org> on 2007/11/20 18:37:43 UTC
[jira] Issue Comment Edited: (STDCXX-612) many iterator types do
not work with types that implement unary operator&
[ https://issues.apache.org/jira/browse/STDCXX-612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12543962 ]
vitek edited comment on STDCXX-612 at 11/20/07 9:36 AM:
---------------------------------------------------------------
The change to tr1/_smartptr.h removes an assertion that _C_ptr is valid. I don't know if the assert was necessary in the first place, but it probably shouldn't be removed without reason.
Also, I think the _RWSTD_ADDRESS_OF() would be easy to accidentally misuse.
_RWSTD_ADDRESS_OF (int, i); // cast address of i to an int
Wouldn't it make more sense for __rw_address_of to do the heavy lifting, and to write the macro to call through? That would require the free function be moved to rw/_defs.h which might not be ideal. It has the advantage that would remove requirement for the first macro parameter, which would cleanup the code just a little bit. It might also be a good idea to add an overload of __rw_address_of for const references.
was (Author: vitek):
The following change to tr1/_smartptr.h removes an assertion that _C_ptr is valid. I don't know if the assert was necessary in the first place, but it probably shouldn't be removed without reason.
element_type* operator->() const {
- return &**this;
+ return _C_ptr;
}
Also, I think the _RWSTD_ADDRESS_OF() would be easy to accidentally misuse.
_RWSTD_ADDRESS_OF (int, i); // cast address of i to an int
Wouldn't it make more sense for __rw_address_of to do the heavy lifting, and to write the macro to call through? That would remove requirement for the first parameter, which would cleanup the code just a little bit. It might also be a good idea to add an overload of __rw_address_of for const references.
> many iterator types do not work with types that implement unary operator&
> -------------------------------------------------------------------------
>
> Key: STDCXX-612
> URL: https://issues.apache.org/jira/browse/STDCXX-612
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 24. Iterators
> Affects Versions: 4.2.0
> Reporter: Travis Vitek
> Assignee: Farid Zaripov
> Fix For: 4.2.1
>
> Attachments: operator_arrow.patch
>
>
> Code that uses the macro _RWSTD_OPERATOR_ARROW will be affected by this issue. Code that has '&*' is also very likely to be affected.
> #include <deque>
> #include <iterator>
> #include <list>
> #include <set>
> #include <vector>
> struct S
> {
> void operator& () const {};
> };
> int main ()
> {
> // this is just a compile test, it is not intended to run
> std::reverse_iterator<S*>().operator->();
> std::set<S>::iterator().operator->();
> std::deque<S>::iterator().operator->();
> std::list<S>::iterator().operator->();
> return 0;
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.