[boost] Re: Re: is_nan
Fernando Cacciola [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Thanks to Gabriel we may have an is_nan() right now. Oops! It was Joel de Guzman who offered his is_nan() implementation. Sorry Joel :-) Fernando ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: is_nan
Fernando Cacciola [EMAIL PROTECTED] wrote: Fernando Cacciola [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Thanks to Gabriel we may have an is_nan() right now. Oops! It was Joel de Guzman who offered his is_nan() implementation. Sorry Joel :-) No problem. I thought Gaby also offered an implementation ahead of me. So you guys are interested then? It would really be nice to have a common boost implementation. I'll put it in the sandbox tomorrow. -- Joel de Guzman joel at boost-consulting.com http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Visitor-based framework to describe classes with exampleofobjectdump in XML format
Joel de Guzman [EMAIL PROTECTED] writes:
Alexander Nasonov [EMAIL PROTECTED] wrote:
From user point of view it's easy. Every class is described using intuitive
class-decl-like style:
void describe_Driver(descriptorDriver class_)
{
class_(Driver).derived_fromPerson()
[
member(Driver::licence_id, licence_id), // note comma operator
member(Driver::licence_issue_date, licence_issue_date)
];
}
Cool syntax! Hmmm Reminds me of Boost.Python, luabind and ahem... Phoenix ;-)
A problem with this is that the introspection information is only
available at runtime. A more-flexible system would use GCC-XML output
to generate something like:
template
struct class_Driver
{
typedef mpl::vectorPerson bases;
typedef mpl::vector
memberint Driver::*, Driver::licence_id
, memberDate Driver::*, Driver::licence_issue_date
, membervoid (Driver::*)(), Driver::accelerate
members;
...
};
So all the introspection information could be available at
compile-time.
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [MPL] for_each broken with empty list's
Hi,
for_each seems to be unable to deal with empty lists, or lists that
are built by push_front on an empty list. However, vectors work
fine. Here is code which demonstrates the problem. Replacing list with
vector makes the code compile.
#include iostream
#include boost/static_assert.hpp
#include boost/mpl/push_front.hpp
#include boost/mpl/list.hpp
#include boost/mpl/size.hpp
#include boost/mpl/for_each.hpp
#include boost/mpl/alias.hpp
typedef mpl::list empty;
typedef mpl::listfloat single;
typedef mpl::push_frontsingle, int::type two;
typedef mpl::push_frontempty, int::type push_on_empty;
BOOST_STATIC_ASSERT(mpl::sizeempty::value == 0); //OK
BOOST_STATIC_ASSERT(mpl::sizesingle::value == 1); //OK
BOOST_STATIC_ASSERT(mpl::sizetwo::value == 2); //OK
BOOST_STATIC_ASSERT(mpl::sizepush_on_empty::value == 1); //OK
struct type_printer
{
type_printer(std::ostream s) : f_stream(s) {}
template typename U void operator()(U )
{
*f_stream typeid(U).name() '\n';
}
private:
std::ostream* f_stream;
};
int main() {
mpl::for_each empty ( type_printer(std::cout) ); //won't compile
mpl::for_each single ( type_printer(std::cout) ); //OK
mpl::for_each two ( type_printer(std::cout) ); //OK
mpl::for_each push_on_empty ( type_printer(std::cout) ); //won't compile
}
Regards,
-Tom Wenisch
Computer Architecture Lab
Carnegie Mellon University
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: [In response to FernandoCacciola]Re:Interestinmultiindex_set?(again)
Hi Fernando (and all others) Please find some preliminary documentation for multiindex_set at: http://groups.yahoo.com/group/boost/files/multiindex.zip The documentation is far from complete, but a reasonably complete rationale is given which hopefully will guide the reader through the design considerations that shaped multiindex_set. The rest of the docs (usage, reference) will probably we written only if there's some heat around the library (writing is not one of my best skills, and I'll go through that bore only if there's some potential audience). I hope we've got now a better starting point to discuss multiindex_set. As always, all sorts of comments are most welcome. Regards, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo Fernando Cacciola ha escrito: Hi Joaquín, I'm probably just misunderstanding your class. So I'll wait for you to upload the documentation and I will repost the issues then. Best Fernando Cacciola ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] problems with config for intel-7.1 on Linux
John Maddock wrote: Looking at the boost regression test results, it seems that Intel on linux defines _WCHAR_T (which is what the EDG front-end documentation specifies for wchar_t support), so I used that as the test - should be in cvs now - can you check that it does the right thing? integer_traits_test succeeds now (regression test tables are updated now for Linux). Regards, m ___ 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]
At 02:22 PM 7/7/2003, Rozental, Gennadiy wrote:
I could probably prohibit usage of CHECK_CLOSE with number of rounding
errors provided.
Is there any other general recommendations how to choose the tolerance
to
FP computation correctness checking?
There has been some recent discussion on comp.lang.c++.moderated, subject
equality of two doubles. The last post was from Andrei Alexandrescu:
What's most of the time needed is relative precision.
So, numerical gurus: how can one express a equals b within 0.1% over
the whole range of floating point numbers? If that can be done, it would
be a nice useful routine.
bool approximately_equal(double lhs, double rhs, double relative_prec)
{
// fill in here please :o)
}
But it really doesn't seem that a test library is the right home for such
functions. I think all the fp stuff should be removed from Boost.Test, and
passed on as a challenge to the numerics experts.
After all, the user can always write:
BOOST_CHECK( approximately_equal(...) );
--Beman
A half-way solution is to have something like:
BOOST_CHECK_EQUAL_NUMBERS(x,y,IsEqual)
and let users specify their own Preciates.
By default, the Test library could provide
a straight-forward ABSOLUTE-ERROR comparator:
templateclass N
struct IsNearlyEqual
{
IsNearlyEqual ( N a_tol = N(1e-6) ) : m_tol(a_tol) {}
bool operator() ( N x, N y ) const
{
return x = y ? ( x - y ) = m_tol
: ( y - x ) = m_tol ;
}
N m_tol ;
} ;
Which would be used as follows:
double n = ..., m = ... ;
BOOST_CHECK_EQUAL_NUMBERS(n,m,IsNearlyEqualdouble());
Fernando Cacciola
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: test_fp_comparisons and rounding errors
A half-way solution is to have something like: BOOST_CHECK_EQUAL_NUMBERS(x,y,IsEqual) and let users specify their own Preciates. There is BOOST_CHECK_PREDICATE By default, the Test library could provide a straight-forward ABSOLUTE-ERROR comparator: By default, the Test library provides relative error comparator, which is according to my understanding is more correct. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] test_fp_comparisons and rounding errors
Above form wouldn't should mismatched values and this is most important. I meant: Above form wouldn't *show* mismatched values and this is most important. Gennadiy. - ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Interest in multiindex_set?(again)
Hi Beman, - Mensaje Original - [...] * The multiindex_set name seems awkward to me. Maybe indexed_set or set_index? I don't like the name either, and would be happy if someone comes with something better. Nevertheless, I don't think indexed_set is a good choice: when picking up a name another one must be chosen for the associated namespace (and it is convenient that these two are not the same, for reasons explained vg in Boost.Tuple docs). I chose multiindex_set/multiindex. The analogous indexed_set/index does not fit: index is too broad a denomination for the namespace. A related question: Should boost::multiindex::multiindex_set be raised into Boost namespace as boost::multiindex_set (or whatever its final name)? Seems the standard practice, but I think it is safer to ask first. * It seems safer to me for the default to be indexes that are unique. * Separating the specification of uniqueness from the list of indices seems like a recipe for mistakes, particularly during maintenance. Is it possible to combine uniqueness specification with the index tuple? Perhaps your example could look like this: typedef boost::multiindex::multiindex_set employee, boost::tuple employee::comp_id, multi employee::comp_name , employee_name::comp_ssnumber , employee_set; or this: typedef boost::multiindex::multiindex_set employee, boost::tuple unique employee::comp_id , non_unique employee::comp_name , unique employee_name::comp_ssnumber , employee_set; This is definitely a good idea, Fernando also hinted at symplifing the specification of unique/non-unique indices. Any suggestion on how to implement it? With two templates for unique and non-unique indices the thing is simple; it is not as simple when only one class is marked. Suggestions here are most welcome. [...] * It isn't clear (or I missed it) if iterators are always logically const-iterators or not. In other words, could your example have been written like this? typedef index_typeemployee_set,1::type employee_set_by_name; employee_set_by_name i=es.get1(); employee_set_by_name::iterator it=i.find(Anna Jones); it-name=Anna Smith; //she just got married to Calvin Smith No it couldn't. Iterators and const_iterators (which incidentally are the same) behave logically as const-iterators, just the same as in STL sets. update() has been carefully crafted so that strong exception-safety is provided: for that, it is necessary that a copy of the element is provided instead of allowing some sort of in-place modification of the element. This is discussed in some detail with Fernando somewhere up this thread. Anyhow, I'm glad to see you working on this, and hope you will continue with it. Thanks for your interest. If no objection is raised I plan to submit the library for pre-formal review in a couple of weeks. Regards, Joaqun M Lpez Muoz Telefnica, Investigacin y Desarrollo ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [MPL] for_each broken with empty list's
Thomas Wenisch wrote: Hi, Hi Thomas, First of all, thanks for the report. for_each seems to be unable to deal with empty lists, or lists that are built by push_front on an empty list. However, vectors work fine. Here is code which demonstrates the problem. Replacing list with vector makes the code compile. It's actually a known issue which I fixed on the branch a couple of weeks ago, but didn't have time to regenerate preprocessed headers and integrate the whole thing into the main trunk then. Now it's there! Thanks once again, Aleksey ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [mpl] ETI problem w/ clear algorithm
Eric Friedman wrote:
Aleksey (and others),
Hi Eric,
I'm working on getting variant to compile under MSVC 6, but I've come
across what seems to be an ETI problem that needs a workaround.
However, I'm not sure what is the most appropriate way to make the fix.
The most common way to deal with ETI is to add a correspondingly guarded
'int' specialization for the template where the error occurs. In our case,
it would be something along these lines, in mpl/aux_/clear_impl.hpp:
#if defined(BOOST_MPL_MSVC_60_ETI_BUG)
template
struct clear_traitsint
{
template typename Sequence struct algorithm
{
typedef int type;
};
};
#endif
Below is the error output from the regression tests (variant_test1).
With the above fix (already in the main trunk), the ETI error goes away, but
looks like you will need a little bit more tweaking in other areas to make
the whole test compile.
HTH,
Aleksey
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [BGL] iteration macros
Hi,
Iteration macros did not work without some 'using' directives because it
uses functions from boots but actually without the boost:: qualifier.
E.g. BGL_FORALL_VERTICES(v,g,graph_t) did not compile unless you have using
namespace boost or using namespace boost::vertices before the invocation of
the macro.
Pls find attached iteration_macros.hpp that corrects this problem.
Regards,
Csaba
begin 666 iteration_macros.hpp
M+R\]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]
M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/[EMAIL PROTECTED]7)I9VAT(#(P
M,[EMAIL PROTECTED]:6%N82!5;FEV97)S:71Y#0HO+R!!=71H;W(Z($IEF5M2!'+B!3
M:[EMAIL PROTECTED]AIR!F:6QE(ES('!AG0@;[EMAIL PROTECTED]AE($)O;W-T($=R
M87!H($QI8G)AGD-B\O#0HO+R!9;W4@VAO=6QD(AA=F4@F5C96EV960@
M82!C;W!Y(]F('1H92!,:6-E;G-E($%GF5E;65N=!F;W(@=AE#0HO+R!
M;V]S=!'F%P:!,:6)R87)Y(%L;VYG('=I=@@=AE('-O9G1W87)E.R!S
[EMAIL PROTECTED]AE(9I;[EMAIL PROTECTED]B\O#0HO+R!097)M:7-S:6]N('1O(UO
M9EF2!T:[EMAIL PROTECTED];[EMAIL PROTECTED][EMAIL
PROTECTED]ES=')I8G5T92!M;V1I9FEE9!C;V1E
M(ES#0HO+R!GF%N=5D+!PF]V:61E9!T:[EMAIL PROTECTED]5X=!O9B!T:ES($Y/
M5$E#12!IR!R971A:6YE9[EMAIL PROTECTED];[EMAIL PROTECTED]AA= [EMAIL
PROTECTED]AE(-O94@
M=V%S(UO9EF:65D(ES(EN8VQU95D('=I=@@=AE(%B;W9E($-/4%E2
M24=(5!.3U1)[EMAIL PROTECTED]:71H('1H92!#3U!94DE'[EMAIL PROTECTED]
M(EN('1H92!,24-%3E-%(9I;4L(%N9!T:%T('1H92!,24-%3E-%#0HO
M+R!F:6QE(ES(1IW1R:6)U=5D('=I=@@=AE(UO9EF:65D(-O94N
[EMAIL PROTECTED](@34%+15,@[EMAIL PROTECTED])3TY3($]2
M(%=!4E)!3E1)15,L($584%)%4U,@3U(@24U03$E%1X-B\O($)Y('=A2!O
M9B!E%MQE+!B=70@;F]T(QI;6ET871I;VXL($QI8V5NV]R($U!2T53
M($Y/#0HO+R!215!215-%3E1!5$E/3E,@3U(@5T%24D%.5$E%4R!/1B!-15)#
M2$%.5$%24Q)[EMAIL PROTECTED](@1DE43D534R!3U(@04Y9#0HO+R!005)424-53$%2
M(%!54E!/[EMAIL PROTECTED](@5$A!5[EMAIL PROTECTED]($](%1(12!,24-%3E-%1!33T94
M5T%212!#3TU03TY%3E13#0HO+R!/4B!$3T-5345.5$%424].(%=)[EMAIL PROTECTED]
M($E.1E))3D=%($%.62!0051%3E13+!#3U!94DE'2%13+!44D%$14U!4DM3
M#0HO+R!/4B!/5$A%4B!224=(5%,N#0HO+ST]/3T]/3T]/3T]/3T]/3T]/3T]
M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]
M/3T]/3T]#0H-[EMAIL PROTECTED]/4U1?1U)!4$A?251%4D%424].7TU!0U)/
M4U](4% -B-D969I;[EMAIL PROTECTED]/4U1?1U)!4$A?251%4D%424].7TU!0U)/4U](
M4% -@T*(V1E9FEN92!1TQ?0T%4*'@L2D@ C(R!Y#0HC95F:6YE($)'
M3%]25)35AL:6YE;G5M*2!1TQ?0T%4*)G;%]F:7)S=%\L;EN96YU;2D-
MB-D969I;[EMAIL PROTECTED],7TQ!4U0H;EN96YU;[EMAIL PROTECTED],7T-!5AB9VQ?;%S=%\L
M;EN96YU;2D-@T*+RH-B @0D=,7T9/4D%,3%]615)424-%4U]4*'8L(L
M(=R87!H7W0I( O+R!4:ES(ES(]N(QI;[EMAIL PROTECTED](!E'!A;F1S('1O
M('1H92!F;VQL;W=I;FL()U=!A;P@;[EMAIL PROTECTED]AE('-A;64@;EN90T*#0H@
M(9OB H='EP96YA;[EMAIL PROTECTED]W0Z.F=R87!H7W1R86ETSQGF%P:%]T/CHZ
M=F5R=5X7VET97)A=]R( T*( @( @( @(!B9VQ?9FERW1?.2 ]('9E
MG1I8V5S*I+F9IG-T+!B9VQ?;%S=%\Y([EMAIL PROTECTED]EC97,H9RDNV5C
M;VYD.PT*( @( @()G;%]F:7)S=%\Y($]()G;%]L87-T7SD[()G;%]F
M:7)S=%\Y([EMAIL PROTECTED]W1?.2D-B @(!F;W(@*'1Y5N86UE()O;W-T
M.CIGF%P:%]TF%I=',\9W)AA?=#XZ.G9EG1E%]D97-CFEP=]R('8[
M#0H@( @( @(!B9VQ?9FERW1?.2 A/2!B9VQ?;%S= _(AV([EMAIL PROTECTED])G
M;%]F:7)S=%\Y+!TG5E*2 Z(9A;'-E.PT*( @( @( @*RMB9VQ?9FER
MW1?.2D-@T*(!4:4@'5R]S92!O9B!H879I;F@='=O(9OBUL;V]P
MR!IR!J=7-T('1O('!R;W9I9[EMAIL PROTECTED];%C92!T;PT*(!D96-L87)E()O
M=@@=AE(ET97)A=]R(%N9!V86QU92!V87)I86)L97,N(%1H97)E(ES
M(')E86QL2!O;FQY#0H@(]N92!L;V]P+B!4:4@W1O'!I;F@8V]N9ET
M:6]N(=E=',@[EMAIL PROTECTED]'=O(UO[EMAIL PROTECTED]EM97,@=AA;B!I= T*(!U
MW5A;QY('=O=6QD()E+!O:!W96QL+B!4:4@F5AV]N(9OB!T:4@
M8F=L7V9IG-T7SD@/2!B9VQ?;%S=%\Y#0H@(EN('1H92!O=71EB!F;W(M
M;]O!IR!I;B!C87-E('1H92!UV5R('!U=',@82!BF5A:R!S=%T96UE
M;G0-B @:[EMAIL PROTECTED]AE(EN;F5R(9OBUL;[EMAIL PROTECTED]@(%1H92!O=AEB!M
M86-R;W,@=V]R:R!I;B!A('-I;6EL87(@9F%S:EO;BX-@T*(!5[EMAIL PROTECTED]AE
M(%]4('9EG-I;VYS('[EMAIL PROTECTED]AE(=R87!H('1Y4@:7,@82!T96UP;%T
M92!P87)A;65T97(@;W(-B @95P96YD96YT(]N([EMAIL PROTECTED]5MQA=4@%R
M86UE=5R+B!/=AEG=I[EMAIL PROTECTED]('1H92!N;[EMAIL PROTECTED]@=F5RVEO;G,N#0H@
M( T*(HO#0H-@T*(V1E9FEN92!1TQ?1D]204Q,7U9%4E1)0T537U0H5DY!
M344L($=.04U%+!'F%P:%1Y4I(%P-F9OB H='EP96YA;[EMAIL PROTECTED]W0Z
M.F=R87!H7W1R86ETSQ'F%P:%1Y4^.CIV97)T97A?:71EF%T;W(@7 T*
M(!1TQ?1DE24U0H7U],24Y%7U\I([EMAIL PROTECTED]W0Z.G9EG1I8V5S*$=.04U%
M*2YF:7)S=[EMAIL PROTECTED],7TQ!4U0H7U],24Y%7U\I([EMAIL PROTECTED]W0Z.G9EG1I8V5S
M*$=.04U%*2YS96-O;F0[(%P-B @0D=,7T9)4E-4*%]?3$E.15]?*2 A/2!
M1TQ?3$%35A?7TQ)3D5?7RD[($)'3%]25)35A?7TQ)3D5?7RD@/2!1TQ?
M3$%35A?7TQ)3D5?7RDI(%P-B @9F]R(AT7!E;F%M92!B;V]S=#HZ9W)A
MA?=')A:71S/$=R87!H5'EP93XZ.G9EG1E%]D97-CFEP=]R(%9.04U%
M.R!#0H@( @0D=,7T9)4E-4*%]?3$E.15]?*2 A/2!1TQ?3$%35A?7TQ)
M3D5?7RD@/R H5DY!344@/2 J0D=,7T9)[EMAIL PROTECTED]')U92DZ
M9F%LV4[(%P-B @( @*RM1TQ?1DE24U0H7U],24Y%7U\I*0T*#0HC95F
M:6YE($)'3%]3U)!3$Q?5D525$E#15,H5DY!344L($=.04U%+!'F%P:%1Y
M4I(%P-F9OB H8F]OW0Z.F=R87!H7W1R86ETSQ'F%P:%1Y4^.CIV
M97)T97A?:71EF%T;W(@7 T*(!1TQ?1DE24U0H7U],24Y%7U\I([EMAIL PROTECTED]
MW0Z.G9EG1I8V5S*$=.04U%*2YF:7)S=[EMAIL PROTECTED],7TQ!4U0H7U],24Y%7U\I
M([EMAIL PROTECTED]W0Z.G9EG1I8V5S*$=.04U%*2YS96-O;F0[(%P-B @0D=,7T9)
M4E-4*%]?3$E.15]?*2 A/2!1TQ?3$%35A?7TQ)3D5?7RD[($)'3%]25)3
Re: [boost] [BGL] iteration macros
Hi Csaba, Iteration macros did not work without some 'using' directives because it uses functions from boots but actually without the boost:: qualifier. E.g. BGL_FORALL_VERTICES(v,g,graph_t) did not compile unless you have using namespace boost or using namespace boost::vertices before the invocation of the macro. Pls find attached iteration_macros.hpp that corrects this problem. Thanks for sending this patch! Unfortunately, I don't think it's correct. The problem is that if I define my own graph type, then functions like vertices are not likely to be defined in namespace boost. Therefore, if your patch is applied, user-defined graph types are no longer usable with iteration macroses. Why the change is needed? Are you on a compiler which does not implement argument-dependent lookup? (BTW, it's more convenient if you send your patches as unified diff against the unmodified sources, in MIME attachment, not uuencoded) Thanks, Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: string conversion methods
Jeff Garland wrote: In date-time there are several 'to_string' functions that provide different ouput formats so a single 'str()' method isn't going to be enough. As for c_str(), you can use this once you have std::string. From my view there is no point in trying to force fit this functionality into an inadequate interface. Finally, by keeping these as free functions dates and times can be used without including I/O headers which the 'to_string' functions use. I'm not saying replace all the _string methods with a str() but jshould we have str() native_file_str() to_simple_str() or string() native_file_string() to_simple_string() just to commonise things. Filesystem has a string() method. stringstreams use str(). I also agree that boost libraries don't need a c_str() method since this can come from the string() (or str()) method. Thanks Russell ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Visitor-based framework to describe classes with example ofobjectdump in XML format
This framework might be interested to those who wishes to read and write
members of classes using member-names. Stuff like serialization, messaging,
automatic binding of class members with GUI/Web forms and OODBs (although
they have ODMG C++ binding).
From user point of view it's easy. Every class is described using intuitive
class-decl-like style:
void describe_Driver(descriptorDriver class_)
{
class_(Driver).derived_fromPerson()
[
member(Driver::licence_id, licence_id), // note comma operator
member(Driver::licence_issue_date, licence_issue_date)
];
}
then it's registered:
namespace {
register_classDriver, describe_Driver reg_Driver;
}
and that's all!
The framework is low level access to class and member information but it's
made using visitor, so it's very flexible and different add-ons can be
built on top of it. I implemented XML dump of objects. Currently, only
limited set of basic types are supported (int, char and std::string) but
it's easy to extend it. Pointers are not yet supported, it's a task for a
future.
Get it from here:
http://groups.yahoo.com/group/boost/files/describe_classes.tar.gz
BTW, I can imagine HTML form where members are grouped by classes (bases and
end class), types of form elements are determined automatically from member
information and pointers are represented as references. Most exciting is
that you get it using one function call! (if you described all classes
earlier).
--
Alexander Nasonov
Remove minus and all between minus and at from my e-mail for timely response
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: no semaphores in boost::thread
Jon Biggar wrote: [...] There is actually one case that needs a semaphore that has no reasonable alternative in pthreads. The only pthread synchronization operation that is asynch-reentrant safe (i.e. can be called from a signal handler) is signaling a pthread semaphore. There's no such thing as a pthread semaphore. In a *threaded* POSIX program you can use sigwait() and/or SIGEV_THREAD delivery. It would be nice if there was some abstraction available in boost threads that used this mechanism internally to get the needed behavior, but encapsulated to hide the error-proneness of a raw semaphore. Well, http://www.mail-archive.com/[EMAIL PROTECTED]/msg07519.html regards, alexander. -- http://www.ibm.com/servers/eserver/linux/fun ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Visitor-based framework to describe classes with exampleofobjectdump in XML format
Alexander Nasonov [EMAIL PROTECTED] wrote:
From user point of view it's easy. Every class is described using intuitive
class-decl-like style:
void describe_Driver(descriptorDriver class_)
{
class_(Driver).derived_fromPerson()
[
member(Driver::licence_id, licence_id), // note comma operator
member(Driver::licence_issue_date, licence_issue_date)
];
}
Cool syntax! Hmmm Reminds me of Boost.Python, luabind and ahem... Phoenix ;-)
--
Joel de Guzman
joel at boost-consulting.com
http://www.boost-consulting.com
http://spirit.sf.net
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] problems with config for intel-7.1 on Linux
I found a problem with the intel configuration for Linux. For that compiler the macro BOOST_NO_INTRINSIC_WCHAR_T gets defined although the compiler has an intrinsic wchar_t. Neither _WCHAR_T_DEFINED nor _NATIVE_WCHAR_T_DEFINED is defined on Linux. __WCHAR_TYPE__ is defined to int. Never- theless, wchar_t and int are distinct types. Looking at the boost regression test results, it seems that Intel on linux defines _WCHAR_T (which is what the EDG front-end documentation specifies for wchar_t support), so I used that as the test - should be in cvs now - can you check that it does the right thing? Thanks, John. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
