BTW, after looking at the implementation I was a bit disappointed to
see two copies of the storage. It seems to nullify one
important reason for using variants (space savings), and it generates
more code than a single-storage version. I know you had some rationale
for
that but I don't
My understanding is that Boost.Config should take care about these issues.
Boost.Test rely on BOOST_HAS_SIGACTION flag. It should not be defined in
case if there is no support for POSIX interfaces. Could you report the value
of that flag in case of compilation failures you are expiriencing.
Hi,
I do not want to start this discussion all over again, but in the reasoning
you presenting I did not find anything new to justify another smart
pointer like component. It's only one simple case of PBSP and I do not see
any reason not to use it.
Gennadiy.
I remember that there are 2 types of separators in boost tokenizer:
returnable and ignorable. Set - as returnable separator, and , as
ignorable. It should give you all the information you need.
Gennadiy.
lattice [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
If we print some pages
Could you please be more specific about which Boost.Test features you
think
should remain and which should be removed or modified? I'm having trouble
relating the discussion to the actual Boost.Test public interface.
Thanks,
--Beman
The only thing I propose to change is to prohibit
There is BOOST_CHECK_PREDICATE
Yes, I know.
My point was that with BOOST_CHECK_EQUAL_NUMBERS() the test library
could output something readable of the form:
numbers x and y are not approximately equal
It could even add to the output something of the form:
according to Pred ;
This
Beman Dawes [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
test_fp_comparisons has been failing for a long time. The issue has to do
with how much tolerance to allow for rounding errors.
The close_at_tolerance algorithm calculates tolerance as follows:
Hi,
I am having problems with subject test with Metrowerks compiler. I was able
to minimize the issue to the following snippet:
#include list
#include iostream
templatetypename T
inline void
print( std::ostream ostr, T const t, long ) { ostr t; }
templatetypename T
inline void
moo(
Daryle Walker [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
While writing some other code, I checked out how some of the macros in
Boost.Test are implemented. The BOOST_CHECK_THROW and
BOOST_CHECK_EXCEPTION macros flag when an intentional exception was
missed and when the
What I meant is that the files contain data specific to your own
programing environment (there are absolute filesystem paths in the 7.1
project files for example). It's the reason why I was suggesting that it
may be a mistake with CVS. If there is no mistake and if the files are
really
* event driven xml file parsing (sax)
I did not really used DOM to much. I may have some comments on SAX though.
Perfunctory look on your interfaces left me wondering: who does it differ
from xerces? Still xmlChar type, tons of virtual functions. We are in modern
C++ world. No need to promote
Hi,
I finally mostly finished first long promised revision for Boost.Test.
Here is the list of major features/updates:
* Major update for documentation
I still think that docs need a lot of work. They incomplete and there are
several pages missing. Also some tutorial material needs to be
Giovanni Bajo [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Hello,
Boost.Test does not currently honor BOOST_DISABLE_WIN32. The attacched
patch
fixes it. Can someone review apply this patch?
Thanks
Giovanni Bajo
Ok. Applied.
BTW, Beman, You recently disabled structured
Regardless, do this: make a copy of one of the status tables, hand change
the entries for the first couple of libs to illustrate what you want,
verify it works with a browser, and send it to me.
Maybe like this.
Gennadiy.
begin 666 Boost Compiler Status Automatic Test.htm
/// START CODE ///
// Boost Unit Test Library:
#include boost/test/unit_test.hpp
#include boost/test/included/test_exec_monitor.hpp
You included test_exec_monitor.
// Individual Components:
// None - just a clean compile would be nice!
using namespace
There are 65 tests in that directory. Multiply that by 7 or 8 compilers,
and it would be a huge additional testing load.
IIRC they all compile-time small tests. There should not be any problems.
Gennadiy.
___
Unsubscribe other changes:
I think the names arguments and options are as good as anything else.
It may be so. But I do not understand how the library use these terms.
Vladimir wrote:
option is (name,value) pair
argument is an command line element which is not option.
These definitions unclear to me. Could you give me
While I don't find the interface proposed by Vladimir to be offensive,
when you get a pile of function arguments of the same type together a
named parameter interface *can* be a help. I don't think I'd use
operator, though. If it's really about readability I'd tend to
sacrifice some
For a command line parser, the decoupling provided by separate
compilation seems to far outweigh the minor benefits of a header-only
implementation. Just my opinions, of course.
We do not need to sacrify decoupling to provide both header based and
offline versions.
Gennadiy.
Daryle Walker [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
In a revamp of the I/O library reviewed a few months ago, I revised the
structure of the test programs to match that given in the Boost.Test
documentation. Is what I have alright? Someone (Beman?) mentioned the
desire
And one important point: there are only three unnamed parameters. There's
a
bunch of other things that can be configured, and they all use *named*
interface:
desc.add_options()
(output, file, output file name).default_value(/tmp/abc)
;
The question arize: Why do you prefer
Consider command line
my_prog --output=/tmp/log input.cpp
Here is the option with name output and value /tmp/log. There's also
argument input.cpp.
1. Why you named namespace progrma_options it in fact you supply both.
2. How could I access argument using high level
OK, I understand your opinion. I'm probably misusing you don't pay for
what
you don't use principle, but I find that 'options_and_argument' class is
important. Sometimes you really don't need typed storage.
Then just use default std::string type for parameter types - you got your
string to
Vladimir Prus [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Gennadiy Rozental wrote:
And one important point: there are only three unnamed parameters.
There's
a
bunch of other things that can be configured, and they all use *named*
interface:
desc.add_options
Hi,
This is not a review of the supplied library. I am not gonna discuss docs
even though they are scarce. I almost don't mention implementation/code/
testing. I just want to express my opinion on design of the library.
Following list is not ordered by importance nor any other order. It just
svertka.driver.cpp(127): error in test_svertka: test {result.begin(),
result.end()} == {result2, ...} failed [-431600044 != -78651042]
I think this message misses one thing: the position where mismatch
occured. If
differing values are printed, it's natural to print position, too.
Eric Friedman [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Gennadiy Rozental wrote:
While I do agree O(1) is better than O(N), I would like to point out
that
it is usable only when the pseudo-variadic template interface is used
(i.e.,
variantT1, T2, ..., TN as opposed
I argue that top-level const type arguments are meaningless in the context
of variant. Given the example you provide:
typedef boost::variantint const, std::string const GlobalParameter;
GlobalParameter input_socket(12345);
input_socket = 54321; // no way to prevent this!!
How come!?
case MAX_WITCH:
visitor( Typelist[MAX_WITCH](storage) );
break;
}
}
Your pseudo-code is misleading. There is no MAX_WHICH available to the
preprocessor when MPL-sequences are given because there is no theoretical
upper limit on the size of a
2. Could type that implements swap() method somehow follow the second
case
road also? For example, could you somehow deduce T* from buffer and swap
it
with local copy of the argument?
Yes, I can look into such optimizations. But as I noted in previous
messages, if I can prevent
templatetypename T
void foo( T const )
{
}
int main()
{
boost::variantint,. v = 5;
// Here I want to pass const reference to integer value of variant to
function foo
// foo( getint( v ) ); - type T is incorrect
foo( ??? );
}
I don't see why
If the issue concerns you this much, you might propose something along the
lines of BOOST_NO_EXCEPTIONS.
That is, you might try: BOOST_NO_RTTI anyone?
- Eric
I did. As a user defined parameter. Terrie made a point that it should be
config parameter cause some embedded compiler indeed does
I think you misunderstand: What I'm arguing is that the usage case you
propose here is itself erroneous. This is *not* an issue of whether I can
implement the behavior. (In fact, I need to do additional work to prohibit
it.)
Let me know if you still disagree.
I disagree. Let say I want to
overview.) This technique is necessary to provide a general guarantee
of strong exception-safety, which in turn is necessary to maintain
a never empty invariant for variant.
What is this invariant? And why is it that important.
The invariant is quite straightforward: any object of
Hi Gennadiy, thanks for the comments. I apologize for my late response.
Hi Eric,
You got me in process of moving to new apartment, so I was offline for a
while.
I will post my comments in separate threads to simplify tracking.
Gennadiy.
___
2. Top level const requirement on bounded types.
It's unreasonable. I should be able to define variant with const
types. It will be as usable as usual constant types are. The only
requirements that we may incur is that if one types is const,
rest should be also.
It's actually not
5. Usage std::type_info for reflection
I don't think we should enforce RTTI for the variant users. We should
be able to postpone the decision on what kind of reflection
information user want till instantiation time.
Please elaborate on this point. FYI, the current variant::type method
3. Copy Constructible/Assignable requirements on bounded types
This only need to be required if variant should have appropriate
feature.
I disagree. As-is, every variant object requires CopyConstructible
bounded types, as it is the only way to construct its content.
Some notes, however.
Also I think we need free function form of value
extraction. In other case it would be difficult to place extract
in context where template parameter is deduced. And check function
is not that important in most cases.
While I am again considering a free function, I'm not sure what
7. Variant size
Unfortunately I was not able to follow exact logic behind usage of 2
different storages. But one thing I know:
sizeof(boost::variantint,std::string) could not be 28.
From what I view it seems that types that are used to construct
storage2 also used when constructed
Hmmm. It works for me. I'm using BOOST_AUTO_UNIT_TEST across several of my
source files without name collisions (after my patch). I'm also using the
GCC
#pragma interface feature, which might make a difference. Pardon my
ignorance, since I'm not very familiar with the auto unit test
There's absolutely no reason I can see to make the exact exception
type depend on the types concerned. Just use a straightforward
class, something along the lines of:
struct bad_lexical_cast : std::exception
{
bad_lexical_cast(
std::type_info const
=== //depot/devel/lib/boost/vendor/boost/test/unit_test_suite.hpp#1 -
/home/green/p4/devel/lib/boost/boost/test/unit_test_suite.hpp
***
*** 267,273
if( name_[0] == '' )
name_.erase( 0, 1 );
! return name_.data();
}
} // namespace detail
---
Does standard require/recomend inline in method declaration? I always
thought it ignored
class A
{
inline void foo();
};
inline void
A::foo()
{
}
Gennadiy
___
Unsubscribe other changes:
Thanx for the patch. I did not forget about it. Applied.
Gennadiy.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Notice the weird misspellings in the error messages. :)
What do you mean?
boolle and intr? :)
Could this be a problem in the unit test framework?
Could be. What should it be?
I wil try to reproduce this locally after 1.30 is out.
Gennadiy
Just curious if anyone's doing something along these lines. A quick
google search on boost turned up only Boost.Test, which (I think?) is
something quite different.
This topic came up several times during last year. Nobody seems to
have reviewable results. I do have full-featured
BOOST_STATIC_ASSERT( is_same list0, result ::value ); // THIS FAILS;
Use
BOOST_STATIC_ASSERT((mpl::equal list0, result ::type::value ));
Gennadiy.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
* [Boost.Test] Request for const fix in unit_test_suite.hpp
Posted 12 Feb 2003. Did this ever get resolved? Gennadiy?
Fixed in second revision.
Gennadiy.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
P.S. Could you, please, clarify for me again what is the purpose of this
tag? How does it related to the fixes I made in trunk after branch is
created?
The tag marks the last trunk revision that has been merged into the
branch, so that when you do a merge to the branch you can always do
1. I committed it in main trunk: cvs commit abc.cpp
2. I tag it with merged_to_RC_whatever tag (? this is not in a procedure
right now)
3. I merge it to the release branch
No, you got 2 and 3 reversed, and you only do the tagging after
switching back to the trunk.
I got it now. May be
It looks pretty explicit to me. If you think it can be improved,
please propose a doc patch.
May be like this. See the patch attached.
Gennadiy.
begin 666 release_procedures.diff
[EMAIL PROTECTED](')E;5AV5?')O8V5D=7)ERYH=T-CT]/3T]/3T]/3T]/3T]
* The Rationale for Array-Based Streams concludes it may have real-life
applications. It would be a bit more satisfying if there was at least one
example of a real-life application.
I second this. Could anybody show an example where array_stream would be
preferable to stringstream.
In other
Hi, Beman
In examples for release procedure you are using: merged_to_1_26_2. While
in Release Procedures for the Release Manager section you are mention:
merged_to_RC_n_n_n. What is correct?
Gennadiy.
P.S. Could you, please, clarify for me again what is the purpose of this
tag? How does it
You couldn't build dlls out of Boost.Test sources on win32 platform yet. Is
there way to explicetly prohibit build of the target in Jamfile for specific
platform?
Gennadiy.
___
Unsubscribe other changes:
Hi,
Here is my a bit late review for the variant library. In spite of several
concerns that I have, I incline to vote to ACCEPT this submission.
Design concerns I would like to be discussed and either accepted or
dismissed. Implementation issues are less important. Rest is mostly
comments.
Here
Hi,
I played today with some links validation software and set it upon
www.boost.org
Here the results for those who is interested.
http://groups.yahoo.com/group/boost/files/BrokenLinksReport.htm
I took care about Boost.Test issues.
Gennadiy.
___
Mutex locking is a simple example of resource management idiom. All
flavors
of resource management are easily implemented in terms of policy based
smart
pointers (don't allow name to confuse you). In this particular case most
probably all that you need is a custom StoragePolicy. Now you
In that fashion it makes sense. But the only smart_ptr that will make
any sense is scoped_ptr. Which will only implement idea #1. As I said my
classes offer far more.
Under smart_ptr I meant policy pased smart pointer, that supply a wide
variaty of ownership policies and allow you to write
Two comments:
1. Does not Boost.Thread already have locking mechanisms
2. IMO any locking mechanisms should be implemented in terms of smart_ptr
Gennadiy.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
If you consider a test suite a test case (which should be how it is, no?),
then yes, that's all I'd need.
Yes. test suite is a test case.
1. Boost.Thread with depend on multithreaded version of Boost.Test. 2.
Boost.Test will try to use minimal/basic part of Boost.Thread
functionality
2. IMO any locking mechanisms should be implemented in terms of
smart_ptr
I don't see the fundamental connection between locking and smart
pointers.
In particular, which smart_ptr are we talking about? shared_ptr [which
may need locking internally for reference count anyway]
or
1. Does not Boost.Thread already have locking mechanisms
The only thing boost threads offer is #1 on my list, that is The ability
to acquire a lock and release it when the object goes out of scope
effectively implemented the Monitor concept. Implementing this idea is
rather easy and
I will try to address 1(without tss) 2 and 4 today.
I committed execution_monitor.cpp with changes that should address above
issues. We may try now recheck how signal handling behave on OpenBSD
Gennadiy.
___
Unsubscribe other changes:
There still are getenv link errors in prg_exec_fail1 and prg_exec_fail2.
I think I've got them fixed. Testing now.
And what is the fix?
prg_exec_fail3.cpp is failing: Assertion(div != 0), line 32.
It what supposed to happend. Important thing is whether the test is aborted
at that moment or
The code never promised to work in multithreaded environment, nor even
to be thread save. It is in my to-do list. Though recent hands in
several situations may require address some of these issues sooner.
What?!? Where's the big, bold disclaimer about that!
It's in to-do section in front
bjam is reporting:
don't know how to make result_report_test.pattern
don't know how to make errors_handling_test.pattern
So it looks like something is wrong with your Jamfile.
I followed Dave A. recommendation and placed them in input section of run
rule.
The above tests expect
However, while the header is there, CW's library doesn't actually
implement the debugging mechanism that this header describes. This is
why you're link does not work -- the code just isn't there.
So Gennadiy's temporary fix is really the permanent fix.
There still are getenv link errors
test_fp_comparisons IS failing on all compilers for now. It shows some
problems with comparison alsorithm. I will take a closer look after
release.
Maybe you could take a quick look sooner? We aren't going to branch for
release until Monday, and the release won't happen for some time
Changing line 64 to:
#elif defined(BOOST_HAS_SIGACTION) !defined(__OpenBSD__)
Does make the tests not hang any more.
Instead it causes them to fail with core dumps, or perhaps that's a
success?
errors_handling_test supposed to cause FPE and crash in case if signal
handling is turned off.
Someone will need to add an SCO specific platform config - I don't have
the
access to the platform, nor do I know how to detect it - but if you can
provide me with the information, or if you just want to go ahead and add
it
then do so.
I will try to look into this. What is the usual procedure
bjam is reporting:
don't know how to make result_report_test.pattern
don't know how to make errors_handling_test.pattern
So it looks like something is wrong with your Jamfile.
I followed Dave A. recommendation and placed them in input section of
run
rule.
The above
* test lib has three tests failing all compilers; at least some of these
passed until recently.
Note that errors_handling_test and results_resport_test failures does not
lead ot any error messages.
So I would recommend to perform clean build of those two.
test_fp_comparisons IS failing on all
sigaction is supported by all gcc versions if the platform has it (and BSD
does).
You right. But, then it looks like it does not work properly, cause
siglongjump causing SIGSEGV.
Maybe we do not want to use sigaction facility with gcc 2.95.3?
Could we change line 64 in execution_monitor.cpp so
I fixed config/test/Jamfile to use proper names of Boost.Test libraries.
How does this thing work in regression testing?
Gennadiy.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Hi, everybody
Today I committed second revision to Boost.Test library. I am not planning
any more code changes in this release. If I have time I will try to reflect
changes made in revision one and two in documentation (Release notes with
changes log will be present in any case). Here is
Hi, everybody
Today I committed second revision to Boost.Test library.
Wow, is that a good idea one day before we branch for release?
I should have done it week ago, but was really sick. Anyway, It does not
contain anything that should break backward compartibility.
Gennadiy.
No, it is some sort of configuration problem.
Look on metrowerks linking errors thread. It about the same issue with
different undefined symbol
There was also compilation error with metrowerks. I fixed it couple hours
ago. Unfortunately I do not have direct access to this compiler so
metrowerks
So, Let introduce one. I need something for coming release.
Done: it's called BOOST_HAS_SIGACTION
John.
Why it doesn't get defined for Visual Age C++ on AIX?
Gennadiy.
___
Unsubscribe other changes:
Sure. Fixed.
Gennadiy.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
If you run bjam with -d2 option, you'll see all the command lines, which
should be enough to find out which libraries are beeing linked.
It appears that I don't really need -d2 to get a linker line. bjam prints ot
togerther with error anyway:
mwld -search -maxerrors 5 -maxwarnings 20 -export
Hi,
Some time ago there was a discussion on how properly identify unix for
selecting proper signal handling algorithm. Here is fragment of John
Maddok's letter:
... currently you have:
// for testing on Win32, GCC thinks it is a unix platform
// TODO: figure out how to tell it is really unix
a. _POSIX_C_SOURCE is not defined
It's probably being overly picky requiring that one to be defined,
strictly
speaking you can't use any POSIX API's unless _POSIX_C_SOURCE has been
defined before the inclusion of any std header - most platforms don't seem
to care though.
b.
It looks to me like the C library is not getting linked into the
executable. There are several possible versions of the C library which
might meet the need (some of them listed in the error messages).
Can you list the libraries that are being linked in? From that I can
probably make a
test-add(BOOST_TEST_CASE(::boost::bind(fn, 1)));
I just tried this and MSVC7 tells me:
test_charset.cpp(50) : error C2664:
'boost::unit_test_framework::test_case
*boost::unit_test_framework::create_test_case(void (__cdecl
*)(void),std::string)' : cannot convert parameter 1 from
1 Need to have language extensions enabled. (for WINNT?)
Do I use any nonstandard language extensions?
No, but code that gets pulled in (WINNT?)does, so the MS project
Properties
requires /Za. This is a minor disadvantage if you like to be 'strict'.
Could you be more specific which
I would like to suggest the addition of the test tool
BOOST_CHECK_NO_THROW to the boost test library. It's purpose should be
obvious from the name and I think it would be quite handy when testing
construction of objects.
Markus
Why would you need that? It's already checked automatically. If
Paul A. Bristow [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
An absolutely invaluable tool.
Perhaps worth documenting for MSVC 7.0 (and probably 6.5?)
1 Need to have language extensions enabled. (for WINNT?)
Do I use any nonstandard language extensions?
Do you want this to be implemented as part of Boost.Test or Boost.Build?
* Test cases/suites need to be defined in a tree hierarchy, where branches
are never run if the parent test doesn't pass.
This could be done in terms of Boost.Test. Not in a current version though.
* These test cases may
I guess it would help if the syntax for all four possibilities
(normal function, templated function, normal function object templated
function object) made it into the Boost.Test documentation.
Syntax is basically the same for all simple (not parameterized tests) cases.
Though I admit
Hi,
I also found it incorrect to keep move semantic in basic template while
was working on my adaptation of SmartPtr. Let's look on auto_ptr for
example. It's basically scoped_ptr with added move semantics. The same need
may arise with almost any SP: one with custom deleted or special checking
You still need to remember something. For example, your library uses ,
to separate elements of std::list... parameter. Can I guess that from
the
options declaration?
It has almost nothing to do with parameter definition. It's details of
argument parsing format. You may though specify it
my_program ( 0, 1) ( 1, 3) (( 0, 1), 15 ), (( 0,1), (7.8) )
This is input of 2 points circle and line. Here chain_lookup_policy
could
be useful.
What if I want C++ expression specified on the command line? Sure, I don't
want make C++ parser operate on command line. Rather, I'd write
Vladimir Prus [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
Gennadiy,
About month ago, while working on Boost.Test issues I was faced with the
need for the more or less full featured command line argument parser. I
recall that you were working on one and
That's a long way of supporting Vladimir's views above. People first need
just command line arguments, then later realize a config file would be
nice. And yes, the transition should be simple and transparent.
--Beman
I do not argue that an ability to support other configuration means could
There's one thing I'm wondering about. If you get an exception in a test,
it
won't show which line caused the exception, only that one has happened
somewhere. In a unit test with 100+ tests, it can be hard to find which
one
caused the exception, so I started to litter the test code with
Robin.Hu [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
Bzip2 is widely spreaded with GNU software. It is available to all *nix
platforms those are available to me, include linux, *bsd, solaris, etc...
IMHO, using tar.bz2 instead of tar.gz is a good idea.
Why
Actually I was hoping you would choose option 3. :-) For me, option 2
just doesn't feel right. And I think it's not in the spirit of the
standard, either. (Implicit conversion from char * to string doesn't
exist, a char * is just a pointer.) I would classify this as
suprising behaviour which
Because none of those; bz2, rar, or ace, will let you do this...
tar zxvf boost-1.29.0.tar.gz
I could not get your point here. Every archiver has it's own command for
unpacking. So what?
Gennadiy.
___
Unsubscribe other changes:
David B. Held [EMAIL PROTECTED] wrote in message
asb9ml$iqi$[EMAIL PROTECTED]">news:asb9ml$iqi$[EMAIL PROTECTED]...
When I'm running a test program, it would be nice to get a usage message
with a -help or -? parameter. That way, I don't have to remember all the
log
level parameters, etc.
1 - 100 of 113 matches
Mail list logo
