RE: [boost] BOOST_MESSAGE
I am using the unit test framework on Solaris 5.8 using workshop 6 I can't get BOOST_MESSAGE to print anything. You need to set a log level to messages. By default it's all_errors. You could do it like this: your program name --log_level=messages If you always want to use above log level you could set an environment variable BOOST_TEST_LOG_LEVEL. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Iterator adaptor question
|| What is the problem adapting pair of iterators to scalar vectors to |produce || an iterator with complex value type? | |The problem is you can hardly adapt a pair. So using iterator_adaptor |(the new class template) does not provide any benefit. | | | Why is that? The whole point in adapting is that you modify some but not all behavior/interface of a thing. There is nothing a pair provides that can be reused so adoption is pointless. There is all that we need so we could create valid iterator. As for how much we will need to overwrite - it still less then writing iterator from scratch. That's why the new version provides iterator_facade and iterator_adaptor. iterator_facade helps with implementing iterators, iterator_adaptor is for adapting iterator like types. | I did not look in depth on new version but I remember that old one | allowed to adapt any source. You needed to do this as the iterator interface implementation was not separated from the actual iterator_adaption. I do not argue which version better fit for the task. I just saying that it could be easily done with old version either. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Iterator adaptor question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rozental, Gennadiy wrote: | What is the problem adapting pair of iterators to scalar vectors to produce | an iterator with complex value type? The problem is you can hardly adapt a pair. So using iterator_adaptor (the new class template) does not provide any benefit. Why is that? I did not look in depth on new version but I remember that old one allowed to adapt any source. For convenience one could've created object generators. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: GUI/GDI template library
Now that the interest for this kind of library has been shown (or not, whatever) could the interested parties please coordinate their efforts using other means than boost mailing list? IIUC this list is for issues with existing code (problems, usage patterns etc) and for submissions that have some code. I do not think that is true. I am already having problems keeping up with the list as is... Set up some kind of filter that dispose of all messages with nonimportant for you topics. Or read it thread based. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Iterator adaptor question
What is the problem adapting pair of iterators to scalar vectors to produce an iterator with complex value type? I am sure both old and new iterator adaptor easily allows it. Gennadiy. -Original Message- From: Neal D. Becker [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 06, 2003 1:31 PM To: [EMAIL PROTECTED] Subject: [boost] Iterator adaptor question Some time back I mentioned I was interested in iterator adaptors to convert between vectors of complex and scalar. I have looked at using the iterator adaptor framework in boost. It appears that it is easy enough to adapt from a complex sequence to pick off either the real or imaginary part, but going the other direction is not feasible? You would need to adapt from a pair of iterators over scalars to output an iterator over complex. Will the new iterator adaptor framework help? ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Iterator adaptor question
1) Since only 1 object can be passed to the iterator adaptor constructor, I had to pass a pair. Use object generators. 2) Distance uses only one of the base iterators. Use minimal distance. 3) iterator_category uses only 1 of the iterators. Use most restrictive category. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: plans for a bugfix release ?
David Abrahams wrote: Beman Dawes [EMAIL PROTECTED] writes: When we released 1.30.0, despite extensive pre-release testing, it went out with several prominent showstopper bugs. Don't you think we'll make the same mistake for 1.31.0? Also, AFAICT 1.30.1 can go out much, much sooner. I agree with Dave here. To me there is another good reason for doing minor releases more frequently. Neither the next major release nor the CVS state is likely to help most of the people who use Boost in their projects. I agree that we should publish patch releases more frequently. But the question here what is the criteria whether the release should be considered patch or next one. In my projects I choose the following strategy: if release does not affect the interface, so that I could simply substitute one shared library with patched one - this is patch release. In other case it's next release. It may be a little different with boost, cause most of the staff in the headers. But the idea should be IMO similar. I guess that there are a lot of projects out there that cannot allow for an interface change in one of the core libs every couple of month. So they really need bugfix only releases if showstopper bugs are found in the last release. We should've publish patch release right after we discovered them. IMO at this point, with all those iterator adaptor changes I would rather made new release. Just my 2c Thomas Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: test_fp_comparisons and rounding errors
This is what BOOST_CHECK_CLOSE is doing basically. Yes, that's the point. What I proposed is that the user can combine the macro with the comparator (I changed the macro name), because the comparison method is often application specific. I suggested to have an absolute error comparator class as a default, but not as a fixed method inside the macro. The problem with any fixed scheme is that it can't be general enough, and the test library is highly general. I'm not sure if any fixed comparison method should be supplied at all. I would choose between my proposal, were specific targets can supply their own comparators, or not having fp comparison at all in the test library itself. I believe Boost.Test need to provide at least some way to check that calculated fP value is as expected. I couldn't use BOOST_EQUAL and do not want to write predicate every time I need to validate floats. I won't be generic enough to cover all the cases. But in majority of the cases it should work. In all other cases you could use BOOST_CHECK_PREDICATE with custom algorithm. It also will show mismatched values (at least try to). For majority of simple cases (not very big, nor very small values) they should behave similarly. For edge cases relative error comparison produces better results IMO No. It is not a matter of value magnitude or edge/non-edge cases. It is a matter of the number and type of operations performed yielding the values to be compared. This is why the best method is highly domain specific. Tolerance is indeed highly domain specific. And I do not force you with how to choose one. As for what is better fit in more cases absolute vs. relative comparison, I believe it's second. Could you show me an example when relative error comparison isn't correct while absolute is? While there many example of reverse situation. Most of the references I have on FP values comparison recommends to use relative errors either. Fernando Cacciola Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: test_fp_comparisons and rounding errors
Do I understand correctly that BOOST_CHECK_CLOSE(v1, v2, 2. * std::numeric_limits::epsilon() ); would check that the absolute difference between v1 and v2 is not more than two eps? Paul No. BOOST_CHECK_CLOSE performs relative errors comparison. See http://www.boost.org/libs/test/doc/floating_point_comparison.htm (Ignore part that tries to calculate the tolerance based on number of rounding errors) Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: test_fp_comparisons and rounding errors
A half-way solution is to have something like: BOOST_CHECK_EQUAL_NUMBERS(x,y,IsEqual) and let users specify their own Preciates. There is BOOST_CHECK_PREDICATE By default, the Test library could provide a straight-forward ABSOLUTE-ERROR comparator: By default, the Test library provides relative error comparator, which is according to my understanding is more correct. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] test_fp_comparisons and rounding errors
Above form wouldn't should mismatched values and this is most important. I meant: Above form wouldn't *show* mismatched values and this is most important. Gennadiy. - ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] vc6 + stlport + boost/unit_test.hpp
Hello, I neep help integrating STLport 4.5.3 with Microsoft Visual C++6.0 SP5 and the unit test framework from boost(1.29). Everything seems fine when I use vc6 with STLport alone but when I try to use it in a test environment I get memory corruption. (It compiles and links fine). 1. Could you provide a small example so I could replicate the issue here? 2. Did you try to debug it? Where does it fail? 3. Try to use Boost.Test that comes with boost 1.30.0. Does it help? I was using sucessfully the Unit test Frameowrk in above confguration. I need more hints to tackle the issue. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] [test] BOOST_CHECK_EQUAL_COLLECTIONS and chars
I will see what could be done. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] test_tools_test metrowerks failure
-Original Message-
From: Peter Dimov [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 18, 2003 6:43 AM
To: Boost mailing list
Subject: Re: [boost] test_tools_test Metrowerks failure
Gennadiy Rozental wrote:
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( std::ostream ostr, T const t ) { print( ostr, t, 0 ); }
inline void
print( std::ostream ostr, std::listint const t, int ) {}
void foo()
{
std::listint lst;
print( std::cout, lst, 0 ); //1
moo( std::cout, lst ); //2
}
Line 1 compile successfully, while line 2 chokes.
Any Ideas?
Yes, the code is broken. moo doesn't see the second overload.
Templates do argument-dependent lookup from the point of
instantiation, and since the only namespace associated with
the 'print(ostr, t, 0)' call is 'std', the second print is
not found.
All above symbols in fact are in a some namespace. It does not have a
difference (if that what you mean)
You need to move it before the definition of moo
(or place it in std:: which is oddly evil but right.)
No. this wouldn't work for me.
In fact I found the solution (I think):
#include list
#include iostream
/
// Library code
templatetypename T
struct printer {
void
operator()( std::ostream ostr, T const t )
{ ostr t; }
};
templatetypename T
inline void
moo( std::ostream ostr, T const t ) { printerT()( ostr, t ); }
/
// Users specialization
template
struct printerstd::listint {
void
operator()( std::ostream ostr, std::listint const t )
{}
};
/
// Usage code
void foo()
{
std::listint lst;
moo( std::cout, lst ); //2
}
Above works with online Cameau. Seems strange that PS and overloading works
different.
Gennadiy.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Some comments on the boost test library documentation.
Thanx, applied. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Test Tool Proposal (test_tools.hpp)
The situation is that I have a consice description of test cases (a vector of C structures) and a function which iterates over that vector, doing BOOST_CHECK in some places. If I place a breakpoint on the failed BOOST_CHECK, then that breakpoint will trigger many times before the actual error happens. Addressed. Check coming revision message. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Little bug in unit_test_result.cpp
Both applied. Thanks. Though CLA support is about to be reworked anyway. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] [test] BOOST_CHECK_THROW proposal
Hello, I'm just using BOOST_CHECK_THROW tool. It works ok, but in addition to exception type I'd like to test the value of 'what()', just to be sure. Is there any way. Would it be possible to add another tool, which checks both type and 'what()' content? Addressed. Check BOOST_CHECK_EXCEPTION tool in a coming revision message. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: CLA/Config file library opinion
2. Layered design.
IMO All of my
concerns are unfortunate consequences of the way you designed your
library. IMO there should be one typed storage for the parsed
arguments
(instead of 3 like you have) linked with formal parameters
description.
You are not correct. There are two storage mechanism for parsed data.
First
('options_and_arguments') stores *only* strings. Second
('variables_map')
stores typed values. So, there's one typed storage.
1. You store something inside class cmdline
2. You store strings in options_and_arguments
3. You store typed values in variables_map
In my opinion 2 places are redundant. You should only have one.
Plus second layer managing composition of parameter originated by
different sources.
That's 'variables_map'.
But variables map is part of first layer, it's store typed arguments. And it
almost
does not have any functionality I expect to see on this second layer
dedicated to combinind parameters from different sources.
b. Force same style for all parameters in command line (I could
not
define /h --my_long_param)
Do you need it in practice?
Why not. Maybe different modules require parameters in different
style.
I feel this to be artifical example, and would not be surprised if no
user
of program_options will ever want it. And if it wants... custom parsers
can be used.
But this is part of functionaly you supply out of the box. And now i need ot
rewrite it.
You keep repeating: use custom parser. I wonder why would I need this
framework then.
desc.add_options()
// first argument is options name
// second argument is parameter name
// third argument is description
(output, file, output file)
;
This means that one comment line is added for first argument, and
then
you can very conveniently specify option name.
Poor maintenance programmer looked on this code and spread hands
puzzled:
What is option name and what is parameter name Which one should I
use
to identify argument? Where the value assigned? What is default value?
Sorry, but this kind of questions can be answered only in docs.
Sorry. But this is not good enough for me.
In my terms above would look like this:
parameterstd::string( output )
place_to( output_file_name )
default_value( /tmp/abc )
description( output file name )
You do not need to know anything in addition about how parser works.
Moreover it's unifies and easily extendable to adopt different modifers.
class cmdline access methods:
option_name()
option_index()
raw_option_name();
option_value();
option_values();
argument();
arguments();
You obviously struggle from need to provide on one hand container
interface, on the other iterator one.
Plus instead of N methods returning
properties of option there should be one that returns foe example
'option'
structure.
... which 'option' structure would contain the same set of methods?
Let's
consider the needs of 'cmdline' clients. You have
cmdline cmd();
while(++cmd) {
if (cmd.at_option()) {
...
}
}
With iterators, that would become
for(cmdline_iterator i(...), e; i != e; ++i) {
if (i-is_option()) {
Wait! Again, what's 'value_type'. Some imaginary 'option_or_argument'
class?
boost::variant? boost::any? Yep, that would be an interator, but you
gain
nothing. It will be only input iterator, and with such a specialized
'value_type', that to use that iterator, you need to known that you're
dealing with command line --- there's no place for genericity.
I'd probably buy your argument if you'd say that one can devise class
'option' and make command line parser, config file parser and something
else parser iterator, with 'option' as the value type. That would be
nice,
but it can't be done. cmdline has addition 'raw_option_name' member
function, and config_file cannot return arguments. The interfaces are a
bit
different.
In my design I provide rnadom access iterator to the storage of parsed
arguments of
type cla::argument. And I could use whatever generic algorithm I like with
it.
Why does anybody need raw_option_name()?
Also it's beyond my understanding why we need at_option, at_argument. May be
it's because I still could not get what meaning you use for these terms in
this context.
I parsed argc/argv, stored typed argument. Now I only need ot get the value
out of argument I identifued somehow (by name, or index, or order -
whatever)
my_prog --service name=Repository ...
Here parameter name is service name, separator is string =, value
is
'Repository'.
Nope. It's not supported by cmdline class.
And you would not be able to support it within the bounds of your design.
9. Multi-pass parsing support
If that's not sufficient (which I doubt), I can think of a more general
solution. Basically, 'cmdline' class can allow unregistered options.
With
a bit of tweaking, it can
RE: [boost] Re: MSVC++ 6.0 compiler errors with 1.30.0 (mostlylexical_cast.hpp)
Even if none of the above looks sound for you I still argue that lexical_cast *should not force* inclusion of typeinfo. It's not inconvinience - it's showstopper. It's much more important than providing specific type info. In majority of the cases one knows it anyway. Kevlin Gennadiy. So. Are we gonna stuck with typeinfo in lexical_cast? Could we have at least some discussion about this? Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: patch: BOOST_AUTO_UNIT_TEST in auto_unit_test.hpp
In your original e-mail, you asked for a solution to the multiple function definition error. Wouldn't using a mechanism similar to cpp_main work? Ie, put the init_unit_test_suite() definition in a CPP file that only gets included once, such as: #include boost/test/included/auto_unit_test.hpp Which in turn includes #include libs/test/src/auto_unit_test.cpp You mean guarded by some kind of macro? I will think more about multi - module support. I still stand by my original patch submission. Although, as you pointed out, for the vast majority of users, it is of no value. However, it worked for me, and it is likely to help others in the future. I will consider this. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: MSVC++ 6.0 compiler errors with 1.30.0 (mostlyle xical_cast.hpp)
My contribution to the discussion is that I don't think supporting C++ language subsets is worth complicating the interface in the way you propose. Maybe lexical_castT*(whatever) should return 0 on failure and that should be enough for those who can't handle the exceptions we want to throw... though I don't know how (or if) that interacts with things like char const*. It's not that I could not handle the exception (exception-less interface is another topic that should be discussed separately). See my other post on consequences of including of typeinfo. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: MSVC++ 6.0 compiler errors with 1.30.0 (mostlylexical_cast.hpp)
I'd certainly be open to make the type_info part optional. A question is how to do it. Using policies may complicate the interface, and from earlier discussions, and also from the earlier Future directions part of the docs, it turned out that adding new parameters weren't deemed acceptable (due to it no longer looking like a cast in that case). That's is not exactly true since third parameter will have a default value. So in default case you wont see a difference. Another way may be a macro. However, as has been mentioned in this thread, it appears that the config macros aren't geared for macros with optional exclusion of RTTI. No. this has nothing to do with config Then one might have a lexical_cast specific macro for it, like BOOST_LEXICAL_CAST_USE_RTTI, like you suggested. We may need this macro even policy based solution would be chosen (only for convinience). See my previos post And again if I am right and RTTI has runtime overhead whatever decision we will make I prefer not to force typeinfo inclusion. User has to have an option this way or another. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: MSVC++ 6.0 compiler errors with 1.30.0 (mostlyle xical_cast.hpp)
No, I am explicitly saying that if you want to avoid typeinfo maybe you should also be forced to compromise and avoid exceptions too. I think that would have the least negative impact on the design and I like the trade-off it implies. This trade-in is based on assumption that If I do not want RTTI runtime overhead I would not want exception one also. But the thing is that I am not using lexical_cast in performance critical parts of application and would and still prefer in most cases exception-based interface without RTTI overhead that affects whole program. Almost the only case when I have a need for namely exception-less interface is the need for the predicate is_lexical_convertible. It more convenient that lexical cast wrapped in try/catch clauses. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: io operations for stl containers?
I am afraid boost/io/format will be confusing in a sight of presence of Boost.Format. I understand. Well, it's in a different namespace. I do not know why BTW. But even if it stays this way, I easily see a newbie looking for Boost.Format staff in your headers and vise-vesa The directories follow the namespaces, so it has std and boost. STL is only a subset of the standard library, so also for that reason, I think std would be more appropriate. OK. This should be quite easy to add. The latter style is also used in Reece Dunn's list manipulator, which also deals with output for sequences. That would be great. I don't have that much practice with it, but I've found myself that I don't have a problem remembering which parameter is what, in the 3+2 optional parameter list. Lack of verbosity may be considered one of the advantages over writing explicit output code. That is not the problem for the developer - when you actively working with library. But may be an issue for maintainer. Even if it's the same person. Let say you returns to the application written year ago and never used this formatting library meanwhile. Then I am afraid formatmap(,,) could be a bit confusing. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: MSVC++ 6.0 compiler errors with 1.30.0 (mostlylexical_cast.hpp)
Having a lexical_cast-specific macro will just cover that component, while the same issue could occur with another library, unless a Boost-wide configuration macro is used. I am convinced. Moreover I know at least 1 more libraries that will need such configuration - Serialization. Gennnadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] patch: BOOST_AUTO_UNIT_TEST in auto_unit_test.hpp
The new (Boost 1.30.0) BOOST_AUTO_UNIT_TEST macro appends the current file line number to the generated function name. This can cause name collisions across source files. My patch appends the function name. The function name has global visibility, so it should be unique. BOOST_AUTO_UNIT_TEST couldn't work with multiple source files anyway, since header supply init function and you could not include it twice in separate modules. If you have solution that solve all the issues with multiple modules I will be happy to discuss it. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: 1.30.0 release postmortem
I added that to Boost.Python, FWIW. Date/Time and Test have it also. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] RPMS?
Yes, I'd like to see that discussion restarted. The Boost Install list would be the place to hold it. While we on topic: why don't we have references to these minor lists anywere. I could not find it not on main site, nor on lists.boost.org (which I presume should mention all lists related to boost)? Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Boost version 1.30.0 released
Date-Time Change History is missing It isn't in CVS either. And if it isn't in CVS, it doesn't go in the release. The release is really just an export of CVS as of the release tag. Nothing gets added, nothing gets subtracted. --Beman My point is: shouldn't we check it before release, so that library authors will take care about it. It least links on front page. Didn't we have an utility for that? I also posted some time ago broken link report on boost.org made by some free utility I found online. It's quite a list. I may run it again today. Would it be usefull for anybody? Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] call_traitsint::value_type
The way call_traits is currently implemented, call_traitsint::value_type is an int, not an int. Maybe it's due to lack of partial specialization. What compiler are you using? Without PTS y oucould not deduce int from int. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: RC_1_30_0: minor patch:boost/test/detail/wrap_stringstream.hpp
Not all^H^H^H^H^H^H^H^HNo compilers are perfectly standard-compliant. Ih this case I would not want to make this change. After all it's only warning. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: RC_1_30_0 still broken -- More lexical_cast
lexical_cast_test.cpp(105): error in test_conversion_to_intr: exception boost::bad_lexical_cast is expected lexical_cast_test.cpp(111): error in test_conversion_to_intr: exception boost::bad_lexical_cast is expected lexical_cast_test.cpp(147): error in test_conversion_to_boolle: exception boost::bad_lexical_cast is expected Notice the weird misspellings in the error messages. :) What do you mean? Also these three tests, like MSVC 6, concerns tests where it doesn't throw when it's supposed to: BOOST_CHECK_THROW(lexical_castint( 123), boost::bad_lexical_cast); BOOST_CHECK_THROW(lexical_castint(std::string( 123)), boost::bad_lexical_cast); BOOST_CHECK_THROW(lexical_castbool(123), boost::bad_lexical_cast); If these are omitted for g++ 2.95.x, all tests pass for that compiler. However, as it compiles without errors on both MSVC 6 and g++ 2.95.x, maybe one shouldn't have any BOOST_WORKAROUND's in the test code? That will make it show up as failing on MSVC 6 and g++ 2.95.x, even though it passes almost all the enabled tests on both. You could use expected failures feature of Boost.Test Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Variant Review: variant iterators
1. I found this name a bit misleading. At first I though that it some king of iteration through variant types 2. From quick glance on your code it seems that visit_helper class unnessesarilly parameterized with T0 and T1. Removing this parameterization (Use member templates instead) should make your code more simple. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] coding style
in favor of 80-column text is just that So I wondered what the general opinion of boost developers is on this issue, I am in favor of 72 column lines myself. This allows me to have three comfortable columns of code on the screen at once. This is namely the reason why I would prefer longer lines. On majority on modern monitors 80-column text fit to left 1/3 of monitor space, leaving 2/3 blank. From idiological prospective you won't find too many reasons to defend 80-column limitation. We tend to use more and more explicit namespace specifications, a lot of template parameters, effectively making even simple assignment to spread on multiple lines (and less readable) would you stick to 80-column. Unless you try to put several statements on the same line, I prefer to see it long not separated. On the other hand, I admit that there are still as lot of people using vi through terminal connection. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] HTML documentation imported into 1.30.0
There are still a lot of people who use dial-up lines and have no viable alternative. We need to limit the Boost distribution to core files and put the other stuff elsewhere. --Beman I believe that sooner or later we will be forced to prepare per-library download. It's quite a work, but should be doable based on lib dependency graph. We may prepare also a core module with most widely used components (for example the one that referred to more that N times). It should minimize number of different modules. So To install library L one need ot download L specific module plus core one. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Variant Library Review
Hi, Since I did not see a response, I would like to post this reminder to make sure that authors did not miss my review and all issues brought are discussed before the library is added to the boost main trunk. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: resource manager naming
1. resource Let me repeat myself: resource_manager is never(almost) the RESOURCE itself. It only managing code. This name would be really misleading. Also managed part is not assumed. FILE is the resource but it is not managed. 2. managed Name will be very unclear in most cases, cause the name of the policies would not be file or handle: managedarray_storage_policy,shared_ownerwship_policy - what is it? What is it manage? 3. releaser Too specific. It is reasonable name for only small part of resource_manager applications. For example resource_manager could be used to just log usage of the resource - how does it make it releaser? 4. proxy This name is too generic and is used in C++ in much more wide sense. 5. resource_manager (resource_mngr) May be the most close to the essence of the concept. But 6. smart_ptr a) As Peter Dimov remarked for majority of non native speakers will sound as good as resource_manager b) idiomatic - IOW Smart Pointer idiom is well established (We are not consider to name component that perform garbage collection - unused_memory_releaser, though it may closer reflect the essence and sound better for native speaker) c) unless somebody show how resource_manager is different from smart_ptr they will be two synonymous to the same component. So. Do we still want to fight about best name for non existent component? Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: resource manager naming
wrap/wrapper This is another name for the proxy. And It has the same problem - too generic. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: smart_ptr vs smart_resource
This is an excellent point. One doesn't go looking for a class named smart_ptr or a library named Boost.SmartPointer when looking to manage the lifetime of some arbitrary resource. When one uses pointers, it makes sense. I would be searching namely for smart_ptr. I know that smart pointer is the name for the resource management idiom. It is a shame for things to simply be the way that they are simply because they started out from a specific beginning... History always has a way of biting us. In this case, we are creating something brand new in Boost. There isn't a PBSP in boost. Therefore, if it is a manifestation of a SmartResource concept or is implemented in terms of a smart_resource class isn't as important as the recognition that it is a special case of the more abstract concept. There can still be a smart_ptr class, even if there's a smart_resource class. Both may be separate manifestations, possibly sharing some implementation details, of a SmartResource concept. Equally plausible, smart_ptr could be implemented in terms of smart_resource somehow (derivation, aggregation, whatever). This all would make sense if you could find at least 10 differences between smart resource and smart pointer. Names are important. Witness the recent discussion about whether pointers are resources, refer to resources, or may refer to resources. Words convey meaning. The wrong words confuse. The right words clarify. The same is true for names. Yes, one can learn that smart_ptr means resource manager for which pointer semantics may be appropriate. But, far better is to have smart_resource and smart_ptr as separate classes. The latter provides a superset of the behavior of the former, but the former may be precisely what's needed in a given context. In general I agree that names are important. In general, but not in this particular case. If names are so important for you here, why do you try to use the name smart resource? What is smart here? May be we should use clever or cunning or wise? And what word resource is doing here? It almost never the resource itself, but the manager code for some resource (it may not even hold reference to the resource itself inside). As I sad before IMO most close name would be resource_manager. But I still do not see a reason in introducing new terms, while already exist well established idiom with name smart pointer Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] smart_ptr vs smart_resource
Well the problem I see is that we are using an entity with pointer written all over it (the name especially, but also the primary semantics). Surely managing general resources according to RAII principles is a more general concept than managing pointers to objects? At the very least there should be a smart resource concept, perhaps embodied in a shared_resource template or, better still, a policy-based smart_resource. shared_ptr/ smart_ptr may then be specialisations or instantiations of these. I have argued previously that these concepts should be kept separate such that smart_resource is a parallel concept to smart_ptr, but recently I am inclined to agree that there is a relationship. However many (most?) of the smart_ptr proponents seem to favour assimilating the smart resource concept into smart_ptr itself! 1. It's all only word games. smart_ptr does not really *point* to resource, or *refer* to the resource. In essence it MANAGE the resource. The way it point/refer to the resource is secondary (it may be c++ pointer, c++ reference, some kind of handle and so on). So the best name may be smart_manager, or even smart_resource_maanger. But I would prefer existent name. It's well esteblished idiom: you say smart pointer - one understand that we are talking about resource management. 2. As for the difference in semantics between generic smart_resource and smart_prt, I argue that once you start implementing generic all purpose framework for smart resource management you will end up with the same semantics as smart_ptr has (there may be some minor differencies with comparison operators) Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: smart_ptr vs smart_resource
-Original Message- From: Phil Nash [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 20, 2003 1:13 PM To: Boost mailing list Subject: Re: [boost] Re: smart_ptr vs smart_resource [Anthony Williams] On Windows, for example, you can use GlobalAlloc to allocate some memory, and you get an HGLOBAL back --- a handle to the memory. You need to call GlobalLock with that handle to get a pointer to the memory which you can actually use. The resource manager therefore needs to keep track of the handle, rather than the pointer (which may be different after different calls to GlobalLock, if there has been an intervening GlobalUnlock). Indeed, the pointer to the locked memory is essentially a separate resource, acquired with GlobalLock() and released with GlobalUnlock. It would be sensible to be able to use the same framework for both the handle and the pointer. This sounds like a perfect case where using a smart_PTR would be very confusing, maybe dangerously so! The only place where you will see usage of the name smart_ptr is somewhere deep in library code: typedef smart_ptr ... GlobalMemoryHandler; After that you will use non-confusing name GlobalMemoryHandler. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: smart_ptr vs smart_resource
The only place where you will see usage of the name smart_ptr is somewhere deep in library code: typedef smart_ptr ... GlobalMemoryHandler; After that you will use non-confusing name GlobalMemoryHandler. It may work out that way in this case - but why not make the name non-confusing in the first place? It's not confusing to me. You appear here to concede that it *is* confusing. No. Imeant that *even* it is confusing for *you*, you still will see it only in one place. We are talking about smart_ptr and a potential smart_resource concept - not GloalMemoryHandler - that was just an example of where the naming becomes particularly confusing - whether it is buried deep in library code or not. This is an example of most wide IMO usage of smart_ptr framework: 1. you define custom policy 2. typedef your own type with correct name 3. Enjoy both correct name and flexible framework I still have yet to hear why you do not like the idea of putting these concepts in their appropriate order? I keep repeating that I do not see a difference in concepts. IOW IMO there is only one concept: resource management that is impleemented in framework named smart_ptr Regards, Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Regression progress; Win32
I think this is just a mistake in Gennadiy's build for Win32. On Win32, a DLL (boost_prg_exec_monitor.dll) cannot link to a symbol in an executable, period. To make this work, the user has to supply a DLL containing cpp_main. Shared libraries build indeed does not work on win32 platform yet. But, to my knowledge it never requested during regresion test build. How would it work for Beman in other case? Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Formal review or Variant Library (Ed B.)
Eric Friedman wrote: The area would be helped by renaming extract to access. I tend to agree the name is confusing. So shall we call it boost::access? Input? what about get_value? Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] bjam on SCO
With the latest CVS... cd BOOST_ROOT/tools/build/jam_src sh ./build.sh 1. This produce an error stating that whence is not accessible. whence seems to be Korn shell utility. SO now I am using ksh ./build.sh 2. Almost zero compilation errors but one: pwd.c: In function `pwd': pwd.c:17: `PATH_MAX' undeclared (first use in this function) PATH_MAX supposed to be pulled in from limits.h. Here what I found in /usr/include/limits.h /* * It is arguable whether these should be defined * even in _IBCS2 mode since the defintions are * WRONG on recent SCO OS's and pathconf should * be used instead */ #ifdef _IBCS2 #define LINK_MAX 1000 #define PATH_MAX 256 #define PIPE_BUF 5120 #endif /* _IBCS2 */ After I added _IBCS2 to build.sh and Jamfile I was able to compile and link usable executable. Though it behave a little bit strance. Every time I am using it, it produces following output: boost_home/boost/tools/build/allyourbase.jam:567: in Cc-platform-specifics warning: unknown rule CcMv boost_home/boost/tools/build/allyourbase.jam:620: in C++ boost_home/boost/tools/build/allyourbase.jam:1089: in Object boost_home/boost/tools/build/allyourbase.jam:1154: in Objects boost_home/boost/tools/build/boost-base.jam:99: in library-file boost_home/boost/tools/build/boost-base.jam:1791: in subvariant-target boost_home/boost/tools/build/boost-base.jam:1548: in link-libraries boost_home/boost/tools/build/boost-base.jam:1780: in subvariant-target boost_home/boost/tools/build/boost-base.jam:1867: in main-target boost_home/boost/tools/build/boost-base.jam:1338: in declare-local-target boost_home/boost/tools/build/testing.jam:40: in boost-test boost_home/boost/tools/build/testing.jam:384: in run-fail Jamfile:12: in test-btl-lib Jamfile:19: in load-jamfiles boost_home/boost/tools/build/bootstrap.jam:15: in boost-build boost_home/boost/boost-build.jam:17: in module scope boost_home/boost/tools/build/allyourbase.jam:567: in Cc-platform-specifics warning: unknown rule CcMv boost_home/boost/tools/build/allyourbase.jam:620: in C++ boost_home/boost/tools/build/allyourbase.jam:1089: in Object boost_home/boost/tools/build/allyourbase.jam:1154: in Objects boost_home/boost/tools/build/boost-base.jam:99: in library-file boost_home/boost/tools/build/boost-base.jam:1791: in subvariant-target boost_home/boost/tools/build/boost-base.jam:1548: in link-libraries boost_home/boost/tools/build/boost-base.jam:1780: in subvariant-target boost_home/boost/tools/build/boost-base.jam:1867: in main-target boost_home/boost/tools/build/boost-base.jam:1338: in declare-local-target boost_home/boost/tools/build/testing.jam:40: in boost-test boost_home/boost/tools/build/testing.jam:384: in run-fail Jamfile:12: in test-btl-lib Jamfile:19: in load-jamfiles boost_home/boost/tools/build/bootstrap.jam:15: in boost-build boost_home/boost/boost-build.jam:17: in module scope boost_home/boost/tools/build/allyourbase.jam:567: in Cc-platform-specifics warning: unknown rule CcMv boost_home/boost/tools/build/allyourbase.jam:620: in C++ boost_home/boost/tools/build/allyourbase.jam:1089: in Object boost_home/boost/tools/build/allyourbase.jam:1154: in Objects boost_home/boost/tools/build/boost-base.jam:107: in executable-file boost_home/boost/tools/build/testing.jam:285: in run-test boost_home/boost/tools/build/testing.jam:209: in build-test boost_home/boost/tools/build/boost-base.jam:1791: in subvariant-target boost_home/boost/tools/build/boost-base.jam:1867: in main-target boost_home/boost/tools/build/boost-base.jam:1338: in declare-local-target boost_home/boost/tools/build/testing.jam:40: in boost-test boost_home/boost/tools/build/testing.jam:384: in run-fail Jamfile:12: in test-btl-lib Jamfile:19: in load-jamfiles and so on for about 600 lines ...found 980 targets... ...updating 11 targets... And then it works as expected. More details are in the BOOST_ROOT/tools/build/jam_src/readme.html This one does not have anything about building jam. Or I missing it? If I will be able ot address above issues I could publish it on sourceforge. Any help? Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Exception catching in execution_monitor.cpp
Maybe I should do the factorization and put it in the sandbox or
boost::detail...
Looking forward to see that. Could you, please, let me know when you done or
if you need my help?
optimization crop up). This is not an idiom that's been
well-exercised in compiler vendors' test suites, it seems.
Still, what about conformance to standard?
What about it?
Does | try { throw; } | idiom supposed to work according ot standard?
Gennadiy
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] SCO config
Here what I getting from config_info compiled with gcc 3.2 GNU C++ version 3.2.1 __cplusplus =1 __STDC__=1 _WCHAR_T [no value] _WCHAR_T_DEFINED [no value] __GNUC__=3 __GNUC_MINOR__ =2 __GNUG__=3 __VERSION__ =3.2.1 __REGISTER_PREFIX__ [no value] __USER_LABEL_PREFIX__[no value] __EXCEPTIONS=1 unix=1 __i386__=1 __unix =1 __i386 =1 i386=1 _WCHAR_T [no value] __STDC_HOSTED__ =1 * GNU libstdc++ version 20021119 __GLIBCPP__ =20021119 _GLIBCPP_VERSION=3.2.1 * Detected Platform: Generic Unix Type char is signed Type wchar_t is signed byte order for type short =0 8 byte order for type int =0 8 16 24 byte order for type long=0 8 16 24 sizeof(wchar_t) =4 sizeof(short) =2 sizeof(int) =4 sizeof(long)=4 sizeof(float) =4 sizeof(double) =8 sizeof(long double) =12 CHAR_BIT=8 CHAR_MAX=127 SHRT_MAX=32767 INT_MAX =2147483647 LONG_MAX=2147483647L LONG_LONG_MAX =9223372036854775807LL _POSIX_FSYNC=1 _POSIX_JOB_CONTROL =1 _POSIX_MAPPED_FILES =1 _POSIX_SAVED_IDS=1 _POSIX_VDISABLE =(255) _POSIX_VERSION =199009L _XOPEN_UNIX =1 _XOPEN_VERSION =4 * Boost version 103000 BOOST_HAS_DIRENT_H [no value] BOOST_HAS_LONG_LONG [no value] BOOST_HAS_NL_TYPES_H [no value] BOOST_HAS_UNISTD_H [no value] BOOST_MSVC6_MEMBER_TEMPLATES [no value] BOOST_NESTED_TEMPLATE =template BOOST_NO_CWCHAR [no value] BOOST_NO_CWCTYPE [no value] BOOST_NO_HASH[no value] BOOST_NO_MS_INT64_NUMERIC_LIMITS [no value] BOOST_NO_SLIST [no value] BOOST_NO_STD_WSTREAMBUF [no value] BOOST_NO_STD_WSTRING [no value] BOOST_NO_SWPRINTF[no value] BOOST_STD_EXTENSION_NAMESPACE =std One thing that bother me is the absence of BOOST_HAS_SIGACTION. I checked and it seems that my sigaction-based signlal handling algorithm working properly on this configuration, so I do not see a reasons why we could not have above variable defined. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Exception catching in execution_monitor.cpp
I've encountered a problem with exceptions in boost/test:
Our project uses a base class for all our exceptions which
cannot derive
from std::exception.
If such an exception is thrown, the message:
Exception in ...: unknown type
is printed out, which is not very helpful in locating the problem.
Is there a way to specify an exception handler, which can
catch our
exceptions and print something more useful?.
I could do something along following lines:
#include iostream
using namespace std;
void
unknown_exception_handler()
{
try {
throw;
}
catch( int i ) {
cout int caught\n;
}
}
int main()
{
try {
throw 1;
}
catch( ... ) {
try {
unknown_exception_handler();
} catch( ... ) {
cout unknown exception\n;
}
}
}
and provide a way to configure unknown_exception_handler.
Dave, do you have something different in mind?
Gennadiy.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Exception catching in execution_monitor.cpp
I could do something along following lines:
#include iostream
using namespace std;
void
unknown_exception_handler()
{
try {
throw;
}
catch( int i ) {
cout int caught\n;
}
}
int main()
{
try {
throw 1;
}
catch( ... ) {
try {
unknown_exception_handler();
} catch( ... ) {
cout unknown exception\n;
}
}
}
and provide a way to configure unknown_exception_handler.
Dave, do you have something different in mind?
Yes; check out
http://www.boost.org/libs/python/doc/v2/exception_translator.html
This allows multiple independently registered exception handlers.
Whether or not that's overkill for your purposes is another matter.
If I understand the code properly, you proposing something along the
following lines:
struct exception_handler {
exception_handler( exception_handler* next = 0 ) : m_next( next ) {}
virtual ~exception_handler() {}
virtual void run( test_case, test_case_method ) = 0;
boost::scoped_ptrexception_handler m_next;
};
templatetypename Exception, typename Translator
struct concreate_exception_handler :
{
concreate_exception_handler( Translator tr, exception_handler next = 0 )
: exception_handler( next ), m_translator( tr ) {}
virtual void run( test_case, test_case_method )
{
try {
if( m_next )
m_next-run( test_case, test_case_method );
else
test_case-*test_case_method();
}
catch(Exception const e) {
m_translator( e );
}
}
Translator m_translator;
};
Now unit test monitor could have member boost::scoped_ptrexception_handler
m_eh and following logic
a) in function
if( m_eh )
m_eh-handle( test_case, method );
else
test_case-*method()
b) add somehow register method
templatetypename Exception, typename Translator
void register_exception_handler( Translator tr )
{
m_eh = new concreate_exception_handlerException,Translator( m_eh );
}
It seems a little bit too complex in comparison with my solution, though
implementable.
note however that the try { throw; } idiom breaks on many popular
compilers that are still in use, which is why my code doesn't use it.
What standard says about it?
I just checked. MSVC6, bcc 5.5.1, gcc 2.95, gcc 3.2, SunPro 4.2 works as
expected. What compilers do I really need to bother about?
Gennadiy.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] OpenBSD regression, hanging tests!
Hangs on both GCC 2.95.3 and 3.2: test / errors_handling_test... http://boost.sourceforge.net/regression-logs/cs-OpenBSD-links. html#errors_handling_test%20gcc http://boost.sourceforge.net/regression-logs/cs-OpenBSD-links. html#errors_handling_test%20gcc-3.2 I tested these both in win32 yesteday. They does not pass, but it does not hang up either. Couldn't you give a little bit more information on where exectly it's looping? Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] bjam on SCO
Hi, Does anybody have bjam executable on SCO unix? If not could somebody point me to complete compilation instructions? Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] OpenBSD regression, hanging tests!
I can give you very little when it comes to information. Under normal runs it just hangs, no output. It strange. At least 2.95.3 should crash imidiately. This compiler does not support sigaction. So there is no signal handling installed. And the first time I force SIGFPE it should abort. At least that what happening on win32 and sun (I just checked) So is there something I can do to get you more meaningfull information? Could you set a breakpoint on line 73: divide_by_zero = 1 / divide_by_zero; and see what is happening here? Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] MacOS regresssion tests
MacOS regresssion tests does not seems to use the latest cvs. Could we run a clean update+build? Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Exception catching in execution_monitor.cpp
If we are going to generalize this there should be a single boost::function0void argument, and if you're going to go down this path we should /definitely/ generalize it. Replicating this design pattern in two separate libraries would be a big mistake. I could not afford boost::function dependency in so low level component as execution_monitor (or even unit_test_monitor). If we will be able to design it as pluggable extension to Boost.Test I would of course prefer the way you implemented it in Boost.Python with boost::function0void argument. optimization crop up). This is not an idiom that's been well-exercised in compiler vendors' test suites, it seems. Still, what about conformance to standard? Gennadiy ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: [test] revision two
However, problems with Boost.Test broke a lot of Metrowerks tests. For some reason I could not locate Metrowerks compilation errors on Test Status page. As for Metrowerks linking errors I have a suspicion that it has something to do with Metrowerks toolset. Also I could not locate errors from errors_handling_test. I fixed it in last update and it should work now (At least it works for me on 4 win32 compilers using bjam) The same with result_report_test. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Request for Config Macro( was RE: [boost] Re: [test] unix identification )
So, Let introduce one. I need something for coming release. Gennadiy. Any suggestions? Looks like testing for _POSIX2_VERSION would be another option - BTW I'm tempted to suggest that we add a config macro and tests for this, that way the configure script will pick this up: BOOST_HAS_SIGACTION maybe? John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Test Tool Proposal (test_tools.hpp)
void checkMyObject(MyObject* my, int context, int a, int b, int c)
{
BOOST_CHECK_EQUAL_MESSAGE(my-getA(), a, context);
BOOST_CHECK_EQUAL_MESSAGE(my-getB(), b, context);
BOOST_CHECK_EQUAL_MESSAGE(my-getC(), c, context);
}
MyObject* my1 = new MyObject(1, 2, 3);
checkMyObject(my1, __LINE__, 1, 2, 3);
MyObject* my2 = new MyObject(4, 5, 6);
checkMyObject(my2, __LINE__, 4, 5, 6);
I believe that message provided by BOOST_CHECK_EQUAL is more valuable, cause
it gives the mismatched values.
When you run in this kind of the situation I would recommend:
1. Use macro instead of function
#define CHECK_MY_OBJECT( obj, vA, vB, vC ) \
BOOST_CHECK_EQUAL(obj-getA(), v1); \
This way want loose line information.
2. use BOOST_MESSAGE tool
void checkMyObject(MyObject* my, int context, int a, int b, int c, size_t
source_line)
{
BOOST_MESSAGE( Testing my-some_kind_of_object_identification() );
// or
BOOST_MESSAGE( Perform check on line: source_line );
BOOST_CHECK_EQUAL(my-getA(), a);
BOOST_CHECK_EQUAL(my-getB(), b);
BOOST_CHECK_EQUAL(my-getC(), c);
}
Regards,
Gennadiy.
P.S. Don't forget to set log level to messages would you decide to choose
the second solution.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Test Tool Proposal (test_tools.hpp)
I've a similiar problem with BOOST_CHECK family, but I think the solution can be different: provide a means to convert failed test into assertion failure. This way I can conveniently debug. Currently, I have to replace BOOST_CHECK with assert manually, to find where the failure happened. Gennadiy, what do you think? - Volodya I do not understand exactly how switching to assert would help you locate the failure point. If you going to run it under debugger you as well could just set a break point on failed assertion. If you going to analize the core using debugger, why not run it under debugger in a first place. If you expect to get a location from the assert output - it will be not better than test tools one. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Test Tool Proposal (test_tools.hpp)
Gennadiy, I had to set the log level from the command line recently, and had a hard time finding out how. I did eventually find an explanation in the docs, but it is buried so deep that it took me quite a while to find it. The was a request couple month ago (by David Held if I am not mistaken) to add some kind of usage/help ability to Boost.Test CLA. That was yet another reason for me to address it with generic cla framework. Once it will be done you wont need to look into the docs to get cla descriptions. Currently cla descriptions are on Unit Test Framework page. I may move it closer to the docs entrance. Or I could provide direct link from first page. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Boost.Test buglet: accessing invalid memory
Hi, You right. It somehow slipped my attention before. Luckily, I was working with library last weekend and already eliminated almost all used of C strings. And it will automatically fix this issue. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] 1.30.0 release schedule
January 31 - Finish commits of major new components. Could be shift this date for 2 days, So we coould use an extra weekend? Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [mpl] conditional expressions
Hi,
Is there neat way with MPL to implement conditional expessions without
introducing aditional structures. For example:
templatetypename Container
void
foo( Container c )
{
// pseudo code
[if ( c is reservable , i.e. has method reserve )
c.reserve( 100 );
]
...
}
Gennadiy.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] function creation in MPL : check_type
Would there be a way to use the MPL so that I could avoid
#define'ed macros for creating these functions?
You don't need MPL to do so.
==
#define MAKE_CHECK_TYPE_FUNCTION(the_type, the_string)\
bool check_type(const string str, const the_type value)\
{\
if(str != the_string)\
{\
cout Wrong type=[ str ] T=
typeid(value).name() endl;\
return false;\
}\
return true;\
}
MAKE_CHECK_TYPE_FUNCTION(bool,b)
MAKE_CHECK_TYPE_FUNCTION(double, f)
MAKE_CHECK_TYPE_FUNCTION(int, i)
MAKE_CHECK_TYPE_FUNCTION(string, s)
==
templatetypename T
check_type_func_traits;
template
check_type_func_traitsbool { static std::string type_id = b }; //
depends on compiler may require extrnal definition also
template
check_type_func_traitsdouble { static std::string type_id = f };
templatetypename T
bool check_type(std::string const str, const T const value)
{
if( str != check_type_func_traitsT::type_id )
{
cout Wrong type=[ str ] T=
typeid(value).name() endl;
return false;
}
return true;
}
Regards,
You may use some different kind of compile time mapping. But this should
work for you.
Gennadiy.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Named Pairs
First of all there are several glitches here:
template typename _T1, int _Name1, typename _T2, int _Name2
class named_pair{
public:
template int _Name
class var{};
template?
class var_Name1{
I am not sure that you allowed to use template parameter for defining
partial specialization.
public:
_T1 value;
}
;?
template?
class var_Name2{
public:
_T2 value;
}
;?
};
enum{ Cash, Name };
void main(int argc, char *argv[]){
named_pairfloat, Cash, char*, Name foobar;
foobar.varCash.value = 32.2;
foobar.varName.value = Fred;
Even if above class definition is allowed foobar.varCash will be invalud
cause varCash is a type name. So basically what you are doing is unusable.
}
Look on MPL example for inherit_linear. It may have what you need.
Gennadiy.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Named Pairs
Look on MPL example for inherit_linear. It may have what you need. Well, as I said, I'm new... I can find mpl documentation, but searches for inherit_linear came up with nothing. http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/boost/boost/libs/mpl/example/ inherit_linearly.cpp?rev=1.1content-type=text/vnd.viewcvs-markup In the above example terms, what you want would look like: typedef mpl::int_c0 Cash; typedef mpl::int_c0 Name; field( foobar, Cash() ) = 32.2; field( foobar, Name() ) = Fred; IOW, this or another way implemented: tuples are your friends. Look onto boost::tuple lib, that supply full featured tuples. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: Preliminary submission: command line config fil e library
It is not necessary. You program will be given *string* (0,1) (1,3) and can parse it using more powerfull means. I guess Spirit is quite appropriate. I provide a way to parse it with very simple means. Unfortunately I will be really busy till the middle of February. So may not be able to work on this further meanwhile. It's a pity, because I've only one more or less serious interface change left in my library, and would prefer to ask for review after that. Do you have any idea when your library will have documentation, examples and tests? Not before the date I mention. If you feel that your design could stand in review go ahead. I will submit my once it's done. Hopefully really soon, cause Boost.Test changes will rely on it. And... how config file parser is concerned with XML? You have option input_message, which value happens to be in XML. The config file parser, which should work on syntactic level, would faithfully return that XML string. On semantic level, the validator function would parse the XML. I fail to see how supporting XML depends on config file parser. Well, Yes. It was bad example. But it does not mean that I could not write wrapper around xerses that uses config_file_iterator line output as an input. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: Preliminary submission: command line config fil e library
Gennadiy Rozental wrote: It is not necessary. You program will be given *string* (0,1) (1,3) and can parse it using more powerfull means. I guess Spirit is quite appropriate. I provide a way to parse it with very simple means. Spirit actually _is_ simple :-) Regards Hartmut I don't argue that. (Unfortunately) I am not familiar with Spirit enough to judge. What I sad is that I *also* provide a means to implement such parsing logic pretty easy. What would be more convinient, easier, more appropriate in every concreate case depends on several factors. One of them is whether or not you familiar with Spirit. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: Preliminary submission: command line confi g fil e library
... through something like lexical property map: [skip] This is basically how key_lookup_policy::operator[]( std::string key_name ) is implemented. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: Preliminary submission: command line config fil e library
quote my_program ( 0, 1) ( 1, 3) (( 0, 1), 15 ), (( 0,1), (7.8) ) This is input of 2 points circle and line. /quote This isn't a simple parsing task anymore. Regards Hartmut Depends. Imagine we have defined input operators for Shape classes istream operator( istream, Point ); // accept format (x,y); in other case throw an exception istream operator( istream, Circle ); // accept format ((x,y), r); in other case throw an exception istream operator( istream, Line ); // accept format ((x1,y1), (x2,y2)) in other case throw an exception They could even exist by itself without CLA processing needs. Each one of them is easily implemented (with tokenizer for example). Now In combination with chain_lookup_policy we could have a cla::parser that accept above syntax with arbitrary order of elements. The idea is originated by the article Industrial strength Pluggable Factories that could be found online. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Preliminary submission: command line config fil e library
I'd like to draw an analogy with shared_ptr. You can provide smart pointer with 5 policy parameters, that user can redefine. Still, I would use boost::shared_ptr, just because I don't want 10 incompatible smart pointers in my program due to small advantage each one has in special situation. What if changing to custom ownership policy will bring you 10% speedup in effciency important part of the code? Would you still say - never, I only use one smart pointer in a program? Likewise, if you have a single interface for declaring options, you should settle of a fixed set of properties. I believe that your handler and my validator and notify mechanisms can be used to cover situation where that set of properties is not sufficient. I don't say that you solution is unable to do anything. But I still prefer more flexible one. For example what if my parameter has 2 descriptions, one long - for long help message and one short for usage message. Where does it fit in your interface? If you don't have such single interface, you'll reduce chances for reuse. If a module adds options to global parser using some non-standard features, you'd have to carry that global parser together with the module. I do not completely understand yuor module principles. So could not comment on this. But As I mention, in my terms one could define several parsers that does not need to know about each other and process cla in chain. Did you look at option_description interface. The constructors have at most three parameters. I positively can't envision any confusion. Add second description, optional/requires, mulitplicable (those are some of the features supported by my parameters) and you could easily see one. In Python, you can use named arguments to function. What you propose looks like using named arguments for calling function with two or three parameters. Possibly much more in my case: cla::named_parameterint( foo ) cla::optional cla::default_value( 1 ) cla::place_to( foo_value ) cla::description( my lovely foo argument ) cla::format_descr( integer value ) cla::prefix( / ) cla::separator( =, ? ) I might be wrong, but using ? to mean optional construct is almost universal convention. I can hardly imagine it's non-obvious. Maybe for unix users. You assumption is not obvose in general case. Do you need this really? Why not? If my parameter is in a form of question, why not have '?' at the end? I think that *existing* habits shold be supported. However, the library should encourage some standard command line style. Contrived command line style is only an inconvenience to user. As an example: what does -r option to CVS does? (It has 2 unrelated meanings, and about 4 syntax variations) May be that's because they stick to one-char parameters identification instead of more expressive solution? It looks like cla::argument is provided by the framework. It is. But it does not mean that all of them are typed You'd still need to function-like logic inside your code, I think. You should call object of some concrete type, and any functor must be converted to that type. Is that duplication reasonable? I don't get this. May be it will become more clear from sources. operator( config::parser, program_options ) ... And what those operator will do? Feed option definitions to the cla::parser. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Preliminary submission: command line config file library
There are only syntactic differences with
http://zigzag.cs.msu.su:7813/program_options/html/variables_map.html
No. I don't think so. You present fixed rigid interface. In my case almost
everything is optional. You don't have parameter description - you don't
provide one.
On the other hand with my interface end-user( programmer) could introduce
his own parameters and modifiers types within bounds if existent framework.
However, some of them are important for me. I'd like to have as little
typing as reasonable, so
1. cla::named_option is extra typing for a very common case
I believe that in this specific case (cla) expressiveness is mush more
important than conciseness. After all it only defined once in program. My
cla parameters could have a lot of features: optional/required,
multiplicable, default_value, . And presenting them just as true, 5,
true, my_var ... is unclear IMO. Especially if you returning to the program
that you wrote year ago and trying to find what is going on with command
line arguments. SO in other words I prefer human readable format for
parameter definition to concise binary one.
2. cla::required is extra typing for a very common case.
In fact it's optional. all parameters are required by default. Presented
only for example.
I've tried to make such common case as simple as possible:
options_description desc;
desc.add_options()
(foo, arg, interesting option)
(bar, arg?, another one)
;
I really think that the arg? notation is superior to any use
Now you need to remember what mark ? mean. And what is the type of it? IMO
much better more expressive:
named_argumentint( arg ) cla::optional
BTW what if I want ? as a part of my parameter name?
For example:
my_program /roll trace file? = yes
CLA is basic facility that is used by many people with different habits. You
could not afford to incur too many restrictions.
Say, I'm writing a generally-useful module. Unfortunately,
it has about 40
options, which should be customizable by users. With your
design the module
would add those options to the global parser. How to use the
module inside
other application? The parser has different lookup policy,
and the code which
adds options no longer works.
I did not mention that, but I do have support for this usage scheme. You may
see that method parse accepts it's argument by reference. As a result after
parsing is complete and mismatches are ignored argc/argv contains unparsed
part of program input. that you could supply to the different parser for
example. This way you could make chain of parsers each responsible for each
own parameters.
Argument access.
The framework provide several ways to access the parsed
argument values
1. Through first_argument/last_argument interface. It will
work if parameter
will create typed formal argument (inherited from
typed_argumentT )
It will look like this:
cla::parser...::iterator it = parser.first_argument();
cla::argument* arg = *it
long value = cla::get_valuelong( arg );
What happens if no type is declared for this value? How
get_value works?
It does not. If argument does not support typed_argument interface it should
provide different means to the value access. it's up to the argument class
designer and is not forced by the framework.
3. Most parameter types supports cla::handler modifier that
allows to set
specific handler (any handler with predefined interface)
for any parameter
parsing event. That allows to implement event driven
parameters parsing.
Would be interesting to see it's interface.
cla::named_parameterMyFancyStructure( fancy_parameters )
cla::handler( any functor that support appropriate interface )
Note that framework does not introduce dependency on boost::function for
example. But do not prohibit to use it as a functor above.
I'd like to backtrack again to command line + Registry use case.
How can it be supported? Do I have to copy all arguments from
command line
to my own location and do the same with registry? Although my library
does not handle registry now, adding the support is trivial.
Ok. You could introduce class like program_options that will provide single
source of program options
Then you could add functions
operator( cla::parser, program_options ) - populate parser based on
program options definitions
operator( config::parser, program_options )
...
This way you are not enforce users to use what they are not need to. And
every separate component need not to know about existence of different
configuration means.
templatetypename KeyPolicy = default_key_policy
class key_lookup_policy : public KeyPolicy, public
key_based_interface {
public:
[...]
};
This class is parameterized with Key policy that
encapsulate logic with Key
identification, key prefix and key/value separator. This
policy allows to
set arbitrary string/char as allowed prefix/separator (or
even
RE: [boost] Preliminary submission: command line config file library
Now about config file feature. I have 2 major issues with your design. 1. You again placed 2 eggs into same basket. There are 2 levels of configuration file reading a) level that is responsible for comments lines, empty lines, continued lines, include, ifdef, defines and so on b) level that is responsible for variable definition in configuration file One may want to use only first level and it's configuration is supplied as XML 2. Look closely on config_file interface: operator++, operator bool Does not it look like something familiar? I have a solution based in iterator_adaptor that present iterator interface: config_file_iterator that manage level a) of configuration reading. It's very flexible and allows you to configure almost every part of it's logic. For example comment char, line continuation char and so on. I also have a solution that works based on config_file_iterator - parameter_handling. It allows to access multi level (with namespaces and sub namespaces) parameters defined in config file. I may be able to present it as an alternative to your config_file class. But it will take some tome to boostify. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: [MPL] Making Tuples
Which example is that? Is inherit_linearly documented somewhere? -Dave http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/boost/boost/libs/mpl/example/ inherit_linearly.cpp?rev=1.1content-type=text/vnd.viewcvs-markup ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] The Wonder of Tuples
Over the weekend I had a bit of free time so I wrote up a spanning_iterator based on the iterator_adaptors framework. To throw in a bit more complication, I wanted something generic enough that I could span different kinds of container. There should be a way to span a std::vector and a std::list as long as their value_types are the same. The spanning_iterator holds two tuples -- one for the current iterators and the other for the end iterators for each container the spanning_iterator spans. The idea is that when the current current iterator reaches its end (the corresponding element in the ends tuple) the next iterator in the current tuple becomes current and so on until all current iterators reach their ends. While ago I wrote joining_iterator that join 2 iterator ranages. You can combine joining interator as many times as you wish to provide multiple ranges iterator. I never really have a chance to writte a docs for it It's if vault area. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Regression test woes
Thanks! The bjam part is now running, but the post test processing is failing. The failure is occurring in the Boost.test tests library. I won't be able to look at it until late afternoon; the error message from the post-processing program was less that helpful. You confusing me again. What is post test processing? And how it related to Boost.Test tests? Also AFAIK status/Jamfile does not have them yet (about to be added) We need to find a way to better test changes to the test library because failure in it cause the whole regression testing system to fail. Perhaps all changes to Boost.Test should first go on a branch, and only be merged when they have been tested with several compilers and operating systems. I am trying to get a naccess to as much compilers as I could. At least windows compilers. I do not commit the changes until all my tests are passing. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Regression test woes
Gennadiy Rozental [EMAIL PROTECTED] writes: metrowerks-C++-action c:\build\libs\test\build\bin\libboost_unit_test_framework.lib\ cwpro8.3\debug \runtime-link-dynamic\execution_monitor.obj ### mwcc Compiler: #File: ..\libs\test\src\execution_monitor.cpp # --- # 157: case _CRT_ASSERT: # Error: ^^^ # undefined identifier '_CRT_ASSERT' ### mwcc Compiler: # 161: case _CRT_ERROR: # Error: ^^ # undefined identifier '_CRT_ERROR' This one appears to be caused by the fact that metrowerks tools does not define the symbol _DEBUG in debug mode Why don't you fix that one, too? _DEBUG is an MSVC-specific symbol. MSVC toolset defines it. While metrowerks don't. Do you want me to fix the latter? Where would be the best place to put debug specific definitions? Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Regression test woes
\runtime-link-dynamic\execution_monitor.obj ### mwcc Compiler: #File: ..\libs\test\src\execution_monitor.cpp # --- # 157: case _CRT_ASSERT: # Error: ^^^ # undefined identifier '_CRT_ASSERT' ### mwcc Compiler: # 161: case _CRT_ERROR: # Error: ^^ # undefined identifier '_CRT_ERROR' This one appears to be caused by the fact that metrowerks tools does not define the symbol _DEBUG in debug mode Why don't you fix that one, too? _DEBUG is an MSVC-specific symbol. MSVC toolset defines it. I see no evidence to support that claim. The msvc compiler flags which turn on debug symbols, etc., also cause _DEBUG to be defined. The toolset never touches _DEBUG. Whatever. The net result is that C runtime debug hooks are gets defined in debug mode. While metrowerks don't. Do you want me to fix the latter? I don't think I want you to fix it. As a user, you're not allowed to #define _DEBUG, since that symbol is reserved to the implementation. Where would be the best place to put debug specific definitions? #ifndef NDEBUG ... #endif I am already doing this in mycode. But it only hides the problem. Metrowerks has the header crtdbg.h similar to MSVC one. If you will take a look into this header you see that C runtime debug hooks (_CRT_ERROR is part if this API) are gets defined if _DEBUG is defined. I think that it is natural to assume that debug hooks should be defined in debug mode. So I still believe that some compiler option is missing and that needs to be fixed. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Regression test woes
The correct fix is to not use a Microsoft debugging feature for a compiler that doesn't support it. Metroverks does supports it. I've committed the following fix: +#if !defined(__MWERKS__) #define BOOST_MS_CRT_DEBUG_HOOK #include crtdbg.h +#endif I don't beleive it's correct if. The one in Dave post is correct Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Regression test woes
First, the regression tests are broken; the message is: unknown dependent target libs!test!buildlibboost_prg_exec_monitor.lib 1. I do not get it. boost_prg_exec_monitor is the new name of the library. bjam could not find it? 2. Where did you get these errors? 3. I though that in most cases minimal testing is used. So majority of boost regression tests should ignore library rename. And only couple of libraries that does use external library will need to change the name in Jamfile. I assume this is the result of a change Glennadiy made last night in the test library build Jamfile, but reverting it to the prior version doesn't clear the problem. Sigh. I've emailed him privately. I did not get it. Could you resend? Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Regression test woes
#File: ..\libs\test\src\execution_monitor.cpp # --- # 157: case _CRT_ASSERT: # Error: ^^^ # undefined identifier '_CRT_ASSERT' ### mwcc Compiler: # 161: case _CRT_ERROR: # Error: ^^ # undefined identifier '_CRT_ERROR' What kind of C runtime hooks metrowerks supports? Errors caused tool to abort. call c:\tools\cwpro8.3\Other Metrowerks Tools\Command Line Tools\cwenv.bat -quiet Could I get these command line tools somewhere to install on my local PC for testing of Boost.Test? #From: ..\libs\test\src\test_tools.cpp # # 53: voidshort_report( std::ostream where_to_, size_t indent_ = 0 );// short # Error: ^^ # declaration syntax error Why? [...very strange error messages skiped] I will try to look into it, if I get an access to this compiler. I was able to test with MSVC6.5, BCC command line, GCC3.2 Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Factoring out Test Library wrapstrstream
The problem is that BCC, by default, uses an 'intrinsic' version of strcmp which is not a real function thus it is not located in std. Declaring strcmp inside std doesn't help. The workaround is to either use unqualified calls to strcmp or to disable its intrinsic version. My patch does the latter. Why don't I have any problems compiling using borland command line tools? ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Factoring out Test Library wrapstrstream
(3) fully included The problem with this is that I put the burden of doing so to the user. I do not get it. In this case you are the user (of Boost.Test library). To use fully included version you are using #include boost/test/included/test_exec_monitor.hpp And that's it. No need for linking. I could use jamfiles, but jam builds doesn't work on every supported platform. For instance, it doesn't work on mine (borland), so I can't resort to jamfiles to attach the test framework to a simple test with a single file. Works for me. On windows I am testing using MSVC, GCC and BCC. Look on Boost.Test unit tests Jamfile. (2) fully linked Similarly, this requires me (and eventually the end user) to compile the test framwwork with every platform I want to test against. This is a burden in some cases. For example, since Borland doesn't work with bjam, I need to do it by hand for this compiler. Similarly, I need to go through all the trouble of building the test framework with every compiler I want to test my code against. This is too much for a single file test which would use just a small subset of the Test Framework AFAIK Boost.Test is compiled and works for all supported compilers/platforms. With and without Jamfile. Great. If I'm not mistaken, most of the stuff from test_tools.hpp can be rearranged so that it becomes self-contained. That is, it would be possible to use some of it by simply including test_tools.hpp, with possibly a macro switch to indicate that its definitions shall be included right into the translation unit being compiled. No. Majority of the staff in test_tools.hpp depends on unit_test_log, unit_test_results and on test_tools.cpp of course. Those three modules constitute the 80 percent of unit test framework and separating them would not buy you to much. Even if you rearrange test-tools so that it can be used standalone without external modules that needs to be linked or added to the project, I think that wrapstrstream() would be quite useful on its own. Using a text stream to quickly format text on the fly is a very common operation, and wrapstrstream() provides a nice solution for it. All right. I will try to prepare standalone file + doc for submission. Do we need the review for this? Best regards, Fernando Cacciola Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] FW: Boost Unit Test Framework: Localisation hiccups
Dear Gennadiy, I've just been trying out the latest (1.29.0) release of the Boost Unit Test Framework. I ran into a few minor localisation hiccups you might want to be told about. I'm using Metrowerks Codewarrior 8.1 on MacOS 9.2. A couple of problems resulted directly from this. 1) At line 45 of execution_monitor.cpp the test #if defined(_MSC_VER) || (defined(__MWERKS__) __MWERKS__ = 0x3000) yielded a false positive. I altered it to #if defined(_MSC_VER) || (defined(__MWERKS__) defined(__INTEL__) __MWERKS__ = 0x3000) Could Metrowerks users conferm that this is the best way to separate Mac and everything else? 2) In cstdint.hpp importing the C99 typedefs failed. When compiled as C++, the MW version of stdint.h behaves by analogy with the other standard headers: it defines the typedefs in std:: and then exports them to the global namespace with using declarations. Unfortunately, this seems to mean that when cstdint.hpp tries to import them from the global namespace, they aren't really there. I've hacked a copy of cstdint.hpp to work by just sticking std:: in where needed, but something more robust needs to be done here. Could this author reply to this? Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] strict_weak_ordering
While ago John Panzer proposed function test_strict_weak_ordering I modified it for use with Boost.Test (look here: http://groups.yahoo.com/group/boost/files/test_strict_weak_ordering/BTL_comp atible/runtime_concept_check.hpp) I was thinking about adding it to Boost.Test. Will you find it usefull? Gennadiy. -Original Message- From: Ben Young [mailto:[EMAIL PROTECTED]] Sent: Monday, November 25, 2002 9:13 AM To: Boost mailing list Subject: [boost] strict_weak_ordering Recently at our company we had a couple of bugs relating to people incorrectly writing comparison operators, so I came up with this little helper. It is very trivial, but useful none the less as bogus comparison operators can be the cause of many bugs. Obviously it could be improved to take a predictate of some kind and checged to use the boost pre-processor library, but, otherwise, is anyone interested Yours Ben Young ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: Formal Review Request: class optional
Your are asking why can't the constructor be not explicit, right?
Well, this would allow the 'direct' syntax fn(1,3) that
Vincent wanted,
but...
It would entirely break the pointer semantics because the
following would be
allowed:
void foo()
{
optionalint opt ;
opt = 3 ; // This will construct a temporary optionalint(3)
if ( opt == 0 ) // tmp optionalint(0) here.
}
You may poison undesired operators.
Even if it would be allowed to have optionalint, you would
still have to
use it as if it were a pointer:
void foo ( optionalint p = optionalint() )
{
if ( !!p ) // or ( peek(p) ) or ( initialized(p) )
BTW why do you need 3 methods that doing the same?
{
int the_p = *p ;
the_p = 3 ;
etc...
}
}
Here 2 questions:
1. Let say we have
struct A { void moo() { ... } };
a. void foo( A* a ) { a-moo(); }
b. void foo( A a ) { a.moo(); } // here we could assume inlining
Does both above versions are equaivalent form assembler stand point?
2. Now let say we use optional:
void foo( optionalA a ) { (*a).moo(); }
From assembler stand point will it be equivalent to 1.a or 1.b?
And here yet another example where optionalT would be useful:
Let say I am using ostream wrapper for my printing and want to separate the
case whgen ostream is not supplied:
class Log
{
optionalostream m_output;
{
And use it for example like this:
templatetypename T
Log::operator( T const t )
{
if( !!m_output )
*m_output t;
}
Would it be equivalent to reference or pointer? Or it the same in both
cases?
Gennadiy.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Factoring out Test Library wrapstrstream
My tests are already arranged in a way that 'test/minimal.hpp' offers too little functionality while a whole test framework, such as test_execution_monitor or unit_test_framework requires me link or include too many translation units. Well currently Boost.Test propose three configuration: 1. Minimal 2. Full linked 3. Full included Does not any one of them fit for you? What are the issues? What set of features you are looking for? As a result, I don't want to use the Test Library (but we could discuss this, because I might be biased by its perceived complexity) I still hope to satisfy your requests for new features and explain everything that seems complex. A quick search for BOOST_NO_STRINGSTREAM reveals that there is a sort of 'idiom' which is extensively used -by hand- among many unit tests (i.e, including the appropriate header and dealing later with either ostrstream or ostringstream). I also found that this idiom is very well captured by the Test Library under the form of the class 'wrapstrstream', which comes exactly as handy as most of the unit tests I've seen need it. You may nor remark it but this class change the interface a little right after 1.29 came out to implement different fix for the issue with copy constructor. Therefore, is it possible to factor out this class so it can be used standalone? Say, as /utility/wrapstrstream.hpp. Gennaidy, what do you think? TIA, Fernando Cacciola Well, if there is an interest in reuse of this class I do not see the reason why not. BTW at very end of 1.29 I added nullstream.hpp into details section of Boost.Test (borrowed and reworked a bit from Daryle Walker more_io). It also belongs somewhere in utility. Gennadiy. P.S. Sorry it took me so long to answer. I just was overloaded at the work and with serialization review. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Formal Review Request: class optional
Good point. On a few ocasions I have use optional to pass optional
parameters.
However, I've came to the following:
Take you example for instance:
void fn(int iImportant, optionalint iNotImportant = optionalint())
{
if ( !!iNotImportant )
{
// not important argument recieved, use it.
foo ( * iNotImportant ) ;
}
}
Since optional uses pointer semantics, the above code could
have been
written using a true pointer with nearly the same syntatic
usage of the
optional parameter:
void fn(int iImportant, int* iNotImportant = NULL )
{
if ( !!iNotImportant )
{
// not important argument recieved, use it.
foo ( * iNotImportant ) ;
}
}
We already talked about this: pointer will add extra memory access, optional
should not (in fact it should be inlined and won't be different from by
value parameter)
The constructor must be explicit in order to disable
unexpected implicit
conversions.
Some may still prefer sometime
foo(3)
to
foo(lvalue(3));
foo(optionalT(3));
implicit conversion to optional should not be dangerous anyway.
Actually, optionalT does not require T to be default constructable.
The reason why you can't have optionalT is -at least- that
you cannot
have a reference to a reference,
and optionalT uses T {const} (for example, in the constructor).
use add_reference instead?
Gennadiy.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Formal Review Request: class optional
We already talked about this: pointer will add extra memory access, optional should not (in fact it should be inlined and won't be different from by value parameter) You are mis-remembering our previous talk. No. I do remembr that we agreed that pointer semantics is better. I still agree with that. Nevertheless my point above was following: Even if optionalT has pointer semantics, unlike pointers *optionalT won't produce extra memory access. implicit conversion to optional should not be dangerous anyway. I disagree. Implicit conversions are usually problematic, but with optional, it is even worst, since (1) a conversion from an uninitialized optional is undefined -^ we talked about to conversion (2) the distinction between (a) the operation of testing whether an optional is initialized or not (b) the operation of accesing the optional value (in this case via a conversion) we talked about to conversion Maybe, but actually, I don't think optional should work with references. It is supposed to wrap a 'value', not a reference/pointer. Fernando Cacciola Why? I always did not like the fact that I need to switch to pointers when my reference argument became optional. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Problem with BOOST_PARAM_TEST_CASE and BOOST_CHECK_THROW
voidImplementBadValueTest( int nToTest )
{
BOOST_MESSAGE( format( Testing value %d ) % nToTest );
throw std::runtime_error( Unexpected! );
}
I've got it. When you throw an exception here it skips parameters iteration
here:
{ m_function( *m_curr_parameter ); ++m_curr_parameter; }
should be
{ m_function( *m_curr_parameter++ ); }
Fixed. Thank you.
Gennadiy.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] MPL's round lambda
On Monday 18 November 2002 05:56 am, Aleksey Gurtovoy wrote: If you are tired of angle brackets in your templates (no, it's not a TV commercial :), may be you'll like this one: typedef eval count_if( list(int,char,long,int) , lambda(is_same(_,int)) ) ::type res; BOOST_STATIC_ASSERT(res::value == 2); Very cool indeed! We need to invent an award for the craziest use of obscure language features (you have my vote). Doug Could those enlightened bring some light for the rest of us? Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Named Template Parameters implementation
Unfortunately this implementation is using template template parameters and partial specialization. I still could not find a time to write a proper comments to this submission. I Will do soon. But If it does not bother it pretty easy to use (easier then one adopted by me from iterator_adaptors for smart_ptr implementation). Gennadiy. -Original Message- From: Fernando Cacciola [mailto:fernando_cacciola;hotmail.com] Sent: Friday, November 15, 2002 10:48 AM To: Boost mailing list Subject: Re: [boost] Named Template Parameters implementation - Original Message - From: Jaakko Jarvi [EMAIL PROTECTED] To: Boost mailing list [EMAIL PROTECTED] Sent: Friday, November 15, 2002 12:18 PM Subject: Re: [boost] Named Template Parameters implementation On Fri, 15 Nov 2002, Fernando Cacciola wrote: As a final touch in the Numeric Conversion library I have almost ready, I want to add it named template parameters for easier usage. Were can I borrow the State of the Art implementation of this idiom from? Don't know about state of the art, but this library tries to do a decent job: libs/named_template_parameters in boost sandbox. Yep, I've seen it... Looks pretty good. I think I figured out how to use it.. But, do you have at hand a sample usage of it? And, Can I borrow this header and include it in the submission package for the Numeric Conversion library? Or do you prefer that we review it stand alone first? /Jaakko Thanks, Fernando Cacciola ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] String algorithm library
Trimming: Iterator trim_begin( Iterator InBegin, Iterator InEnd, const std::locale Loc=std::locale() ) Seq ltrim( const Seq Input, const std::locale Loc=std::locale() ) Seq ltrim_in( Seq Input, const std::locale Loc=std::locale() ) Seq rtrim( const Seq Input, const std::locale Loc=std::locale() ) Seq rtrim_in( Seq Input, const std::locale Loc=std::locale() ) Seq trim( const Seq Input, const std::locale Loc=std::locale() ) Seq trim_in( Seq Input, const std::locale Loc=std::locale() ) 1. I would prefer explisit names: trim_left, trim_right,... 2. Where do you specify what to trim? What If I want to trim 3. why do we need not _in functions? If you want it that bad you could do something like: Seq trim_copy( Seq input, Seq trim_func( Seq, const std::locale ) ); Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Named Template Parameters implementation
This archive contains one header and test http://groups.yahoo.com/group/boost/files/smart_pointers/Policy%20based%20sm art_ptr/smart_ptr.zip Here the message with description http://aspn.activestate.com/ASPN/Mail/Message/1190858 Compile and work on MSVC6.5 and gcc. But Jaakko version has it's own advantages. Maybe good portable version somewhere in between. I will post with details later. Gennadiy. -Original Message- From: Fernando Cacciola [mailto:fernando_cacciola;hotmail.com] Sent: Friday, November 15, 2002 2:22 PM To: Boost mailing list Subject: Re: [boost] Named Template Parameters implementation OK, I read the docs, followed the example and *tried* to use it in the library. Unfortunately, I received tons of mysterious compiler errors with BCC55; apparently as a result of the usage of template template parameters in ntp::as_named. Gennadiy, I'm not sure if I understood what you said... do you have an alternative implementation? If so, were? Fernando Cacciola ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] MPL lambda
Hi, Alexey. I am having hard time grasping how this %#$% lambda facility is working. Unfortunally paper does not provide enough information. Could you at least provide general scetch?Amoung other things I would like to know when I need to use _ and when _1,_2,...? Could you write in a form of step by step description how fold-family algorithms are working? Also is there gen_scattered/linear_hierarchy implementation somewhere for MPL sequenses? Thank you, Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Serialization Library Review
1) I don't like the non-intrusive way of specifying the version/save/load operation. The rationale for having the serialization template in the global namespace is quite weak. The alternative of using free functions is much better IMO. The library should use unqualified calls to those free functions and Koenig look-up would do the rest. This solution has also the benefit that specialization is replaced by overloading, a feature that is more easily supported by compilers. Moreover IMO it simply would not work because of the inheritance, or I missing something. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [preprocessor] vertical and horisontal repititions
Could somebody explain the difference and when which one should be used. Also is there PP desing paper that explain how it is working/implemented? Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
