Re: 23.list.iterators test with environment

2006-07-06 Thread Martin Sebor
Farid Zaripov wrote: tests/include/23.list.h tests/src/23.list.cpp tests/containers/23.list.iterators.cpp This test (based on 21.string.iterators test) exercises the following list class methods: begin, end, rbegin, rend, front, back, get_allocator. Okay, this looks like a good start! One g

Re: string methods thread safety

2006-07-06 Thread Martin Sebor
Martin Sebor wrote: Anton Pevtsov wrote: [...] I found the tricky place in the rwthread.cpp, line 397: void* const next_arg = thr_arg ? thr_arg + i : (void*)(thr_id + i); I suspect here should be void* const next_arg = thr_arg ? *(thr_arg + i) : (void*)(thr_id + i); The fix included.

Re: string methods thread safety

2006-07-06 Thread Martin Sebor
Martin Sebor wrote: [...] I have a semi-exhaustive thread safety test for sting stashed away somewhere. Let me dig it up and post it to give you an idea. The test is attached. It's supposed to be portable across most today's C++ implementations (which isn't our goal). The thread safety tests I

[jira] Assigned: (STDCXX-253) Top level 'make util' command fails

2006-07-06 Thread Martin Sebor (JIRA)
[ http://issues.apache.org/jira/browse/STDCXX-253?page=all ] Martin Sebor reassigned STDCXX-253: --- Assign To: Martin Sebor > Top level 'make util' command fails > --- > > Key: STDCXX-253 > URL: http://is

Re: svn commit: r414916 - /incubator/stdcxx/trunk/tests/include/alg_test.h

2006-07-06 Thread Martin Sebor
Anton Pevtsov wrote: Martin, I've noted that this commitment brokes several algorithms test (on MSVC). They used make_iter in the following way: const Iterator first = make_iter (xsrc, xsrc, xsrc + nsrc, dummy_it); And this results in the error: error C2666: 'make_iter' : 2 overloads have simi

Re: svn commit: r418319 - /incubator/stdcxx/trunk/tests/strings/21.string.io.cpp

2006-07-06 Thread Martin Sebor
Anton Pevtsov wrote: Martin Sebor wrote: Because the virtual function gets called for each character? Yes. Moreover, the one call of the operator in the test may result in calls to several virtual functions (one by one). Hmm, I guess since we're throwing an exception on each call to the vi

Steps twords graduations

2006-07-06 Thread William A. Rowe, Jr.
FYI I'm very satisfied with the overall progress of stdcxx, but see two obstacles to graduation; * the bug tracking system is being well utilized to discuss patches, but the dev list is still a bit quiet on the design-decision front. It's important that decisions are open and not made in

[jira] Created: (STDCXX-253) Top level 'make util' command fails

2006-07-06 Thread Andrew Black (JIRA)
Top level 'make util' command fails --- Key: STDCXX-253 URL: http://issues.apache.org/jira/browse/STDCXX-253 Project: C++ Standard Library Type: Bug Components: Build Environment: All Reporter: Andrew Black >From the root o

Re: using stdcxx in tuscany/C++

2006-07-06 Thread William A. Rowe, Jr.
Great news! Thanks for keeping us in the loop. Martin Sebor wrote: Hi, We have heard that the Tuscany developers have been exploring the option of using Apache stdcxx as the common implementation of the C++ Standard Library for Tuscany/C++. We are wondering whether this is in fact the case and

using stdcxx in tuscany/C++

2006-07-06 Thread Martin Sebor
Hi, We have heard that the Tuscany developers have been exploring the option of using Apache stdcxx as the common implementation of the C++ Standard Library for Tuscany/C++. We are wondering whether this is in fact the case and, if so, what the stdcxx team can do in order to make it as smooth as

[jira] Commented: (STDCXX-157) [XLC++ 7.0, 8.0] explicit instantiation fails to emit some symbols

2006-07-06 Thread Martin Sebor (JIRA)
[ http://issues.apache.org/jira/browse/STDCXX-157?page=comments#action_12419595 ] Martin Sebor commented on STDCXX-157: - Original Message Subject: Fw: PMR 02236,K78,000 (Compiler fails to emit symbol for a member function) Date: Thu, 6

Re: stdcxx building problem on the gcc 3.2.2/Linux RedHat9

2006-07-06 Thread Martin Sebor
Farid Zaripov wrote: But I don't understand why a change in the order of dependencies makes a difference in the order of libraries on the command line. Can you explain it to me? I don't know. I think it's works because used implicit rule which passes the target dependenses to the command

RE: stdcxx building problem on the gcc 3.2.2/Linux RedHat9

2006-07-06 Thread Farid Zaripov
> But I don't understand why a change in the order of dependencies > makes a difference in the order of libraries on the command line. > Can you explain it to me? I don't know. I think it's works because used implicit rule which passes the target dependenses to the command line In command

RE: svn commit: r418319 - /incubator/stdcxx/trunk/tests/strings/21.string.io.cpp

2006-07-06 Thread Anton Pevtsov
Martin Sebor wrote: > Because the virtual function gets called for each character? Yes. Moreover, the one call of the operator in the test may result in calls to several virtual functions (one by one). Here is the question: are there any restrictions on the order and number of the streambuf virtua

RE: svn commit: r414916 - /incubator/stdcxx/trunk/tests/include/alg_test.h

2006-07-06 Thread Anton Pevtsov
Martin, I've noted that this commitment brokes several algorithms test (on MSVC). They used make_iter in the following way: const Iterator first = make_iter (xsrc, xsrc, xsrc + nsrc, dummy_it); And this results in the error: error C2666: 'make_iter' : 2 overloads have similar conversions