[jira] Created: (STDCXX-689) [LWG #280] std::reverse_iterator missing template assignment operator
[LWG #280] std::reverse_iterator missing template assignment operator - Key: STDCXX-689 URL: https://issues.apache.org/jira/browse/STDCXX-689 Project: C++ Standard Library Issue Type: Bug Components: 24. Iterators Affects Versions: 4.2.0, 4.1.4, 4.1.3, 4.1.2 Reporter: Martin Sebor Priority: Trivial Fix For: 4.2.1 LWG Issue 280 added a template assignment operator to reverse_iterator: http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#280 It doesn't look like we ever added the function. I'm having trouble coming up with a test case that would reveal its absence so this is just a placeholder to remind us to look into this in more detail to make sure the function really is needed (if not, there's no need to complicate the interface of the template). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: GNU "Autotools" Branch?
Eric Lemings wrote: I haven't tested it on any platform other than Mac OS X; not all config tests have been translated yet into M4 macros (especially tests related to linking); and those that have been written need a thorough review as well as some polishing. So it's safe to say it's still very much in development. Once I get a successful 'distcheck', I'll create this branch in the stdcxx/branches/autotools directory. The baseline for this branch will only contain a scant few config macros initially along with plenty of guidance on writing the rest. :) Sounds good to me. Unless someone objects in the next, say, 48 hours go ahead and create the branch at your leisure. I assume you'll be branching off of trunk (as opposed to an existing branch). Martin Brad. -Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor Sent: Saturday, January 05, 2008 4:01 PM To: stdcxx-dev@incubator.apache.org Subject: Re: GNU "Autotools" Branch? Eric Lemings wrote: I have some code that I'd like to contribute to the Apache STDCXX repository. It adds support for the GNU "Autotools" suite of tools (i.e. Autoconf, Automake, and Libtool). Would a branch in the Subversion stdcxx/branches directory be the appropriate place to check in this code? If you're still developing the code we can create a branches/autotools branch for this work. But if it's already finished and tested on all platforms we might want to think about rolling it into 4.3 instead (once it has been created). Martin Thanks.
[jira] Closed: (STDCXX-443) [IBM XLC++] should avoid using -qinline or -Q in C++ code
[ https://issues.apache.org/jira/browse/STDCXX-443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Travis Vitek closed STDCXX-443. --- Resolution: Fixed committed to trunk in http://svn.apache.org/viewvc?view=rev&revision=601922 merged to 4.2.x in http://svn.apache.org/viewvc?view=rev&revision=604045 > [IBM XLC++] should avoid using -qinline or -Q in C++ code > - > > Key: STDCXX-443 > URL: https://issues.apache.org/jira/browse/STDCXX-443 > Project: C++ Standard Library > Issue Type: Improvement > Components: Configuration >Affects Versions: 4.1.3 > Environment: IBM VisualAge C++ 6.0, 7.0, and XLC++ 8.0 >Reporter: Martin Sebor >Assignee: Travis Vitek > Fix For: 4.2.1 > > Attachments: stdcxx-443.patch > > > Quoting from the XLC++ 8.0 Compiler Reference, page 249 (-Q option): > To maximize inlining: > * for C programs, specify optimization (-O) and also specify the appropriate > -Q options for the C language. > * for C++ programs, specify optimization (-O) but do not specify the -Q > option. > We should review whether our use of -Q in optimized builds is called for. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: GNU "Autotools" Branch?
I haven't tested it on any platform other than Mac OS X; not all config tests have been translated yet into M4 macros (especially tests related to linking); and those that have been written need a thorough review as well as some polishing. So it's safe to say it's still very much in development. Once I get a successful 'distcheck', I'll create this branch in the stdcxx/branches/autotools directory. The baseline for this branch will only contain a scant few config macros initially along with plenty of guidance on writing the rest. :) Brad. > -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor > Sent: Saturday, January 05, 2008 4:01 PM > To: stdcxx-dev@incubator.apache.org > Subject: Re: GNU "Autotools" Branch? > > Eric Lemings wrote: > > I have some code that I'd like to contribute to the Apache STDCXX > > repository. It adds support for the GNU "Autotools" suite of tools > > (i.e. > > Autoconf, Automake, and Libtool). > > > > Would a branch in the Subversion stdcxx/branches directory be the > > appropriate place to check in this code? > > If you're still developing the code we can create a branches/autotools > branch for this work. But if it's already finished and tested on all > platforms we might want to think about rolling it into 4.3 instead > (once it has been created). > > Martin > > > > > Thanks. > > > >
stdcxx-dev@incubator.apache.org
[
https://issues.apache.org/jira/browse/STDCXX-612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12556772#action_12556772
]
Martin Sebor commented on STDCXX-612:
-
I also have no problem deferring this issue for 4.3. It's very much a corner
case. Let's see what Farid thinks about it.
As for compatibility, the [still informal] binary compatibility policy is
silent on this point but I don't think we need to be concerned with
hypothetical compilers when it comes to maintaining compatibility. IMO, we
should only be constrained by compilers we do test and support.
> 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
> #include
> #include
> #include
> #include
> struct S
> {
>void operator& () const {};
> };
> int main ()
> {
>// this is just a compile test, it is not intended to run
>std::reverse_iterator().operator->();
>std::set::iterator().operator->();
>std::deque::iterator().operator->();
>std::list::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.
stdcxx-dev@incubator.apache.org
[
https://issues.apache.org/jira/browse/STDCXX-612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12556768#action_12556768
]
Travis Vitek commented on STDCXX-612:
-
I'm a little on the fence as to whether item 1 above really is forward
compatible or not. There may be some compiler that we aren't testing that
requires it, and we would be breaking compatibility there.
I don't really have a problem with letting this issue sit until 4.3 or later.
I'm also open to never fixing the issue if someone can provide a reasonable
argument for why you would want it to not work. Of course that may require
someone to explain why the standards gurus decided to require this interesting
behavior in some places. That said, if we are intent on doing something with
this issue now, then I think the above is acceptable.
> 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
> #include
> #include
> #include
> #include
> struct S
> {
>void operator& () const {};
> };
> int main ()
> {
>// this is just a compile test, it is not intended to run
>std::reverse_iterator().operator->();
>std::set::iterator().operator->();
>std::deque::iterator().operator->();
>std::list::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.
Test Dependencies
It seems that most of the tests depend on nothing more than the C++ standard library and the RWTest library. Others have some dependencies that are not so obvious. Some require the TOPDIR environment variable defined, some locale tests require the locales database files, etc. Can someone outlines these dependencies in greater detail? Or is this info documented in a file somewhere in the distribution? Thanks, Brad.
[jira] Commented: (STDCXX-605) [IBM XLC++] errors compiling dynatype.cpp
[ https://issues.apache.org/jira/browse/STDCXX-605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12556723#action_12556723 ] Martin Sebor commented on STDCXX-605: - Do you want to try to commit it now that you have commit privs? > [IBM XLC++] errors compiling dynatype.cpp > - > > Key: STDCXX-605 > URL: https://issues.apache.org/jira/browse/STDCXX-605 > Project: C++ Standard Library > Issue Type: Bug > Components: Examples >Affects Versions: 4.2.0 > Environment: XLC++ 6.0 through 9.0/AIX 5.3 >Reporter: Martin Sebor >Assignee: Travis Vitek > Fix For: 4.2.1 > > Attachments: stdcxx-605-out.patch, stdcxx-605-v1.patch, > stdcxx-605-v2.patch, stdcxx-605-v3.patch > > > The dynatype.cpp example program fails to compile with IBM XLC++ 9.0 on AIX > with ethe following errors: > xlCcore_r -c -I$(TOPDIR)/include/ansi-I$(TOPDIR)/include > -I$(BUILDDIR)/include -I$(TOPDIR)/examples/include -O -Q > -qtemplateregistry=dynatype.ti $(TOPDIR)/examples/tutorial/dynatype.cpp > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 203.27: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "int". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 209.30: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "double". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 215.30: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "double". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 222.35: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "const char *". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 228.35: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "const char *". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 238.28: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "char". > gmake: *** [dynatype.o] Error 1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
stdcxx-dev@incubator.apache.org
[
https://issues.apache.org/jira/browse/STDCXX-612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12556722#action_12556722
]
Martin Sebor commented on STDCXX-612:
-
Travis, let us know if this approach sounds reasonable to you or if you see a
problem.
> 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
> #include
> #include
> #include
> #include
> struct S
> {
>void operator& () const {};
> };
> int main ()
> {
>// this is just a compile test, it is not intended to run
>std::reverse_iterator().operator->();
>std::set::iterator().operator->();
>std::deque::iterator().operator->();
>std::list::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.
stdcxx-dev@incubator.apache.org
[
https://issues.apache.org/jira/browse/STDCXX-612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12556720#action_12556720
]
Martin Sebor commented on STDCXX-612:
-
We need to be careful here. We can't change [revers.iter.opref] or any other
function that deliberately relies on the return type of operator&() being
[convertible to] pointer.
As for where things should be defined: _defs.h is for macro definitions only.
There shouldn't be any other definitions (types, templates, or functions). As
an aside, we should be using C++ casts in favor of the C-style ones.
Here's how I'd like to propose we proceed:
1) First, to simplify things, eliminate the _RWSTD_ARROW() macro. It's a
workaround for a compiler limitation that none of our compilers suffers from
anymore (check the generated config headers) and so this is a forward
compatible change.
2) For standard container iterators define operator->() in terms of the pointer
data member as opposed to in terms of operator&() and avoid having to deal with
any conversion issues.
3) Leave reverse_iterator::operator->() unchanged (i.e., return &operator*()).
4) Change istream_iterator::operator->() to simply return &_C_val.
5) Change __rw_debug_iter::operator->() to simply return _C_iter.
6) Discuss how to deal with the uninitialized_xxx() algorithms.
> 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
> #include
> #include
> #include
> #include
> struct S
> {
>void operator& () const {};
> };
> int main ()
> {
>// this is just a compile test, it is not intended to run
>std::reverse_iterator().operator->();
>std::set::iterator().operator->();
>std::deque::iterator().operator->();
>std::list::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.
[jira] Commented: (STDCXX-605) [IBM XLC++] errors compiling dynatype.cpp
[ https://issues.apache.org/jira/browse/STDCXX-605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12556714#action_12556714 ] Travis Vitek commented on STDCXX-605: - Dandy. > [IBM XLC++] errors compiling dynatype.cpp > - > > Key: STDCXX-605 > URL: https://issues.apache.org/jira/browse/STDCXX-605 > Project: C++ Standard Library > Issue Type: Bug > Components: Examples >Affects Versions: 4.2.0 > Environment: XLC++ 6.0 through 9.0/AIX 5.3 >Reporter: Martin Sebor >Assignee: Travis Vitek > Fix For: 4.2.1 > > Attachments: stdcxx-605-out.patch, stdcxx-605-v1.patch, > stdcxx-605-v2.patch, stdcxx-605-v3.patch > > > The dynatype.cpp example program fails to compile with IBM XLC++ 9.0 on AIX > with ethe following errors: > xlCcore_r -c -I$(TOPDIR)/include/ansi-I$(TOPDIR)/include > -I$(BUILDDIR)/include -I$(TOPDIR)/examples/include -O -Q > -qtemplateregistry=dynatype.ti $(TOPDIR)/examples/tutorial/dynatype.cpp > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 203.27: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "int". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 209.30: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "double". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 215.30: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "double". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 222.35: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "const char *". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 228.35: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "const char *". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 238.28: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "char". > gmake: *** [dynatype.o] Error 1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (STDCXX-688) remove include/xxx_spec.h headers
remove include/xxx_spec.h headers - Key: STDCXX-688 URL: https://issues.apache.org/jira/browse/STDCXX-688 Project: C++ Standard Library Issue Type: Improvement Components: 23. Containers Reporter: Martin Sebor Priority: Minor The xxx_spec.h headers below are a vestige of a failed attempt to provide partial specializations of standard containers for pointer types. They have never been used, in all likelihood are broken, and should be removed. $ svn ls http://svn.apache.org/repos/asf/incubator/stdcxx/trunk/include/ | grep _spec\.h deque_spec.h list_spec.h vector_spec.h -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
