[boost] Re: variant questions
BTW, after looking at the implementation I was a bit disappointed to see two copies of the storage. It seems to nullify one important reason for using variants (space savings), and it generates more code than a single-storage version. I know you had some rationale for that but I don't remember what it is; I hope it's in the docs along with some explanation of the expected size of the resulting object. Regards, Dave Double storage is needed to ensure strong guaraty for variant. I argued need for it before and I still believe we not nesseserily need to do that (I remember your post on the topic, that strong guaranty is a incorrect goal to pursue for the variant). Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: POSIX, gcc, Comeau, Boost.Test, glibc
My understanding is that Boost.Config should take care about these issues. Boost.Test rely on BOOST_HAS_SIGACTION flag. It should not be defined in case if there is no support for POSIX interfaces. Could you report the value of that flag in case of compilation failures you are expiriencing. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Proposed smart_handle library
Hi, I do not want to start this discussion all over again, but in the reasoning you presenting I did not find anything new to justify another smart pointer like component. It's only one simple case of PBSP and I do not see any reason not to use it. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: How to achieve this goal using boost::tokenizer?
I remember that there are 2 types of separators in boost tokenizer: returnable and ignorable. Set - as returnable separator, and , as ignorable. It should give you all the information you need. Gennadiy. lattice [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] If we print some pages ,we can select pages in a range to print. for example,if we enter 2,3,5-7 in Ms-word print dialog,then page 2,3,5,6,7 is printed. Now questions is : if we get a string like this 2,3,5-7,if we use boost::tokenizer, we can only get 2,3,5,7. eventually some information is lost. How can we get the desired result2,3,5,6,7 using boost::tokenizer? ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: test_fp_comparisons and rounding errors
Could you please be more specific about which Boost.Test features you think should remain and which should be removed or modified? I'm having trouble relating the discussion to the actual Boost.Test public interface. Thanks, --Beman The only thing I propose to change is to prohibit defining tolerance by the number of rounding errors. User still will be able to use BOOST_CHECK_CLOSE tool with the FP tolerance as a third parameter. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: test_fp_comparisons and rounding errors
There is BOOST_CHECK_PREDICATE Yes, I know. My point was that with BOOST_CHECK_EQUAL_NUMBERS() the test library could output something readable of the form: numbers x and y are not approximately equal It could even add to the output something of the form: according to Pred ; This is what BOOST_CHECK_CLOSE is doing basically. By default, the Test library provides relative error comparator, which is according to my understanding is more correct. But there is no such thing as a more correct way to compare FP values in the context free level of a test library. You know already that relative errors have to be scaled to be meaningful, but choosing the right scaling is the complex. A default semantic that simply scales epsilon() times any of the arguments will be simply unusable for most practical tests because actual errors will easily exceed that; yet OTOH, suppling a factor to increase the scaling will mainly lead users to the problematic Illusion of Simplicity that brought us to this discussion. That part of interface I propose to eliminate. User will aonly be able to define a tolearance as it is. BOOST_CHECK_CLOSE( a, b, 1e-05 ); // 1e-05 is good enough for my practiacal purposes A comparison based on absolute errors is pesimistic, but for unbiased comparisons it often results on what is expected, much more often that relative-error based comparisons. It isn't smart but is easy to understand. For majority of simple cases (not very big, nor very small values) they should behave similarly. For egde cases relative error comparison produces better results IMO Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: test_fp_comparisons and rounding errors
Beman Dawes [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
test_fp_comparisons has been failing for a long time. The issue has to do
with how much tolerance to allow for rounding errors.
The close_at_tolerance algorithm calculates tolerance as follows:
n*std::numeric_limitsT::epsilon()/2 (1)
where n is the number of possible floating-point rounding errors.
The particular test case that is failing calls the comparison algorithm
with a rounding error argument of 4. That allows for up to 2 epsilons
tolerance.
Thanks, Beman for bringing this up. I actually was playing with this test
lately. It does indeed fail on following comparison:
I compare 0.11 with 0.11.
Left size calculated as: 11./100 (1 rounding error).
Right side calculated as: tmp = 11/10 (1 rounding error ); tmp*tmp - tmp (2
rounding errors).
In sum have 1+1+2 = 4 rounding errors. According to my understanding
relative error of calculation should not exceed tolerance calculated with
above formula 1. This statement does not hold.
What I've tried to do is to analyze the relative error/(epsilon/2) for
different compilers and FPTs. Here is the code:
templatetypename FPT
void foo( FPT* = 0 )
{
FPT tmp = 11;
tmp /= 10;
FPT tmp1 = tmp * tmp - tmp;
FPT tmp2 = 11./100;
FPT diff = fpt_abs( tmp1 - tmp2 );
FPT d1 = diff / tmp1;
FPT d2 = diff / tmp2;
FPT r1 = d1 / std::numeric_limitsFPT::epsilon() * 2;
FPT r2 = d2 / std::numeric_limitsFPT::epsilon() * 2;
std::cout diff= diff std::endl;
std::cout epsilon= std::numeric_limitsFPT::epsilon()
std::endl;
std::cout r1= r1 std::endl;
std::cout r2= r2 std::endl;
}
int
main()
{
foofloat();
foodouble();
foolong double();
return 0;
}
Here is the result produced for different compilers:
Borland command line:
---
diff= 2.98023e-08
epsilon= 1.19209e-07
r1= 4.54545
r2= 4.54545
diff= 1.11022e-16
epsilon= 2.22045e-16
r1= 9.09091
r2= 9.09091
diff= 5.42101e-19
epsilon= 1.0842e-19
r1= 90.9091
r2= 90.9091
Metrowerks
-
diff= 2.98023e-08
epsilon= 1.19209e-07
r1= 4.54545
r2= 4.54545
diff= 9.71445e-17
epsilon= 2.22045e-16
r1= 7.95455
r2= 7.95455
diff= 9.71445e-17
epsilon= 2.22045e-16
r1= 7.95455
r2= 7.95455
GCC 3.2.3
---
diff= 2.98023e-08
epsilon= 1.19209e-07
r1= 4.54545
r2= 4.54545
diff= 1.11022e-16
epsilon= 2.22045e-16
r1= 9.09091
r2= 9.09091
diff= 5.42101e-19
epsilon= 1.0842e-19
r1= 90.9091
r2= 90.9091
MSVC 6.5
diff= 0
epsilon= 1.19209e-007
r1= 0
r2= 0
diff= 9.71445e-017
epsilon= 2.22045e-016
r1= 7.95455
r2= 7.95455
diff= 9.71445e-017
epsilon= 2.22045e-016
r1= 7.95455
r2= 7.95455
MSVC6.5 + STLport
--
diff= 0
epsilon= 1.19209e-007
r1= 0
r2= 0
diff= 9.71445e-017
epsilon= 2.22045e-016
r1= 7.95455
r2= 7.95455
diff= 9.71445e-017
epsilon= 2.22045e-016
r1= 7.95455
r2= 7.95455
MSVC7.1
--
diff= 2.98023e-008
epsilon= 1.19209e-007
r1= 4.54545
r2= 4.54545
diff= 9.71445e-017
epsilon= 2.22045e-016
r1= 7.95455
r2= 7.95455
diff= 9.71445e-017
epsilon= 2.22045e-016
r1= 7.95455
r2= 7.95455
Mingw
---
diff= 2.98023e-08
epsilon= 1.19209e-07
r1= 4.54545
r2= 4.54545
diff= 9.71445e-17
epsilon= 1.11022e-16
r1= 15.9091
r2= 15.9091
diff= 9.71445e-17
epsilon= 1.11022e-16
r1= 15.9091
r2= 15.9091
As you can see It's never less then 4.
One idea, that I had, is maybe Testing tool introduce an extra error
during relative error calculation. It take an extra 6(?) operations before
comparison is performed. It still does not explain all the results above and
I am not sure it's correct.
I attached the test program for anybody interested.
Regards,
Gennadiy.
begin 666 fpt.cpp
M(VEN8VQU94@/)O;W-T+VQI;6ETRYH' ^#0HC:6YC;'5D92 \:6]S=')E
M86T^#0H-G1E;7!L871E/'1Y5N86UE($905#X-FEN;EN92!4%0-F9P
M=%]A8G,H($905!AF@*2 -GL-B @(!R971U[EMAIL PROTECTED])G(#P@, _(UA
MF@.B!AF[#0I]#0H-G1E;7!L871E/'1Y5N86UE($905#X-G9O:60@
M9F]O*!4%0J(#T@, I#0I[#0H@( @1E!4('1M @/2 Q,3L-B @(!T
M;7 @+ST@,3 [#0H@( @1E!4('1M#$@/2!T;7 @*B!T;7 @+2!T;7 [#0H-
MB @(![EMAIL PROTECTED]UP,B ](#$Q+B\Q,# [#0H-B @(![EMAIL PROTECTED]EF9B ](9P
M=%]A8G,H('1M[EMAIL PROTECTED];7 R(D[#0H-B @(![EMAIL PROTECTED]@/2!D:69F(\@
M=UP,3L-B @(D:69F
M/2 B( @(#P\(1I9F8@/#P@W1D.CIE;F1L.PT*( @('-T9#HZ8V]U= \
M/ B97!S:6QO;CT@(B \/!S=0Z.FYU;65R:6-?;EM:71S/$905#XZ.F5P
MVEL;VXH*2 \/!S=0Z.F5N9P[#0H@( @W1D.CIC;W5T(#P\()R,3T@
M(B \/!R,2 \/!S=0Z.F5N9P[#0H@( @W1D.CIC;W5T(#P\()R,CT@
M(B \/!R,B \/!S=0Z.F5N9P[#0I]#0H-FEN=
[boost] test_tools_test metrowerks failure
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?
Gennadiy.
P.S. Rest of Windows compilers I have access to seems to be happy with
above.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Exception testing for Boost.Test incomplete
Daryle Walker [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] While writing some other code, I checked out how some of the macros in Boost.Test are implemented. The BOOST_CHECK_THROW and BOOST_CHECK_EXCEPTION macros flag when an intentional exception was missed and when the expected exception type was caught. But what about when an exception of the _wrong_ type is thrown. Shouldn't there be a catch(...) that notes that the wrong type was caught and re-throws the error? Any operation may throw an unexpected exception. To manage this Boost.Test runs test cases under control of the Execution Monitor. Any exception thrown from inside a test case gets caught and reported. So I believe current semantic of above tools is correct. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [test] first revision to 1.30.0
What I meant is that the files contain data specific to your own programing environment (there are absolute filesystem paths in the 7.1 project files for example). It's the reason why I was suggesting that it may be a mistake with CVS. If there is no mistake and if the files are really usable by other people having MSVC, that's fine. No. There are no important absolute pathes there. Only intermidiate files located forced into c:\temp\boost_test_library\. You shouldn 't have any problems using these project locally. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: API Review request: XML APIs for C++
* event driven xml file parsing (sax)
I did not really used DOM to much. I may have some comments on SAX though.
Perfunctory look on your interfaces left me wondering: who does it differ
from xerces? Still xmlChar type, tons of virtual functions. We are in modern
C++ world. No need to promote such a Javish solution.
Here is my vision on the problem, couple ideas on XML parser design:
1. No xmlChar type - template parameter
namespace xml {
templatetypename Ch, typename Tr
class parser {...};
}
2. No hardcoded virtual functions. In some refinements it still may come to
use virtual functions here and there. One way to achieve this is to supply
implementation as template parameter:
namespace xml {
templatetypename HandlerImpl
class parser : public HandlerImpl {...};
}
3. Most probably above may not be good enough. For better reusability let
then use multiple template parameters for different types of handlers:
namespace xml {
templatetypename DocumentHandler, typename ErrorHandler, typename
DTDHandler, ...
class parser : public foo( DocumentHandler, ErrorHandler, DTDHandler, ... )
{...};
}
meta function foo should deduce the correct type to inherit from. We may
want to take into an account the fact that if the same type is used as both
document and error handler, we don't want to inherit twice.
Also above interface definitely asks for named template parameters.
4. There maybe several flavors of document handlers. One simple: as usual
concrete handler needs to expose methods like on_start_element and accept
the name plus attributes. As an alternative we may consider document
handlers supporting named callbacks (in a form of boost::function...)
registration. IOW such handler would call a callback when element with
desired name encountered. There are other alternatives.
This way I believe we could create fastest and convenient parser.
I am sure that there also could be Spirit-based or Spirit-like solution.
Check with the Spirit guys.
Regards,
Gennadiy.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [test] first revision to 1.30.0
Hi,
I finally mostly finished first long promised revision for Boost.Test.
Here is the list of major features/updates:
* Major update for documentation
I still think that docs need a lot of work. They incomplete and there are
several pages missing. Also some tutorial material needs to be extended. I
reworked documentation structure. All suggestions and comment in this regard
are welcome.
* BOOST_CHECK_EXCEPTION
New tool allows not only check that desired exception has thrown, but also
validate a predicate with an exception as an argument.
* Test cases/suites dependency support
Now one should be able to say: do not run this test case/suite unless
that test case passed
Syntax:
test_case_1-depend_on( test_case_2 );
* zero arity function template based test case.
This is the case met several times in boost libraries tests: run some
function several times with different template parameter as an template
argument. Unfortunately due to some C++ limitation I did not find a solution
with out extra out of function support. Here is the syntax:
templatetypename T
void my_foo( ) // add parameter T* =0 if you want it to work under MSVC 6.5
{
...
}
BOOST_META_FUNC_TEST_CASE( my_foo );
...
test-add( BOOST_FUNC_TEMPLATE_TEST_CASE( my_foo, types_list ) );
Above statement will make the framework to run the function my_footype(),
instantiated with all types in provided as a second argument type list.
* Smart predicates support
In some cases users want to be able to perform complex check and in
combination with result to return error message with explanation
I moved extended_predicate_value into public interface. Now used could
return instance if this class that could hold boolean value and error
message from a predicate. The framework will use the supplied error message
for error logging
* Support for non-printable types
In some cases users forced to use less descriptive tools because more
descriptive would require presence of the output operator()
For example:
std::listint my_list, expected_list;
...
BOOST_CHECK_EQUAL( my_list, expected_list );
Now this does not work cause std::listint does not have an operator()
defined. To address this I added extra decision point which function to use
to print the value. One could overwrite this function to use custom print
mechanism. Also helper macro
BOOST_TEST_DONT_PRINT_LOG_VALUE( type_name ) introduced, that automatically
prevent compilation error in above case. Use it outside of test function
definition
BOOST_TEST_DONT_PRINT_LOG_VALUE( std::listint )
BOOST_CHECK_EQUAL( my_list, expected_list ); // Now works
BOOST_CHECK_EQUAL( my_list, expected_list );
* many bug fixes and minor enhancements
Update is available in cvs. Let me know about any issues.
Regards,
Gennadiy.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [patch] Boost.Test and BOOST_DISABLE_WIN32
Giovanni Bajo [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hello, Boost.Test does not currently honor BOOST_DISABLE_WIN32. The attacched patch fixes it. Can someone review apply this patch? Thanks Giovanni Bajo Ok. Applied. BTW, Beman, You recently disabled structured exceptions support for Comeau. Are you sure it does not work in any configuration? I remember seeing references online on Comeau structured exceptions support. And if it indeed does not work should we define above macro then? Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: compiler status page proposition
Regardless, do this: make a copy of one of the status tables, hand change
the entries for the first couple of libs to illustrate what you want,
verify it works with a browser, and send it to me.
Maybe like this.
Gennadiy.
begin 666 Boost Compiler Status Automatic Test.htm
M/%$3T-465!%([EMAIL PROTECTED]3$E#((M+R]7,T,O+T141!(5$U,(#0N,!4
MF%NVET:6]N86PO+T5.(CX*/$M+2!S879E9!FF]M('5R;#TH,# U-BEH
M='1P.B\O8F]OW0NV]UF-E9F]R9V4N;F5T+W)E9W)EW-I;VXM;]GR]C
M[EMAIL PROTECTED]:'1M; M+3X*/$A434P^CQ(14%$/@H\5$E43$4^0F]O[EMAIL PROTECTED]
MEL97(@4W1A='5S($%U=]M871I8R!497-T/]4251,13X*/$U%5$$@:'1T
MUE75I=CTB0V]N=5N=U47!E(B!C;VYT96YT/2)T97AT+VAT;6P[(-H
M87)S970]=VEN9]WRTQ,C4Q(CX*/[EMAIL PROTECTED]5N=#TB36ECF]S;V9T
M($9R;VYT4%G92 U+C B(YA;64](D=%3D52051/4B(^CPO2$5!1#X*/$)/
[EMAIL PROTECTED]5X=#TB(S P,# P,(@8F=C;VQOCTB(V9F9F9F9B(^CQ404),12!B
M;W)D97(](C B/@H@(#Q40D]$63X@B @/%12/B *( @(#Q41#X\24U'(AE
M:6=H=#TB.#8B('-R8STB8RLK8F]OW0N9VEF(B!W:61T:#TB,CW(B!B;W)D
M97(](C B/CPO5$0^B @( \5$0^( H@( @( \2#$^0V]MEL97(@4W1A
M='5S.B!)[EMAIL PROTECTED]/](,3X*( @( @/$(^4G5N($1A=4Z/]/B P-CHP
M,SHP-!55$,L($UO;F1A2 P.2!*=6YE(#(P,#,@B @( @(#Q0/E1EW0@
MG5N('5N95R($E32!!:7@@-2XQ3 \0E(^B @( @( @;W-L979E; U
M,3 P+3 T+!6:[EMAIL PROTECTED]($UA2 R,# S(#Q4CX*( @( @(!E
M=F5R[EMAIL PROTECTED]@-F%M($-%5[EMAIL PROTECTED]@5]O;B!+;F%P96X\+U ^B @( \
M+U1$/@H@(#PO5%(^B @/]40D]$63X@CPO5$%3$4^CQ4CX*/%1!0DQ%
M(-E;QS%C:6YG/2(P(B!C96QL%D9EN9STB-2(@8F]R95R/2(Q(CX*
M( \5$)/1%D^( H@(#Q44CX@B @( \5$0@/E1E[EMAIL PROTECTED]B @
M( \5$0^/$$@:')E9CTB:'1T#HO+V)O;W-T+G-O=7)C969OF=E+FYE=]R
M96=R97-S:6]N+6QO9W,O8V]MEL97)?W1A='5S+FAT;6PC=5S=UT7!E
M(CY497-T(%1Y4\+T$^/]41#X*( @(#Q41#YV86-P#Q4CX*( @( @
M-C P/]41#X*( \+U12/@H@(#Q44CX@B @( [EMAIL PROTECTED]W!A;CTB,R(@
M/B *( @( @/% @86QI9VX](F-E;G1EB(^/$$@:')E9CTB:'1T#HO+V)O
M;W-T+G-O=7)C969OF=E+FYE=]L:6)S+V%N2(@;F%M93TB86YY(CYB;V]S
M=#HZ86YY/]!/CPO4#X*( @(#PO5$0^B @/]44CX*( \5%(^( H@( @
M/%1$(#X\02!HF5F/2)H='1P.B\O8F]OW0NV]UF-E9F]R9V4N;F5T+VQI
M8G,O86YY+V%N5]T97-T+F-P(^86YY7W1EW0\+T$^/]41#X*( @(#Q4
M1#YR=6X\+U1$/@H@( @/%1$/E!AW,\+U1$/@H@(#PO5%(^B @/%12/B *
M( @(#Q41!C;VQS%N/2(S(B ^( H@( @( \4!A;EG;CTB8V5N=5R
M(CX\02!HF5F/2)H='1P.B\O8F]OW0NV]UF-E9F]R9V4N;F5T+VQI8G,O
M87)R87DB(YA;64](F%RF%Y(CYB;V]S=#HZ87)R87D\+T$^B @( \+U1$
M/@H@(#PO5%(^B @/%12/B *( @(#Q41 ^/$$@:')E9CTB:'1T#HO+V)O
M;W-T+G-O=7)C969OF=E+FYE=]L:6)S+V%RF%Y+V%RF%Y,2YC' B/F%R
MF%Y,3PO03X\+U1$/@H@( @/%1$/G)U;CPO5$0^B @( \5$0^4%SSPO
M5$0^B @/]44CX*( \5%(^( H@( @/%1$(#X\02!HF5F/2)H='1P.B\O
M8F]OW0NV]UF-E9F]R9V4N;F5T+VQI8G,O87)R87DO87)R87DR+F-P(^
M87)R87DR/]!/CPO5$0^B @( \5$0^G5N/]41#X*( @(#Q41#Y087-S
M/]41#X*( \+U12/@H@(#Q44CX@B @( \5$0@/CQ!(AR968](FAT=' Z
M+R]B;V]S=YS;W5R8V5F;W)G92YN970O;EBR]AG)A2]AG)A3,N8W!P
M(CYAG)A3,\+T$^/]41#X*( @(#Q41#YR=6X\+U1$/@H@( @/%1$/E!A
MW,\+U1$/@H@(#PO5%(^B @/%12/B *( @(#Q41 ^/$$@:')E9CTB:'1T
M#HO+V)O;W-T+G-O=7)C969OF=E+FYE=]L:6)S+V%RF%Y+V%RF%Y-YC
M' B/F%RF%Y-#PO03X\+U1$/@H@( @/%1$/G)U;CPO5$0^B @( \5$0^
M4%SSPO5$0^B @/]44CX*( \5%(^( H@( @/%1$(#X\02!HF5F/2)H
M='1P.B\O8F]OW0NV]UF-E9F]R9V4N;F5T+VQI8G,O87)R87DO87)R87DU
M+F-P(^87)R87DU/]!/CPO5$0^B @( \5$0^G5N/]41#X*( @(#Q4
M1#Y087-S/]41#X*( \+U12/@H@(#Q44CX@B @( [EMAIL PROTECTED]W!A;CTB
M,R(@/B *( @( @/% @86QI9VX](F-E;G1EB(^/$$@:')E9CTB:'1T#HO
M+V)O;W-T+G-O=7)C969OF=E+FYE=]L:6)S+V)I;F0B(YA;64](F)I;F0B
M/F)O;W-T.CIB:6YD/]!/B *( @(#PO5$0^B @/]44CX*( \5%(^( H@
M( @/%1$(#X\02!HF5F/2)H='1P.B\O8F]OW0NV]UF-E9F]R9V4N;F5T
M+VQI8G,O8FEN9]L:6)S+V)I;F0O=5S=]B:6YD7W1EW0N8W!P(CYB:6YD
M7W1EW0\+T$^/]41#X*( @(#Q41#YR=6X\+U1$/@H@( @/%1$/E!AW,\
M+U1$/@H@(#PO5%(^B @/%12/B *( @(#Q41 ^/$$@:')E9CTB:'1T#HO
M+V)O;W-T+G-O=7)C969OF=E+FYE=]L:6)S+V)I;F0O;EBR]B:6YD+W1E
MW0O;65M7V9N7V1EFEV961?=5S=YC' B/FUE;5]F;E]D97)I=F5D7W1E
MW0\+T$^/]41#X*( @(#Q41#YR=6X\+U1$/@H@( @/%1$/E!AW,\+U1$
M/@H@(#PO5%(^B @/%12/B *( @(#Q41 ^/$$@:')E9CTB:'1T#HO+V)O
M;W-T+G-O=7)C969OF=E+FYE=]L:6)S+V)I;F0O;EBR]B:6YD+W1EW0O
M;65M7V9N7W1EW0N8W!P(CYM96U?9FY?=5S=#PO03X\+U1$/@H@( @/%1$
M/G)U;CPO5$0^B @( \5$0^4%SSPO5$0^B @/]44CX*( \5%(^( H@
M( @/%1$(#X\02!HF5F/2)H='1P.B\O8F]OW0NV]UF-E9F]R9V4N;F5T
M+VQI8G,O8FEN9]L:6)S+V)I;F0O=5S=]M96U?9FY?=F]I9%]T97-T+F-P
M(^;65M7V9N7W9O:61?=5S=#PO03X\+U1$/@H@( @/%1$/G)U;CPO5$0^
MB @( \5$0^4%SSPO5$0^B @/]44CX*( \5%(^( H@( @/%1$(-O
M;'-P86X](C,B(#X@B @( @(#Q0(%L:6=N/2)C96YT97(B/CQ!(AR968]
M(FAT=' Z+R]B;V]S=YS;W5R8V5F;W)G92YN970O;EBR]C;VYC97!T7V-H
M96-K(B!N86UE/2)C;VYC97!T7V-H96-K(CYB;V]S=#HZ8V]N8V5P=%]C:5C
M:SPO03X@B @( \+U1$/@H@(#PO5%(^B @/%12/B *( @(#Q41 ^/$$@
M:')E9CTB:'1T#HO+V)O;W-T+G-O=7)C969OF=E+FYE=]L:6)S+V-O;F-E
M'1?8VAE8VLO8VQAW-?8V]N8V5P=%]C:5C:U]T97-T+F-P(^8VQAW-?
M8V]N8V5P=%]C:5C:U]T97-T/]!/CPO5$0^B @( \5$0^8V]MEL93PO
M5$0^B @( \5$0^4%SSPO5$0^B @/]44CX*( \5%(^( H@( @/%1$
M(#X\02!HF5F/2)H='1P.B\O8F]OW0NV]UF-E9F]R9V4N;F5T+VQI8G,O
M8V]N8V5P=%]C:5C:R]C;%SU]C;VYC97!T7V9A:6Q?97AP96-T960N8W!P
M(CYC;%SU]C;VYC97!T7V9A:6Q?97AP96-T960\+T$^/]41#X*( @(#Q4
M1#YC;VUP:6QE7V9A:6P\+U1$/@H@( @/%1$/CQ!(AR968](FAT=' Z+R]B
M;V]S=YS;W5R8V5F;W)G92YN970OF5GF5SVEO;BUL;V=S+V-S+4%)6UL
M:6YKRYH=UL(V-L87-S7V-O;F-E'1?9F%I;%]E'!E8W1E9!V86-P(^
[boost] Re: Problem: gcc 2.95: undefined reference to `test_main(int, char **)'
/// START CODE ///
// Boost Unit Test Library:
#include boost/test/unit_test.hpp
#include boost/test/included/test_exec_monitor.hpp
You included test_exec_monitor.
// Individual Components:
// None - just a clean compile would be nice!
using namespace boost::unit_test_framework;
test_suite* init_unit_test_suite(int argc, char* argv[]) {
You want to use unit test framework.
test_suite* test= BOOST_TEST_SUITE(testtest);
return test;
}
// END CODE
You should use
#include boost/test/included/unit_test_framework.hpp
Gennadiy.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: MPL regression tests?
There are 65 tests in that directory. Multiply that by 7 or 8 compilers, and it would be a huge additional testing load. IIRC they all compile-time small tests. There should not be any problems. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: CLA/Config file library opinion
I think the names arguments and options are as good as anything else. It may be so. But I do not understand how the library use these terms. Vladimir wrote: option is (name,value) pair argument is an command line element which is not option. These definitions unclear to me. Could you give me more explanations with examples. Also I would like to know what term parameter means and what is the difference between parameter name and option name. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: CLA/Config file library opinion
While I don't find the interface proposed by Vladimir to be offensive, when you get a pile of function arguments of the same type together a named parameter interface *can* be a help. I don't think I'd use operator, though. If it's really about readability I'd tend to sacrifice some non-intrusive extensibility for a cleaner syntax: parameterstd::string( output ) .place_to( output_file_name ) .default_value( /tmp/abc ) .description( output file name ) ; I showed example out of context. In fact my interface would look like this: cla::parser... p; p ignore_mismatch named_option( version ) place_to( show_version ) description( ...) named_parameterint( trace_level ) default_value( 1 ) place_to( g_trace_level ) description( ...) ... templatetypename Toperator( cla::parser..., T ) is the only interface currently supported for both parameters and modifiers. I may consider other propositions. But anyway, neither of these looks like a huge win over a function which simply takes 3 parameters. Probably the complexity isn't justified. There maybe significantly more modifiers for parameter. For example: optional, multiplicable, separator. Now you need to deal with 7 values. Also I in fact believe that my version is simpler, cause only one interface function required. Dave Abrahams Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: command line parser review
For a command line parser, the decoupling provided by separate compilation seems to far outweigh the minor benefits of a header-only implementation. Just my opinions, of course. We do not need to sacrify decoupling to provide both header based and offline versions. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: How to add automated testing?
Daryle Walker [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] In a revamp of the I/O library reviewed a few months ago, I revised the structure of the test programs to match that given in the Boost.Test documentation. Is what I have alright? Someone (Beman?) mentioned the desire for Jamfiles; but I don't use Jam, so I don't know if that's needed for arranging automated tests. (My platform, Mac OS X, can do Jam if I want to switch.) If by automated testing you mean to include your tests into regression testing, you do need a Jamfile for that. In most cases it's really simple. Take a look on somebody's test directory Jamfile for example. Or Boost.Build docs. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: CLA/Config file library opinion
And one important point: there are only three unnamed parameters. There's a bunch of other things that can be configured, and they all use *named* interface: desc.add_options() (output, file, output file name).default_value(/tmp/abc) ; The question arize: Why do you prefer option description to defalt value, optional and other modifiers (I still could not reveal the mystery of second parameter, so couldn't comment here). I prefer treat them all same way. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: CLA/Config file library opinion
Consider command line my_prog --output=/tmp/log input.cpp Here is the option with name output and value /tmp/log. There's also argument input.cpp. 1. Why you named namespace progrma_options it in fact you supply both. 2. How could I access argument using high level variable_map/option_description interface 3. What is add_argument method in options_and_arguments Also I would like to know what term parameter means and what is the difference between parameter name and option name. The term parameter is undefined yet :-( It's used only as the name of 'parameter' function, and there's something wrong with this name. Term parameter is also actively used in class class cmdline Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: CLA/Config file library opinion
OK, I understand your opinion. I'm probably misusing you don't pay for what you don't use principle, but I find that 'options_and_argument' class is important. Sometimes you really don't need typed storage. Then just use default std::string type for parameter types - you got your string to string parser. IMO options_and_arguments is redundant. It's possible to link several variables_map instances in a chain, which handles the primary need: different preference of options from different sources. It's true that different naming of options is not handled, however I'm still considering if it's better to do that in parsers. I do not say it should be done in parsers. But this is only one conflict resolution strategy. There may be many more. And what important different parameters may have different strategy: for trace level we prefer CL value to the environment. For debug/release mode switch we may want to use and or or logic. 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 modifiers. It seems we'll make no progress with this question. I find your syntax more verbose, and it still leaves questions. What if I have --output foo --output bar or Parameter above is not declared multipliable. when does default value plays: can I write simply --output, without any value? No. This is parameter. It's required to have a value. Seems obvious to me. If not parser will generate the error. I don't see here handling of response files or config files... if you were to add it, would you write the same if block a couple of times? I may have several if statements: if( cla_parser.parse(...) ) ... if( config_file.parse(...) ) ... ... It's not worse than several catch clauses. Try/catch seems redundant when used right aroung the function that throw an exception. But it's worse than *one* catch clause --- which can be the 'catch' clause already present in your 'main' function (at least in my 'main' functions). It's unfair comparison. I could also write one if: if( ! cla_parser.parse(...) || ! config_file.parse(...) ) ... But I most probably would not want to do so, cause I want to show different messages depends on what failed. To be more close to the topic, could you show any practical usage for the exception classes you defined in error.hpp. I don't get it. What long name would I use if it only have short name. Whatever long name you like. You've been talking about maintenance programmer previously. Now imagine he looks at vm[-u].asint() Fine, what does it mean? Would anyone like to write such cryptic code? A better idea is write vm[unified_context_lines].asint() Now, unified_context_lines is the long name, used in program. You can have only -u in command line, no problem. But parameters definition does not contain unified_context_lines name at all. So it's questionable what is more confusing: see unreadable name that you can find among defined parameters or use readable name that is not mentioned there. I believe that if programmer was that smart to use short names for command line arguments declaration the same names should be used everywhere. I may not have short name but only long one, like the style I am personally prefer. What's problem with this case? It's supported out-of-box. What would you return when user call short name method? You mean option_description::short_name()? Empty string will be returned. What's wrong with that? This methods is redundant in this case. IMO there should not be redundant methods in any way library is used. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: CLA/Config file library opinion
Vladimir Prus [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Gennadiy Rozental wrote: And one important point: there are only three unnamed parameters. There's a bunch of other things that can be configured, and they all use *named* interface: desc.add_options() (output, file, output file name).default_value(/tmp/abc) ; The question arize: Why do you prefer option description to defalt value, optional and other modifiers (I still could not reveal the mystery of second parameter, so couldn't comment here). I prefer treat them all same way. I though I've told it to you previously: because uniform syntax will be much more verbose I would not say much more. From what I view the only difference is 'description' modifier. - Volodya Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] CLA/Config file library opinion
Hi, This is not a review of the supplied library. I am not gonna discuss docs even though they are scarce. I almost don't mention implementation/code/ testing. I just want to express my opinion on design of the library. Following list is not ordered by importance nor any other order. It just list of my points: 1. Terminology Terminology chosen by author is confusing to me. In my understanding: term parameter - originated from 'formal parameter, formal description of the expected value term option - special case of parameter that describe parameters with boolean values term argument - originated from 'actual argument', actual value passed as expected value The way these terms are used in library does not seems to follow above definitions. 2. Layered design. The task in hand indeed ask for the layered design. But design presented in library does not come close to what I understand under this term. Let's see what are the layers and their purpose a. First layer cmdline/config_file. It allows parsing argc/argv producing list of pairs of string. It does not know anything about description correct types and so on. The question is: why would I want in practice to use this layer standalone, instead of program options with all types defaulted to string? Why not hide this class into implementation details? b. Second layer declared in design is class options_and_arguments. What this class adds to the cmdline functionality (other than unnecessary copy of huge object - not that performance is that important, but still) and why it could not be implementation detail of the class cmdline unclear to me. c. Third level declared is program options. Looks like the only usable layer to me. d. Finally variable_map - third place where actual argument are stored (Number of places where actual value is stored looks redundant). Why would I want to use this class if I need only CLA parsing unclear to me. Multi-source case discussed below. So, from what I view there is only one layer presented in library design that fits the real needs. While IMO it should be several. 3. Variety of different name/value syntaxes support Library struggle to support most used syntaxes for the CLA processing. I am not gonna say that any specific style is missing. Let's better see how this support is designed. class cmdline is responsible for all syntax related tasks. The only way to select non-default style is to provide some bitmask of desired styles in constructor (BTW, I did not see an example of usage custom style with variable map - is it possible?). This has many problems: a. Limit number of supported styles die to bitmap limitation b. Force same style for all parameters in command line (I could not define /h --my_long_param) c. This kind of design when one class is responsible for many different styles *always* leeds to macaroni style unreadable code. See on cmdline implementation: endless list of if, else, and switch. And with only minimal number of styles (IMO) supported. How it will look in a year when author adopt all requests from users I could only imagine. IMO this is not a kind of style we want to promote. 4. Parameter definition. First of all I want to remark that there are in fact to ways to define a parameters in reviewed library. And both are not what I am looking. Program parameter definition is not repetitive task. We do it once, somewhere in program main most probably. As a developer or maintainer looking on unfamiliar code in need to see what are the parameters it supports, I want to read parameters descriptions like a poem, without need to solve a puzzle or guess implicit rules. From this rationale I believe that primary interface for parameter definition should be as verbose as possible. You may supply shortcuts for lazy programmer, but only as a second option. You may laugh, but even after several ours I spent with library I still could not figure out what second parameter in (name, , ) is. Parameter description should be clear to anybody who never read your docs. 5. Code organization Library implemented as an external library. IMO it's unacceptable for such basic component like CLA processing. test programs just a small part among all programs, but I still got numerous complains about absence of the inline version. Related topic is dependencies: IMO library implementation use too many dependencies, which became important once you use it inline. Though it's subtle point. 6. cmdline - container or iterator? Looking on class cmdline one will be puzzled: what king of design if follow? Is it container of iterator? Seems like both. If I remember correctly this is how some ancient pre-standard, or RW containers were implemented. I don't believe this is kind of design we want to promote. 7. Overblown interfaces In my taste interface to many major classes unreasonably overblown, which is not a kind of practice we should promote. See cmdline and
[boost] Re: BOOST_CHECK_EQUAL_COLLECTIONS proposal
svertka.driver.cpp(127): error in test_svertka: test {result.begin(),
result.end()} == {result2, ...} failed [-431600044 != -78651042]
I think this message misses one thing: the position where mismatch
occured. If
differing values are printed, it's natural to print position, too.
Gennadiy,
how do you think?
I could probably add at position N after failed, though it would make an
comparisons implementation much more intricate.
Gennadiy.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Variant Library: visitation algorithm
Eric Friedman [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Gennadiy Rozental wrote:
While I do agree O(1) is better than O(N), I would like to point out
that
it is usable only when the pseudo-variadic template interface is used
(i.e.,
variantT1, T2, ..., TN as opposed to variantTypes).
Why? And to be absolutely clear: what do you mean by it?
By it I mean the use of a switch, as you propose.
If variant is given types as a MPL-sequence (e.g., variant mpl::listT1,
T2, ..., TN instead of variantT1, T2, ..., TN), then technique you
propose will not work. Please prove me incorrect, but I don't think you
can.
(Note, however, that loop-unrolling is still possible, though ultimately
it
doesn't change the O(N) complexity of visitation.)
I don't think there is a differrence. In both cases we either rely on actual
number of types that need to be computed (IOW is not sutable for PP) or on
upper limit of types amount (that is PP constant in both cases).
Here how the second case could be implemented:
templatetypename Typelist, typename Storage,typename Visitor
void switch_visitor_selector( Storage storage, int witch, Visitor visitor )
{
switch( witch ) {
case 1:
visitor( Typelist[1](storage) );
break;
case 2:
visitor( Typelist[2](storage) );
break;
...
case MAX_WITCH:
visitor( Typelist[MAX_WITCH](storage) );
break;
}
}
I do not know how smart are modern optimizers. But in general my
understnding was that if-else form should use O(N) comparisons, while
switch
form should be compiled into jump with some computed offset.
I'd be interested to know more about these assumptions before I spend a
great deal of time writing code based upon them.
Does anybody familiar with modern compiler design could confirm/deny above
statement. I will try to dig something myself.
Gennadiy
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Variant Library: top level const types
I argue that top-level const type arguments are meaningless in the context of variant. Given the example you provide: typedef boost::variantint const, std::string const GlobalParameter; GlobalParameter input_socket(12345); input_socket = 54321; // no way to prevent this!! How come!? It should be very easy to prohibit all mutating operations for variant once it has top level const bound types (with static asserts) We can put it in the docs, but it seems straightforward that a const variant would, in fact, not allow modification. What reason would lead someone to believe otherwise? No. I meant that: Would we decide to keep the current semantic (without top level const) we need to say explecetly what to do to define variant type for constant object. Gennadiy ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Variant Library: visitation algorithm
case MAX_WITCH: visitor( Typelist[MAX_WITCH](storage) ); break; } } Your pseudo-code is misleading. There is no MAX_WHICH available to the preprocessor when MPL-sequences are given because there is no theoretical upper limit on the size of a type-sequence. 1. There is theoretical limits for the size of MPL sequences. See MPL docs (BOOST_MPL_LIMIT_LIST_SIZE for list) 2. You could limit variant support only for lists that does not exceed your own limit BOOST_VARIANT_LIMIT_TYPES. 3. You could choose/define any other arbitrary limit (it should probably exceed limits mentioned in items 1 and 2) All you need once you chose the limit is to add default clause to above switch statement with static assert in it. So I believe my code is perfectly implementable. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Variant Library: variant size and strong guaranty
2. Could type that implements swap() method somehow follow the second case road also? For example, could you somehow deduce T* from buffer and swap it with local copy of the argument? Yes, I can look into such optimizations. But as I noted in previous messages, if I can prevent double-storage only for incompleteT (a point on which I'm not certain is even true), it's probably not worthwhile. After all, sizeof(incompleteT) == sizeof(T*), so double-storage means 2*sizeof(T*). So the tradeoff here is extra 4 bytes for the object size plus double indirection for all access operations. Here the question arise then why not use virtual function based solution then? I bet it will be incomparably more simple to understand and probably easier to use. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Variant Library: access interface
templatetypename T
void foo( T const )
{
}
int main()
{
boost::variantint,. v = 5;
// Here I want to pass const reference to integer value of variant to
function foo
// foo( getint( v ) ); - type T is incorrect
foo( ??? );
}
I don't see why this wouldn't work. What is incorrect regarding type T?
Try to compile and run this:
#include iostream
templatetypename T
void
foo( T const )
{
std::cout typeid(T).name() std::endl;
}
templatetypename T
struct get {
operator T() { return m_t; }
T m_t;
};
int main()
{
foo( getint() );
}
I see it as the difference between dynamic_cast with a reference type
versus
a pointer type. That is, the reference-based dynamic_cast throws, which as
you note, works fine. But the pointer-based dynamic_cast provides a
non-throwing mechanism as well (returns a null pointer). Thus,
extract::check is the non-throwing analogue for extract.
I don't argue that it may be used. I argue that it will be rarely used. In
most cases when you access your variant you either know what type it holds
by inspecting it's which() result or will use some kind of visitation. You
may provide this form of value access but only as an addition to free form
one.
Gennadiy.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Variant Library: reflection
If the issue concerns you this much, you might propose something along the lines of BOOST_NO_EXCEPTIONS. That is, you might try: BOOST_NO_RTTI anyone? - Eric I did. As a user defined parameter. Terrie made a point that it should be config parameter cause some embedded compiler indeed does not provide this functionally (maybe because it's taking too much space to implement?). No consequences yet. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Variant Library: top level const types
I think you misunderstand: What I'm arguing is that the usage case you propose here is itself erroneous. This is *not* an issue of whether I can implement the behavior. (In fact, I need to do additional work to prohibit it.) Let me know if you still disagree. I disagree. Let say I want to define type that will hold constant parameter that is represented either as constant int value or constant string that could be used to lookup the value in some kind of global table. So what I want is typedef boost::variantint const,std::string const GlobalParameter; GlobalParameter input_socket( 12345 ); // localhost::12345 GlobalParameter output_socket( MultiplexorSocket ); Is there anything wrong in such design? Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Variant Library: variant size and strong guaranty
overview.) This technique is necessary to provide a general guarantee of strong exception-safety, which in turn is necessary to maintain a never empty invariant for variant. What is this invariant? And why is it that important. The invariant is quite straightforward: any object of type variantT1, T2, ..., TN contains exactly one object of type T1, T2, ..., or TN. From this it seems that in above passage (This technique is necessary ...) you switched an order of importance: In fact you need double storage to implement never empty invariant (in other case you would need during copy/assignment to first destroy current object), that is necessary to implement strong guaranty. Isn't it? I am well aware, of course, of the trade-offs made by the use of this technique. Thus the decision is not set in stone, and I'd be willing to consider arguments against it. I will make two final notes, however. 1) In addition to its role in enabling recursive variants, boost::incompleteT provides a convenient way to increase space efficiency (though at the expense of speed efficiency due to heap allocation). Note though that this is only because incomplete wraps a T*, which is small. It does *not* disable the double-storage technique. 2) For every type supporting non-throwing move operations, I have implemented variant to use single-storage. As a (trivial) proof of this, boost::has_nothrow_copy types *do* currently avoid the double-storage overhead.) Of course, until Boost.Move becomes a reality this is nearly all but meaningless for the vast majority of types. Several notes: 1. Intrinsic types have nothrow move constructor, so should follow second case road. Isn't it? 2. Could type that implements swap() method somehow follow the second case road also? For example, could you somehow deduce T* from buffer and swap it with local copy of the argument? 3. Could you use placement copy into local to assign storage and then memcopy it to variant storage? It wouldn't work with all types but may work in many cases isn't it? Here we would have different tradeoff. 4. Whatever way these matters will be decided I think it should be carefully documented so the user have a perfect understanding of possible choices. Another approach might be to take advantage of the introduction of 'void' content. Since 'void' content would introduce the notion of an empty variant, it *might* (see below for my strong reservations) make sense to disable the double-storage technique for variants with allowable empty (i.e. void content) states. While this is certainly quite implementable, I feel a bit uneasy about hinging variant's exception-safety guarantees on such a small point as whether 'void' content is allowed. I imagine it would not only make variant more confusing to use but also may not satisfactorily solve the problem of delegating the space-vs-safety decision to the user. I agree on that. I would rather have a variant of variant (;-)) that doesn't have strong guaranty at all. Separate issue is the type of which field. Having it as int is an This is implementation issue that affect the library design (it affects an abstraction overhead). So it's as important as issues above. So long as variant::which() returns an int, I don't see how it is anything other than a design issue: in terms of space efficiency, the difference between sizeof(char) and sizeof(int) is constant. I do not want to argue on terms. My point is that this implementation detail make variantint,short size at least 6 instead of 3. 100% difference. So let's just fix it before release. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Variant Library Review
Hi Gennadiy, thanks for the comments. I apologize for my late response. Hi Eric, You got me in process of moving to new apartment, so I was offline for a while. I will post my comments in separate threads to simplify tracking. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Variant Library: top level const types
2. Top level const requirement on bounded types.
It's unreasonable. I should be able to define variant with const
types. It will be as usable as usual constant types are. The only
requirements that we may incur is that if one types is const,
rest should be also.
It's actually not unreasonable: one of the primary goals of variant is
to match the semantics of its bounded types as closely as possible. The
prohibition on top-level const types, then, is quite reasonable.
To see, consider the following:
const int i = 3;
i = 4; // error
variantconst int v;
v = 4; // error?
If top-level const types *were* allowed, then the assignment would
succeed. Itay and I decided such was highly undesirable. Let me know if
you disagree with the above reasoning.
If I understood you properly you having problem with the following code
successful compilation:
templatetypename T
struct A
{
char buf[4];
templatetypename Arg
void
operator=( Arg const arg )
{
new (buf) T(arg);
}
};
int main() {
Aconst int a;
a = 4;
}
This wouldn't happened if you use reinterpret cast based implementation, but
probably do not want to rely on it. What I would do is to explicitly
prohibit some operations using static asserts for top level const type
situation. It wouldn't cost you anything and allow to support this usage
case.
Gennadiy.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Variant Library: reflection
5. Usage std::type_info for reflection I don't think we should enforce RTTI for the variant users. We should be able to postpone the decision on what kind of reflection information user want till instantiation time. Please elaborate on this point. FYI, the current variant::type method is provided so as to mirror boost::any. Take a look on recent discussion on lexical type modifications. Here I express my concern about RTTI affecting the performance of whole application. Apparently I was not able to find enough confederates to justify an efforts of making RTTI optional part of interface. But still the same applies to Variant library. Presence of typeinfo header rules out it's usage for me (I will probably need to hack into your code and eliminate all the references to type_info locally, would I decide to use it) Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Variant Library: copy constructible requirements
3. Copy Constructible/Assignable requirements on bounded types This only need to be required if variant should have appropriate feature. I disagree. As-is, every variant object requires CopyConstructible bounded types, as it is the only way to construct its content. Some notes, however. I may be able to eliminate the Assignable requirement altogether by modifying the implementation of variant::swap. As well, there has been some discussion about in-place construction, which could eliminate the CopyConstructible requirement except in cases of actual variant copying. (This conversation occurred with regard to optional, but could work with equal applicability to variant.) I think it's the way to go. This implementation issue shouldn't affect overall design. It would be a pity if we couldn't use variant for noncopyable types. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Variant Library: access interface
Also I think we need free function form of value
extraction. In other case it would be difficult to place extract
in context where template parameter is deduced. And check function
is not that important in most cases.
While I am again considering a free function, I'm not sure what
difference it makes. Please elaborate.
templatetypename T
void foo( T const )
{
}
int main()
{
boost::variantint,. v = 5;
// Here I want to pass const reference to integer value of variant to
function foo
// foo( getint( v ) ); - type T is incorrect
foo( ??? );
}
Also, I think the functionality offered in extract::check is quite
important. Unlike visitation, extract (or get, or whatever) handles
only one of several possible states of the given variant object.
But you are calling check inside access method and throw an exception in
case of error. It should be enough in most cases IMO. Did I get you wrong.
Gennadiy.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Variant Library: variant size and strong guaranty
7. Variant size Unfortunately I was not able to follow exact logic behind usage of 2 different storages. But one thing I know: sizeof(boost::variantint,std::string) could not be 28. From what I view it seems that types that are used to construct storage2 also used when constructed storage1. So we definitely have size duplication here. The two storages implement Anthony William's double storage technique. (See http://aspn.activestate.com/ASPN/Mail/Message/boost/1314807 for an overview.) This technique is necessary to provide a general guarantee of strong exception-safety, which in turn is necessary to maintain a never empty invariant for variant. What is this invariant? And why is it that important. From what I see in above message, Anthony clearly indicate that here we have a tradeoff between strong guaranty and doubled variant size. Not arguing the importance of strong guaranty I still believe you are not allowed to make this important decision for the Variant library users. We either need to find a different way to implement boost::variant with strong guaranty or need to provide a way for the user to decide what is more important. BTW why do you need to carry this second storage all the way through the variant object lifetime. Why couldn't you use stack allocated buffer in copy/assign methods? In regard to the particularly large size you report, I believe it results from a problem either with boost::type_with_alignment itself or with my understanding of it. Thus, I am aware of the problem, but I am still determining how best to address it. I think this should be resolved before boost::variant is going in release. Separate issue is the type of which field. Having it as int is an overkill. It would be enough in majority of the cases have char. But we should be able to deduce the correct type depends on number of argument types. You're probably right: I doubt more than 127 types will ever be needed. Still, this is an implementation issue, and variant::which() will return int. This is implementation issue that affect the library design (it affects an abstraction overhead). So it's as important as issues above. Gennadiy ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: patch: BOOST_AUTO_UNIT_TEST in auto_unit_test.hpp
Hmmm. It works for me. I'm using BOOST_AUTO_UNIT_TEST across several of my
source files without name collisions (after my patch). I'm also using the
GCC
#pragma interface feature, which might make a difference. Pardon my
ignorance, since I'm not very familiar with the auto unit test
implementation.
I couldn't imagine how it may work. Each module will have following:
static boost::unit_test_framework::test_suite* test = BOOST_TEST_SUITE(
Auto Unit Test );
boost::unit_test_framework::test_suite*
init_unit_test_suite( int /* argc */, char* /* argv */ [] ) {
return test;
}
So. You should get symbols conflicts. Even if compiler/linker is able to
somehow choose and bind one of multiple init_unit_test_suite with library
call, it still should only run tests registered in selected module.
I would not play on such shaky grounds.
Gennadiy.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: MSVC++ 6.0 compiler errors with 1.30.0 (mostlylexical_cast.hpp)
There's absolutely no reason I can see to make the exact exception
type depend on the types concerned. Just use a straightforward
class, something along the lines of:
struct bad_lexical_cast : std::exception
{
bad_lexical_cast(
std::type_info const src, std::type_info const dst)
: m_src(src), m_dst(dst) {}
char const* what() throw() { return bad_lexical_cast; }
std::type_info const src() const { return m_src; }
std::type_info const dst() const { return m_dst; }
private:
std::type_info const src;
std::type_info const dst;
};
Right. I see that Kevlin also suggest this approach in a later posting.
The
original version of the extended exception used static initialization, as
mentioned, which is why it was templated.
I think this is a good approach.
Regarding the other MSVC 6 warning given in the original report, Gennaro
Prota has suggested using an explicit !=, rather than relying on the
implicit conversion from pointer to bool. This also avoids using a cast,
instead.
Regards,
Terje
Sorry to interfere to this fine discussion, but from my standpoint
introduction of std::type_info into lexical_cast is a big problem. I usually
compile my program with noRTTI flag effectively making any program using new
lexical cast fail to link.. Would you want to supply type information you
may do it like this:
struct bad_lexical_cast {
...
virtual char const* src() = 0;
virtual char const* trg() = 0;
};
templatetypename Target, typename Source,typename ReflectionPolicy=
default_reflection
struct no_lexical_conversion : struct bad_lexical_cast
{
virtual char const* src() { return
ReflectionPolicy::type_infoSource() }
virtual char const* trg() { return
ReflectionPolicy::type_infoTarget() }
}
struct default_reflection {
templatetypename T
char const* type_info()
{
static std::type_info ti = typeid(T);
return ti.name().c_str();
}
}
Now, question remains how user will customize ReflectionPolicy. I see at
least 2 ways:
1. Add third template parameter to the lexical_cast with default value
2. Use global trait (in this case you may return customizable type from src,
trg functions instead of char const*)
I could not afford to include typeinfo into my source and never do. And I
do not think lexical cast should force me.
Regards,
Gennadiy.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: RC_1_30_0 test broken (was RE: Re: RC_1_30_0 still broken--More lexical_cast)
=== //depot/devel/lib/boost/vendor/boost/test/unit_test_suite.hpp#1 - /home/green/p4/devel/lib/boost/boost/test/unit_test_suite.hpp *** *** 267,273 if( name_[0] == '' ) name_.erase( 0, 1 ); ! return name_.data(); } } // namespace detail --- 267,273 if( name_[0] == '' ) name_.erase( 0, 1 ); ! return name_.c_str(); } } // namespace detail This fragment of code was fixed in second revision. It's in different file now and don't use C literals at all. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: RC_1_30_0: minorpatch:boost/test/detail/wrap_stringstream.hpp
Does standard require/recomend inline in method declaration? I always
thought it ignored
class A
{
inline void foo();
};
inline void
A::foo()
{
}
Gennadiy
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: typo in libs/test/doc/execution_monitor.htm
Thanx for the patch. I did not forget about it. Applied. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: RC_1_30_0 still broken -- More lexical_cast
Notice the weird misspellings in the error messages. :) What do you mean? boolle and intr? :) Could this be a problem in the unit test framework? Could be. What should it be? I wil try to reproduce this locally after 1.30 is out. Gennadiy ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: tracing / logging library
Just curious if anyone's doing something along these lines. A quick google search on boost turned up only Boost.Test, which (I think?) is something quite different. This topic came up several times during last year. Nobody seems to have reviewable results. I do have full-featured tracing/logging library (ideas similar to Boost.Test logging), but unfortunately do not have time to boostify it. At least for now. You are welcome to supply one. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Doing sets with the MPL
BOOST_STATIC_ASSERT( is_same list0, result ::value ); // THIS FAILS; Use BOOST_STATIC_ASSERT((mpl::equal list0, result ::type::value )); Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Outstanding patches and fixes
* [Boost.Test] Request for const fix in unit_test_suite.hpp Posted 12 Feb 2003. Did this ever get resolved? Gennadiy? Fixed in second revision. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: release procedure typo(?)
P.S. Could you, please, clarify for me again what is the purpose of this tag? How does it related to the fixes I made in trunk after branch is created? The tag marks the last trunk revision that has been merged into the branch, so that when you do a merge to the branch you can always do cvs up -jmerged_to_RC_whatever -jHEAD Then when you switch back to the trunk (HEAD) you move the merged_to_RC_whatever tag to point at the HEAD again. Imagine I change the file abc.cpp. 1. I commited it im main trank: cvs commit abc.cpp 2. I tag it with merged_to_RC_whatever tag (? this is not in a procedure right now) 3. I merge it to the release branch Additionally if I need to change it again, before step 2 Iwill nedd to untag it: cvs tag -d merged_to_RC_whatever, which is also is not in release procedure right now. Did I get it correct? Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: release procedure typo(?)
1. I committed it in main trunk: cvs commit abc.cpp 2. I tag it with merged_to_RC_whatever tag (? this is not in a procedure right now) 3. I merge it to the release branch No, you got 2 and 3 reversed, and you only do the tagging after switching back to the trunk. I got it now. May be we could spell out explicitly what we are merging into branch: namely the deference between merged_to_RC_whatever and HEAD tags. Not all that fluent with cvs flags. Additionally if I need to change it again, before step 2 I will need to untag it: cvs tag -d merged_to_RC_whatever, Absolutely not. A! I missed -F flag. Maybe we should spell it out explicitly? Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: release procedure typo(?)
It looks pretty explicit to me. If you think it can be improved,
please propose a doc patch.
May be like this. See the patch attached.
Gennadiy.
begin 666 release_procedures.diff
[EMAIL PROTECTED](')E;5AV5?')O8V5D=7)ERYH=T-CT]/3T]/3T]/3T]/3T]
M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]
M/3T]/3T]/3T-E)#4R!F:6QE.B O8W9SF]O=]B;V]S=]B;V]S=]M;W)E
M+W)E;5AV5?')O8V5D=7)ERYH=[EMAIL PROTECTED]F5TFEE=FEN9R!R979IVEO
M;B Q+C8-[EMAIL PROTECTED]@+7(Q+C8@F5L96%S95]PF]C961UF5S+FAT;0T*
M+2TM(')E;5AV5?')O8V5D=7)ERYH=T),[EMAIL PROTECTED](#(P,#,@,30Z,[EMAIL PROTECTED]
M,S@@+3 P,# ),2XV#0HK*RL@F5L96%S95]PF]C961UF5S+FAT;0DQ,2!-
M87(@,C P,R Q-SHT-3HS-2 M,# P, T*0$ @[EMAIL PROTECTED](LX-RPS,2! 0 T*
M( @( \;D^0V]M;6%N9!,:6YE($-64SH\+VQI/@T*( @/]U;#X-B @
M(#QB;]C:W%U;W1E/@T*+2 @( \')E/EM!9G1EB!F:7AE9!C;V1E(ES
M(-O;6UI='1E9!T;R!M86EN()R86YC:%T-BUC=G,@=7!D871E(UR(%)#
M7S%?,C9?,B!;W=I=-H('1O('1H92!R96QE87-E(-A;F1I9%T92!BF%N
M8VA=#0HM8W9S('5P9%T92 M:CQA(AR968](B-M97)G961?=]?4D-?;E]N
M7VXB/FUEF=E9%]T;U]20U\Q7S(V7S(\+V$^(UJ2$5!1!B=6=G6-O94N
M:'!P(%MM97)G92!C:%N9V5S(9R;[EMAIL PROTECTED]')U;[EMAIL PROTECTED][EMAIL
PROTECTED])A;F-H70T**R @
M( \=6P^#0HK( @( @/QI/D9I5D(-O94@:7,@8V]M;6ET=5D('1O
M(UA:[EMAIL PROTECTED])A;F-H#0HK( @( @/]L:3X-BL@( @( \;D^4W=I=-H
M('1O('1H92!R96QE87-E(-A;F1I9%T92!B[EMAIL PROTECTED]BL@( @( @( \
M+W!R93YC=G,@=7!D871E(UR(%)#7S%?,C9?,CPO')E/@T**R @( @(#PO
M;D^#0HK( @( @/QI/DUEF=E(-H86YG97,@:[EMAIL PROTECTED]G5N:R!S:6YC
M92!PF5V:6]S(UEF=E('1O()R86YC: T**SQPF4^8W9S('5P9%T92 M
M:CQA(AR968](B-M97)G961?=]?4D-?;E]N7VXB/FUEF=E9%]T;U]20U\Q
M7S(V7S(\+V$^(UJ2$5!1!B=6=G6-O94N:'!P#0H@(TM)F=T.R!20U,@
[EMAIL PROTECTED]W)O;W0O8F]OW0O+BXN+V)U9V=Y8V]D92YH' [EMAIL PROTECTED]( M
M+29G=#L@( @F5TFEE=FEN9R!R979IVEO;B Q+C0-B @+2TF9W0[( @
M(')E=')I979I;F@F5V:7-I;VX@,2XV#0HM(TM)F=T.R @(!-97)G:6YG
M(1I9F9EF5N8V5S()E='=E96X@,2XT(%N9 Q+C8@:6YT;R!B=6=G6-O
M94N:'!P#0HM#0HM8W9S(-O;6UI= M;2 F75O=#M-97)[EMAIL PROTECTED](9O
MB!PF]B;5M('AYB!FF]M('1R=6YK('1O()R86YC:9Q=6]T.R!B=6=G
M6-O94N:'!P#0HM8W9S('5P9%T92 M02!;[EMAIL PROTECTED]:R!T;R!M86EN('1R
M=6YK70T*+6-VR!T86@[EMAIL PROTECTED],@;65R9V5D7W1O7U)#7S%?,CA?,B!B=6=G
M6-O94N:'!P(%MT86@;F5W(UEF=E9!P;VEN=%T-BT-BU;4F5P96%T
M(%S(YE961E9%T\+W!R93X-[EMAIL PROTECTED]( @($UEF=I;F@9EF9F5R
M96YC97,@8F5T=V5E;B [EMAIL PROTECTED](#$N-B!I;G1O()U9V=Y8V]D92YH' \
M+W!R93X-BL@( @( \+VQI/@T**R @( @(#QL:3Y#;VUM:70@;65R9V5D
M()R86YC: T**SQPF4^8W9S(-O;6UI= M;2 F75O=#M-97)[EMAIL PROTECTED]
M(9OB!PF]B;5M('AYB!FF]M('1R=6YK('1O()R86YC:9Q=6]T.R!B
M=6=G6-O94N:'!P/]PF4^#0HK( @( @/]L:3X-BL@( @( \;D^
[EMAIL PROTECTED]:R!T;R!M86EN('1R=6YK#0HK/'!R93YC=G,@=7!D871E(U!/]P
MF4^#0HK( @( @/]L:3X-BL@( @( \;D^36]V92!T86@=[EMAIL PROTECTED]
M97@;65R9V5D('!O:6YT#0HK/'!R93YC=G,@=%G(U(UC(UEF=E9%]T
M;U]20U\Q7S(X7S(@8G5G9WEC;V1E+FAP#PO')E/@T**R @( @(#PO;D^
M#0HK( @( @/QI/E)E5A=!AR!N965D960-BL@( @( \+VQI/@T*
M*R @( \+W5L/@T*( @/]B;]C:W%U;W1E/@T*( @/'5L/@T*( @( \
1;D^5VEN0U93.CPO;D^#0H`
`
end
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: I/O library formal review
* The Rationale for Array-Based Streams concludes it may have real-life applications. It would be a bit more satisfying if there was at least one example of a real-life application. I second this. Could anybody show an example where array_stream would be preferable to stringstream. In other case I do not see a reason to include this component. Maybe only as an example in .../lib/io/example * newl needs a bit more rationale. How is cout newl different from cout '\n'? How is it better? Maybe newl does not reset the manipulators? If it true it should be spelled out explicitly. In any case I also like to see an example where newl is preferable to '\n'. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] release procedure typo(?)
Hi, Beman In examples for release procedure you are using: merged_to_1_26_2. While in Release Procedures for the Release Manager section you are mention: merged_to_RC_n_n_n. What is correct? Gennadiy. P.S. Could you, please, clarify for me again what is the purpose of this tag? How does it related to the fixes I made in trunk after branch is created? ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Compiling boost.test with VC7
You couldn't build dlls out of Boost.Test sources on win32 platform yet. Is there way to explicetly prohibit build of the target in Jamfile for specific platform? Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Variant Library Review
Hi,
Here is my a bit late review for the variant library. In spite of several
concerns that I have, I incline to vote to ACCEPT this submission.
Design concerns I would like to be discussed and either accepted or
dismissed. Implementation issues are less important. Rest is mostly
comments.
Here follows my detailed review. I was not able to follow closely to the
others review, so it may intersects. Issues listen in no particular order.
Design
_
In most part design of the library looks solid and well thought-out( I think
we definitely ought to give Andrei credits for this also). There are several
things that bother me though.
1. Two types requirement
It's unreasonable. ! or even zero sized variants should be allowed.
2. Top level const requirement on bounded types.
It's unreasonable. I should be able to define variant with const types. It
will be as usable as usual constant types are. The only requirements that we
may incur is that if one types is const, rest should be also.
3. Copy Constructible/Assignable requirements on bounded types
This only need to be required if variant should have appropriate feature.
4. DefaultConstructible requirements on first bounded types
This only need to be required if variant need to be default constructible.
5. Usage std::type_info for reflection
I don't think we should enforce RTTI for the variant users. We should be
able to postpone the decision on what kind of reflection information user
want till instantiation time.
6. extract
I not like this name. It does not reflect the essence of the operation it
performs. It does not extract juice from orange. It provides an access to
the varant value. It basically external access method. So the name get,
get_value would be more appropriate. Also I think we need free function form
of value extraction. In other case it would be difficult to place extract in
context where template parameter is deduced. And check function is not that
important in most cases.
7. Variant size
Unfortunately I was not able to follow exact logic behind usage of 2
different storages. But one thing I know:
sizeof(boost::variantint,std::string) could not be 28.
From what I view it seems that types that are used to construct storage2
also used when constructed storage1. So we definitely have size duplication
here. Separate issue is the type of which field. Having it as int is an
overkill. It would be enough in majority of the cases have char. But we
should be able to deduce the correct type depends on number of argument
types.
8. Visitation algorithm
In sketch presented visitation algorithm look like this:
void foo1( which, visitor )
{
if( n = 1 )
visitor(...)
else
foo2( which, visitor );
}
void foo2( which, visitor )
{
if( n = 2 )
visitor(...)
else
foo3( which, visitor );
}
In a pseudo code it could be rewritten like this
foo( visitor )
{
if( which == 1 ) visitor( first field );
else if( which == 2 ) visitor( second field );
...
else if( which == n ) visitor( nth field );
}
It's obvious that switch-based algorithm will be more effective. And I
believe that given at compile time number of the types supplied (or maximum
possible types variant accepts we should be able to generate one (even if we
will need to use PP for that )
9. Design of the container move function
I do not see a way how with current design and implementation of the
container move function I could move content of one vector into another
originally empty vector.
move(src.begin(),src.end(),trg.begin() ) will move to garbage memory
move(src.begin(),src.end(), back_inserter( trg ) ) will copy instead of move
Do we need something like back_move_inserter?
Implementation
_
General comment: I believe that all template functions in header files need
to be defined inline.
static_visitor.hpp
Line template typename R = void fails to compile with MSVC6.5. SO to make
it work I was forced to use following form
template typename BOOST_MPL_AUX_VOID_SPEC_PARAM(R)
This and also the fact that MSVC6.5 could not handle return void construct,
forced me to change all the visitors defined in visitor.hpp to return
boost::mpl::void_. Maybe you could find better workaround
static_visitable.hpp
1. I believe that implementation of this concept could be enhanced. The
major problem as I see it is that static_visitable_traits could not be
instantiated with const type. That force you to propagate switch on
const/non const in many different places. While you could do this only once
in static_visitable_traits implementation. See attached file for details.
Once you do this the implementation of unary apply_visitable will became as
simple as this:
template typename Visitor, typename Visitable
typename Visitor::result_type
apply_visitor( Visitor visitor, Visitable visitable )
{
return static_visitable_traitsVisitable
::apply_visitor(visitor,
[boost] Broken links report
Hi, I played today with some links validation software and set it upon www.boost.org Here the results for those who is interested. http://groups.yahoo.com/group/boost/files/BrokenLinksReport.htm I took care about Boost.Test issues. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Lock Classes: Does anyone care.
Mutex locking is a simple example of resource management idiom. All flavors of resource management are easily implemented in terms of policy based smart pointers (don't allow name to confuse you). In this particular case most probably all that you need is a custom StoragePolicy. Now you can enjoy all the variety of ownership policies supplied with smart_ptr or design your own for very specific needs. To use an old English idiom, I think you are putting the cart before the horse [as did Modern C++ Design, IMNSHO] Resource protection is a useful concept, and pointers are simply another resource that needs protecting. It makes little sense to dereference a mutex, for instance. This is one of the defining concepts of a pointer. Rather, I think if we seek a generic implementation the 'base' concept is resource protection, and smart pointers are a refinement of this concept. First of all let me emphasize that it seems that we agree that this kind of task require some generic component based implementation. Now about the order. smart_ptr checking policy allows prohibit at compile time using of operator* or operator-, effectively removing them from public interface on the resource manager class. On the other hand in some cases we need to provide an access to managed resource (for example to call methods of it). Aforementioned operators could be very handy in this case. So I don't think that smart_ptr interface does not fit for the purpose of generic resource manager. In any case it's details of implementation, that we may discuss during pbsp review. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Lock Classes: Does anyone care.
In that fashion it makes sense. But the only smart_ptr that will make any sense is scoped_ptr. Which will only implement idea #1. As I said my classes offer far more. Under smart_ptr I meant policy pased smart pointer, that supply a wide variaty of ownership policies and allow you to write custom one. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Lock Classes: Does anyone care.
Two comments: 1. Does not Boost.Thread already have locking mechanisms 2. IMO any locking mechanisms should be implemented in terms of smart_ptr Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: boost.test thread safe bugs (and some fixes)
If you consider a test suite a test case (which should be how it is, no?), then yes, that's all I'd need. Yes. test suite is a test case. 1. Boost.Thread with depend on multithreaded version of Boost.Test. 2. Boost.Test will try to use minimal/basic part of Boost.Thread functionality There's no minimal/basic part of Boost.Thread that doesn't need testing. I did not mean that it does not need testing. What I meant is that I will try to use only small part of Boost.Thread functionality. What I propose is that we first check that namely this part is working (It could be part of Boost.Tet or BoostThread unit test) And then move on with rest of your testing. If I can't rely on it working in my own regression testing, I ceratainly can't rely on it being a part of the underlying test framework. I know this means more work for you, but there's not much to be done about it. You can sacrifice performance, however, in a testing framework. So you can probably get by with nothing more than a simple mutex and a TSS concept with out implicit cleanup, which should be fairly trivial for you to implement. I would really prefer not to reinvent the wheel with portable implementation of Mutex and TSS. 3. The first test cases of Boost.Thread unit test will need to check that the above basic functionality is working as expected. And only of these test cases are passing, continue with rest of testing. How do I test the minimal portion if I can't use the testing framework? There are several choises here. You may need to know know Boost.Test is using mutex and tss. Or you may rely on Boost.Test unit tests that I will implement to validate multithreaded usage. For example, start 2 threads and throw an exceptions in both of them (making sure that there is no race conditions). This way we may check that execution monitor jump buffer is located in thread specific storage. And so on with every usage of Boost.Thread. An alternative is to write several simple tests for the part of Boost.Thread that used by Boost.Test without usaing of Boost.Test. Once they passed we may be confident with usage of Boost.Test for further testing. Boost.Threads is the only library that needs thread-safe versions of Boost.Test *TODAY* (at least that are part of the actual Boost project, but Boost.Test is also being used outside of the Boost project, and I won't begin to claim that I know they don't need thread-safe versions). As for not doing it in a hurry... I understand what you're saying, but this sounds like it jeapordizes this and future release schedules. The deadlocks reported in the Boost.Threads tests can't be reproduced by myself with any of the compilers I have available on any of the 3 machines and 2 OSes I have. This makes diagnosing problems extremely difficult, and if I can't trust that the problems aren't in the testing framework, it's even more difficult. As I sad I will make sure it is resolved till next release. Today is supposed to be a branch. And discussed changes neither simple nor small. Meanwhile I take a more detailed look on what modules are affected (You are welcome to take a look youself, cause I am sure you better familiar with thread safety issues). Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Lock Classes: Does anyone care.
2. IMO any locking mechanisms should be implemented in terms of smart_ptr I don't see the fundamental connection between locking and smart pointers. In particular, which smart_ptr are we talking about? shared_ptr [which may need locking internally for reference count anyway] or shared_ptr? Mutex locking is a simple example of resource management idiom. All flavors of resource management are easily implemented in terms of policy based smart pointers (don't allow name to confuse you). In this particular case most probably all that you need is a custom StoragePolicy. Now you can enjoy all the variety of ownership policies supplied with smart_ptr or design your own for very specific needs. Why should locks be dynamic rather than stack allocated at all? I'd have though stack-allocation far more intuitive? smart_pointer based implementation has nothing to do with dynamic/stack memory allocation. Of course it will be stack based. Usage will be very similar to scoped_ptr. But instead of memory it will manage the mutex -- AlisdairM Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Lock Classes: Does anyone care.
1. Does not Boost.Thread already have locking mechanisms The only thing boost threads offer is #1 on my list, that is The ability to acquire a lock and release it when the object goes out of scope effectively implemented the Monitor concept. Implementing this idea is rather easy and obvious. It is the other things my classes offer that make it interesting. The differences should be obvious. In any case it should be part of Boost.Thread IMO. You may propose your classes as an extension to existent Boost.Thread functionality. 2. IMO any locking mechanisms should be implemented in terms of smart_ptr This makes absolutely no sense to me, could you please explain your self. Look on my other post on the topic Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: boost.test thread safe bugs (and some fixes)
I will try to address 1(without tss) 2 and 4 today. I committed execution_monitor.cpp with changes that should address above issues. We may try now recheck how signal handling behave on OpenBSD Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Win32 Metrowerks problems [was Re: [test] revision two]
There still are getenv link errors in prg_exec_fail1 and prg_exec_fail2. I think I've got them fixed. Testing now. And what is the fix? prg_exec_fail3.cpp is failing: Assertion(div != 0), line 32. It what supposed to happend. Important thing is whether the test is aborted at that moment or Boost.Test notification appear. --Beman Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: boost.test thread safe bugs (and some fixes)
The code never promised to work in multithreaded environment, nor even to be thread save. It is in my to-do list. Though recent hands in several situations may require address some of these issues sooner. What?!? Where's the big, bold disclaimer about that! It's in to-do section in front page. Though you right. There should have been explicit disclaimer about that. We have to have all of the Boost.Test library thread safe, because the Boost.Thread library depends on it. It you are accessing Boost.Test interfaces only from one thread it may work even with current implementation. No. I don't think it's common situation. You don't usually create and run test cases inside the other test case code. *I* had considered doing just this, in order to get a tree structure for dependent test cases. Nothing in the documentation seems to indicate this is something that's not supported, and I think that would be the wrong answer in any event. I already implemented changes that should allow reentrant usage of execution monitor. So this is not a problem any more. On the other hand I was thinking about implementing direct support for test cases dependency inside the Boost.Test (next release). Would it be enough for you to be able to specify that one test case should run only if some other one passed? To make this thread safe you would need to store the pointer in a thread local storage slot, BTW I don't think you can use boost.threads for this, as it will create a dependency quagmire for status/Jamfile :-( I thought to introduce macro BOOST_MULTITHREADED_UNIT_TEST and guard all usage of Boost.Thread with it. It does not create extra dependency and should allow to build multithreaded version with bjam subvariant feature. How would this work for the Boost.Thread library. Boost.Test must be usable by Boost.Thread, and this means it must be thread safe with out using Boost.Thread. 1. Boost.Thread with depend on multithreaded version of Boost.Test. 2. Boost.Test will try to use minimal/basic part of Boost.Thread functionality 3. The first test cases of Boost.Thread unit test will need to check that the above basic functionality is working as expected. And only of these test cases are passing, continue with rest of testing. This is not unique situation. Boost.Test have the similar problems. It's like in relativistic physics: one could not measure the exact value cause the measure tools affect the measurement. Thread safety issues are very critical, AFAICT. Boost.Threads depends on Boost.Test, and assumes it is thread safe. I understand, William, your concern. But the Boost.Thread library is the only library that needs thread-safe version of Boost.Test. Thread safety will need to be addressed all over the place not only in execution_monitor. Add here that I am not familiar with your library. As a result I would not want to do this in a hurry. I promise to take care about it for the next release. Would it be acceptable for you? -- William E. Kempf Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Regression progress; Win32
bjam is reporting: don't know how to make result_report_test.pattern don't know how to make errors_handling_test.pattern So it looks like something is wrong with your Jamfile. I followed Dave A. recommendation and placed them in input section of run rule. The above tests expect them as first command line argument. The files themself are located in test directory. Is bjam running it OK on your machine? Yes. errors_handling_test fails on some compilers due to difference in compiler output (I will think how to deal with it in a future) Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Win32 Metrowerks problems [was Re: [test] revisiontwo]
However, while the header is there, CW's library doesn't actually implement the debugging mechanism that this header describes. This is why you're link does not work -- the code just isn't there. So Gennadiy's temporary fix is really the permanent fix. There still are getenv link errors in prg_exec_fail1 and prg_exec_fail2. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Regression progress; Win32
test_fp_comparisons IS failing on all compilers for now. It shows some problems with comparison alsorithm. I will take a closer look after release. Maybe you could take a quick look sooner? We aren't going to branch for release until Monday, and the release won't happen for some time after that. The whole point of the schedule is to allow time to fix lately discovered problems. The thing is that I do not know yet what the problem is. The following should work but it does not: double tmp = 11; // no rounding error tmp /= 10; // one rounding error double fp1 = tmp; // no rounding errors double fp2 = 11./100; // one rounding error double tolerance = std::numeric_limitsFPT::epsilon() * (4)/2; // one rounding error; 4 - total number of rounding errors BOOST_CHECK_CLOSE( fp1, fp2, tolerance ) should work but it does not I will need to investigate it with more details. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: OpenBSD regression, hanging tests!
Changing line 64 to: #elif defined(BOOST_HAS_SIGACTION) !defined(__OpenBSD__) Does make the tests not hang any more. Instead it causes them to fail with core dumps, or perhaps that's a success? errors_handling_test supposed to cause FPE and crash in case if signal handling is turned off. I do not know about thread tests. The problems with hanging tests may be related to the thread safety issues discoverred by John. We may try to retry to use signal handling once I address above issues. This includes both the test and thread hangs. What about random? Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: SCO config
Someone will need to add an SCO specific platform config - I don't have the access to the platform, nor do I know how to detect it - but if you can provide me with the information, or if you just want to go ahead and add it then do so. I will try to look into this. What is the usual procedure for adding platform specific config? Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Regression progress; Win32
bjam is reporting: don't know how to make result_report_test.pattern don't know how to make errors_handling_test.pattern So it looks like something is wrong with your Jamfile. I followed Dave A. recommendation and placed them in input section of run rule. The above tests expect them as first command line argument. The files themself are located in test directory. Did you forget to check them in? They under cvs for a long time. Note that Linux regression tests works as expected. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Regression progress; Win32
* test lib has three tests failing all compilers; at least some of these passed until recently. Note that errors_handling_test and results_resport_test failures does not lead ot any error messages. So I would recommend to perform clean build of those two. test_fp_comparisons IS failing on all compilers for now. It shows some problems with comparison alsorithm. I will take a closer look after release. I also supposedly fixed several errors/warnings from different win32 compilers i my unit test. * test lib is causing new Borland warnings for many other libraries. See type_traits/is_pointer_test for example. fixed. Gennadiy ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: OpenBSD regression, hanging tests!
sigaction is supported by all gcc versions if the platform has it (and BSD does). You right. But, then it looks like it does not work properly, cause siglongjump causing SIGSEGV. Maybe we do not want to use sigaction facility with gcc 2.95.3? Could we change line 64 in execution_monitor.cpp so signal handling won't be used. Does it fix hanging tests? Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Regression progress; Win32
I fixed config/test/Jamfile to use proper names of Boost.Test libraries. How does this thing work in regression testing? Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [test] revision two
Hi, everybody Today I committed second revision to Boost.Test library. I am not planning any more code changes in this release. If I have time I will try to reflect changes made in revision one and two in documentation (Release notes with changes log will be present in any case). Here is approximate list of things that came with this revision: * XML log format is introduced Now user willing to automate errors processing could get a log in XML format. Command line switch is introduced that manage log format: --log_format=[XML|HRF] will force XML or human readable format respectively. * XML report format is introduced Now user willing to automate results analysis could get a result report in XML format. Command line switch is introduced that manage report format: --report_format=[XML|HRF] will force XML or human readable format respectively. * Command line option --output_format is introduced that both log/report format simultaneously * BOOST_CHECK_NO_THROW test tool is introduced Name says it all. * BOOST_BITWISE_CHECK test tool is introduced Allows to perform bitwise comparisons of the two arguments provided. Will report as many errors as many bits mismatch. Mismatch position is reported. * Documentation default palette changed to white * Components examples and test documentation page is introduced. Now all test/examples links lead to this page that has summary information about all of them, that include expected output, type of test and so on. * Signal handling selection algorithm fixed. It's tentative fix, that will need to be substituted with BOOST_HAS_SIGACTION checks once they are introduce. Current change allowed to use signal handling with gcc on win32 also. * C strings usage in minimized as much as possible. * class_properties header modified to use Boost.Preprocessor for friends declaration * other minor changes and bug fixes Let me know about any issues. Regards, Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [test] revision two
Hi, everybody Today I committed second revision to Boost.Test library. Wow, is that a good idea one day before we branch for release? I should have done it week ago, but was really sick. Anyway, It does not contain anything that should break backward compartibility. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Win32 Metrowerks problems [was Re: [test] revision two]
No, it is some sort of configuration problem. Look on metrowerks linking errors thread. It about the same issue with different undefined symbol There was also compilation error with metrowerks. I fixed it couple hours ago. Unfortunately I do not have direct access to this compiler so metrowerks specific errors sometime may creep in waiting for regression test results (I hope to resolve this soon). Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Request for Config Macro( was RE: Re: [test] unixidentification )
So, Let introduce one. I need something for coming release. Done: it's called BOOST_HAS_SIGACTION John. Why it doesn't get defined for Visual Age C++ on AIX? Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Request for const fix in unit_test_suite.hpp
Sure. Fixed. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [test] metrowerks linking errors
If you run bjam with -d2 option, you'll see all the command lines, which should be enough to find out which libraries are beeing linked. It appears that I don't really need -d2 to get a linker line. bjam prints ot togerther with error anyway: mwld -search -maxerrors 5 -maxwarnings 20 -export dllexport -nowraplines -g -subsystem console -o ..\..\..\libs\test\test\bin\prg_exec_fail1.test\cwpro8\debug\runtime-link-d ynamic\prg_exec_fail1.exe @..\..\..\libs\test\test\bin\prg_exec_fail1.test\cwpro8\debug\runtime-link- dynamic\prg_exec_fail1.CMD ..\..\..\libs\test\test\bin\prg_exec_fail1.test\cwpro8\debug\runtime-link-dy namic\prg_exec_fail1.CMD: ..\..\..\libs\test\test\bin\prg_exec_fail1.test\cwpro8\debug\runtime-link-d ynamic\prg_exec_fail1.obj ..\..\..\libs\test\build\bin\libboost_prg_exec_monitor.lib\cwpro8\debug\run time-link-dynamic\libboost_prg_exec_monitor.lib ..\..\..\libs\test\build\bin\libboost_prg_exec_monitor.lib\cwpro8\debug\run time-link-dynamic\libboost_prg_exec_monitor.lib Does it help? Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [test] unix identification
Hi, Some time ago there was a discussion on how properly identify unix for selecting proper signal handling algorithm. Here is fragment of John Maddok's letter: ... currently you have: // for testing on Win32, GCC thinks it is a unix platform // TODO: figure out how to tell it is really unix #elif defined(__unix) !defined(__GNUC__) There are several things wrong with this: __unix need not be defined on POSIX conforming systems __unix may be defined on systems that don't support sigaction etc. almost all version of __GNUC__ do have sigaction support including cygwin. How about: #if defined(_POSIX_C_SOURCE) defined(_POSIX_VERSION) (_POSIX_VERSION = 199506L) !defined(_WIN32) which should be about right if I've understood the standard correctly. IMO there are several issues with above check. If you would take a look here http://boost.sourceforge.net/regression-logs/cs-win32-links.html#config_info %20gcc you will see that a. _POSIX_C_SOURCE is not defined b. _POSIX_VERSION is smaller Nevertheless, I was able to check that this version of gcc perfectly compile and work with unix style signal handling. Accordingly here is the question: how properly identify the unix style signal handling? Gennadiy. P.S. Also let me revisit my other related question: would it be ok on all compatible platforms to use csignal instead of signal.h? ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [test] unix identification
a. _POSIX_C_SOURCE is not defined It's probably being overly picky requiring that one to be defined, strictly speaking you can't use any POSIX API's unless _POSIX_C_SOURCE has been defined before the inclusion of any std header - most platforms don't seem to care though. b. _POSIX_VERSION is smaller Particular platforms may have sigaction support even though they only claim conformance to an earlier version of the POSIX standard - cygwin is one - check for __CYGWIN__. So as a result we will get: #if defined(__CYGWIN__) || defined(_POSIX_VERSION) (_POSIX_VERSION = 199506L) Did I get it correct now? But look here what I dig up in status pages (not all compilers unfortunately provide config_info): A) gcc 3.1 on MacOS _POSIX_C_SOURCE is not defined _POSIX_VERSION=198808L _POSIX2_VERSION=199212L B) gcc 3.2 on HPUX _POSIX_C_SOURCE is not defined _POSIX_VERSION=199009L _POSIX2_VERSION=199209L C) gcc 3.2, gcc 2.95.3, intel 6.0, intel 7.0 kylix on linux _POSIX_C_SOURCE is defined _POSIX_VERSION=199506L _POSIX2_VERSION=199209L D) gcc 2.95.3, gcc 3.2 on OpenBSD _POSIX_C_SOURCE is not defined _POSIX_VERSION=199009L _POSIX2_VERSION=199212L Cases A,B and D will be ruled out. Any suggestions? Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [test] metrowerks linking errors
It looks to me like the C library is not getting linked into the executable. There are several possible versions of the C library which might meet the need (some of them listed in the error messages). Can you list the libraries that are being linked in? From that I can probably make a better suggestion. No. I have no idea. This is bjam output. More examples you could see on win32 status page for Boost.Test unit tests. Maybe metrowerks toolset could answer your question. -Howard Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost.Test with templated test cases... or is itbind?(was:Howto make Boost.Test work with function objects?)
test-add(BOOST_TEST_CASE(::boost::bind(fn, 1))); I just tried this and MSVC7 tells me: test_charset.cpp(50) : error C2664: 'boost::unit_test_framework::test_case *boost::unit_test_framework::create_test_case(void (__cdecl *)(void),std::string)' : cannot convert parameter 1 from 'boost::_bi::bind_tR,F,L' to 'void (__cdecl *)(void)' with [ R=void, F=void (__cdecl *)(int), L=boost::_bi::list_av_1int::type ] No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called Is this a problem with me, my compiler, or something else? Markus Did you include unit_test_suite_ex.hpp? If yes, try to separate fn: function0void tc = fn Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Minimal test tool - very minor comments
1 Need to have language extensions enabled. (for WINNT?) Do I use any nonstandard language extensions? No, but code that gets pulled in (WINNT?)does, so the MS project Properties requires /Za. This is a minor disadvantage if you like to be 'strict'. Could you be more specific which header require this option? BTW MSVC65 does not seems to require it. 2 Need to have /EHa rather than /EHs for async exceptions. (for WINNT?) You need to clarify on that. Why would I want to force async exception model? I can't imagine, but the MSVC compiler 7.0 reports that /EHa is required for it to compile, and it does. (I suspect it is something like winnt.h that is pulled in?) MSVC 6.5 does not require async model. Would be strange for 7.0 to require it. 4 Warnings level 4 ok, (except get two warnings about test_main's unused args). They are used. Sorry I misundestood you. You could not declare argments names in test_main if you are not using them Plain black on white please. Sorry to be so boring. Use btl-simple.css style instead of btl.css. Both are located in style subdirectory. You will need to change the header of doc files for that. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Suggestion for new test library test tool
I would like to suggest the addition of the test tool BOOST_CHECK_NO_THROW to the boost test library. It's purpose should be obvious from the name and I think it would be quite handy when testing construction of objects. Markus Why would you need that? It's already checked automatically. If exception is thrown, you will get the notificatinon from test monitor. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Minimal test tool - very minor comments
Paul A. Bristow [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... An absolutely invaluable tool. Perhaps worth documenting for MSVC 7.0 (and probably 6.5?) 1 Need to have language extensions enabled. (for WINNT?) Do I use any nonstandard language extensions? 2 Need to have /EHa rather than /EHs for async exceptions. (for WINNT?) You need to clarify on that. Why would I want to force async exception model? 3 std for loop scope is OK. I did not get this at all. What do you mean? 4 Warnings level 4 ok, (except get two warnings about test_main's unused args). They are used. (and there are several spilling misfakes in that section Did you mean spelling mistakes? Could you send them to me? - and why is the document background so gray?) All pages have the same background. What would you prefer? Thanks for your work on this. You are welcome. Paul Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Complex testing requirements
Do you want this to be implemented as part of Boost.Test or Boost.Build? * Test cases/suites need to be defined in a tree hierarchy, where branches are never run if the parent test doesn't pass. This could be done in terms of Boost.Test. Not in a current version though. * These test cases may include tests for compilation and/or link success/failure. This is definitely soemwhere in Boost.Build area. * By default I would like to build and test the entire tree of test cases/suites, obeying the first rule I provided above, but there should be a way to build and test a single test case/suite with out regard to the parent (i.e. force a build and test of a single suite with out regard to any others in the tree). Running test cases by name will be implemented as soon as CLA framework will be completed. IOW soon. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost.Test with templated test cases... or is itbind?(was:Howto make Boost.Test work with function objects?)
I guess it would help if the syntax for all four possibilities (normal function, templated function, normal function object templated function object) made it into the Boost.Test documentation. Syntax is basically the same for all simple (not parameterized tests) cases. Though I admit that extensions should be documented. Depends on my load in next couple weeks will try to fix in coming release. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: SmartPtr (Loki) - auto_ptr/move c'tor issue
Hi,
I also found it incorrect to keep move semantic in basic template while
was working on my adaptation of SmartPtr. Let's look on auto_ptr for
example. It's basically scoped_ptr with added move semantics. The same need
may arise with almost any SP: one with custom deleted or special checking
policy. So I argue that there always exist valid regular (non movable) SP
that correspond to the movable one I need; and movable is always a
metafunction of non movable one. Lets call this metafunction
make_movable. So IMO what we need is to implement this make_movable
metafunction. It could be either
templatetypename SP
make_movable {
typedef ... type;
}
or
templatetypename Policy1,typename Policy2,... here we list policies of SP
make_movable {
typedef ... type;
}
What I am currently have is inheritance. Though I am not sure it's best
solution:
template typename T,
typename StoragePolicy,
class auto_smart_ptr : public smart_ptrT,StoragePolicy,...
{
public:
// here we implement everything that make it movable
// the rest is inherited from smart_ptr
};
class template smart_ptr does not know anything at all about movable
semantic.
Regards,
Gennadiy.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Preliminary submission: command line config fil e library
You still need to remember something. For example, your library uses , to separate elements of std::list... parameter. Can I guess that from the options declaration? It has almost nothing to do with parameter definition. It's details of argument parsing format. You may though specify it explicitly by naming the interpreter for your parameter, like this: cla::named_parameterstd::list.., space_separated_list Can I guess what multiplicable is? I think it's pretty obvious. If not I may change name to more expressive/clear if you know one. With your proposal it would look something like parser named_parameter(output) short_name(o) value_name(file) description(where to send output) And it should be repeated for each option. in fact: parser dual_named_parameter( output, o ) format_descr( file ) description( where to send output ); In your case: desc3.add_options() (output,o, file, where to send output) The only differences are is that I explicitly specify what does these strings mean and I allow different kinds of parameters (positional for example). Does key_lookup_policy support short options? No. But dual_lookup_policy does. program_options may use this policy. I personally prefer to use key_lookup_policy with guessing_key_policy. I do not need to remember 2 independent names and could specify long or short name. Therefore program_options cannot support them either. So, if I want to handle both command line and config file I have to give up something very handy. That is not correct as it follows from above. - Volodya Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Preliminary submission: command line config fil e library
my_program ( 0, 1) ( 1, 3) (( 0, 1), 15 ), (( 0,1), (7.8) ) This is input of 2 points circle and line. Here chain_lookup_policy could be useful. What if I want C++ expression specified on the command line? Sure, I don't want make C++ parser operate on command line. Rather, I'd write my_program f(1, 2) + 10 I don't need chain_lookup_policy where a couple of quote characters will do. IT doesn't matter weather or not you are using quotes. To parse out Point, Point, Circle, Line out of input above you need chain of responsibilities logic. I really can't comment further without seeing the code. Ok. I put in vault area some snapshot. I take some not testes functionality out of there. But you should get the feeling. Unfortunately I will be really busy till the middle of February. So may not be able to work on this further meanwhile. It's located here: http://groups.yahoo.com/group/boost/files/cla_framework.zip No. Does yours? Getting really picky, does yours allows to validate XML against DTD? In fact yes. My test configuration file look like this: input_message \ some XML here \ \ expected_output after transformation 1 cxvbxbxb expected_output after transformation 2 df sdf sdf Now my test program read test configuration file and feed value of input_message parameter to the xerces parser. - Volodya Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Preliminary submission: command line config filelibrary
Vladimir Prus [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
Gennadiy,
About month ago, while working on Boost.Test issues I was faced with the
need for the more or less full featured command line argument parser. I
recall that you were working on one and took a look on some of your
preliminary code in vault area.
What code, specifically? The only think I remember placed there is
a low-level command line parser, which was never meant to be the
single solution. In fact, it is now meant only for
1. I don't want to depend on Boost use cases
2. Possibly, for adding some very custom hooks.
And ... was really disappointed. I do not
believe that any solid design could fit for variety of different
needs/expectations that exist. One big class with many many
options/styles
does not look like good design decision. I was not able to look into
deep
details with your current submission, but from what I view even if it
better
it still has similar design. While we are at it I could make 2 remarks
about
your submission: a) None of 5 compiler configurations installed on my XP
could not compile it.
:-(
I've made some corrections recently. Did anything improve?
I've tried version you announced yesteday.
b) see separate post regarding you config file design
with is also unsatisfactory IMO.
I have not seen any separate post. Are you sure you've sent it?
It was too late yestaday for another post. I would not be able to comment
now also. See soon.
So I made my move and implemented my own solution, that I will be
call:
CLA framework. It's still missing some bits and pieces, particularly
docs is
not started yet. But I will present it as an alternative to your
submission.
(Though I may not be able to work on this within following month due to
extreme load with other activities). Here is short description of my
design.
Is it possible to take a look at the code, too?
Ok. I will try to clean up and present some compilable snapshot
Class cla::parser is core class in a framework. It's definition looks
like this:
templatetypename LookupPolicy
class parser : public LookupPolicy {
...
OK, disagreement begins. I thought that someone could suggest using
policies.
But considering it, I came to conlustion that they don't give anything.
Program options are just (name, value) pairs. If you add a mechanism to
store them into program variables, you have everything.
There are many diffirent algorithms how you could parse program option
values from input. Name part is optional. Consider positional arguments. Or
I have one policy that I forgot to mention: chain_lookup_policy. It's work
is based on Chain of responcibilities Design pattern. In this case Every
parameter knows how to parse itelf out of input. And this identification may
not be the name at all.
Further, assume this situation. My program would like to handle options
that
can be specified at
1. Command line
2. Config file (ini)
3. An XML config file
4. Windows registry
Things like validation, and default values really apply to all of them.
I'd like to declare all options once, and then get them from those
sources.
In your design, I'd have to declare 4 different parsers, feed them all
with
options, and the parse all the sources, right?
IMO tis is majoy drowback of your solution - you put too many eggs into the
same busket. Compare number of peeople that need only CLA framework with
number of paople that need all you mention above. Or even CLA and config
file. Numbers are incomparable. What I would od is to present independent
solution. Plus some kind of unified interface that works on different level
and allows ot compine different configuration means.
[...]
Lookup policy
Lookup policy is in a sense an algorithm for parsing the arguments
from
the input provided.
If it's the parsing algorithm, then why it's called lookup policy?
This algorithm defines how we perform lookup of the parameter in the input.
Do you have better name?
Each specific lookup policy could incur what type of the
parameters/modifiers it's supports. Currently framework itself present
following lookup policies;
key_lookup_policy - each parameter is identified by unique key
positional_lookup policy - each parameter is identified by position in
input
dual_lookup_policy - each parameter is identified by dual (most
probably long/short) key
getopt_lookup_policy - getopt style option parsing (with sticky
options)
From your description it looks like some of policies deal with parsing
and some with parameter naming. Or are they responsible for both?
Policy only defines how we perform *lookups* - parameter identfication.
There is separate class (I did not mention) - interpreter - that is
responcible for parsing the parameter value from input after the parameter
was identified. But it's optional - you are not required to used namely this
mena
[boost] Re: Re: Preliminary submission: command line config file library
That's a long way of supporting Vladimir's views above. People first need just command line arguments, then later realize a config file would be nice. And yes, the transition should be simple and transparent. --Beman I do not argue that an ability to support other configuration means could be convinient *in some cases*. My point is in much more frequently rigid coupling of cla and config file support will be undesired burden. IMO expressed in other post we need separate components responsible for every configuration source. Support for simple and transparent transition could be done on higher level on top of above components. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost unit test suggestion - checkpoints for exceptions
There's one thing I'm wondering about. If you get an exception in a test, it won't show which line caused the exception, only that one has happened somewhere. In a unit test with 100+ tests, it can be hard to find which one caused the exception, so I started to litter the test code with BOOST_CHECKPOINT(), which then shows up at the exception. However, I realised that even this was just narrowing down the search, and to pinpoint the error line, one would need one BOOST_CHECKPOINT() for each test line. So why not automate this? While working on first revision to Boost.Test I thought about very same issue in regards to fatal/system errors during testing: How to help programmer to locate where in test case problem occurred? I was about to implement automatic checkpointing when I realized that in fact it is already in place in existent implementation: Just set log level to all and last pass/fail message will give you all information you need. So I do not believe any extension is required in this matter. Regards, Gennadiy P.S. I've tried several times to reply to your private mail. But got Undeliverable mail... message. Here is the question and reply: --- Terje Slettebø [EMAIL PROTECTED] wrote: P.S. I haven't been able to set the reporting level, by setting environment variables in Windows. Is there some other way to set the reporting level for the unit test framework? --report_level=[confirm,short,detailed,no] environment variable: BOOST_TEST_REPORT_LEVEL Be aware that after setting environment variable in windows you may need to restart GUI, so it will pick up new value. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost release compressed by bzip2
Robin.Hu [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Bzip2 is widely spreaded with GNU software. It is available to all *nix platforms those are available to me, include linux, *bsd, solaris, etc... IMHO, using tar.bz2 instead of tar.gz is a good idea. Why would not use rar or ace instead of zip then? It already almost as much spread as zip is. And twice as small. Gennadiy. P.S. If we have enough space could we simply publish several additional formats? ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: BOOST_CHECK_EQUAL() dangers
Actually I was hoping you would choose option 3. :-) For me, option 2 just doesn't feel right. And I think it's not in the spirit of the standard, either. (Implicit conversion from char * to string doesn't exist, a char * is just a pointer.) I would classify this as suprising behaviour which should be avoided wherever possible. Test library is all about usability and only then generocity or standart purity. Would you be working with c strings I wonder how long it will take until you became tired adding std::string on both sides of comparison: BOOST_CHECK_EQUAL( std::string( s ), std::string( t ) ); ... BOOST_CHECK_EQUAL( std::string( s ), std::string( t ) ); ... BOOST_CHECK_EQUAL( std::string( s ), std::string( t ) ); and will introduce simple forwarding macro #define M_CHECK_EQUAL_STR( s, t ) \ BOOST_CHECK_EQUAL( std::string( s ), std::string( t ) ); Boost.Test is doing this for you now. There is a very little posibility of misuse (comparison of pointers as check for correctness is very strange things in general IMO). Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Boost release compressed by bzip2
Because none of those; bz2, rar, or ace, will let you do this... tar zxvf boost-1.29.0.tar.gz I could not get your point here. Every archiver has it's own command for unpacking. So what? Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [Test] Feature request
David B. Held [EMAIL PROTECTED] wrote in message asb9ml$iqi$[EMAIL PROTECTED]">news:asb9ml$iqi$[EMAIL PROTECTED]... When I'm running a test program, it would be nice to get a usage message with a -help or -? parameter. That way, I don't have to remember all the log level parameters, etc. Dave Ok. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
