special
value (e.g., -1 :) to *disable* the exception safety tests in
a small number of test cases (as opposed to enabling then for
just a subset of them as we do now).
Martin
With best wishes,
Anton Pevtsov
-Original Message-
From: Martin Sebor [mailto:[EMAIL PROTECTED]
Sent
Anton Pevtsov wrote:
[...]
Martin Sebor wrote:
I don't think it's incorrect since compare() must be implemented as if
by calling eq(), although the standard should probably not mandate > one
or the other. The way it's done in our implementation, however, is
probably goi
Liviu Nicoara wrote:
Hi,
The following test case fails with the latest dev stdcxx (*):
tmp$ cat t.cpp
#include
#include
#include
int main ()
{
std::strstreambuf sb;
std::ostream os (&sb);
os << " ";
std::streampos pos =
sb.pubseekoff (0, std::ios::end, std::ios::
Anton Pevtsov wrote:
Ok, but I see another issue: the significant part of the test cases
doesn't require memory allocation.
These cases cann't produce bad_alloc and there is no reason to test
exception safety on them.
Also the assert which verifies that an exception was thrown fails for
such te
Anton Pevtsov wrote:
I am porting the test for lib.string.access methods (operator[] and at)
and found one issue.
The code
#include
int main (void)
{
std::string s ("a", 1);
const char& c = s[1];
return 0;
}
results in assertion and fails. But the standard says for
const_refe
Anton Pevtsov wrote:
The test for lib.string.substr is here:
http://people.apache.org/~antonp/stdcxx05032006/
Also there are required difference for 21.strings.cpp and 21.strings.h
files.
Looks good! Please make the formatting changes we discussed
before committing, i.e., change
static co
Anton Pevtsov wrote:
Martin, I made few changes to this test. The difference file is
attached.
I think it is necessary to modify other find methods and compare method
to force them returning npos instead of the length_error exception
throwing.
What do you think about this?
That's a good idea. I
[EMAIL PROTECTED] wrote:
Author: sebor
Date: Thu May 4 18:49:19 2006
New Revision: 399914
URL: http://svn.apache.org/viewcvs?rev=399914&view=rev
Log:
2006-05-04 Martin Sebor <[EMAIL PROTECTED]>
* 21.string.append.cpp (test_append): Simplified the handling
Anton Pevtsov wrote:
I committed the test.
Martin Sebor wrote:
PS One question: why is the "last" string always the last test case in
the array?
It is just a marker of the end of the test cases array. There is no
special need in it, I use it during the test implementation for
Anton Pevtsov wrote:
Martin Sebor wrote:
Anton, this simplifies the exception safety setup. Another change
[...]
I'll try to cook one up over the weekend or sometime next week.
The changes looks good. I'll use them porting the rest of the tests.
I plan to port tests for ac
Anton Pevtsov wrote:
The ported test is here:
http://people.apache.org/~antonp/stdcxx05062006/
Index: 21.strings.cpp
===
--- 21.strings.cpp (revision 400251)
+++ 21.strings.cpp (working copy)
@@ -204,6 +204,7 @@
[EMAIL PROTECTED] wrote:
Author: sebor
Date: Mon May 8 18:08:00 2006
New Revision: 405254
URL: http://svn.apache.org/viewcvs?rev=405254&view=rev
Log:
2006-05-08 Martin Sebor <[EMAIL PROTECTED]>
* replace.cpp: Replaced LSTR, LLEN, and LPAR in test cases with
Anton Pevtsov wrote:
Martin, this is the signature for
at (size_type) const and
operator [] (size_type) const.
Right. Plus the non-const overload of each.
Ther is small problem with brackets: our engine set it automatically
before and after the signature description.
But this signature is a
Anton Pevtsov wrote:
Martin Sebor wrote:
[...]
Unfortunately, with your changes the replace test just fails on Windows.
The attached diff files contains my attempt to fix the problem.
Thanks! Please go ahead and commit it.
[...]
But on Windows I still have problems with the end of a
Anton Pevtsov wrote:
Martin Sebor wrote:
[...]
But on Windows I still have problems with the end of a string (somewhere
in the test driver): it looks like there is no '\0' symbol there, but it
is expected.
I think I just spotted something as well, with both MSVC and Intel
C++ on L
Anton Pevtsov wrote:
I still have no access to the repository, so I was unable to commit the
changes to char.cpp.
There was an email on [EMAIL PROTECTED] explaining that
they had some semi-serious hardware issues and that recovery
is in progress. They didn't give a date/time of when they
antici
Martin Sebor wrote:
Anton Pevtsov wrote:
I still have no access to the repository, so I was unable to commit the
changes to char.cpp.
There was an email on [EMAIL PROTECTED] explaining that
they had some semi-serious hardware issues and that recovery
is in progress. They didn't give a
Craig Chariton wrote:
There is an interesting problem that occurs with vectors. Here is the
sample code:
[...]
I have not been able to find any references to such a problem with
vectors
on the lists or in JIRA. Has this problem been recognized and solved?
AFAIK, it's not a known issue. Coul
Craig Chariton wrote:
Jira issue STDCXX-179 created.
Thanks!
Martin
Craig Chariton
-Original Message-
From: Martin Sebor [mailto:[EMAIL PROTECTED]
Sent: Friday, May 12, 2006 4:29 PM
To: stdcxx-dev@incubator.apache.org
Subject: Re: Problem with vectors and insert
Craig Chariton
Anton Pevtsov wrote:
Here is the ported test for lib.string.cons and required differences to
the 21.strings.h/cpp files (with changes required for
lib.string.access):
http://people.apache.org/~antonp/stdcxx05102006/
Please go ahead and commit this whenever you have a chance.
Btw., it's beginnin
Craig Chariton wrote:
When using std::vector::insert my understanding is that we should be able to
insert either a single item or a group of elements.
The requirements on the template overload of insert() are given
in Table 67 of the C++ standard:
given a sequence (such as vector) a, an iter
I just posted our quarterly status report both in Subversion
and on the Wiki. Any comments or suggestions, especially from
our mentors, are welcome and appreciated.
http://svn.apache.org/repos/asf/incubator/stdcxx/site/status/2006-04.text
http://wiki.apache.org/incubator/May2006
Martin
[EMAIL PROTECTED] wrote:
Author: antonp
Date: Mon May 15 01:07:34 2006
New Revision: 406579
URL: http://svn.apache.org/viewcvs?rev=406579&view=rev
Log:
2006-05-15 Anton Pevtsov <[EMAIL PROTECTED]>
* char.cpp (rw_match): Fixed the bug with the expanded string length.
It looks like th
Martin Sebor wrote:
[EMAIL PROTECTED] wrote:
Author: antonp
Date: Mon May 15 01:07:34 2006
New Revision: 406579
URL: http://svn.apache.org/viewcvs?rev=406579&view=rev
Log:
2006-05-15 Anton Pevtsov <[EMAIL PROTECTED]>
* char.cpp (rw_match): Fixed the bug with the expanded str
Anton Pevtsov wrote:
Martin Sebor wrote:
Btw., it's beginning to look like we might run out of bits in the
bitmap. If it happens we'll probably have to split it into two data
members, one for the signature and one for the function id.
Yes, we will run out of bits in the bitmap. Th
Anton Pevtsov wrote:
The test for lib.string.swap and required changes to the
21.strings.h/cpp are here:
http://people.apache.org/~antonp/stdcxx05152006/
Also there is difference to the 21.string.append.cpp - I added push_back
test cases to this test.
Okay, thanks!
We might also want to imple
Anton Pevtsov wrote:
The test for lib.string.swap and required changes to the
21.strings.h/cpp are here:
http://people.apache.org/~antonp/stdcxx05152006/
This is okay for now, btw., please go ahead and commit it. We
do need to enhance the test to exercise the common idiom used
to shrink a strin
Anton Pevtsov wrote:
Martin Sebor wrote:
I committed the user-defined allocator yesterday so that we can get
started on enhancing the tests to use it. Since I haven't thoroughly
tested UserAlloc yet let me do one test first to iron out> any
kinks.
I tried to use the UserAlloc to
Anton Pevtsov wrote:
Martin, I added several test cases to verify the swap with temporary
string and committed the test:
http://svn.apache.org/viewcvs?rev=406940&view=rev
Great, thanks!
I plan to enhance the test to exercise the function with unequal
allocators.
Okay. I've done some work o
EMAIL PROTECTED]
Sent: Wednesday, May 17, 2006 05:29
To: stdcxx-commits@incubator.apache.org
Subject: svn commit: r407120 - /incubator/stdcxx/trunk/include/vector.cc
Author: sebor
Date: Tue May 16 18:28:38 2006
New Revision: 407120
URL: http://svn.apache.org/viewcvs?rev=407120&view=rev
Log
Message-
From: Martin Sebor [mailto:[EMAIL PROTECTED]
Sent: Friday, May 12, 2006 05:22
To: stdcxx-dev@incubator.apache.org
Subject: Re: svn commit: r405254 -
/incubator/stdcxx/trunk/tests/strings/21.string.replace.cpp
Martin Sebor wrote:
Anton Pevtsov wrote:
I still have no access to the r
Jeremy Dean wrote:
I am having a problem building Standard Library.
[...]
When I try to build an optimized build, the localedef hangs and never
returns.
Have you searched the bug database for similar problems? The
configuration issue below causes similar symptoms in locale:
http://issues.apac
Anton Pevtsov wrote:
Martin, I updated all tests to use new macro DEFINE_STRING_TEST_DISPATCH
and allocator.
The diff file is here:
http://people.apache.org/~antonp/stdcxx05172006/
Thanks for doing that! Please go ahead and apply the changes.
Martin Sebor wrote:
<>PS I noticed th
/stdlib/config/src/LOCALE_NAME_FMAT.cpp:251
Jeremy
-Original Message-
From: Martin Sebor [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 17, 2006 10:00 AM
To: stdcxx-dev@incubator.apache.org
Subject: Re: Problem building Standard library
Jeremy Dean wrote:
I am having a problem building
Jeremy Dean wrote:
I compiled this new test on the system and it also gets a segmentation
fault.
I guess you'll need to do some debugging because it runs fine
both in our nightly tests and in my manual builds. Where does
the current test crash and why? (It can't be on line 251.)
Martin
Anton Pevtsov wrote:
Martin,
This code:
_RWSTD_NAMESPACE (std) {
// declare to avoid dragging in all of
// (yes, it is undefined for programs to do that)
template
struct allocator;
} // namespace std
produces a warning on MSVC: the allocator is defined as class.
The changing to "class al
Anton Pevtsov wrote:
[...]
Here is another question. We use template class Allocator in the tests,
and it assumes that code should be valid for std:allocator too.
But
SharedAlloc a;
Allocator z (&a);
wll not compile when Allocator is std::allocator. Is there any way to
use std::allocator and
Anton Pevtsov wrote:
The ported test for lib.string::operator+ is here:
http://people.apache.org/~antonp/stdcxx05182006/
Also there are required changes to 21.strings.h/cpp files: 5 new
signatures and memberId element, etc.
Okay, this looks okay to commit, although I think we will need
to some
then setting it to a greater value and letting the
function succeed.
Let me know your thoughts!
Martin
URL: http://svn.apache.org/viewvc?rev=407684&view=rev
Log:
2006-05-18 Martin Sebor <[EMAIL PROTECTED]>
* 21.string.replace.cpp (test cases): Changed the meaning of
Liviu Nicoara wrote:
The problem - as I saw it in the locale_name_fmat comp test Jeremy was
running - seems to be a buffer overrun in LOCALE_NAME_FMAT.cpp at line
189 (trunk) because the 'def_locale' buffer may not have enough space to
hold the name of a locale, e.g. the one Jeremy got:
LC_CTYPE
Anton Pevtsov wrote:
Martin Sebor wrote:
Anton, the most important bit here enables the exception safety tests
for all test cases (except those that test other exceptions such as >
out_of_range). I'd like to do the same in the rest of > the tests as
well.
I see, thanks.
Anton Pevtsov wrote:
Martin Sebor wrote:
[...]
I also think we can do better than hardcode assumptions about the
order of the constants (the computation of the nonmember constant in
21.strings.cpp).
Hmm, shall we separate members indexes or enum elements (and
signatures?) from the nonmember
Jeremy, if you would like to see this problem fixed please remember
to file an issue for it.
Martin
Martin Sebor wrote:
Liviu Nicoara wrote:
The problem - as I saw it in the locale_name_fmat comp test Jeremy was
running - seems to be a buffer overrun in LOCALE_NAME_FMAT.cpp at line
189
Narayanan wrote:
Hello,
I am interested in contributing to the Standard C++ library opensource
project. Please add me to the list of contributors.
Great, there's plenty we can use help with! :)
There is no official list of contributors that we could add you
to (see http://incubator.apac
Anton Pevtsov wrote:
Martin, I tested our solution generation script against new Intel compiler
9.1.0.22. The library builds successful, but produces several warnings.
see the
attached file, please.
The dllexport/import warnings look suspicious to me. The members
in question are defined in a
Anton Pevtsov wrote:
Martin Sebor wrote:
<>I've been playing with this a bit and it turns out that we do have
<>enough bits if we only make better use of them :) Here's how we can
squeeze all the functions and their signatures into 32 bits:
[...]
<>A 32-bit
Anton Pevtsov wrote:
[...]
I updated the script to incorporate icc-9.1 into supported
configurations. It required minor changes to several script files. The
changes are here:
http://people.apache.org/~antonp/stdcxx05232006/Scripts/
Change log:
2006-05-23 Anton Pevtsov <[EMAIL PROTECTED]>
Martin Sebor wrote:
Anton Pevtsov wrote:
[...]
I see, thanks. I'll update the test when the changes to
21.strings.h/.cpp appears on the svn.
Okay. I was busy with other things today (actually yesterday,
I forgot to send this last night) but I'm hoping to wrap it
up today.
I&#
Anton Pevtsov wrote:
Ported test for std::string non-members operators (+, ==, != , <=, >=,
<, >) are here:
http://people.apache.org/~antonp/stdcxx05252006b/
Would you mind terribly merging all the [in]equality and relational
tests and keep just the one for operator+() separate? The code for
al
Anton Pevtsov wrote:
The updated tests are here:
http://people.apache.org/~antonp/stdcxx05252006a/
Now all tests cases are used to exercise the exception safety.
Awesome! Please commit ASAP! :)
Martin
Change Log:
2006-05-25 Anton Pevtsov <[EMAIL PROTECTED]>
* 21.string.replace.cp
Hey Anton, attached is a patch that factors some more of the
boilerplate code out of the test function and into a helper
class template. I would like to move it to 21.strings.h but
I'm wondering if you could first take a look at it to see
if you think it will be readily usable in all or most of th
Thanks
Martin
Thanks,
Anton Pevtsov
-Original Message-----
From: Martin Sebor [mailto:[EMAIL PROTECTED]
Sent: Friday, May 26, 2006 05:00
To: stdcxx-dev@incubator.apache.org
Subject: factoring out more test code
Hey Anton, attached is a patch that factors some more of the boilerplate
Anton Pevtsov wrote:
Martin, the test driver build on msvc-7.1 produces warnings.
21.strings.cpp
D:\Projects\RogueWave\work\stdlib\tests\src\../include\21.strings.h(108)
: warning C4554: '<<' : check operator precedence for possible error;
use parentheses to clarify precedence
The cause is
1
Martin Sebor wrote:
[...]
21.strings.cpp
\Projects\RogueWave\work\stdlib\tests\src\21.strings.cpp(190) : warning
C4800: 'int' : forcing value to bool 'true' or 'false' (performance
warning)
Btw., I opened a bug for this with Microsoft and copied
Anton Pevtsov wrote:
Martin Sebor wrote:
Would you mind terribly merging all the [in]equality and relational
tests and keep just the one for operator+() separate?
The merged operators test (21.string.operators) and separate test for
operator+ are here:
http://people.apache.org/~antonp
Martin Sebor wrote:
Anton Pevtsov wrote:
Looks good. I thnik this helps us to reduce the identical code in tests,
escpecially when "range" cases are exercised. Also it is possible to
update the tests one by one, isn't it?
Yes, I believe so. Let me start working on changing
Anton Pevtsov wrote:
The capacity test updated to last changes in the test driver is here
(differences):
http://people.apache.org/~antonp/stdcxx05302006/
This looks good. Since the changes to the capacity test are more
involved than just adding new test cases could you please commit
them separa
Anton Pevtsov wrote:
Martin, unfortunately, these changes results in segmentation fault both
on Windows and Unix.
I'll investigate this, but could you take a look on it too when you have
a chance?
Sure. I tested (as usual) with gcc and EDG eccp on SPARC/Solaris
and saw no problems, but I have j
Anton Pevtsov wrote:
I corrected errors in 21.strings.h/.cpp and updated replace and cons
tests in the same way, now they exercise strings with special length
too.
The tests including modified yesterday are here (except cons):
http://people.apache.org/~antonp/stdcxx05312006a/
Are they ok to comm
Anton Pevtsov wrote:
[...]
I started with cons test, here is my attempt to add verification of the
allocator methods usage:
http://people.apache.org/~antonp/stdcxx05312006b/
I think that we are needed in access to allocator methods names. I
modified the allocator header and implementation files t
Eric Lemings wrote:
On May 31, 2006, at 1:35 PM, Eric Lemings wrote:
http://issues.apache.org/jira/browse/STDCXX-192
I wonder if the .type is directive necessary at all. I'm testing
it on i86/Linux to see how things go and if the results are good
I'm inclined to simply remove it.
If you ha
Martin Sebor wrote:
Eric Lemings wrote:
On May 31, 2006, at 1:35 PM, Eric Lemings wrote:
http://issues.apache.org/jira/browse/STDCXX-192
I wonder if the .type is directive necessary at all. I'm testing
it on i86/Linux to see how things go and if the results are good
I'm i
Anton Pevtsov wrote:
Martin Sebor wrote:
As a general comment, we should be on the lookout for ways to reduce
the amount of boilerplate code that will end up repeated across all
tests, such the snippet of code below. It would be > nice to be
able to say something like:
[...]
As a fi
Martin Sebor wrote:
[...]
Btw., I'm not sure exactly what other string tests are left but an
enhancement that still needs to be implemented across several of the
tests (ctors, append, erase, insert and replace) is exercising the
exception safety of the member function templates. Since mu
Craig Chariton wrote:
I am getting a compiler Warning 552 on HP-UX 11.11 with an A.03.63
compiler. Here is the code that recreates the warning:
[...]
I am not seeing this with gcc on Linux. The code appears to run the
fine on in both cases. I was just wondering if this is a compiler issue
a
Eric Lemings wrote:
http://issues.apache.org/jira/browse/STDCXX-192
This looks like a patch for STDCXX-191, not 192, even though both
the subject and the link refer to 192. Either way, I applied it
here: http://svn.apache.org/viewvc?rev=411888&view=rev
Thanks!
Martin
=
Scott Zhong wrote:
http://issues.apache.org/jira/browse/STDCXX-196
I'm not sure what's going on yet but I have been able to reproduce
the behavior in a fairly small test case (but not independent of
stdcxx). Somehow, rethrowing the caught exception causes the fault.
$ cat t.cpp && nice make t
x27;m behind on email...)
Martin
With best wishes,
Anton Pevtsov
-Original Message-
From: Martin Sebor [mailto:[EMAIL PROTECTED]
Sent: Friday, May 19, 2006 02:04
To: stdcxx-dev@incubator.apache.org
Subject: Re: test for lib.string.swap
Anton Pevtsov wrote:
[...]
Here is another questio
MAIL PROTECTED]>
Date: Mon, 05 Jun 2006 20:01:34 -0600
From: Martin Sebor <[EMAIL PROTECTED]>
Organization: Rogue Wave Software
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12)
Gecko/20050920
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: stdcxx-dev@incubator.apache.o
Martin Sebor wrote:
Hey Anton, this bounced yesterday. Please see the attachment
to read the whole email.
Crud. It looks like the attachment didn't make it. Let me try
again.
Martin
Original Message
Subject: failure notice
Date: 6 Jun 2006 02:02:03 -
From: [
Anton Pevtsov wrote:
Martin Sebor wrote:
Have these changes been applied? (Sorry, I'm behind on email...)
No.
I merged these differences with current test implementation and updated
it to use StringCaseTestData.
The final diff is here:
http://people.apache.org/~antonp/stdcxx06062006
Scott Zhong wrote:
There are several stdlib test that uses mynew.h and the placement new is
causing it to seg fault.
Affected tests:
tests/stdlib/containers/deque_modifiers
tests/stdlib/diagnostics/exceptions
tests/stdlib/test/new
This test exercises the correctness of the replaced o
I reproduced the crash in a small compiler-only test case
(specific to XLC++) and filed a PMR with IBM. Here are the
details: http://issues.apache.org/jira/browse/STDCXX-199.
It looks to me like exceptions are essentially unusable
in this configuration.
Martin
Martin Sebor wrote:
Scott Zhong
p;view=rev
Log:
2006-06-06 Martin Sebor <[EMAIL PROTECTED]>
* 21.strings.h (IteratorId): New member type of StringIds.
(StringFunc): Added a new data member.
* 21.strings.cpp (_rw_iter_names): New.
(_rw_opt_char_types, ...): Sized based on the corresponding
Anton Pevtsov wrote:
Martin, I suggest to move the common to all range overlodas for
different methods code to the 21.strings.h
I think we may have RangeBase class with begin methods and virtual
operator ().
Here are the changes to the tests which use this approach:
http://people.apache.org/~anto
Anton Pevtsov wrote:
[...]
Ok, I see. I think we may leave the design as is at this time.
But there is a problem with reverse iterators. It looks like we should
provide special resulting sequence for them.
What do you think about this?
Yeah, I realize the reverse iterators don't quite fit in a
. I'm behind on a number of things and this is
one of them. I'll try to get caught up by Monday. Thanks for
the reminder!
Martin
Thanks,
Anton Pevtsov
-Original Message-----
From: Martin Sebor [mailto:[EMAIL PROTECTED]
Sent: Friday, April 21, 2006 23:03
To: stdcxx-dev@incubator.apa
Anton Pevtsov wrote:
Here are the diffs to the ctor test required by the testing of the range
overloads:
http://people.apache.org/~antonp/stdcxx06092006/
Why don't we reuse the virtual RangeBase member function used
for other template members and have test_ctor pass it str_arg?
CtorRange would
Anton Pevtsov wrote:
[...]
Yes it is possible to reverse the expanded substring in known range, but
we check results in other way:
std::size_t match = rw_match (tcase.res, str.data (),
tcase.nres);
Here the rw_match calls rw_expand. These functions know nothing about
the iterators and r
Martin Sebor wrote:
Anton Pevtsov wrote:
Martin, what about this issue?
I tried to rebuild all configurations and found that release are still
broken.
Maybe, we should open a jira issue to not forget about the problem?
[...]
This should fix it:
http://svn.apache.org/viewvc?rev=413162&
Anton Pevtsov wrote:
Yes, the problem fixed.
But now the library and tests build produces a lot of 4273 warnings
(inconsistent dll linkage).
Is this correct?
Warnings are almost never "correct" :) I haven't done a Windows
build in a while so I guess it might be time for me to fire up
the IDE an
correcting the typos.
Thanks,
Anton Pevtsov
-Original Message-----
From: Martin Sebor [mailto:[EMAIL PROTECTED]
Sent: Friday, June 09, 2006 21:39
To: stdcxx-dev@incubator.apache.org
Subject: Re: svn commit: r412249 - in /incubator/stdcxx/trunk/tests:
include/21.strings.h src/21.strings.c
Martin Sebor wrote:
Anton Pevtsov wrote:
Yes, the problem fixed.
Unfortunately, the fix seems to break MSVC 8 because of all
the nasty hackery that Microsoft introduced into the headers
in this version of the compiler just so they could spit out
their useless deprecation warnings. Sigh
Anton Pevtsov wrote:
Martin, I updated the replace test to exercise the reverse_iterator.
It is here:
http://people.apache.org/~antonp/stdcxx06132006/
I think that if it is ok we might want to make some changes to
StringTestCase and StringTestCaseData (copy constructable?) structures
to create n
Martin Sebor wrote:
Martin Sebor wrote:
Anton Pevtsov wrote:
Yes, the problem fixed.
Unfortunately, the fix seems to break MSVC 8 because of all
the nasty hackery that Microsoft introduced into the headers
in this version of the compiler just so they could spit out
their useless
Anton Pevtsov wrote:
Martin Sebor wrote:
This seems to include the changes for reverse_iterator. Shouldn't
those be implemented separately (and in the driver instead)?
Yes. I committed changes for range overloads in cons test here:
http://svn.apache.org/viewvc?rev=414235&view=
o for Intel C++.
Martin
Thanks,
Anton Pevtsov
-Original Message-
From: Martin Sebor [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 14, 2006 04:50
To: stdcxx-dev@incubator.apache.org
Subject: Re: release configurations (8d, 8s, 12d, 12s) fail to compile
on Windows, MSVC 7.1
Marti
Anton Pevtsov wrote:
Martin Sebor wrote:
[...]
Ditto for Intel C++.
I built using the Intel 9.1 compiler and got several warnings - the
build log (config, library, test driver and one test for example) is
attached.
I am not sure that all these warnings occurred as a result of your fix
Anton Pevtsov wrote:
Martin, here is the fix to this bug:
http://people.apache.org/~antonp/stdcxx06162006/scripts/
Thanks a lot!
Please check it in.
Martin
With best wishes,
Anton Pevtsov
-Original Message-
From: Martin Sebor (JIRA) [mailto:[EMAIL PROTECTED]
Sent: Wednesday
Anton Pevtsov wrote:
The test exercising the string methods begin, end, rbegin, rend, c_str,
data and get_allocator is here:
http://people.apache.org/~antonp/stdcxx06162006/
Thanks! Just a few comments:
If all the hardcoded pairs of strings are the same (as the
c_str_void_test_cases array look
Anton Pevtsov wrote:
Martin, I am working on the test for lib.string.io and there are several
questions:
I'm not surprised ;-) The area of iostreams and locales are in
general less cleanly specified than the rest of the library.
1. Shall we implement an our own locale class to exercise the >
Anton Pevtsov wrote:
[...]
Here is another one possible issue:
As I understand 21.3.7.9, paragraph 4 the os.setstate() should be called
after os.width(0). In stdcxx width(0) is called after the setstate() and
if the exceptions mask is not ios_base::goodbit then width(0) will not
called. The Dink
Anton Pevtsov wrote:
Martin, I have a question about the change in char.cpp. It results in
the following:
1) The strings beginning with '\0' and requiring expand will not be
expanded.
You mean something like "[EMAIL PROTECTED]" or "[EMAIL PROTECTED]"?
2) The strings with '\0' at the end will
Martin Sebor wrote:
Anton Pevtsov wrote:
Martin, I have a question about the change in char.cpp. It results in
the following:
1) The strings beginning with '\0' and requiring expand will not be
expanded.
You mean something like "[EMAIL PROTECTED]" or "[EMAIL PROT
Anton Pevtsov wrote:
The first version of the test with the required changes to 21.string.*
and rw_streambuf.h is here:
http://people.apache.org/~antonp/stdcxx06232006/
Wow, this looks very good! It will need more comments but we can
add those later. I suspect I might be in a good position to s
Anton Pevtsov wrote:
Martin Sebor wrote:
But before committing the rest we need to first settle the issue of
rw_expand().
Martin, in my previous mail I didn't mention that the problem occur when
rw_expand is called from the rw_match function.
Sorry about that. The test which illustrate
Anton Pevtsov wrote:
[...]
The possible fix of the STDCXX-206 and STDCXX-205 is here
http://people.apache.org/~antonp/stdcxx06262006/lib/
It required changes in several places:
[...]
What do you think about this?
I'm still thinking about what the best way to deal with it is
and discussing it
Martin Sebor wrote:
[...]
Hmm. There are two possible interpretations of the third argument
to rw_match():
1. it gives the maximum number of characters to compare (i.e.,
after all directives have been expanded)
2. it denotes the number of characters in the first argument
(i.e., before
ed first string but that would either have to be
hardcoded in each test case requiring changes to all the
TEST macros, or computed. Or am I missing something?
Martin
So I'll do it when the new version of the char.cpp will be ready.
Thanks,
Anton Pevtsov
-Original Message-
From:
sing something?
Martin
So I'll do it when the new version of the char.cpp will be ready.
Thanks,
Anton Pevtsov
-Original Message-
From: Martin Sebor [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 27, 2006 04:40
To: stdcxx-dev@incubator.apache.org
Subject: Re: rw_match() bug
Ma
401 - 500 of 3807 matches
Mail list logo
