Re: test for lib.alg.random_shuffle
Anton Pevtsov wrote: I'm porting the test for the lib.alg.random_shuffle algorithm and I have a question about the current test implementation. There is the special test case for the built-in random number generator which does the following: some test array is defined and initialized with numbers, when the random_shuffle algorithm is called for this array, and the result is compared with another predefined array (which was initialized with the same numbers and "shuffled" manually). The results of the random_shuffle of the given array depends on the implementation of the random number generator used by random_shuffle, Correct. and this results in that the test case may be passed for the 1025-th invocation of the random_shuffle algorithm only. Not sure what you mean here. The question is: is it necessary to keep this test case in the ported test version? I believe the point of comparing the result of the algorithm against the hardcoded values is to verify that the algorithm produces the same results across all platforms and architectures. The standard doesn't require this degree of portability but our implementation provides it anyway -- to guarantee consistent behavior. I'm not seeing any runtime problems with the test and I'm not sure I understand where you think the problem is. Martin
Re: 23.containers.deque.modifiers.cpp
Take two with corrections to add z modifier to size_t arguments. Liviu Nicoara wrote: > I have attached a second version of the test. Please let me know if this > addresses the points you raised. > > Thanks, > Liviu > > Liviu Nicoara wrote: > >>Martin Sebor wrote: >> >> >>>Liviu Nicoara wrote: >>> >>> >>> I have attached my tentative porting of lib.deque.modifiers test to the new driver. Martin, I would appreciate suggestions for improving the sections which use ToString class (one of those uses split formatting). >>> >>> >>>I don't see the class defined in the test. Did you by any chance >>>move/copy it into your version alg_test.h? >> >> >>Yes, I did. My bad, I just wanted to get your feed-back on the >>formatting bits and I didn't think that was important. I will stick a >>ToString in each of the tests using it. >> >> >> >>>I think the bits that use the ToString class are fine. As soon as >>>I'm done with the extension to rw_asnprintf() to format arrays of >>>class X (we need to rename it!) it should be straightforward to >>>simply remove the class and pass the arrays directly to rw_assert(). >> >> >>Super. >> >> >> >>>Btw., the old tests were designed to avoid invoking the RW_ASSERT >>>macro except on failure (i.e., there's usually an if (failed) { } >>>block around it). >> >> >>I got that. I will eliminate the conditionals from now on. >> >>Thanks, >>Liviu >> > > > /*** * * 23.containers.deque.modifiers.cpp - test exercising [lib.deque.modifiers] * * $Id$ * *** * * Copyright (c) 1994-2005 Quovadx, Inc., acting through its Rogue Wave * Software division. Licensed under the Apache License, Version 2.0 (the * "License"); you may not use this file except in compliance with the * License.Youmay obtain a copy ofthe Licenseat * http://www.apache.org/licenses/LICENSE-2.0.Unless requiredby * applicable law or agreed to in writing, software distributed under * the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR * CONDITIONS OF ANY KIND, either express or implied. See the License * for the specific language governing permissions and limitations under * the License. * **/ #ifdef _MSC_VER // silence warning C4244: 'argument' : conversion from 'T' to // 'const std::allocator<_TypeT>::value_type', possible loss of data // issued for deque::assign(InputIterator a, InputIterator b) and // deque::insert(iterator, InputIterator a, InputIterator b) due // the implicit conversion of a to size_type and b to value_type // required by DR 438: // http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#438 # pragma warning (disable: 4244) #endif #include // for sprintf() #include// for free() #include// for strlen() #include #ifndef _RWSTD_NO_REPLACEABLE_NEW_DELETE // disabled for MSVC since it can't reliably replace the operators # define DEFINE_REPLACEMENT_NEW_AND_DELETE #endif // _RWSTD_NO_REPLACEABLE_NEW_DELETE #include #include #include #include /**/ // for convenience typedef unsigned char UChar; // Formatting class template struct ToString { public: ToString (const T* first, const T* last, int pos, bool use_id = false) : buffer_ (0) { std::size_t buflen = 0; if (first > last) { rw_asnprintf (&buffer_, &buflen, "%s", "bad range"); return; } for (const T* ptr = first; ptr != last; ++ptr) { char* tmp = buffer_; // Shoddy formatting, relying on buffer_ not being modified // until it has been processed (first %s in formatting string) rw_asnprintf (&tmp, &buflen, "%s%{?}>%{;}%{?}%d:%{;}%{lc}%{?}<%{;}", buffer_ ? buffer_ : "\0", ptr - first == pos,// '>' use_id, ptr->id_, // ":" ptr->val_, // ptr - first == pos); // '<' buffer_ = tmp; } } ~ToString () { if (buffer_) std::free (buffer_); } operator const char* () const { return buffer_; } private: char* buffer_; }; /**/ typedef std::deque > Deque; std::size_t new_capacity; namespace __rw { _RWSTD_SPECIALIZED_FUNCTION inline Deque::size_type __rw_new_capacity(Deque::size_type n, const Deque*) { if (n) { // non-zero size argument indicates a request for an increase // in the capacity of a deque object's dynamically sizable // vector of nod
Re: 23.containers.deque.modifiers.cpp
I have attached a second version of the test. Please let me know if this addresses the points you raised. Thanks, Liviu Liviu Nicoara wrote: > Martin Sebor wrote: > >>Liviu Nicoara wrote: >> >> >>>I have attached my tentative porting of lib.deque.modifiers test to the >>>new driver. Martin, I would appreciate suggestions for improving the >>>sections which use ToString class (one of those uses split formatting). >> >> >>I don't see the class defined in the test. Did you by any chance >>move/copy it into your version alg_test.h? > > > Yes, I did. My bad, I just wanted to get your feed-back on the > formatting bits and I didn't think that was important. I will stick a > ToString in each of the tests using it. > > >>I think the bits that use the ToString class are fine. As soon as >>I'm done with the extension to rw_asnprintf() to format arrays of >>class X (we need to rename it!) it should be straightforward to >>simply remove the class and pass the arrays directly to rw_assert(). > > > Super. > > >>Btw., the old tests were designed to avoid invoking the RW_ASSERT >>macro except on failure (i.e., there's usually an if (failed) { } >>block around it). > > > I got that. I will eliminate the conditionals from now on. > > Thanks, > Liviu > /*** * * 23.containers.deque.modifiers.cpp - test exercising [lib.deque.modifiers] * * $Id$ * *** * * Copyright (c) 1994-2005 Quovadx, Inc., acting through its Rogue Wave * Software division. Licensed under the Apache License, Version 2.0 (the * "License"); you may not use this file except in compliance with the * License.Youmay obtain a copy ofthe Licenseat * http://www.apache.org/licenses/LICENSE-2.0.Unless requiredby * applicable law or agreed to in writing, software distributed under * the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR * CONDITIONS OF ANY KIND, either express or implied. See the License * for the specific language governing permissions and limitations under * the License. * **/ #ifdef _MSC_VER // silence warning C4244: 'argument' : conversion from 'T' to // 'const std::allocator<_TypeT>::value_type', possible loss of data // issued for deque::assign(InputIterator a, InputIterator b) and // deque::insert(iterator, InputIterator a, InputIterator b) due // the implicit conversion of a to size_type and b to value_type // required by DR 438: // http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#438 # pragma warning (disable: 4244) #endif #include // for sprintf() #include// for free() #include// for strlen() #include #ifndef _RWSTD_NO_REPLACEABLE_NEW_DELETE // disabled for MSVC since it can't reliably replace the operators # define DEFINE_REPLACEMENT_NEW_AND_DELETE #endif // _RWSTD_NO_REPLACEABLE_NEW_DELETE #include #include #include #include /**/ // for convenience typedef unsigned char UChar; // Formatting class template struct ToString { public: ToString (const T* first, const T* last, int pos, bool use_id = false) : buffer_ (0) { std::size_t buflen = 0; if (first > last) { rw_asnprintf (&buffer_, &buflen, "%s", "bad range"); return; } for (const T* ptr = first; ptr != last; ++ptr) { char* tmp = buffer_; // Shoddy formatting, relying on buffer_ not being modified // until it has been processed (first %s in formatting string) rw_asnprintf (&tmp, &buflen, "%s%{?}>%{;}%{?}%d:%{;}%{lc}%{?}<%{;}", buffer_ ? buffer_ : "\0", ptr - first == pos,// '>' use_id, ptr->id_, // ":" ptr->val_, // ptr - first == pos); // '<' buffer_ = tmp; } } ~ToString () { if (buffer_) std::free (buffer_); } operator const char* () const { return buffer_; } private: char* buffer_; }; /**/ typedef std::deque > Deque; std::size_t new_capacity; namespace __rw { _RWSTD_SPECIALIZED_FUNCTION inline Deque::size_type __rw_new_capacity(Deque::size_type n, const Deque*) { if (n) { // non-zero size argument indicates a request for an increase // in the capacity of a deque object's dynamically sizable // vector of nodes return n * 2; } // zero size argument is a request for the initial size of a deque // object's dynamically sizable vect
0.new.cpp
I have attached my attempt at converting new.cpp "self" test to the new driver. Liviu /*** * * 0.new.cpp - test exercising replacement operator new and delete * * $Id$ * *** * * Copyright (c) 1994-2005 Quovadx, Inc., acting through its Rogue Wave * Software division. Licensed under the Apache License, Version 2.0 (the * "License"); you may not use this file except in compliance with the * License.Youmay obtain a copy ofthe Licenseat * http://www.apache.org/licenses/LICENSE-2.0.Unless requiredby * applicable law or agreed to in writing, software distributed under * the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR * CONDITIONS OF ANY KIND, either express or implied. See the License * for the specific language governing permissions and limitations under * the License. * **/ #include #include #include #include #include #include #include int exit_status /* = 0 */; extern "C" { int line; int fail; jmp_buf env; void handle_ABRT (int) { fail = 0; longjmp (env, 1); } } #define FAIL(code) \ fail = line = __LINE__; \ signal (SIGABRT, handle_ABRT); \ if (0 == setjmp (env)) {\ code; \ exit_status = 1;\ rw_assert (false, __FILE__, line, "expected assertion");\ } \ else\ (void)0 #define PASS(code) \ fail = -1; line = __LINE__; \ signal (SIGABRT, handle_ABRT); \ if (0 == setjmp (env)) \ code; \ else if (fail != line) {\ exit_status = 1;\ rw_assert (false, __FILE__, line, "unexpected assertion"); \ } (void)0 /**/ void test_new_delete () { rw_info (0, __FILE__, __LINE__, "exercising successful allocation and deallocation"); { void *p = 0; PASS (p = operator new (0)); rw_assert (p != 0, __FILE__, __LINE__, "operator new(0) != 0"); operator delete (p); } { void *p = 0; PASS (p = operator new (1)); rw_assert (p != 0, __FILE__, __LINE__, "operator new(1) != 0"); operator delete (p); } { void *p = 0; PASS (p = operator new (2)); rw_assert (p != 0, __FILE__, __LINE__, "operator new(2) != 0"); operator delete (p); } { void *p = 0; PASS (p = operator new (1024)); rw_assert (p != 0, __FILE__, __LINE__, "operator new(1024) != 0"); operator delete (p); } } /**/ #define CATCH(code) \ try { code; fail = 1; } \ catch (_RWSTD_BAD_ALLOC) { fail = 0; } \ catch (...) { fail = 2; } \ rw_assert (!fail, __FILE__, __LINE__, \ "%s", 1 == fail ? "failed to throw" :\ "threw an unknown exception") #define NOTHROW(code) \ try { fail = 0; code; } \ catch (...) { fail = 1; } \ rw_assert (!fail, __FILE__, __LINE__, "unexpected exception") void test_bad_alloc () { rw_info (0, __FILE__, __LINE__, "exercising the ability of ordinary " "operator new to throw std::bad_alloc"); rwt_free_store* const pst = rwt_get_free_store (0); *pst->throw_at_blocks_ [0] = pst->blocks_ [0]; CATCH (operator new (0)); CATCH (operator new (1)); CATCH (operator new (2)); CATCH (operator new (1024)); { void *p = 0; NOTHROW (p = operator new[](0)); operator delete[](p); } { void *p = 0; NOTHROW (p = operator new[](1)); operator delete[](p); } { void *p = 0; NOTHROW (p = operator new[](2)); operator delete[](p); } { vo
Re: 23.containers.deque.modifiers.cpp
Martin Sebor wrote: > Liviu Nicoara wrote: > >>I have attached my tentative porting of lib.deque.modifiers test to the >>new driver. Martin, I would appreciate suggestions for improving the >>sections which use ToString class (one of those uses split formatting). > > > I don't see the class defined in the test. Did you by any chance > move/copy it into your version alg_test.h? Yes, I did. My bad, I just wanted to get your feed-back on the formatting bits and I didn't think that was important. I will stick a ToString in each of the tests using it. > > I think the bits that use the ToString class are fine. As soon as > I'm done with the extension to rw_asnprintf() to format arrays of > class X (we need to rename it!) it should be straightforward to > simply remove the class and pass the arrays directly to rw_assert(). Super. > > Btw., the old tests were designed to avoid invoking the RW_ASSERT > macro except on failure (i.e., there's usually an if (failed) { } > block around it). I got that. I will eliminate the conditionals from now on. Thanks, Liviu
Re: 23.containers.deque.modifiers.cpp
Liviu Nicoara wrote: I have attached my tentative porting of lib.deque.modifiers test to the new driver. Martin, I would appreciate suggestions for improving the sections which use ToString class (one of those uses split formatting). I don't see the class defined in the test. Did you by any chance move/copy it into your version alg_test.h? I think the bits that use the ToString class are fine. As soon as I'm done with the extension to rw_asnprintf() to format arrays of class X (we need to rename it!) it should be straightforward to simply remove the class and pass the arrays directly to rw_assert(). Btw., the old tests were designed to avoid invoking the RW_ASSERT macro except on failure (i.e., there's usually an if (failed) { } block around it). It was done to avoid the relatively expensive formatting done behind the scenes (as a result of expanding the RW_ASSERT() macro). The new driver doesn't do any formatting unless a diagnostic is actually active (i.e., unless an assertion fails) or unless tracing is on (i.e., unless the --trace option is used), so this is not a concern anymore. It's also important to be able exercise the formatting code even when there are no assertion failures (via the --trace option), and it can be useful to keep track of the number of assertions (or individual test cases) exercised. So it would be good to remove the if conditionals from around the assertions in the ported tests. Doing so will also allow us to get rid of the dummy assertion at the end of some tests and the code that counts the number of failures. Martin
Re: x.y.z numbering and releases
William A. Rowe, Jr. wrote: Martin Sebor wrote: William A. Rowe, Jr. wrote: > >> [...] I suspect that may not fully >> address your concerns (i.e., the fact that there is a 1.2.3 branch >> before an official release has taken place). > > > I do believe it does, granted the 1.2.3-rc3 branch would be internally > labeled (version id) 1.2.3, but the branch it sits on and the tarballs > it's packaged in both clearly designate 1.2.3-rc3... I'm not dead set against the x.y.z- convention but as I said before, I'm not convinced that obfuscating the upcoming version in the name of the branch is necessary. In addition I can imagine situations where the specific "candidate" suffix would be inappropriate. Consider the not so uncommon case where development happens in parallel on two (or more) branches in addition to trunk/. For instance: ... branches/1.2/ <== current development of 1.2 branches/1.2.3/ <== to be released branches/2.0/ <== future binary incompatible branch Did I understand this correctly? Yes. If so, yes I can agree that -candidate might be overkill. Let's consider, it's really no different if someone picks up 1.2.3 and sends us some report about it, than if they pick up the 1.2 branch and report an issue. Since tags/ is where to look for a specific release, and most folks do know that branches/ are dynamic points in time, I guess my concern is unfounded. Yes. I think it's a matter of clearly documenting the branching (and versioning) policy and the release process rather than trying to come up with a foolproof naming convention. Martin
Re: x.y.z numbering and releases
Martin Sebor wrote: William A. Rowe, Jr. wrote: > >> [...] I suspect that may not fully >> address your concerns (i.e., the fact that there is a 1.2.3 branch >> before an official release has taken place). > > > I do believe it does, granted the 1.2.3-rc3 branch would be internally > labeled (version id) 1.2.3, but the branch it sits on and the tarballs > it's packaged in both clearly designate 1.2.3-rc3... I'm not dead set against the x.y.z- convention but as I said before, I'm not convinced that obfuscating the upcoming version in the name of the branch is necessary. In addition I can imagine situations where the specific "candidate" suffix would be inappropriate. Consider the not so uncommon case where development happens in parallel on two (or more) branches in addition to trunk/. For instance: ... branches/1.2/ <== current development of 1.2 branches/1.2.3/ <== to be released branches/2.0/ <== future binary incompatible branch Did I understand this correctly? If so, yes I can agree that -candidate might be overkill. Let's consider, it's really no different if someone picks up 1.2.3 and sends us some report about it, than if they pick up the 1.2 branch and report an issue. Since tags/ is where to look for a specific release, and most folks do know that branches/ are dynamic points in time, I guess my concern is unfounded. Bill
Re: [VOTE] publish stdcxx 4.1.3
Justin Erenkrantz wrote: On Sun, Jan 22, 2006 at 11:47:49AM -0700, Martin Sebor wrote: and -1 with this the final tarball in incubation. I'm not sure I undrestand what you mean -- can you elaborate? I think he means that if this were the final tarball before graduation, then he'd vote against because of the issues he raised. While we're making positive forward progress, stdcxx is not ready to graduate yet. Thanks for the clarification. I completely agree that we're not ready yet. I didn't mean to suggest we were, but I can see how my wording in the quarterly report could have been read that way. So, count him as a +1. =) -- justin Will do. Martin
Re: x.y.z numbering and releases
William A. Rowe, Jr. wrote: Martin Sebor wrote: Okay, so just to make sure we're all clear, the process we seem to be converging on goes like this: 1. branch X.Y.Z/ from trunk/ 2. with N starting at 1, tag the X.Y.Z/ branch X.Y.X-rc-N/ and create the corresponding tarball, stdcxx-X.Y.Z-rc-N.tar.gz; vote on tarball 3.1 if the vote passes, rename tarball to stdcxx-X.Y.Z.tar.gz and proceed to publish it 3.2 otherwise, fix problems on the X.Y.Z branch, increment N by 1 and go to 2 I like. Is there anyway we can rename branches/x.y.z/ in such a way as to avoid confusing users that it is the final release? E.g. branches/x.y.z-candidate/ ? I thought you said you were okay with branches/x.y.z/: William A. Rowe, Jr. wrote: > Martin Sebor wrote: > >> [...] I suspect that may not fully >> address your concerns (i.e., the fact that there is a 1.2.3 branch >> before an official release has taken place). > > > I do believe it does, granted the 1.2.3-rc3 branch would be internally > labeled (version id) 1.2.3, but the branch it sits on and the tarballs > it's packaged in both clearly designate 1.2.3-rc3... I'm not dead set against the x.y.z- convention but as I said before, I'm not convinced that obfuscating the upcoming version in the name of the branch is necessary. In addition I can imagine situations where the specific "candidate" suffix would be inappropriate. Consider the not so uncommon case where development happens in parallel on two (or more) branches in addition to trunk/. For instance: branches/1.2.3/ <== to be released branches/2.0/ <== future binary incompatible branch Take gcc as an example of this situation: http://gcc.gnu.org/viewcvs/ Currently, in addition to trunk/, development takes place at least on branches/4_0_branch/ and branches/4_1_branch/ (and up until not so long ago the 3_4_branch/ was also active). Certainly, naming the 4.1 branch 4_1_candidate wouldn't be quite right at this point since it's still being actively developed. Assuming we agree to rule out "-candidate" as the suffix, what are we left with? We could use the gcc "-branch" convention but given that the branch lives under branches/ that is clearly superfluous. In my opinion, anyone experienced enough to pull down a branch from Subversion can be expected to "know what they're doing" and we can safely avoid spending cycles preventing them from "accidentally" using unstable code. The rest of our users will grab the release tarball from the download location so there's no risk there. Martin
Re: [VOTE] publish stdcxx 4.1.3
On Sun, Jan 22, 2006 at 11:47:49AM -0700, Martin Sebor wrote: > >and -1 with this the final tarball in > >incubation. > > I'm not sure I undrestand what you mean -- can you elaborate? I think he means that if this were the final tarball before graduation, then he'd vote against because of the issues he raised. While we're making positive forward progress, stdcxx is not ready to graduate yet. So, count him as a +1. =) -- justin
Re: [PING] Re: 21.string.cons test
I am working on it. Sorry for not answering promptly, it won't happen again. Liviu Martin Sebor wrote: > Liviu -- please let me know either way; if you don't have it I'll port > it myself. > > Thanks > Martin > > > Martin Sebor wrote: > >>Liviu Nicoara wrote: >> >> >>>Attached is my attempt at converting the lib.string.cons test. It >>>contains the additional new_test.h/new.cpp and >>>string_test.h/string_test.cpp for support. >> >> >>Do you happen to also have the test for the replacement operator new? >>The current one fails with the changes to new.cpp (because new.cpp >>uses the driver without initializing it first). >> >>Martin > >
[PING] Re: 21.string.cons test
Liviu -- please let me know either way; if you don't have it I'll port it myself. Thanks Martin Martin Sebor wrote: Liviu Nicoara wrote: Attached is my attempt at converting the lib.string.cons test. It contains the additional new_test.h/new.cpp and string_test.h/string_test.cpp for support. Do you happen to also have the test for the replacement operator new? The current one fails with the changes to new.cpp (because new.cpp uses the driver without initializing it first). Martin
test for lib.alg.transform
The attached file contains my attempt to update lib.alg.transform tests and port it to new test driver. With best wishes, Anton Pevtsov /*** * * transform.cpp - test exercising 25.2.3 [lib.alg.transform] * * $Id: //stdlib/dev/tests/stdlib/algorithm/transform.cpp#18 $ * *** * * Copyright (c) 1994-2005 Quovadx, Inc., acting through its Rogue Wave * Software division. Licensed under the Apache License, Version 2.0 (the * "License"); you may not use this file except in compliance with the * License.Youmay obtain a copy ofthe Licenseat * http://www.apache.org/licenses/LICENSE-2.0.Unless requiredby * applicable law or agreed to in writing, software distributed under * the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR * CONDITIONS OF ANY KIND, either express or implied. See the License * for the specific language governing permissions and limitations under * the License. * **/ #include // for transform #include // for size_t #include #include // for rw_test() _RWSTD_NAMESPACE (std) { // disable explicit instantiation for compilers (like MSVC) // that can't handle it #ifndef _RWSTD_NO_EXPLICIT_INSTANTIATION template OutputIter > > transform (InputIter > >, InputIter > >, OutputIter > >, func > >); template OutputIter > > transform (InputIter > >, InputIter > >, InputIter > >, OutputIter > >, binary_func > >); #endif // _RWSTD_NO_EXPLICIT_INSTANTIATION } // namespace std /**/ template struct incT { incT (int dummy) { funcalls_ = 0; dummy_ = dummy; } T operator() (const T &x) const { ++funcalls_; T y(x); y.val_ += 1; return y; } // dummy operator T operator() (const T &a, const T &b) const { _RWSTD_UNUSED(b); return a; } int dummy_; static std::size_t funcalls_; }; template struct plusT { plusT (int dummy) { funcalls_ = 0; dummy_ = dummy; } // dummy operator T operator() (const T &a) const { return a; } T operator() (const T &a, const T &b) const { ++funcalls_; T x(a); x.val_ = a.val_ + b.val_; return x; } int dummy_; static std::size_t funcalls_; }; template std::size_t incT::funcalls_; template std::size_t plusT::funcalls_; /**/ template void test_transform (const std::size_t line, const std::size_t N, const InputIterator1& it1, const InputIterator2& it2, const OutputIterator& out, const Function& fun_dummy, const T* , int same_seq, bool binary) { static const char* const it1name = type_name (it1, (T*)0); static const char* const it2name = type_name (it2, (T*)0); static const char* const outname = type_name (out, (T*)0); static const char* const fname= "transform"; static const char* const funname = binary ? "binary_function" : "unary_function"; _RWSTD_UNUSED(fun_dummy); rw_info (0, 0, 0, "std::%s (%s, %2$s%{?}, %s%{;}, %s, %s)%{?}, %s%d == %s%{;}", fname, it1name, binary, it2name, outname, funname, same_seq, "first", same_seq, "dest"); // generate sequential values for each default constructed T T::gen_ = gen_seq; // use ::operator new() to prevent default initialization T *buf1 = new T [N]; T* buf2 = new T [N]; T* buf3 = same_seq ? (same_seq == 1 ? buf1 : buf2) : new T [N]; int start1_val = same_seq == 2 ? buf2[0].val_ : buf1[0].val_; int start2_val = same_seq == 2 ? buf1[0].val_ : buf2[0].val_; for (std::size_t i = 0; i < N; ++i) { const InputIterator1 first1 = make_iter (buf1, buf1, buf1 + i + 1, it1); const InputIterator1 last = make_iter (buf1 + i + 1, buf1, buf1 + i + 1, it1); const InputIterator2 first2 = make_iter (buf2, buf2, buf2 + i + 1, it2); const OutputIterator dest = make_iter (buf3, buf3, buf3 + i + 1, out); Function fun(0); // exercise 25.2.3 - std::transform<> () const OutputIterator result = binary ? std::transform (first1, last, first2, dest, fun) : std::transform (first1, last, dest, fun); // check the returned iterator bool success = result.cur_ == buf3 + i + 1; rw_assert (success, 0, line, "std::%s (%s, %2$s%{?}, %s%{;}, %s, %
test for lib.alg.random_shuffle
I'm porting the test for the lib.alg.random_shuffle algorithm and I have a question about the current test implementation. There is the special test case for the built-in random number generator which does the following: some test array is defined and initialized with numbers, when the random_shuffle algorithm is called for this array, and the result is compared with another predefined array (which was initialized with the same numbers and "shuffled" manually). The results of the random_shuffle of the given array depends on the implementation of the random number generator used by random_shuffle, and this results in that the test case may be passed for the 1025-th invocation of the random_shuffle algorithm only. The question is: is it necessary to keep this test case in the ported test version? Thanks, Anton Pevtsov