Re: [boost] Any, Function, and Signals documentation
At 06:24 PM 2/17/2003, Douglas Gregor wrote: On Monday 17 February 2003 04:49 pm, Beman Dawes wrote: Having the docs locally on my own machine is just a lot more satisfactory. Cheaper, too (my Internet access is metered service.) Well, you'll have the doc source on your machine, and can generate whatever format you want. Where is this documented? How long does it take? It there a way to only regenerate the files that change, or does the entire Boost docs have to be generated? I'd like to give it a try, but need pointers to docs. I don't even have an XML editor at the moment, let alone any of the other tools. The documentation isn't big (~650k, much smaller compressed). However, generated documentation tends to change a lot even with minor changes to the input, so unless someone has a good way to tell CVS don't track any history for this file then the CVS repository will get huge with the histories of these generated files. Understood. So we need to come up with some other smooth way of updating the documentation HTML files on developers machines to match the CVS state. Seems like a step backward. We have a simple model now. Click on CVS update (or equivalent in your favorite client) and you get the latest version of all files. CVS is the only tool needed. Sure, but we also have documentation that's inconsistent across libraries, not indexable, and unavailable in any format other than HTML. Our current simple model is simple for simple uses, but doesn't extend to any more advanced cases. A system that is too cumbersome to use isn't really more advanced, it is just a mess. We need to make the new system as easy to use as the old one or only the masochists will use it. Using generated documentation has some up-front costs: you'll need to get an XSLT processor, and maybe some stylesheets (if you don't want them downloaded on demand), and probably run a simple configuration command (now a shell script; will be in Jam eventually). I don't mind some added costs as long as the system is easy to use. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Formal review or Variant Library (Ed B.)
Ed Brey wrote:
I vote that variant be accepted into boost. I read all the
documentation, and tried out the code in a simple test under
VC7. I am very pleased with this library. Following are a
comments I have that can help make it even better:
Thanks for the favorable review. I'll try to address your comments
below.
*Design:*
Please consider incorporating a blank type. This idea
would be to allow the equivalent of void to be added to the
type list. boost::blank (or whatever it would be called)
would be meet BoundedType concept, but otherwise do nothing.
The empty function would return true if a blank is currently stored.
This is an interesting idea. It may even be possible to implement
variant to detect a void type so that the following would be allowed:
variant T1, ... void, ... Tn
In the case of a variant containing void, empty() would return true,
and visitation would be undefined.
I'd be interested if others have opinions on this issue.
Interestingly, with the addition of a blank type, variant
comes close to being a superset of boost::optional, although
not quite close enough to obsolete it.
Yes, not quite enough to obsolete it: as I noted to Fernando, variant
carries more implementation baggage than boost::optional. However, the
connection is conceptually sound.
Extract is confusing. One problem is that it is deceivingly
named. It doesn't extract data from the variant at all, but
rather provides type-specific access to data that still
resides in the variant. It is not clear from the name or the
documentation that this would be bad:
variantint* v = new variantint;
extractint i(*v);
delete v;
return i;
The area would be helped by renaming extract to access.
I tend to agree the name is confusing. So shall we call it
boost::access? Input?
The other point of confusion is when bad_extract gets thrown.
The usage sections actually does more good than harm. When
I read it, I first thought that under some conditions the
constructor would throw and sometimes it wouldn't. The throw
at in the call to operator() was subtle, especially since the
call isn't even needed. It would be better to skip the usage
and state in the constructor section that the constructor
never throws.
Duly noted. If the extract (access?) facility survives the review, I'll
make the change to the docs.
Another approach to the throwing problem would be to
eliminate the class altogether, and instead provide a member
function that returns a reference to the desired type, or
throws if there is a type mismatch. The reference would be
invalidated by an assignment of a different type to the
variant, but that is only an incremental restriction, since
the reference is invalidated in any case by destruction of
the variant. Likewise, it would be reasonable to provide a
non-throwing function (perhaps called access_matching) that
returns a pointer. I know these simple member functions
sound mundane, but I think they will solve the problem well.
I don't think a member function really will solve the problem, but I do
agree the whole extract facility can be improved.
In the past we sought to support the following...
variant... var;
T* p = extractT(var);
T r = extractT(var);
...but it had to be dropped because (essentially) ambiguity exists
between the following:
template typename T, typename Extractable
T extract(Extractable operand);
template typename T, typename Extractable
T* extract(Extractable * const operand);
If someone has an idea for a better solution, Itay and I would certainly
welcome it.
Finally, it wasn't clear to me why the return type for
which() wasn't unsigned.
It's not? I see that which() returns an unsigned int, which I believe is
the same as unsigned. (Am I wrong?)
*Implementation:*
The destroyer class contains a function with an unreferenced
formal parameter, which triggers a warning under VC7. Since
this a useful warning, all unreferenced formal parameters
should be removed (or commented out).
I'm not sure what parameter you're referring to. The only function in
destroyer class is...
template typename T
void operator()(const T operand) const
{
operand.~T();
}
...but certainly all formal parameters (i.e., operand) are referrenced
in the function body.
What sort of warning are you getting from VC7?
*Documentation:*
tutorial.html:
- a_printer and inst are not defined.
- chacne - chance
- The next code snip, demonstrate - The next code snip demonstrates
sample.html:
- What is the weight of a star or space ship? Totaling mass
would make more sense to me. :-)
- In the bad space example, total_weight's functions should
return int.
- Switching between using and not using the static_visitor
base class was confusing to me. (I didn't notice it at first
and was confused as to why result_type was defined sometimes
but not others.)
reference.html:
-
Re: [boost] linux regression tests : static-l.les ?
On Monday 17 February 2003 02:30 am, Samuel Krempp wrote: The mandrake 9 box used for the linux regression tests seem to fail static-linking tests. http://boost.sourceforge.net/regression-logs/cs-linux-links.html#format_tes t1%20gcc /usr/bin/ld: cannot find -lstdc++ collect2: ld returned 1 exit status export LD_LIBRARY_PATH g++ -static -g -o ../libs/format/test/bin/format_test1.test/gcc/debug/runtime-link-static/fo rmat_test1 ../libs/format/test/bin/format_test1.test/gcc/debug/runtime-link-static/fo rmat_test1.o ../libs/test/build/bin/libboost_test_exec_monitor.a/gcc/debug/runtime-link -static/libboost_test_exec_monitor.a ../libs/test/build/bin/libboost_test_exec_monitor.a/gcc/debug/runtime-link -static/libboost_test_exec_monitor.a ../libs/test/build/bin/libboost_test_exec_monitor.a/gcc/debug/runtime-link -static/libboost_test_exec_monitor.a ../libs/test/build/bin/libboost_test_exec_monitor.a/gcc/debug/runtime-link -static/libboost_test_exec_monitor.a-Wl,-rpath-link,. I noticed the same error for the other lib static-linked : libs/io/test/ios_state_test.cpp I'm thinking the problem is specific to the test box, since those libraries 's tests link without problem on my debian Thanks for letting me know. Tonight's regression should link properly. -- Alkis ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Any, Function, and Signals documentation
Douglas Gregor said: On Monday 17 February 2003 04:49 pm, Beman Dawes wrote: At 02:00 PM 2/17/2003, Douglas Gregor wrote: They're always available here, regenerated nightly in HTML, DocBook, FO, PDF, and man pages: http://www.cs.rpi.edu/~gregod/boost/doc/html/libraries.html That really isn't very satisfactory. In the last hour for example, pages on that web site have only been available sporadically. One minute access is OK, the next minute the site or page can't be found. No problems with other popular web sites. You probably caught me messing with the scripts (and therefore regenerating the documentation in-place). Long term, this wouldn't be satisfactory. The scripts should be generated in a seperate location to minimize the amount of time in which the online distribution is impacted. Having the docs locally on my own machine is just a lot more satisfactory. Cheaper, too (my Internet access is metered service.) Well, you'll have the doc source on your machine, and can generate whatever format you want. Not everyone will have the tools needed for generating docs. So I don't think this is satisfactory either. We don't want to stick all of the generated HTML into CVS (too big). If it is too big for the regular CVS, isn't it too big for the distribution too? How big is big? The documentation isn't big (~650k, much smaller compressed). However, generated documentation tends to change a lot even with minor changes to the input, so unless someone has a good way to tell CVS don't track any history for this file then the CVS repository will get huge with the histories of these generated files. A reasonable concern. But if we keep only release versions of generated documentation in CVS, I don't think it will be too severe. Intermediate doc changes would either have to be accessed directly from the web or generated locally from CVS. Seems a fair compromise to this issue to me. Documentation changes will show up the next morning at the aforementioned site. I'd like to add a link to this generated documentation on the main page (so it is obvious that both the current release documentation and the current CVS documentation are available on-line). Seems like a step backward. We have a simple model now. Click on CVS update (or equivalent in your favorite client) and you get the latest version of all files. CVS is the only tool needed. Sure, but we also have documentation that's inconsistent across libraries, not indexable, and unavailable in any format other than HTML. Our current simple model is simple for simple uses, but doesn't extend to any more advanced cases. But we have to meet all the needs, both simple and complex. So I think some sort of compromise is needed here. It really isn't practical for many Boost developers to download a whole tarball and unpack it every time they want to be sure their Boost tree is up to date. Unpacking doesn't do things like getting rid of obsolete files either. Need a way to just download the changed files - and that sounds like CVS to me. It's my hope that developers will adopt BoostBook for their own documentation. Then any time they want to be sure their local copy of the documentation is up-to-date they just regenerate the format they want locally. It's really not much different from rebuilding, e.g., libboost_regex with Boost Jam. Actually, today it's much different. There's no Jam files for producing the documentation, and several tools are required to run the makefiles that not all developers will have on hand. In the future I expect we'll be able to simplify the process, but you have to admit we're not there yet. So I think we need to figure out a way for generated docs to work in the context of CVS. Or am I just being too picky? If I can stabilize the filenames a bit, it _might_ be plausible to use CVS along with the cvs admin -o command, which can erase completely certain revisions of a file. It would be possible for a little grim reaper script to come by and erase all but the most recent version of each file on a nightly basis, after checking in the new version. Sounds tenuous to me... That's why I think the release snapshot compromise is better. This will still have issues with differing file names, but will put a minimal impact on the CVS repository. They will only break if the links try to link inside the documentation files, e.g., to a specific anchor. Links that go directly to the library's entry point (index.html) will find the meta-refresh index.html that redirects to the generated documentation. I've checked with inspect: nothing broke. Well, but that's because there are only three libraries being generated now. Some lib's docs do a lot more linking to other boost docs. --Beman It's easy to link out of the generated documentation to static documentation (of course), and it's much easier to link amongst entities in
Re: [boost] Formal Review: Variant Library
Jeff Garland writes: Today is the start of the formal review of the Variant library by Eric Friedman and Itay Maman. Firstly, I vote to ACCEPT the Variant library into boost, as it fills a real need. However, I have some comments: * Nowhere is it documented that using incompleteT as a type will result in values of type T being stored on the heap, whereas values of other types are stored within the variant itself. Though this is an understandable restriction (I can't see how else to handle incomplete types), this may be an issue, because operator new might be private for class T. * which() is documented to return int, when the implementation returns unsigned int. * extractT() is badly named, as it retrieves a reference-to-T, not a T --- how about extract_referenceT()? Anthony -- Anthony Williams Senior Software Engineer, Beran Instruments Ltd. Remove NOSPAM when replying, for timely response. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: boost.test thread safe bugs (and some fixes)
Gennadiy Rozental said: 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. But that's an impossibility. I have to test from multiple threads (or what would the point be?!?). Now certain parts of the interface might be restricted to a single thread... but I don't feel comfortable even with that. 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? If you consider a test suite a test case (which should be how it is, no?), then yes, that's all I'd need. 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 There's no minimal/basic part of Boost.Thread that doesn't need 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. 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? 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. If I can't measure the correctness of Boost.Threads, because Boost.Test affects the measurement, then what good is it? 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? 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. -- William E. Kempf ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: condition::notify_all
Scott McCaskill wrote: I was just looking at the win32 implementation of the condition variable class in the thread library and noticed something odd. In version 1.7 of condition.cpp, there is a bug fix for condition::notify_one. At the beginning of the function, a mutex is acquired, but not all control paths resulted in the mutex being released. Part of the fix involved making sure that the mutex is always released. However, it looks like the same behavior still exists in the current version of condition.cpp for notify_all (win32)--not all control paths will release the mutex. Am I mistaken, or is this a bug? It looks the same to me. Any comment about this? snip --Scott McCaskill Mike ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Boost.dynamic_any vs Boost.Function
{This is a second attempt to post}
With a help of boost::dynamic_any::call operation (not yet implemented) it's
possible to use boost::dynamic_any::any instead of Boost.Function. Though
this new solution is less specialized and probably slower then
Boost.Function it has one advantage demonstrated in the example below:
typedef boost::dynamic_any
boost::mpl::list
boost::dynamic_any::callvoid (int ),
boost::dynamic_any::callvoid (double )
flexible_function; // 2 in 1!
int main()
{
flexible_function f;
f = ++_1; // increment for int and double
int i = 2;
f(i); // ++i
double d = 3;
f(d); // ++d
}
--
Alexander Nasonov
Remove - m y c o p from my e-mail address for timely response
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Patch for multi_array/test/constructors.cpp
Hi there,
currently the constructors test of the multi array library fails for
VACPP6. This is due to the fact that the test uses an unsigned int
where a size_type should be used.
The attached patch replaces the unsigned int with size_t which allows
the test to pass for VACPP6 and hopefully doesn't break it for anyone
else.
Markus
Index: constructors.cpp
===
RCS file: /cvsroot/boost/boost/libs/multi_array/test/constructors.cpp,v
retrieving revision 1.3
diff -c -r1.3 constructors.cpp
*** constructors.cpp15 Jul 2002 22:19:16 - 1.3
--- constructors.cpp18 Feb 2003 12:33:16 -
***
*** 12,18
template class Array
void check_shape(const Array A,
! unsigned int* sizes,
int* strides,
unsigned int num_elements)
{
--- 12,18
template class Array
void check_shape(const Array A,
! size_t * sizes,
int* strides,
unsigned int num_elements)
{
***
*** 23,29
check_shape(A[0], ++sizes, ++strides, num_elements / A.size());
}
! void check_shape(const double, unsigned int*, int*, unsigned int)
{}
template typename ArrayA, typename ArrayB
--- 23,29
check_shape(A[0], ++sizes, ++strides, num_elements / A.size());
}
! void check_shape(const double, size_t*, int*, unsigned int)
{}
template typename ArrayA, typename ArrayB
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Patch for dynamic_bitset
Hi there, currently, dynamic bitset tests fail for VA6 because the library doesn't correctly detect that a standard compliant allocator is available. Therefore I propose the attached patch to be applied to boost/detail/dynamic_bitset.hpp. The patch uses BOOST_NO_STD_ALLOCATOR to check if a workaround is needed. It only tries to use the workaround if BOOST_NO_STD_ALLOCATOR is defined. Markus Index: dynamic_bitset.hpp === RCS file: /cvsroot/boost/boost/boost/detail/dynamic_bitset.hpp,v retrieving revision 1.11 diff -c -r1.11 dynamic_bitset.hpp *** dynamic_bitset.hpp 4 Feb 2003 09:10:50 - 1.11 --- dynamic_bitset.hpp 18 Feb 2003 11:00:39 - *** *** 64,75 dynamic_bitset_base(size_type num_bits, const Allocator alloc) : dynamic_bitset_alloc_baseAllocator(alloc), ! #if (defined(_MSC_VER) (_MSC_VER = 1300)) || !defined(_CPPLIB_VER) || (_CPPLIB_VER 306) // Dinkumware for VC6/7 m_bits(dynamic_bitset_alloc_baseAllocator:: ! m_alloc.allocate(calc_num_blocks(num_bits), 0)), #else m_bits(dynamic_bitset_alloc_baseAllocator:: ! m_alloc.allocate(calc_num_blocks(num_bits))), #endif m_num_bits(num_bits), m_num_blocks(calc_num_blocks(num_bits)) --- 64,77 dynamic_bitset_base(size_type num_bits, const Allocator alloc) : dynamic_bitset_alloc_baseAllocator(alloc), ! #ifndef BOOST_NO_STD_ALLOCATOR m_bits(dynamic_bitset_alloc_baseAllocator:: ! m_alloc.allocate(calc_num_blocks(num_bits))), #else + # if (defined(_MSC_VER) (_MSC_VER = 1300)) || !defined(_CPPLIB_VER) || +(_CPPLIB_VER 306) // Dinkumware for VC6/7 m_bits(dynamic_bitset_alloc_baseAllocator:: ! m_alloc.allocate(calc_num_blocks(num_bits), 0)), ! # endif #endif m_num_bits(num_bits), m_num_blocks(calc_num_blocks(num_bits)) ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] datetime and long long
Many of the regression tests for the date time library are failing
currently because the library relies on std::abslong long being
available. AKAIK, the C++ standard doesn't require this so the library
shouldn't make use of it.
Maybe datetime should specify it's own version of abs like this:
#include cstdlib
#include stdlib.h
template typename T T abs(T i) { return std::abs(i); }
template long long abs(long long i) {return ::llabs(i); }
Markus
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Formal Review: Variant Library
Fernando Cacciola wrote: I'm trying the variant library, by currently it doesn't compile with bcc551. I'd like to be able to compile it with my compiler so I can base my vote (tentatively to accept it) on more than the documentation and interpretation of the code. Thanks for the tentative acceptance. Is there anything so far in the documentation or your interpretation of the implementation on which you'd like to comment? The first problem is that the current type_traits/type_with_alignment.hpp does not expose max_align any more for the Borland compilers. The second problem is the extensive usage of non-type template parameters that don't follow the guidelines for integral constant expressions (full qualified access). For instance, as a rule of thumb, don't use: bool_cxyz::value but boolxyz; both mpl and the new type traits have been designed to work with the second form which works with Borland. Where is bool? (And how would that even work, seeing as bool is a reserved keyword?) I don't see it in the Boost 1.29 release or the main CVS. Where are you looking? Or exactly what technique are you describing? Since the bcc5.5.1 command line compiler is available from http://www.borland.com/index.html I ask the variant developers to download it and make the necessary changes. AFACIT there are many changes but they're all trivial. I can assist them by indicating what to change, but I don't have the time right now to made the changes myself. Getting variant to work under just two compilers (GCC 3.2 and MSVC7) as required by the formal review submission guidelines has been sufficiently time-consuming. This is why more compilers are not already supported. However, I *am interested* in porting variant to other compilers in the future, and I do welcome any assistance in this regard. Thanks for your comments, Eric ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] PRB with type_traits::is_member_function_pointer
Hi there, currently, the is_member_func_test fails for VACPP6 with the following error messages: /home/auto/schoepf/src/extern/boost-cvs/boost/type_traits/is_member_function_pointer.hpp, line 37.29: 1540-1206 (S) The class template instantiation of is_mem_fun_pointer_implvoid (UDT::*)() is ambiguous. /home/auto/schoepf/src/extern/boost-cvs/boost/type_traits/detail/is_mem_fun_pointer_impl.hpp, line 37.8: 1540-1207 (I) The template arguments match template struct is_mem_fun_pointer_implR (T::*)(). /home/auto/schoepf/src/extern/boost-cvs/boost/type_traits/detail/is_mem_fun_pointer_impl.hpp, line 40.8: 1540-1207 (I) The template arguments match template struct is_mem_fun_pointer_implR (T::*)() const. /home/auto/schoepf/src/extern/boost-cvs/boost/type_traits/detail/is_mem_fun_pointer_impl.hpp, line 42.8: 1540-1207 (I) The template arguments match template struct is_mem_fun_pointer_implR (T::*)() volatile. /home/auto/schoepf/src/extern/boost-cvs/boost/type_traits/detail/is_mem_fun_pointer_impl.hpp, line 44.8: 1540-1207 (I) The template arguments match template struct is_mem_fun_pointer_implR (T::*)() const volatile. ../libs/type_traits/test/is_member_func_test.cpp, line 17.37: 1540-0700 (I) The previous message was produced while processing struct boost::is_member_function_pointervoid (UDT::*)(). ../libs/type_traits/test/is_member_func_test.cpp, line 11.15: 1540-0700 (I) The previous message was produced while processing unnamed::is_member_function_pointer(). When looking at is_mem_fun_pointer_impl.hpp it looks like the Metrowerks compiler has the same problem. Could anyone please add a check for __IBMCPP__ =600 at line 345 of this file and regenerate it? Thanks, Markus ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Mac OS (Darwin) failures?
In looking at the Mac OS (Darwin) regression tests to see why there are so many failures, a number of tests are failing with only this message: /usr/local/boost/boost/type_traits/is_float.hpp:22: warning: use of `long double' type; its size may change in a future release /usr/local/boost/boost/type_traits/is_float.hpp:22: warning: (Long double usage is reported only once for each file. /usr/local/boost/boost/type_traits/is_float.hpp:22: warning: To disable this warning, use -Wno-long-double.) There are two odd things about this: 1) This is just a warning so why is the test being reported as failing? 2) The darwin toolset specifies CFLAGS : -Wno-long-double, so why is the warning even being issued? Any ideas? (I can't test because of lack of access to the platform.) --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Any, Function, and Signals documentation
On Tue, 18 Feb 2003, William E. Kempf wrote: Douglas Gregor said: You probably caught me messing with the scripts (and therefore regenerating the documentation in-place). Long term, this wouldn't be satisfactory. The scripts should be generated in a seperate location to minimize the amount of time in which the online distribution is impacted. Of course. Having the docs locally on my own machine is just a lot more satisfactory. Cheaper, too (my Internet access is metered service.) Well, you'll have the doc source on your machine, and can generate whatever format you want. Not everyone will have the tools needed for generating docs. So I don't think this is satisfactory either. Well, it's one of several options. If you need up-to-date documentation, you can either generate it, view it online, or download an archive. If older documentation is acceptable, it'll be in the distribution (and, if there is agreement on your next suggestion, in CVS). A reasonable concern. But if we keep only release versions of generated documentation in CVS, I don't think it will be too severe. Intermediate doc changes would either have to be accessed directly from the web or generated locally from CVS. Seems a fair compromise to this issue to me. I'm okay with this. It's my hope that developers will adopt BoostBook for their own documentation. Then any time they want to be sure their local copy of the documentation is up-to-date they just regenerate the format they want locally. It's really not much different from rebuilding, e.g., libboost_regex with Boost Jam. Actually, today it's much different. There's no Jam files for producing the documentation, and several tools are required to run the makefiles that not all developers will have on hand. In the future I expect we'll be able to simplify the process, but you have to admit we're not there yet. My intended analogy was with Boost.Build. To use Boost.Build, you need to compile and install another program (Boost Jam), and perform a build step to get updated binaries. BoostBook will be the same way: compile and install another program (XSLT processor) and perform a build step to get updated documentation. (Granted, Boost Jam comes with the Boost distribution, but an XSLT processor should not; on the other hand, you need Jam if you want to use Regex, Thread, Signals, or Date-Time, but generally nobody is required to rebuild documentation). The only issue lies in the transition period when not all documentation has been converted to Boost.Book and some of the static documentation needs to link into a library that's been converted. ... and I don't know how to do that, yet. I think there's several of us interested who will be working on this when time permits. But honestly, having it in the sandbox is at least a little inconvenient... and to me it makes little sense if some released documentation is going to depend on it. If there are no complains, I would _love_ to move BoostBook out of the sandbox and into its (presumably) permanent place in Boost CVS. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Any, Function, and Signals documentation
On Mon, 17 Feb 2003, Beman Dawes wrote: At 06:24 PM 2/17/2003, Douglas Gregor wrote: Well, you'll have the doc source on your machine, and can generate whatever format you want. Where is this documented? How long does it take? It there a way to only regenerate the files that change, or does the entire Boost docs have to be generated? Documented here: http://www.cs.rpi.edu/~gregod/boost/doc/html/boostbook.html See the Getting started section. Unfortunately, if you don't have a *nix box or Cywin, don't bother. The Makefile is the easiest way to do things, because we don't yet have Jam support. I'd like to give it a try, but need pointers to docs. I don't even have an XML editor at the moment, let alone any of the other tools. At a minimum, you'll need an XSLT processor. The aforementioned documentation has links binaries for my preferred processor, which is also available via Cygwin and on many Unix platforms. Seems like a step backward. We have a simple model now. Click on CVS update (or equivalent in your favorite client) and you get the latest version of all files. CVS is the only tool needed. Sure, but we also have documentation that's inconsistent across libraries, not indexable, and unavailable in any format other than HTML. Our current simple model is simple for simple uses, but doesn't extend to any more advanced cases. A system that is too cumbersome to use isn't really more advanced, it is just a mess. We need to make the new system as easy to use as the old one or only the masochists will use it. Working on it :) Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Any, Function, and Signals documentation
Douglas Paul Gregor said: On Tue, 18 Feb 2003, William E. Kempf wrote: Douglas Gregor said: A reasonable concern. But if we keep only release versions of generated documentation in CVS, I don't think it will be too severe. Intermediate doc changes would either have to be accessed directly from the web or generated locally from CVS. Seems a fair compromise to this issue to me. I'm okay with this. What are other's thoughts on this compromise? It's my hope that developers will adopt BoostBook for their own documentation. Then any time they want to be sure their local copy of the documentation is up-to-date they just regenerate the format they want locally. It's really not much different from rebuilding, e.g., libboost_regex with Boost Jam. Actually, today it's much different. There's no Jam files for producing the documentation, and several tools are required to run the makefiles that not all developers will have on hand. In the future I expect we'll be able to simplify the process, but you have to admit we're not there yet. My intended analogy was with Boost.Build. To use Boost.Build, you need to compile and install another program (Boost Jam), and perform a build step to get updated binaries. BoostBook will be the same way: compile and install another program (XSLT processor) and perform a build step to get updated documentation. (Granted, Boost Jam comes with the Boost distribution, but an XSLT processor should not; on the other hand, you need Jam if you want to use Regex, Thread, Signals, or Date-Time, but generally nobody is required to rebuild documentation). This a minor difference here, though. The bjam executable boot straps fairly easily on most platforms. XSLT processors aren't quite as convenient. At least that was my experience that last time I tried to do DocBook stuff on a Windows box (with out Cygwin). Things may have improved in this regard, and if not, I'm sure we can improve things ourselves, but I'm nervous that we're not ready for this yet. The only issue lies in the transition period when not all documentation has been converted to Boost.Book and some of the static documentation needs to link into a library that's been converted. ... and I don't know how to do that, yet. Which is the single biggest concern with the migration to Boost.Book. Here's where I see the real catch-22, and I'm not sure how to deal with it. I think there's several of us interested who will be working on this when time permits. But honestly, having it in the sandbox is at least a little inconvenient... and to me it makes little sense if some released documentation is going to depend on it. If there are no complains, I would _love_ to move BoostBook out of the sandbox and into its (presumably) permanent place in Boost CVS. Well, I'm in favor of that, since we're moving at least some of the documentation to Boost.Book with this release (or so I gathered). So what's the group opinion on this one? -- William E. Kempf ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: condition::notify_all
Michael Glassford said: Scott McCaskill wrote: I was just looking at the win32 implementation of the condition variable class in the thread library and noticed something odd. In version 1.7 of condition.cpp, there is a bug fix for condition::notify_one. At the beginning of the function, a mutex is acquired, but not all control paths resulted in the mutex being released. Part of the fix involved making sure that the mutex is always released. However, it looks like the same behavior still exists in the current version of condition.cpp for notify_all (win32)--not all control paths will release the mutex. Am I mistaken, or is this a bug? It looks the same to me. Any comment about this? I somehow missed the original post here. Now fixed in CVS. -- William E. Kempf ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: datetime and long long
The problem is, VA _has_ std::abs. You just need a specialization for
long long then.
namespace std {
template long long abs(long long n) { return llabs(n); }
}
Don't know if this is legal, though.
How about just skipping the template:
#ifdef _VA_WHATEVER_COMPILER_MACRO_IS
namespace std {
long long abs(long long n) { return llabs(n); }
}
#endif
Jeff
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Formal review or Variant Library (Ed B.)
Eric Friedman wrote: In the past we sought to support the following... variant... var; T* p = extractT(var); T r = extractT(var); ...but it had to be dropped because (essentially) ambiguity exists between the following: template typename T, typename Extractable T extract(Extractable operand); template typename T, typename Extractable T* extract(Extractable * const operand); This is only ambiguous in its most general form given above. If you rewrite it as template class T, ... T extract(variant... operand); template class T, ... T const extract(variant... const operand); template class T, ... T * extract(variant... * operand); template class T, ... T const * extract(variant... const * operand); it's no longer ambiguous. The other option is to support a dynamic_cast-style extract: T * p = extractT*(var); T r = extractT(var); but it would likely require partial ordering/specialization. extract is probably not the best name in both cases since it doesn't extract, it returns a reference to the internal representation. The documentation needs to describe when this reference is invalidated. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] datetime and long long
At 11:26 AM 2/18/2003, Jeff Garland wrote: Take a look at bosot/date_time/compiler_config.hpp which does something similar. All we need to do to fix these regressions is add the compiler to the list of those that don't have std::abs at line 34. Based on the above, I've bump the VC++ version up to 1310 to cover version 7.1. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Formal Review: Variant Library
How different is boost::any from this new variant library? Don't they address the same issue? rod. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: 'optional' - request for extension
Eric Friedman [EMAIL PROTECTED] wrote in message b2s34c$bav$[EMAIL PROTECTED]">news:b2s34c$bav$[EMAIL PROTECTED]... Fernando Cacciola wrote: [snip] (3) variant dependency. We are just about to review boost::variant. I was planning to wrap optional around variant discarding its current implementation. This might seem like a good idea in theory, but for the simple case presented by optional, the baggage of variant's implementation is overkill IMO. Indeed. I've been looking at the implementation and it is exactly the case. Anyway, I see that you're progressing towards move semantics, so I will likely find useful those utilities once you finish them (in order to increase exception guarantess) It might be useful in the future, however, to build a tests for optional that compares your boost::optionalT against a suitably-wrapped boost::variantempty, T. Yes. However, to support the in-place form and use variant, the later will have to suppport this form itself. Proposed solution: [snip] ...I figured that a factory could move the forwarding problem out of optional while at the same time allow for an almost identical usage. This seems like a good idea, particularly in terms of integrating factory-based initialization with variant. Great. [snip] It allows to use in-place for noncopyable default-constructible objects: optionalZ opt(true,in_place()); It allows you to have alternative factories which support alternative forwarding methods: optionalX opt(false,in_place2(2,hello)); And since the factory can be reused, plugging the mechanism into variant, for instance, is trivial. Notice that the verbosity is actually put in the in-place factory mainly. I would implement and document such factory as another utility and just use it on optional interface. Let me know when you get this working for optional. I personally would be quite interested in seeing how it might fit into variant. (I won't be making any changes, however, until after variant's review has ended.) OK. I'll keep you inform. -- Fernando Cacciola ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_class
Rani Sharoni wrote: You can probably use a similar approach to implement yet another is_class (not void, reference and doesn't have an implicit standard conversion to bool). I wonder whether int () const has an implicit standard conversion to bool. ;-) ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: boost.test thread safe bugs (and some fixes)
William E. Kempf wrote: 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). And if another example is needed, I suspect the sockets library is going to want threadsafe testing in the near future. [although this may apply to any library that itself considers thread safety, such as shared_ptr] -- AlisdairM Team Thai Kingdom ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] datetime and long long
Take a look at bosot/date_time/compiler_config.hpp which does something similar. All we need to do to fix these regressions is add the compiler to the list of those that don't have std::abs at line 34. Based on the above, I've bump the VC++ version up to 1310 to cover version 7.1. Good, thanks. Jeff ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: is_class
Peter Dimov wrote: Rani Sharoni wrote: You can probably use a similar approach to implement yet another is_class (not void, reference and doesn't have an implicit standard conversion to bool). I wonder whether int () const has an implicit standard conversion to bool. ;-) Good catch. According to 8.3.5/7 - A typedef of a function type whose declarator includes a cv-qualifier-seq shall be used only to declare the function type for a nonstatic member function, to declare the function type to which a pointer to member refers, or to declare the top level function type of another function typedef declaration. This means that you can't take a reference or pointer to such types and therefore such types will fail all the is_function implemetations I know about (and few other traits like is_convertible). typedef int ftype() const; templatetypename T char *f(T*); templatetypename T long *f(...); long *p = fftype(0); // Failed to compile using EDG 3.0.1 and GCC3.2 I think that this case should fall under SFINAE and it might worth a DR. Rani ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Preliminary submission: command line config file li brary
From: Vladimir Prus [EMAIL PROTECTED] Rob Stewart wrote: The purpose of command line parsing is to decode the arguments list into pieces of information, abstracting the syntax of the command line away from the program. Thus, the library should be able to understand any of various encoding schemes. That's syntantic level. I believe it should be as independent from meaning of options as possible: command line, preferrable, should be immediately parsable by humans. I think we're saying the same thing. My point is that the library should abstract the parsing such that the program need only describe the supported options and query to learn which have been set and with what values. The format those parameters take on the command line or in a configuration file should be hidden. The question then becomes how the library should provide the values from the command line. There are a number of fundamental types that could be exposed by the library: bool, long, double, and string. The question is whether the library should support any others. I selected those types because Boolean and string parameters are obviously important, and long and double would handle pretty much all numeric arguments one would put in a command line. The level 2 of my library provides only syntantic representation of the read options. See http://zigzag.cs.msu.su:7813/program_options/html/ for the list of layers. I can't access that page, but I was simply suggesting that the library can expose a rather minimal set of types gleaned from the command line. Client code can transform from those types to anything else desired. Boolean and string parameters are obvious. Nothing else is needed as strings can (obviously) represent all other arguments. Sure, you could provide a means to read a file line by line and pass each line to a parser of some sort. However, given all of the ways to parse the text one might find in such a file, I don't see how that could be done so it is sufficiently flexible and yet actually provides value. IOW, the parsing would be little more than read a line, give it to the parser, read another line, give it to the parser, etc. That certainly doesn't justify a special library. What special library? I see two libraries in what you've proposed: one that manages command line parsing and one that manages configuration file parsing. If command line and configuration file parsing are completely abstracted from the parameter specification/management, then it's a question of what configuration formats are provided by default, possibly bloating client code unnecessarily. Perhaps I've missed some valuable service that should be included in the proposed library, but I can't see that it should do more than what I've outlined herein. If you do, please enlighten me! It looks like you don't need some of the extra features that both Gennadiy and myself are after. For example, custom value interpreration or automatic help message? An automatic help message is certainly useful; I simply didn't mention it specifically. Custom value interpretation strikes me as overkill. If your library provides a string corresponding to a particular parameter, I can use that string in myriad ways to produce information for my program. Putting that logic into a command line parsing library seems over the top. Could you please tell which features in both designs are unnecessary and should be removed? I don't know the full set of features either of you have provided at the moment, but I hope the above clarifies my thoughts on the scope of such a library. I'll second the question raised regarding the more complex parsing: isn't that the job of a tool like Spirit? Be careful to avoid doing too much in this library. You can make it really powerful and capable, but that alone may keep too many at bay. -- Rob Stewart [EMAIL PROTECTED] Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer; ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Any, Function, and Signals documentation
On Tue, 18 Feb 2003, William E. Kempf wrote: If there are no complains, I would _love_ to move BoostBook out of the sandbox and into its (presumably) permanent place in Boost CVS. Well, I'm in favor of that, since we're moving at least some of the documentation to Boost.Book with this release (or so I gathered). So what's the group opinion on this one? -- William E. Kempf For reference, here is the directory structure I'm proposing: - BoostBook XML documentation for each library will go into libs/library-name/doc (wherever the HTML documentation was located) - BoostBook tools go into tools/doc. Specifically: + BoostBook DTD will be in tools/doc/dtd/ + BoostBook XSL will be in tools/doc/xsl/ + BoostBook docs will be in tools/doc/doc + BoostBook makefiles/Jamfiles/etc will be in tools/doc/build - Generated documentation goes into doc/ + doc/html, doc/man, and doc/pdf contain generated documentation in HTML, Man pages, and PDF, respectively - Top-level documentation (e.g., library categories, descriptions of libraries with static documentation) goes into doc/src Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: condition::notify_all
William E. Kempf wrote: Michael Glassford said: Scott McCaskill wrote: I was just looking at the win32 implementation of the condition variable class in the thread library and noticed something odd. In version 1.7 of condition.cpp, there is a bug fix for condition::notify_one. At the beginning of the function, a mutex is acquired, but not all control paths resulted in the mutex being released. Part of the fix involved making sure that the mutex is always released. However, it looks like the same behavior still exists in the current version of condition.cpp for notify_all (win32)--not all control paths will release the mutex. Am I mistaken, or is this a bug? It looks the same to me. Any comment about this? I somehow missed the original post here. Now fixed in CVS. Thanks for looking into it, Mike ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Win32/VC++ 7.1 final beta regression tests posted
Because of interest in how well Boost 1.30.0 and VC++ 7.1 will work together, I've posted regression tests. See http://boost.sourceforge.net/regression-logs/ The folks at Microsoft asked that we identify these tests as beta, since the actual release may get slightly different results. And of course the Boost code is not quite the 1.30.0 release yet either. I'll try to rerun these occasionally, but they won't happen daily unless someone makes a specific request. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: is_class
Rani Sharoni wrote: Peter Dimov wrote: Rani Sharoni wrote: You can probably use a similar approach to implement yet another is_class (not void, reference and doesn't have an implicit standard conversion to bool). I wonder whether int () const has an implicit standard conversion to bool. ;-) Good catch. According to 8.3.5/7 - A typedef of a function type whose declarator includes a cv-qualifier-seq shall be used only to declare the function type for a nonstatic member function, to declare the function type to which a pointer to member refers, or to declare the top level function type of another function typedef declaration. This means that you can't take a reference or pointer to such types and therefore such types will fail all the is_function implemetations I know about (and few other traits like is_convertible). I forgot that the implementation that uses SFINAE works (creating array of function type fail the deduction). typedef int ftype() const; templatetypename T char *f(T *); templatetypename T long *f(...); long *p = fftype(0); // Failed to compile using EDG 3.0.1 and GCC3.2 I think that this case should fall under SFINAE and it might worth a DR. Rani ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Win32/VC++ 7.1 final beta regression tests posted
Beman Dawes wrote: Because of interest in how well Boost 1.30.0 and VC++ 7.1 will work together, I've posted regression tests. See http://boost.sourceforge.net/regression-logs/ You might want to disable warning 4675, resolved overload was found by argument-dependent lookup. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Win32/VC++ 7.1 final beta regression tests posted
Beman Dawes wrote: Because of interest in how well Boost 1.30.0 and VC++ 7.1 will work together, I've posted regression tests. See http://boost.sourceforge.net/regression-logs/ From the department of nitpickers ;¬ ) The links to the fail messages refer to .../cs-win32-links.htm#... rather than .../cs-vc71beta-links.htm#... I manually fixed-up the URL in my browser and saw that the vc71beta html file is present and correct though. -- AlisdairM ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Fwd: Thread-Local Storage (TLS) and templates
Any thoughts on this issue?
From: Steve Clamage [EMAIL PROTECTED]
To: C++ core language mailing list
Message c++std-core-9820
Some compilers implement thread-local storage (TLS) for what would
otherwise be global variables. The compiler and runtime system
arrange for each thread to see its own copy of a global variable.
Should the address of such a variable be allowed as a non-type
template parameter? For example, this code is OK:
extern int k;
template int* V class C { ... };
Ck ck;
But what if k is designated thread-local? The actual variable
referred to by the address of k will differ among threads.
(I'm assuming an implementation where k results in a link-time
constant whether k is an ordinary or thread-local variable.)
In favor of allowing k to be thread-local:
Converting a multi-process program to multi-thread is simple.
Just declare per-process variables to be thread local. Template and
other usage of such variables remains separate per thread as it was
per process.
Against allowing k to be thread-local:
What does the ODR mean in this situation? (Counter-counter
argument: threaded programs and per-thread variables could
mean that the ODR needs a different definition anyway.)
If a programmer instantiates C on a thread variable, would
having thread-specific behavior be expected or unexpected?
What is existing practice among compilers that support TLS?
---
Steve Clamage, [EMAIL PROTECTED]
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Formal Review: Variant Library
-Itay Rodolfo Lima [EMAIL PROTECTED] wrote in message b2tm6v$9o7$[EMAIL PROTECTED]">news:b2tm6v$9o7$[EMAIL PROTECTED]... How different is boost::any from this new variant library? Don't they address the same issue? In short: (1) boost::any can accept a value of any possible type. boost::variant accepts only values of a finite set of types, which are passed as template parameters (2) boost::any offers a query-based mechanism for accessing its held value: any_castT(a); This operation may fail (at runtime). The equivalent facility of boost::variant is: apply_visitor(a_visitor, a_variant). This operation will fail at *compile-time* if a_visitor is not a valid visitor for a_variant. More details can about visitation can be found in variant's docs. -Itay ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Lock Classes: Does anyone care.
I posted this a couple days ago and have yet to seen any sort of reply or any sign that anyone is interested. If people are having trouble understanding the concept please let me know and I will try harder to explain it. If you meant to reply but haven't yet, sorry for being impatient. If no one responds to this email I will assume no one cares and will give up. Even though I think it is useful I don't have the time to push it. Original Message: Attached is a series of lock I created for one of my projects. These classes have the following features. 1) The ability to acquire a lock and release it when the object goes out of scope effectively implemented the Monitor concept. 2) Avoid the need for recursive locks by careful and efficient book keeping with the out the use of global thread specific data. 3) Document and enforce guaranteed lock behavior for functions which take a lock class as a parameter. Recursive locks may avoid the need for the bookkeeping. However recursive looks are more expensive. Also, with recursive locks, as far as I know, it is imposable to temporally release the lock. For example when calling a network function I don't want to keep the lock as the object is in a consistent state and holding the lock while waiting for a reply will greatly reduce concurrency. My lock classes makes this possible to do efficiently and safely as it is not possible to accentually call a function that will release a lock without giving it permission to do so. The only downside is that you have to explicit pass the lock around to each function as a parameter. My recommendation is to use the lock classes as parameters to private methods or functions which may call each other and thus need to avoid acquiring a non recursive lock more than once. Public members can than call the private members by simply providing the function with the appropriate lock. I have not seen anything quite like it so I thought I would share it here and see what other people think. Feedback on the idea or implementation welcome. This code, at the moment, does not follow boost standards. If people think it is a worthy addition to boost I will be willing to being it up to boost standards. But for right now please refrain from making comments on coding style or the like. -- http://kevin.atkinson.dhs.org ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Fwd: Thread-Local Storage (TLS) and templates
Greg Colvin wrote:
Any thoughts on this issue?
From: Steve Clamage [EMAIL PROTECTED]
To: C++ core language mailing list
Message c++std-core-9820
Some compilers implement thread-local storage (TLS) for what would
otherwise be global variables. The compiler and runtime system
arrange for each thread to see its own copy of a global variable.
Should the address of such a variable be allowed as a non-type
template parameter? For example, this code is OK:
extern int k;
template int* V class C { ... };
Ck ck;
But what if k is designated thread-local? The actual variable
referred to by the address of k will differ among threads.
Looks like a no-brainer, k can't be a compile-time constant if k is
thread-local.
1.
void f()
{
Ck ck;
}
2.
void f()
{
typedef Ck ck_type;
ck_type ck;
}
3.
typedef Ck ck_type;
void f()
{
ck_type ck;
}
The type of ck cannot depend on the thread that is executing f.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Lock Classes: Does anyone care.
Kevin, we're currently in the middle of a release and a formal review... If you wait a week or so.. and recall our attention, you're likely to get a response. Just hold on. Thanks, Fernando Cacciola ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Mac OS (Darwin) failures?
on 2/18/03 10:58 AM, Beman Dawes at [EMAIL PROTECTED] wrote: In looking at the Mac OS (Darwin) regression tests to see why there are so many failures, a number of tests are failing with only this message: /usr/local/boost/boost/type_traits/is_float.hpp:22: warning: use of `long double' type; its size may change in a future release /usr/local/boost/boost/type_traits/is_float.hpp:22: warning: (Long double usage is reported only once for each file. /usr/local/boost/boost/type_traits/is_float.hpp:22: warning: To disable this warning, use -Wno-long-double.) There are two odd things about this: 1) This is just a warning so why is the test being reported as failing? 2) The darwin toolset specifies CFLAGS : -Wno-long-double, so why is the warning even being issued? Any ideas? (I can't test because of lack of access to the platform.) The posted regression test was done with the gcc toolset but on Mac OS X. You can tell because the heading on the Pass/Fail column says GNU GCC instead of darwin. The gcc toolset doesn't include the flag to disable the long double warning. I just ran the test regression tests and there were significantly fewer errors. I would be will to run regular regression tests if someone would explain where I need to post the output. Chris ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Formal Review: Variant Library
Eric Friedman [EMAIL PROTECTED] wrote in message b2s4b1$eof$[EMAIL PROTECTED]">news:b2s4b1$eof$[EMAIL PROTECTED]... Fernando Cacciola wrote: I'm trying the variant library, by currently it doesn't compile with bcc551. I'd like to be able to compile it with my compiler so I can base my vote (tentatively to accept it) on more than the documentation and interpretation of the code. Thanks for the tentative acceptance. Is there anything so far in the documentation or your interpretation of the implementation on which you'd like to comment? Yes, but all just trivial issues... see below The first problem is that the current type_traits/type_with_alignment.hpp does not expose max_align any more for the Borland compilers. The second problem is the extensive usage of non-type template parameters that don't follow the guidelines for integral constant expressions (full qualified access). For instance, as a rule of thumb, don't use: bool_cxyz::value but boolxyz; both mpl and the new type traits have been designed to work with the second form which works with Borland. Where is bool? (And how would that even work, seeing as bool is a reserved keyword?) I don't see it in the Boost 1.29 release or the main CVS. Where are you looking? Or exactly what technique are you describing? Sorry... I typed too fast. I'll describe below the sort of required changes. Since the bcc5.5.1 command line compiler is available from http://www.borland.com/index.html I ask the variant developers to download it and make the necessary changes. AFACIT there are many changes but they're all trivial. I can assist them by indicating what to change, but I don't have the time right now to made the changes myself. Getting variant to work under just two compilers (GCC 3.2 and MSVC7) as required by the formal review submission guidelines has been sufficiently time-consuming. This is why more compilers are not already supported. I see. However, I *am interested* in porting variant to other compilers in the future, and I do welcome any assistance in this regard. All right. My initial requirement to be able to compile the library in order to vote was biased by the complexity of the implementation (I wanted to make sure it worked as intended). However, after staring at it more closely I can now follow the implementation and see for myself that it is good enough. After looking closely at the documentation, implementation and examples I vote to ACCEPT the library. Comments follow: ** documentation ** a) In the introduction appears the term 'inhomogeneous'; isn't the term 'heterogeneous' a much more familiar synonym? b) The first variant program in the tutorial is actually full of errors :-) c) The docs says that at least two parameters should be supplied. This isn't true. In fact, the implementation itself uses variants of a single parameter. d) The docs don't mention at all the possibility of using an mpl seuqence as the type set. Even if this is a restricted feature -for those good compilers-, it should be mentioned because it's most useful. e) Th visitation examples mismatches 'print_int_float_visitor' with 'print_int_char_visitor' f) In the Visitor concept docs, it says: ...a function object which unambiguously accepts any value of each of the variant's bounded types... First, I think this description is too informal, it itsn't clear if the visitor must have overloads for all of the types _separately_, or if the arguments must be passed by (const) reference, etc... Perhaps something like: ...a function object whith an overloaded set of function call operators such that any value of each and all of the variant's bounded types can be passed to one of the operators unambiguosly, probably requireing an implicit conversion. ** design ** I've found the design overally satisfactory. The overload-resolution based value-semantics are a winner IMO. I'm not so sure about the usability of the incomplete-type support given its heap usage, but that's a corner feature and I can't see any better way. I ditto others comments about support for 'void' as one of the types with the corresponding change in 'empty()' semantics. I also like the 'access' (currently extract) version that returns T* with NULL meaning that the currenty type isn't T. This would leverage handy idioms. ** implementation ** First of all, I'd like to congratulate the authors for a very clear implementation! I've been able to follow it even though it is rather complex and heavy on metaprogramming. Good work! a) static_visitable seems to be needed/useful for visitable-types, yet it is undocumented. b) I tend to disklike librariers with warnings about unreacheable code and fixed conditions. The main conditional in 'using_storage1' and related code will have this if there are no throwing types in the set. At least for Borland, it would be better to enclose the code between: c) 'which' and realated is
Re: [boost] Lock Classes: Does anyone care.
On Tue, 18 Feb 2003, Fernando Cacciola (Home) wrote: Kevin, we're currently in the middle of a release and a formal review... If you wait a week or so.. and recall our attention, you're likely to get a response. Just hold on. No problem. I'm in no rush. If I don't get any response expressing serious interest I will repost in two weeks. -- http://kevin.atkinson.dhs.org ___ 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
Re: [boost] Mac OS (Darwin) failures?
[2003-02-18] Chris Little wrote: on 2/18/03 10:58 AM, Beman Dawes at [EMAIL PROTECTED] wrote: In looking at the Mac OS (Darwin) regression tests to see why there are so many failures, a number of tests are failing with only this message: /usr/local/boost/boost/type_traits/is_float.hpp:22: warning: use of `long double' type; its size may change in a future release /usr/local/boost/boost/type_traits/is_float.hpp:22: warning: (Long double usage is reported only once for each file. /usr/local/boost/boost/type_traits/is_float.hpp:22: warning: To disable this warning, use -Wno-long-double.) There are two odd things about this: 1) This is just a warning so why is the test being reported as failing? 2) The darwin toolset specifies CFLAGS : -Wno-long-double, so why is the warning even being issued? Any ideas? (I can't test because of lack of access to the platform.) The posted regression test was done with the gcc toolset but on Mac OS X. You can tell because the heading on the Pass/Fail column says GNU GCC instead of darwin. The gcc toolset doesn't include the flag to disable the long double warning. I just ran the test regression tests and there were significantly fewer errors. I would be will to run regular regression tests if someone would explain where I need to post the output. scp result-file.html shell.sourceforge.net:/home/groups/b/bo/boost/htdocs/regressions-logs Reapeat that for the the index and the links files. -- grafik - Don't Assume Anything -- [EMAIL PROTECTED] - [EMAIL PROTECTED] -- 102708583@icq ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Formal Review: Variant Library
Sorry... I sent the last post but I forgot this:
The following pragmas turn off the warnings about condition is always
'true/false
and unreachable code on Borland:
int foo() {
#if BOOST_WORKAROUND(__BORLANDC__)
#pragma option push -w-ccc -w-rch
#endif
if ( true )
return 2 ;
return 0 ;
#if BOOST_WORKAROUND(__BORLANDC__)
#pragma option pop
#endif
}
--
Fernando Cacciola
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Fwd: Thread-Local Storage (TLS) and templates
Greg Colvin wrote: Any thoughts on this issue? My thoughts: a) *errno* (the C99/POSIX.1-2001/SUSv3 edition of it). b) *lazy* is good. Well, http://groups.google.com/groups?selm=3DA6C62A.AB8FF3D3%40web.de (Subject: Re: local statics and TLS objects) https://listman.redhat.com/pipermail/phil-list/2002-November/000322.html (faster pthread_getspecific) regards, alexander. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Lock Classes: Does anyone care.
Fernando Cacciola (Home) wrote: Kevin, we're currently in the middle of a release and a formal review... If you wait a week or so.. and recall our attention, you're likely to get a response. Just hold on. And, in the meantime, you might want to post your stuff to: news:comp.programming.threads regards, alexander. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: RE:Formal Review: Variant Library
[EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED].. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Win32/VC++ 7.1 final beta regression tests posted
At 02:35 PM 2/18/2003, Alisdair Meredith wrote: Because of interest in how well Boost 1.30.0 and VC++ 7.1 will work together, I've posted regression tests. See http://boost.sourceforge.net/regression-logs/ From the department of nitpickers ;¬ ) The links to the fail messages refer to .../cs-win32-links.htm#... rather than .../cs-vc71beta-links.htm#... I manually fixed-up the URL in my browser and saw that the vc71beta html file is present and correct though. Duh... Fixed. Thanks! --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: RE:Formal Review: Variant Library
[EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED].. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Formal review or Variant Library (Ed B.)
Eric Friedman [EMAIL PROTECTED] wrote in message
003c01c2d6f7$2a812c90$49390c80@erk">news:003c01c2d6f7$2a812c90$49390c80@erk...
[...]
template typename T
void operator()(const T operand) const
{
operand.~T();
}
[...]
Is the destructor really a const function?
Dave
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Win32/VC++ 7.1 final beta regression tests posted
At 02:21 PM 2/18/2003, Peter Dimov wrote: Beman Dawes wrote: Because of interest in how well Boost 1.30.0 and VC++ 7.1 will work together, I've posted regression tests. See http://boost.sourceforge.net/regression-logs/ You might want to disable warning 4675, resolved overload was found by argument-dependent lookup. Yeah, I saw that too. But I don't want to put effort into VC++ 7.1 until (1) Boost 1.30.0 is out the door, (2) we have a release copy, (3) I finish some non-Boost work which is backing up. If you want to make changes yourself, feel free to do so. However, please test to make sure whatever you change doesn't screw up VC++ 7.0. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Fw: Why scoped_ptr dost provide custom deallocation?
Greg Colvin wrote: And I don't see a problem with adding constructors to scoped_ptr that support custom deallocation, especially since C++ has no 'finally' construct. Although someone mentioned this earlier, I have not seen it reiterated -- if the size of scoped_ptr grows to more than just the pointer itself, I can not use it. I imagine that others also need it to remain simple, at least in this respect. If someone adds anything to scoped_ptr or scoped_array that increases its size, I hope he/she will give it a new name, so that I can continue to use the current classes. -- Dick Hadsell 914-259-6320 Fax: 914-259-6499 Reply-to: [EMAIL PROTECTED] Blue Sky Studioshttp://www.blueskystudios.com 44 South Broadway, White Plains, NY 10601 ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Crunch time
Those not getting responses to queries posted to this list should be aware that it is crunch time for a lot of Boost developers - some of us are variously trying to finish off release 1.30.0, participate in a public review, meet looming deadlines for submissions to the C++ standards committee and the ACCU conference, or get in a mid-winter vacation. Some are trying to do all of those things at once! Thus apologies in advance if response is slower than usual. And don't be shy about reposting in a week or two if you don't get a response. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Win32/VC++ 7.1 final beta regression tests posted
Beman Dawes [EMAIL PROTECTED] skrev i meddelandet [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... At 02:21 PM 2/18/2003, Peter Dimov wrote: Beman Dawes wrote: Because of interest in how well Boost 1.30.0 and VC++ 7.1 will work together, I've posted regression tests. See http://boost.sourceforge.net/regression-logs/ You might want to disable warning 4675, resolved overload was found by argument-dependent lookup. Yeah, I saw that too. But I don't want to put effort into VC++ 7.1 until (1) Boost 1.30.0 is out the door, (2) we have a release copy, (3) I finish some non-Boost work which is backing up. If you want to make changes yourself, feel free to do so. However, please test to make sure whatever you change doesn't screw up VC++ 7.0. Disabling this warning would hardly affect 7.0, as it is just an indication that 7.1 properly usues argument-dependent lookup, which 7.0 does not (except for operators...). A lot of the failures seems to be a warning that 7.1 actually does the right thing. A bit unfair to count this as a failure! Bo Persson [EMAIL PROTECTED] ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Thread-Local Storage (TLS) and templates
Greg Colvin [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
Any thoughts on this issue?
From: Steve Clamage [EMAIL PROTECTED]
To: C++ core language mailing list
Message c++std-core-9820
Some compilers implement thread-local storage (TLS) for what would
otherwise be global variables. The compiler and runtime system
arrange for each thread to see its own copy of a global variable.
Should the address of such a variable be allowed as a non-type
template parameter? For example, this code is OK:
extern int k;
template int* V class C { ... };
Ck ck;
But what if k is designated thread-local? The actual variable
referred to by the address of k will differ among threads.
(I'm assuming an implementation where k results in a link-time
constant whether k is an ordinary or thread-local variable.)
Two thoughts:
1) I don't know of any compiler which automatically makes 'k' thread-local.
You either have to:
a) tell the compiler that it is thread-local, ie. __declspec(thread) int k;,
or you must:
b) implement TLS yourself using an API which does pass a valid pointer to an
int in this case, but one that is certainly not a compile-time constant.
2) In case a) we are dealing with an implementation-defined language
extension ( __declspec(thread) ) so whether the address of such a variable
is to be allowed as a non-type template parameter appears like it may also
be implementation defined. In case b) we are not dealing with a compile-time
constant so that it must certainly fail.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Fw: Why scoped_ptr dost provide custom deallocation?
Richard Hadsell wrote: Although someone mentioned this earlier, I have not seen it reiterated -- if the size of scoped_ptr grows to more than just the pointer itself, I can not use it. I imagine that others also need it to remain simple, at least in this respect. If someone adds anything to scoped_ptr or scoped_array that increases its size, I hope he/she will give it a new name, so that I can continue to use the current classes. I am curious why the size of scoped_ptr matters so much? I certainly worry about the size of shared_ptr as I may store many of them in containers. However, this is not possible with scoped_ptr so I am curious about usage where size might still matter? [Whenever I think I have the hang of these things, someone goes and points out the obvious case I'm missing! The more you look into smart pointer, the more you understand why the debates never end!!] -- AlisdairM ___ 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: Formal review or Variant Library (Ed B.)
"David B. Held" wrote:
[...] template typename T void operator()(const T operand) const { operand.~T(); } [...] Is the destructor really a const function? Dave The object being destroyed is the formal parameter "operand". The object whose operator() is called is not changed at all, thus the 'const' qualification is in place.
-Itay.
[boost] RE:Formal Review: Variant Library
(I appologize for the two awkward replies I had sent before. It seems that my news client and myself have some issues to resolve...)
[EMAIL PROTECTED] wrote:
[snip] 2) The Visitor concept brings a couple questions to mind: a) Why allow modification (termed "persistency" in the docs)? No other FunctionObject abstraction does, and modern C++ users are well-acquainted with and used to the associated restrictions on FunctionObjects.
Indeed we had some discussions about this issue. The final argument was thatthe usage scenarios are different for a visitor and for (traditional)FunctionObject: In the STL context a FunctionObject is needed when one actionshould be repeatedly applied over asingle sequence of objects. This task is carried out by a *single* invocation of the appropriate algorithm.A Visitor, on the otherhand, is likely to be applied over several variant instances, which are notnecessarily stored inside a container. Hence, the code will (likely) haveseveral apply_visitor() calls, where a different variant object is passed toeach one. If the visitor was passed by value, we would end up with somethinglike this:
struct my_visitor { };
typedef variantA,B,C variant_type;void f(variant_type x, variant_type y, variant_type z){ my_visitor vis1 = apply_visitor(my_visitor(), x); my_visitor vis2 = apply_visitor(vis1, y); my_visitor vis3 = apply_visitor(vis2, z);
// do something with vis3
}
I feel that this code is overly verbose and counter-intuitive.
[Two other points - in favor of the pass-by-reference method - are theability to use polymorphic visitors without slicing them, and the reducedoverhead, since copy-construction is avoided. However, these points are lesssubstantial than the first argument, since you can use a simple wrapperclass to work-around the problems.]
b) Do Boost.Lambda expressions qualify as Visitors? I am not familiarenough with the implementation of either library to be able to tell...
A valid visitor must expose a nested type, result_type, which specifies itsreturn type. I believe it should be possible (although I did not try it yet)to wrap a lambda expression inside a proxy class which will defineresult_type as void.
-Itay
Re: [boost] Formal review or Variant Library (Ed B.)
Ed Brey [EMAIL PROTECTED] writes:
Extract is confusing. One problem is that it is deceivingly named.
The name was my suggestion, so I'm going to argue with you a bit about
that.
It doesn't extract data from the variant at all, but rather provides
type-specific access to data that still resides in the variant.
Provides type-specific access to data that still resides in the
variant is a mouthful, but I'm still not sure what it means. How is
it different from extracting the data?
It is not clear from the name or the documentation that this would
be bad:
variantint* v = new variantint; extractint i(*v); delete v;
return i;
Ugh. Is it clear from the name that this would be bad?
std::back_insert_iteratorstd::vectorint f()
{
vectorint v;
return back_inserter(v);
}
If the documentation for extract doesn't say that behavior is
undefined if extraction occurs after the constructor argument is
destroyed, it should. Wouldn't that cover your (rather implausible)
case?
The area would be helped by renaming extract to access.
How is access any clearer? Access can plausibly be interpreted as
a noun or a verb in the context of variant, so I don't like it very
much.
BTW, I just realized that a conversion from variantT to optionalT
could be used to do extraction as well. Maybe it would be better to
ditch extract altogether and just use optional?
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Formal review or Variant Library (Ed B.)
Itay Maman [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
David B. Held wrote:
[...]
template typename T
void operator()(const T operand) const
{
operand.~T();
}
[...]
Is the destructor really a const function?
The object being destroyed is the formal parameter operand.
The object whose operator() is called is not changed at all, thus
the 'const' qualification is in place.
I realize that the operator ought to be const. But should the reference
be? I guess I don't know if you should be able to call a d'tor on a
const or not.
Dave
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: boost.test thread safe bugs (and some fixes)
Gennadiy Rozental said: 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. Again, how do you test it is working if we can't use the Boost.Test framework! We're in a catch-22 situation so long as you use Boost.Thread in Boost.Test. 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. I understand you not wanting to do so, but I see no alternative. 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. How do you create a thread here if we can't prove that the Boost.Thread creation works portably? You'll still wind up reinventing the wheel here, you're just choosing to implement thread creation instead of the mutex and TSS. From my POV it would be easier to do the mutex and TSS, but hey, I don't care as long as you can prove that the testing framework works *before* I start using it to test Boost.Threads. -- William E. Kempf ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Formal review or Variant Library (Ed B.)
David B. Held wrote: [snip] I realize that the operator ought to be const. But should the reference be? I guess I don't know if you should be able to call a d'tor on a const or not. My understanding is that since the following is legal... const T* p = ...; delete p; ...so is what you see in variant.hpp: const T r = ...; r.~T(); Even if my understanding is correct though, it may be best for destroyer to take a non-const reference to avoid confusion. Anyone? Thanks, Eric ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Formal review or Variant Library (Ed B.)
Eric Friedman [EMAIL PROTECTED] wrote in message b2uflv$86s$[EMAIL PROTECTED]">news:b2uflv$86s$[EMAIL PROTECTED]... [...] const T r = ...; r.~T(); Even if my understanding is correct though, it may be best for destroyer to take a non-const reference to avoid confusion. Comeau says it's ok, so I'd just leave it as is. It does seem peculiar to me, though. Dave ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Lock Classes: Does anyone care.
Gennadiy Rozental wrote: 1. Does not Boost.Thread already have locking mechanisms 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? Why should locks be dynamic rather than stack allocated at all? I'd have though stack-allocation far more intuitive? -- AlisdairM ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Fw: Why scoped_ptr dost provide custom deallocation?
Alisdair Meredith wrote: I am curious why the size of scoped_ptr matters so much? I certainly worry about the size of shared_ptr as I may store many of them in containers. However, this is not possible with scoped_ptr so I am curious about usage where size might still matter? [Whenever I think I have the hang of these things, someone goes and points out the obvious case I'm missing! The more you look into smart pointer, the more you understand why the debates never end!!] Our application is a raytracing renderer. Storing data for each object encountered in a scene that contains ~100,000 objects is a problem. Some of the data are in scoped_arrays of scoped_ptrs. If we had to double the size of those arrays just to get a feature that we don't need, I would copy the current scoped_ptr code and make it my own. I couldn't take the memory waste, even if it were only another 50 MB. We work very hard in every other way to use memory frugally, so that we can support larger scenes, which our users continually demand. -- Dick Hadsell 914-259-6320 Fax: 914-259-6499 Reply-to: [EMAIL PROTECTED] Blue Sky Studioshttp://www.blueskystudios.com 44 South Broadway, White Plains, NY 10601 ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] datetime and long long
Jeff Garland [EMAIL PROTECTED] writes:
Many of the regression tests for the date time library are failing
currently because the library relies on std::abslong long being
available. AKAIK, the C++ standard doesn't require this so the library
shouldn't make use of it.
Maybe datetime should specify it's own version of abs like this:
#include cstdlib
#include stdlib.h
template typename T T abs(T i) { return std::abs(i); }
template long long abs(long long i) {return ::llabs(i); }
Take a look at bosot/date_time/compiler_config.hpp which
does something similar. All we need to do to fix these regressions
is add the compiler to the list of those that don't have std::abs
at line 34. Turns out that some compilers that support long long
do define a version of abs for long long. (I'm sure you also
know that some compilers don't call it the type long long
either which is why we have boost::int64_t).
Just as an aside, at some point this logic should likely
move out of date_time and into the general config somewhere
so that others can access std::abs on these types if they
need.
AFAICT the logic is backwards: you should assume there's no std::abs
which works on long long and use your own function by default, only
using std::abs if the compiler is *known* to support that
extension... if it's even worth the trouble (it'll be less code to
just do the whole thing yourself).
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Formal review or Variant Library (Ed B.)
David Abrahams wrote: BTW, I just realized that a conversion from variantT to optionalT could be used to do extraction as well. Maybe it would be better to ditch extract altogether and just use optional? I think this makes sense. The disadvantage is the overhead of optional just to do extraction. I understand from the other posts that implementing optional in terms of variant as is an overkill? If so, at least effort must be put into making both libraries reuse as much common parts as possible. I'm sure there are lots of commonality, right? -- Joel de Guzman [EMAIL PROTECTED] http://www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Fwd: Thread-Local Storage (TLS) and templates
Peter Dimov [EMAIL PROTECTED] writes:
Looks like a no-brainer, k can't be a compile-time constant if k is
thread-local.
1.
void f()
{
Ck ck;
}
2.
void f()
{
typedef Ck ck_type;
ck_type ck;
}
3.
typedef Ck ck_type;
void f()
{
ck_type ck;
}
The type of ck cannot depend on the thread that is executing f.
It doesn't have to. When used as a template parameter, an address
could refer to something more like a member function pointer, i.e. an
offset in the thread's table of globals.
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: boost.test thread safe bugs (and somefixes)
William E. Kempf [EMAIL PROTECTED] writes: Gennadiy Rozental said: 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. Again, how do you test it is working if we can't use the Boost.Test framework! We're in a catch-22 situation so long as you use Boost.Thread in Boost.Test. You can do it the way programmers have always done it: simple assert. 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. I understand you not wanting to do so, but I see no alternative. I tend to sympathize with Gennadiy's POV here. Writing minimal portable testing code from scratch is a LOT simpler than trying to do the same in the domain of threading. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Fw: Why scoped_ptr dost provide custom deallocation?
Richard Hadsell wrote: Some of the data are in scoped_arrays of scoped_ptrs. Ah ah, you've done what I said was impossible, you HAVE created a container of scoped_ptrs!!! As I suspected, live and learn g Thanks for the explaination. -- AlisdairM ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Formal review or Variant Library (Ed B.)
David Abrahams wrote: [snip] BTW, I just realized that a conversion from variantT to optionalT could be used to do extraction as well. Maybe it would be better to ditch extract altogether and just use optional? I had thought about this before, but I dismissed it (perhaps too quickly) because I do not believe optional can contain references (i.e., optionalT) because references themselves are non-copyable. Perhaps though optional reference_wrapperT could be returned? Thoughts? Eric ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Any, Function, and Signals documentation
-Original Message- From: William E. Kempf [mailto:[EMAIL PROTECTED]] This a minor difference here, though. The bjam executable boot straps fairly easily on most platforms. XSLT processors aren't quite as convenient. At least that was my experience that last time I tried to do DocBook stuff on a Windows box (with out Cygwin). Things may have improved in this regard, and if not, I'm sure we can improve things ourselves, but I'm nervous that we're not ready for this yet. It may be easier to use a platform dependent (or user selectable) xslt tool rather than try to build/install a cross platform one? Anyone who has a recent enough IE installed on Windows has XSLT installed - why not use it. If you actually want a full docbook authoring environment, things are a little ;-) more complex - but just building the docs shouldn't be too hard? I've been using XSLT on windows and linux. On windows I'm just using MS's msxml. This seems to be pretty solid these days - nothing to build - just install it... To do a command line xslt transformation you can use a little (28k exe) utility that uses the msxml dll. The utility (msxsl) can be downloadded from: http://msdn.microsoft.com/downloads/default.asp?URL=/code/sample.asp?url =/msdn-files/027/001/485/msdncompositedoc.xml regards Darryl Green. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Win32/VC++ 7.1 final beta regression tests posted
At 05:26 PM 2/18/2003, Bo Persson wrote: A lot of the failures seems to be a warning that 7.1 actually does the right thing. A bit unfair to count this as a failure! Warnings aren't counted as failures. A test compile, link, or run has to actually report failure (via non-zero return code). I've cleared the boost\type_traits\is_convertible.hpp(154) problem. That accounted for a dozen or so failures, so the results are looking even better. Failure rate dropped to 8%. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Any, Function, and Signals documentation
At 11:56 AM 2/18/2003, William E. Kempf wrote: Well, I'm in favor of that, since we're moving at least some of the documentation to Boost.Book with this release (or so I gathered). So what's the group opinion on this one? I'd like to hold off as many changes as possible until after the release. I don't have time to think clearly about the problems involved, and I'd like to actually try out some of the software too. The final day or two before a branch-for-release isn't a good time for this important discussion. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Lock Classes: Does anyone care.
On Tue, 18 Feb 2003, Gennadiy Rozental wrote: Two comments: 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. 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. -- http://kevin.atkinson.dhs.org ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Preliminary submission: command line config file library
FYI, xParam (sourceforge) seems to fulfill similar requirements. In article [EMAIL PROTECTED], Rob Stewart wrote: From: Vladimir Prus [EMAIL PROTECTED] Rob Stewart wrote: The purpose of command line parsing is to decode the arguments list into pieces of information, abstracting the syntax of the command line away from the program. Thus, the library should be able to understand any of various encoding schemes. That's syntantic level. I believe it should be as independent from meaning of options as possible: command line, preferrable, should be immediately parsable by humans. I think we're saying the same thing. My point is that the library should abstract the parsing such that the program need only describe the supported options and query to learn which have been set and with what values. The format those parameters take on the command line or in a configuration file should be hidden. The question then becomes how the library should provide the values from the command line. There are a number of fundamental types that could be exposed by the library: bool, long, double, and string. The question is whether the library should support any others. I selected those types because Boolean and string parameters are obviously important, and long and double would handle pretty much all numeric arguments one would put in a command line. The level 2 of my library provides only syntantic representation of the read options. See http://zigzag.cs.msu.su:7813/program_options/html/ for the list of layers. I can't access that page, but I was simply suggesting that the library can expose a rather minimal set of types gleaned from the command line. Client code can transform from those types to anything else desired. Boolean and string parameters are obvious. Nothing else is needed as strings can (obviously) represent all other arguments. Sure, you could provide a means to read a file line by line and pass each line to a parser of some sort. However, given all of the ways to parse the text one might find in such a file, I don't see how that could be done so it is sufficiently flexible and yet actually provides value. IOW, the parsing would be little more than read a line, give it to the parser, read another line, give it to the parser, etc. That certainly doesn't justify a special library. What special library? I see two libraries in what you've proposed: one that manages command line parsing and one that manages configuration file parsing. If command line and configuration file parsing are completely abstracted from the parameter specification/management, then it's a question of what configuration formats are provided by default, possibly bloating client code unnecessarily. Perhaps I've missed some valuable service that should be included in the proposed library, but I can't see that it should do more than what I've outlined herein. If you do, please enlighten me! It looks like you don't need some of the extra features that both Gennadiy and myself are after. For example, custom value interpreration or automatic help message? An automatic help message is certainly useful; I simply didn't mention it specifically. Custom value interpretation strikes me as overkill. If your library provides a string corresponding to a particular parameter, I can use that string in myriad ways to produce information for my program. Putting that logic into a command line parsing library seems over the top. Could you please tell which features in both designs are unnecessary and should be removed? I don't know the full set of features either of you have provided at the moment, but I hope the above clarifies my thoughts on the scope of such a library. I'll second the question raised regarding the more complex parsing: isn't that the job of a tool like Spirit? Be careful to avoid doing too much in this library. You can make it really powerful and capable, but that alone may keep too many at bay. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Formal review or Variant Library (Ed B.)
Title: RE: [boost] Formal review or Variant Library (Ed B.)
From: David Abrahams [mailto:[EMAIL PROTECTED]]
Extract is confusing. One problem is that it is deceivingly named.
The name was my suggestion, so I'm going to argue with you a bit about
that.
It doesn't extract data from the variant at all, but rather provides
type-specific access to data that still resides in the variant.
Provides type-specific access to data that still resides in the
variant is a mouthful, but I'm still not sure what it means. How is
it different from extracting the data?
It is not clear from the name or the documentation that this would
be bad:
variantint* v = new variantint; extractint i(*v); delete v;
return i;
Ugh. Is it clear from the name that this would be bad?
std::back_insert_iteratorstd::vectorint f()
{
vectorint v;
return back_inserter(v);
}
Yes, because here you have an inserter, which depends on what it
inserts data into. An extract on the other hand can usually exist
on its own.
I may be missing something, but as long as its just a proxy that offers
a type specific view of the data shouldn't it be called a view or a
proxy?
Glen
[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] Encapsulate boost::bind in a template method
Hi,
I want to encapsulate boost::find in a template
method in a base class for easier use.Here is some code:
#include boost/function.hpp#include
boost/bind.hpp
class CWindow {public:CWindow()
{SetEventHandler(CWindow::OnCreate); // this call
works}long OnCreate() {return
0;}templatetypename T void SetEventHandler(long
(T::*Function)()) {boost::functionlong EventFunction =
boost::bind(Function, this);// ...// Add
EventFunction into a std::map}};
class CButton : public CWindow
{public:CButton()
{SetEventHandler(CButton::OnPaint); // this call doesn't
compile}long OnPaint() {return
0;}};
int main() {return 0;}
The SetEventHandler call in the CButton's
constructor generates 2 errors on VC++ 7.0:
mem_fn_template.hpp(37): error C2440: 'newline' :
'CWindow *' can't be converted in 'CButton *'mem_fn_template.hpp(37): error
C2647: '-*' : 'const boost::_mfi::mf0R,T::F' can't be dereferenced
in '$T'
It also doesn't compile on g++ 3.2.
If I copy paste the template method in every
derived class the code compiles well, but this can't be a good soluation.
:(And if i outcomment "boost::functionlong EventFunction" it also
works, but of course I need to work with boost::bind's return value.
;-)
Is there a way to solve this problem?
cu,Matthias
Re: [boost] Re: Re: Lock Classes: Does anyone care.
On Tue, 18 Feb 2003, Gennadiy Rozental wrote: 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. And if I don't you won't even consider it? I am at this point trying to pitch the general idea, not how it should be integrated into boost. If people like it I will work on Boost integration. 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 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. -- http://kevin.atkinson.dhs.org ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Formal Review: Variant Library
Beman Dawes [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... At 02:49 PM 2/18/2003, Itay Maman wrote: Rodolfo Lima [EMAIL PROTECTED] wrote in message b2tm6v$9o7$[EMAIL PROTECTED]">news:b2tm6v$9o7$[EMAIL PROTECTED]... How different is boost::any from this new variant library? Don't they address the same issue? [snip] Note that the need to document the difference between boost::any and boost::variant is common to both libraries. Thus (assuming boost::variant is accepted) it would make sense to document the difference in one place (presumably boost::variant) but then also add a sentence with a link to the boost::any docs. Perhaps add that to your do list:-) --Beman Agreed. -Itay ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Preliminary submission: command line config file library
Rob Stewart wrote: From: Vladimir Prus [EMAIL PROTECTED] Rob Stewart wrote: The purpose of command line parsing is to decode the arguments list into pieces of information, abstracting the syntax of the command line away from the program. Thus, the library should be able to understand any of various encoding schemes. That's syntantic level. I believe it should be as independent from meaning of options as possible: command line, preferrable, should be immediately parsable by humans. I think we're saying the same thing. My point is that the library should abstract the parsing such that the program need only describe the supported options and query to learn which have been set and with what values. The format those parameters take on the command line or in a configuration file should be hidden. We're in complete agreement until now. And I think precisely that is implemented. The question then becomes how the library should provide the values from the command line. There are a number of fundamental types that could be exposed by the library: bool, long, double, and string. The question is whether the library should support any others. I selected those types because Boolean and string parameters are obviously important, and long and double would handle pretty much all numeric arguments one would put in a command line. The level 2 of my library provides only syntantic representation of the read options. See http://zigzag.cs.msu.su:7813/program_options/html/ for the list of layers. I can't access that page, but I was simply suggesting that the library can expose a rather minimal set of types gleaned from the command line. Client code can transform from those types to anything else desired. Boolean and string parameters are obvious. Nothing else is needed as strings can (obviously) represent all other arguments. There is rather minimal set. For simple utilities I myself prefer to get list of option/arguments (represented as strings), and then use them. Sure, you could provide a means to read a file line by line and pass each line to a parser of some sort. However, given all of the ways to parse the text one might find in such a file, I don't see how that could be done so it is sufficiently flexible and yet actually provides value. IOW, the parsing would be little more than read a line, give it to the parser, read another line, give it to the parser, etc. That certainly doesn't justify a special library. What special library? I see two libraries in what you've proposed: one that manages command line parsing and one that manages configuration file parsing. If command line and configuration file parsing are completely abstracted from the parameter specification/management, then it's a question of what configuration formats are provided by default, possibly bloating client code unnecessarily. I don't understand what you mean by bloating. With shared library, the size is not that important: client code includes only call to the functions it uses, and loading shared libraries is fast. For static library, unused code will not be even linked in. Perhaps I've missed some valuable service that should be included in the proposed library, but I can't see that it should do more than what I've outlined herein. If you do, please enlighten me! It looks like you don't need some of the extra features that both Gennadiy and myself are after. For example, custom value interpreration or automatic help message? An automatic help message is certainly useful; I simply didn't mention it specifically. Custom value interpretation strikes me as overkill. If your library provides a string corresponding to a particular parameter, I can use that string in myriad ways to produce information for my program. Putting that logic into a command line parsing library seems over the top. Why? Personally, if I have 10 int parameters on command line, I don't want to convert them all to integers by hand, but want the library to be able to do this for me. If you don't want this functionality, don't use it. The only support from the library part is ability to call user-provided callback. I believe this is quite simple idea. Could you please tell which features in both designs are unnecessary and should be removed? I don't know the full set of features either of you have provided at the moment, but I hope the above clarifies my thoughts on the scope of such a library. Other than the question of custom value interpretation, I see no big objections. I'll second the question raised regarding the more complex parsing: isn't that the job of a tool like Spirit? Be careful to avoid doing too much in this library. You can make it really powerful and capable, but that alone may keep too many at bay. For more complex parsing, you can use any tool you like. As I've mentioned
Re: [boost] Re: Preliminary submission: command line config file library
Vincent N. Virgilio wrote: FYI, xParam (sourceforge) seems to fulfill similar requirements. I had a brief look at the project before, and looked for another time now. Are you sure that project called XParam - General-Purpose Object Serialization Framework for C++ has the same requiremens and tools for command line processing? My opinion is that: 1. It primarily aims at clases serialization. 2. The command line part is not so powerfull. For example, it has single syntax, AFAIKT, does not allow multiple assignment to the same variable, and looks like the syntax of, say, list of values, is fixed. Am I missing something? - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
