Re: [boost] Determining interest in combining_iterator
Thanks for your comments on the combining iterator. David Abrahams wrote: It's a wonderful idea, Thomas! You might look at the Boost sandbox; Jeremy Siek, Thomas Witt and I are trying to finalize the work in the boost/iterator and libs/iterator directories to replace the current iterator adaptors Thanks for your kind words. I'll play with the sanbox stuff. Is the main purpose there to incorporate better iterator categories? Anyway, I won't take any further action until all that has settled down. Douglas Paul Gregor wrote: Sounds great. Since the functionality is a direct generalization of transform_iterator, I'd prefer to use the name transform_iterator and either (a) switch entirely to your combining_iterator implementation or (b) give transform_iterator_generator the brains to switch between your implementation and the existing implementation based on the number of iterators being adapted. Uh uh, I was kinda hoping nobody would bring that up, because I agree and at the same time strongly disagree. Of course you're right, the transforming iterator is a special case of the combining iterator, and under any kind of theoretical point of view, it should be treated as such. There is no way I can argue with you on that. And yet, I am very strongly in favor of keeping the two entirely separate. Here's why: From a library user's point of view, the fact that the transforming iterator is a special case of the combining iterator is quite accidental. If someone is looking for the functionality of the transforming iterator, she should find just that, without being forced to view the thing she's looking for as a special case of something completely different. One could in fact express this viewpoint in a somewhat theoretical manner by saying that the transforming iterator is not so much a *special* case of the combining iterator than a *degenerate* case. Combining iterators is not where one would naturally look when in need of a transforming iterator. Anthony Williams wrote: IMHO, it seems more logical to split the concept, so the grouping of the iterators is separated from the transformation By separating the grouping and the transforming, do you mean to write an iterator that holds a tuple of iterators and then, upon dereferencing, returns the tuple of dereferenced values, and then use that in conjunction with boost's transforming iterator? That would make a lot of sense. However, I would need a little convincing that it really adds useful functionality that people are looking for. Paul A. Bristow wrote: I can see this VERY useful to some, but probably not widely useful. In view of the emphasis on very, I'll count that as a yes vote. Thomas Becker Zephyr Associates, Inc. Zephyr Cove, NV __ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [date_time] enabling microsec_clock under C++Builder
Mark Blewett wrote: I was surprised at the difference too, so tested here with a Dual 800Mhz PIII (Dell Precision 220) running Windows 2000 Advanced Server (SP2). Cutting and pasting into a default Win32 console project in VC6 (SP4 I think) gives a result of ~0.72 on an idle machine. FYI: From Microsofts Platform SDK docs on QueryPerformanceCounter On a multiprocessor machine, it should not matter which processor is called. However, you can get different results on different processors due to bugs in the BIOS or the HAL. To specify processor affinity for a thread, use the SetThreadAffinityMask function. Not sure if this effected your results or not. Cheers Russell ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Determining interest in combining_iterator
Thomas Becker [EMAIL PROTECTED] writes: Anthony Williams wrote: IMHO, it seems more logical to split the concept, so the grouping of the iterators is separated from the transformation By separating the grouping and the transforming, do you mean to write an iterator that holds a tuple of iterators and then, upon dereferencing, returns the tuple of dereferenced values, and then use that in conjunction with boost's transforming iterator? Yes, this is exactly what I meant. That would make a lot of sense. However, I would need a little convincing that it really adds useful functionality that people are looking for. Personally, I have found several occasions where I have needed a pair of iterators to yield a pair of values, which is why I wrote my pair iterator. The particular example I cited in the article is where a colleague had a pair of vectors which were the x and y values respectively for a graph. They were supplied as two vectors, and the graph drawing code required them as two vectors, yet the analysis code in the middle required a sequence of (x,y) pairs --- initially for sorting by x value, but also to ensure that transforms were applied correctly and consistently. The alternative is to write functors to sort a list of indices and redirect through the index table whenever access to the data is required. I can imagine similar situations where a tuple of sequences must be treated as a sequence of tuples --- indeed, the supporting example for your combining iterator is precisely such a situation; the client code wishes to perform an operation on the tuple of values resulting from dereferencing the supplied tuple of iterators. I can build this from my pair iterator --- pairit(i1,pairit(i2,pairit(i3,...))) --- but it would seem to make sense to generalize the code to have a boost::tuple-friendly interface --- I think you would still need a custom tuple to handle the ownership issues (I may be wrong on this point, since I haven't studied boost::tuple in depth) 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] bad_lexical_cast
You might want to read http://www.objectmentor.com/resources/articles/lsp.pdf for a rationale of the LSP. A somewhat different view is expressed in http://alistair.cockburn.us/crystal/articles/cdos/constructivedesconstructionofsubtyping.htm. Am Son, 2003-03-23 um 14.00 schrieb David Abrahams: LSP is weird anyway. What's the point of polymorphism if you're not going to change the behavior of the class in some observable way? If the derived class were transparently substitutable for the base class it wouldn't be much good, would it? -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Determining interest in combining_iterator
Hi Thomas, some time ago I was in the very same situation that I needed an iterator of tuples - or a tuple of iterators, which virtually is the same IMO. My solution then was to extend tuple functionality, i.e. to add everything that a good iterator requires, such as dereference, operator++() etc., to a tuple type (not boost:tuple, but a 'tupple' type of my own. Hm.) About three months ago, I released that stuff to Boost Sandbox, where it sits (in directory 'tupple') rather unnoticed (lack of marketing, I guess), Thanks for your kind words. I'll play with the sanbox stuff. Is the main purpose there to incorporate better iterator categories? Anyway, I won't take any further action until all that has settled down. so if you play with the sandbox stuff, you might as well check it out. (Hint: open boost/tupple/detail/container_tupple_part_spec.hpp and search for 'iterator_tuple'. Don't blame me for indentation, this is generated code.). I don't really know which approach - iterator of tuples vs. tuple of iterators - is better, but comparing the two approaches might yield some insight. I'd be really interested in an exchange of ideas, - Roland ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] ANN: New Version of Wave, a C++/C99 preprocessor library
Hi all, There is a new version of the 'Wave C++/C99 preprocessor library' available: it is V0.9.1. This library consists out of - a set of (template-) classes exposing an iterator interface, which when dereferenced return the preprocessed tokens, generated on the fly from an underlying arbitrary iterator based input stream - a (sample) driver program, which is a full blown C++/C99 preprocessor, usable on top of any other every day compiler of your choice If the first public release of Wave (the V0.9.0) was merely a proof of concept, so this new release (the V0.9.1) has the following highlights: - full compliance with the C++ Standard [ISO/IEC 14882:1998] reached and verified with the help of a 'strict' version of the Boost.Preprocessor library of Paul Mensonides, which couldn't be used even with EDG based compilers (Comeau/Intel). - implemented variadics (macros with variable parameter count) and placemarkers (empty macro arguments) usable as an optional extension to the C++ Standard - implemented a C99 mode, which has variadics and placemarkers enabled by default (as mandated by the C99 Standard [INCITS/ISO/IEC 9899:1999]) and which additionally rejects certain C++ tokens (the alternative keywords as 'and', 'or' etc. and the '::', '-*', '.*' operators), which are invalid for C99 - updated the documentation (look here: http://spirit.sourceforge.net/index.php?doc=docs/wave_v0_9/index.html) - major speedup (this depends on the complexity of the compiled code and may reach upto 3-5 times if compared to the Wave V0.9.0 code) - the interface of the library has settled, fixed a lot of minor and major bugs - added Jamfile.v2 to allow a convenient build process for gcc based systems Wave is tested to be compilable and working with VC7.1 (final beta), gcc (Cygwin and Linux), Intel V7.0 (Stlport4.5.3 and DinkumwareSTL from VC6sp5). The Wave V0.9.1 library can be downloaded here: http://sourceforge.net/projects/spirit/. It is usable under a license compatible with the Boost licensing schemes. Any comments are very much appreciated. Regards Hartmut ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: random and msvc6
Lapshin, Kirill [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]m01.gsp.gs.com...
Hi All,
[snip]
Thorsten, was the error you observed on intel 7 related to this one?
Unfortunately not. The program I'm trying to compile is this:
#include boost/random.hpp
#include ctime
using namespace boost;
using namespace std;
typedef lagged_fibonacci607 base_generator_type;
base_generator_type´generator( time( 0 ) );
uniform_01base_generator_type uni( generator );
Yesterday I actually gave up because the error was just too wierd:
apparently something as simple as a typedef and
a pointer to a class could not compile.
Since I saw your new mail, I gave it a try again and it turned out to be a
problem with templated constructors within
'lagged_fibonacci_01.hpp'.:
templateclass Generator
explicit lagged_fibonacci_01(Generator gen) { init_modulus();
seed(gen); }
I don't fully understand what the real cause for the error is; I've tried to
reconstruct the error without luck.
Anyway, I guess my local copy of the file will just have those two lines
commented out.
regards
Thorsten
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [optional] two problems with BCB 6 and 1.30b
Pavel Vozenilek [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
- Original Message -
From: Fernando Cacciola [EMAIL PROTECTED]
Following snippet of code fails:
-
#include boost/optional.hpp
#include utility
void foo(const boost::optionalstd::pairunsigned, unsigned aux =
boost::optionalstd::pairunsigned, unsigned ())
{}
int main() {}
-
[snip]
Hmm..
I can't reproduce the problem here with the 1.30.0 release,
BCB6, update 4, from within the IDE.
Which command line options are you using?
The BCB flags are:
OK, I finally reproduced the problem:
It has nothing to do with compiler flags (I made a mistake when
I tried the snippet which masked the error), but it has nothing to
do with optional either :-)
The following produces the same error:
#include utility
void foo( std::pairunsigned, unsigned aux
= std::pairunsigned, unsigned () // (1)
)
{}
int main() {}
-
Commenting line (1) we can see that the problem
is related to the default value expression.
Furthermore, adding: using std::pair ; solves
the problem.
Further investigations revleas that this is a
subtle ADL bug related to default arguments:
In the following:
--
namespace A {
templateclass T1
struct X {} ;
templateclass T1,class T2
struct Y {} ;
}
void foo ( A::Xint aux
= A::Xint() // (1)
) ;
void bar ( A::Yint,int aux
= A::Yint,int() // (2)
) ;
int main() {}
(1) compiles
but (2) doesn't, unless using A::Y is added.
Fernando Cacciola
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: boost::any feature request
Vladimir Prus wrote: Aha, that's what I was trying to say, but not very clearly. Yes, *this* will work. But... it means that if you do any a1; anyfast_allocator a2 = a1; Then value stored in a2 will be allocated using a1's allocator, not a2's. Once any is created with a specific allocator, all copies will use the same allocator, which is doubtful behaviour. In the example above, the fast_allocator parameter has no effect at all. Even if this behavior is desirable, you don't need to add template parameter to 'any'. I agree, there is no need for the template parameter for any. You can add template parameter to 'holder' only, and another constructor, which allows to specify allocator. But then you can't make static_cast to holderKnownType, UnknownAllocator inside any_castKnownType(a); May be wrap allocator specific stuff into separate interface? There are two allocator types: (a) type specific ones like std::allocatorint and (b) catch-all allocators. Option (a) is probably better when you know the type: any a(1); // a uses new/delete any b(2, fast_allocatorint()); I don't know whether to leave the original allocator or replace it with another one while making a copy: any c(a); // c uses new/delete any d(b); // d uses fast_allocatorint? -- Alexander Nasonov Remove minus and all between minus and at from my e-mail for timely response ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] VC7/Threads Warnings
Andrew J. P. Maclean said: I am using Boost Ver 1.30 just released. I built the libraries with BJam. Now when building my code I get lots of warnings like the following. These warnings worry me a bit because they are level 1 and 2 warnings. Is it safe to ignore these or do I need to manually set some option? I never got these warnings with Boost 1.29. There does appear to be something wrong in your setup. I'm going to guess that you're linking against the static RTL? -- William E. Kempf ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] VC7/Threads Warnings
As I am having the same problem, I looked a little to the bjam settings, and it seems that, at least when building with VC7.x, the -Wx (warning level) option is not set, that is why probably with bjam these warnings are not seen ... Viv - Original Message - From: William E. Kempf [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, March 25, 2003 3:39 PM Subject: Re: [boost] VC7/Threads Warnings Andrew J. P. Maclean said: I am using Boost Ver 1.30 just released. I built the libraries with BJam. Now when building my code I get lots of warnings like the following. These warnings worry me a bit because they are level 1 and 2 warnings. Is it safe to ignore these or do I need to manually set some option? I never got these warnings with Boost 1.29. There does appear to be something wrong in your setup. I'm going to guess that you're linking against the static RTL? -- William E. Kempf ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: boost::any feature request
Alexander Nasonov wrote:
Vladimir Prus wrote:
You can add template parameter to 'holder' only,
and another constructor, which allows to specify allocator.
But then you can't make static_cast to holderKnownType, UnknownAllocator
inside any_castKnownType(a); May be wrap allocator specific stuff into
separate interface?
You can if you add one more level of inheritance:
templateclass T, class Allocator
class holder_with_allocator
: public holderT // make static_cast to it
{
// ...
};
There are two allocator types: (a) type specific ones like
std::allocatorint and (b) catch-all allocators.
Option (a) is probably better when you know the type:
any a(1); // a uses new/delete
any b(2, fast_allocatorint());
I don't know whether to leave the original allocator or replace it with
another one while making a copy:
any c(a); // c uses new/delete
any d(b); // d uses fast_allocatorint?
I forgot that we're allocating a memory for holderT not for type T. But
there is a solution called rebind. So, I really don't know what to choose.
--
Alexander Nasonov
Remove minus and all between minus and at from my e-mail for timely response
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] isomorphism.hpp broken in visual studio?
Hi,
I'm using msvc6.0 and am trying to check if 2 graphs are equal using the functions in isomorphism.hpp. However, when I try to do this, I get 2 errors about there being too few template parameters for safe_iterator_property_map. Below is a very minimalistic example that generates the behaviour. Should I abandon all hope for getting this done with msvc6? Does it work in msvc.net?
thanks in advance,
Dieter Vrancken
The example:
#include boost/graph/isomorphism.hpp
int main()
{
return 0;
}
The output:
Compiling...
main.cpp
c:\boost_1_30_0\boost/graph/isomorphism.hpp(56) : error C2976:
'safe_iterator_property_map' : too few template arguments
c:\boost_1_30_0\boost/property_map.hpp(409) : see declaration of
'safe_iterator_property_map'
c:\boost_1_30_0\boost/graph/isomorphism.hpp(234) : see reference to class template
instantiation
'boost::detail::isomorphism_algoGraph1,Graph2,IsoMapping,Invariant1,Invariant2,IndexMap1,IndexMap2'
being compiled
c:\boost_1_30_0\boost/graph/isomorphism.hpp(63) : error C2976:
'safe_iterator_property_map' : too few template arguments
c:\boost_1_30_0\boost/property_map.hpp(409) : see declaration of
'safe_iterator_property_map'
c:\boost_1_30_0\boost/graph/isomorphism.hpp(234) : see reference to class template
instantiation
'boost::detail::isomorphism_algoGraph1,Graph2,IsoMapping,Invariant1,Invariant2,IndexMap1,IndexMap2'
being compiled
Error executing cl.exe.
test.exe - 2 error(s), 0 warning(s)
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: boost::optional feature request.
Douglas Paul Gregor [EMAIL PROTECTED] writes: On Mon, 24 Mar 2003, Edward Diener wrote: Do you really want the key to an associative container to be an optional value ? I would be hard-pressed to find a use for that. FWIW, the Signals library actually does this internally (although with boost::any objects instead of boost::optional objects). However, I would contend that the need is too specialized to warrant adding an operator. Seems entirely reasonable to me to add it. It looks like at least two people have needed exactly those semantics. What's the cost? -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: boost::optional feature request.
Edward Diener [EMAIL PROTECTED] writes: David Abrahams wrote: Douglas Paul Gregor [EMAIL PROTECTED] writes: On Mon, 24 Mar 2003, Edward Diener wrote: Do you really want the key to an associative container to be an optional value ? I would be hard-pressed to find a use for that. FWIW, the Signals library actually does this internally (although with boost::any objects instead of boost::optional objects). However, I would contend that the need is too specialized to warrant adding an operator. Seems entirely reasonable to me to add it. It looks like at least two people have needed exactly those semantics. What's the cost? I am not trying to shoot down the request but could someone give me a practical example of the case where an optional value which does not exist ( I hope that's the right term for when an optional value has no valid value ) serves as a key in an associative container ? I guess you can look at how boost::any is used in the signals library for an example. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] VC7/Threads Warnings
David Abrahams said: William E. Kempf [EMAIL PROTECTED] writes: David Abrahams said: William E. Kempf [EMAIL PROTECTED] writes: Hmm... this surprised me. Mr. Maclean indicated the warnings were level 1 _and_ 2. Builds with bjam do report errors, so the warning level can't be 0. MSDN indicates Level 2 is the default warning level at the command line. So I assumed that it must be an RTL issue causing the warnings for him. However, experimenting with 'bjam -sTOOLS=vc7 -sBUILD=vc7*cxxflags-W2' does indeed produce the warnings in question. So it appears that MSDN is wrong, and that level 1 is selected if none is supplied? I plan to bump the level up in my own set of bjam tool sets. Suggestion: turn them on with #pragmas in the library's test files. This won't turn them on when compiling the library itself, though. Turning them on only for the test files won't catch many of the warnings. So I suggest you use #pragmas in the library implementation files also. My point is that you shouldn't need a custom toolset to see the warnings, and if it's your aim to avoid triggering them they should show up in the Boost regression tests when you do. I guess I'm wondering if the official toolsets shouldn't be changed. I don't understand why the MSDN indicates it should default to /W2 while we're seeing it default to what I assume is /W1. But, projects created by the IDE default to /W3 (which is also the level recommended by the MSDN), so it makes sense to me that we should probably do the same? Otherwise, users are likely to see warnings that we don't represent in the regression logs. -- William E. Kempf ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] VC7/Threads Warnings
I was surprised to find that /Wp64 flag (detect 64-bit portability) means that std::size_t is 64 bit. This leds to a number of oddities that confused me. Is this perhaps causing your problem? Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 Mobile mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of vc Sent: Tuesday, March 25, 2003 5:20 PM To: Boost mailing list Subject: Re: [boost] VC7/Threads Warnings - Original Message - From: William E. Kempf [EMAIL PROTECTED] Yes it seems that in command line by default is W1. If you set the /Wp64 flag (detect 64-bit portability) you will get warnings level 1 and they can be seen using bjam without setting the Wx flag. So, seems that W1 is by default ... Viv ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Thread Lib and DLL
I am curious as to why the new version of the Thread library does not provide a static library in the 1.30 version of boost. After reading some initial posts, I have seen references to thread local storage, but haven't seen anything that documents why this makes a static library impossible. All thing considered, I find a static library is much more desirable than a dll. Thanks! David Brownell ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] VC7/Threads Warnings
For your information I also get these warnings when building using bjam. As you mention below - ignoring the warnings seems OK in my code (but it is simple stuff). Is it possible to create a static library? I suspect that the defines prevent this. This was possible in version 1.29. Obviously this is not for the monitor but when not using the monitor it would be nice to have a static library to link in. Then I don't have to worry about making sure the dll is present. Andrew ___ Andrew J. P. Maclean Centre for Autonomous Systems The Rose Street Building J04 The University of Sydney 2006 NSW AUSTRALIA Ph: +61 2 9351 3283 Fax: +61 2 9351 7474 URL: http://www.cas.edu.au/ ___ -Original Message- From: William E. Kempf [mailto:[EMAIL PROTECTED] Sent: Wednesday, 26 March 2003 03:29 To: [EMAIL PROTECTED] Subject: Re: [boost] VC7/Threads Warnings vc said: As I am having the same problem, I looked a little to the bjam settings, and it seems that, at least when building with VC7.x, the -Wx (warning level) option is not set, that is why probably with bjam these warnings are not seen ... Hmm... this surprised me. Mr. Maclean indicated the warnings were level 1 _and_ 2. Builds with bjam do report errors, so the warning level can't be 0. MSDN indicates Level 2 is the default warning level at the command line. So I assumed that it must be an RTL issue causing the warnings for him. However, experimenting with 'bjam -sTOOLS=vc7 -sBUILD=vc7*cxxflags-W2' does indeed produce the warnings in question. So it appears that MSDN is wrong, and that level 1 is selected if none is supplied? I plan to bump the level up in my own set of bjam tool sets. As for the warnings themselves... I'm still doing more research just to be 100% sure, but everything I've found thus far indicates you can ignore these warnings as long as you link against the same RTL in both the Boost.Threads DLL and the application. After I verify this, I'll remove the warnings through the use of pragmas. -- William E. Kempf ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: exception context
Darren Cook [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] [snip] I wanted something like the call stack that shows in python or java when an uncaught exception occurs; I tried to start a discussion on something similar, although I wanted language support. However, one of my points also were (and is) that it would be nice not only for uncaught exceptions, but also for running programs. My concern is that we have no standard mechanism for inspecting the errors in running programs when they (perhaps) have shipped to the customer. What is particularly irritating is that one instance of a program might work perfect whereas another instance may contain errors. If we cannot inspect those errors, we're in trouple if we cannot redo these errors . The entire thread can be found here: http://groups.google.com/groups?hl=dalr=ie=UTF-8selm=b1g8ca%2497i%241%40s unsite.dk regards Thorsten ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] patch: BOOST_AUTO_UNIT_TEST in auto_unit_test.hpp
The new (Boost 1.30.0) BOOST_AUTO_UNIT_TEST macro appends the current file line number to the generated function name. This can cause name collisions across source files. My patch appends the function name. The function name has global visibility, so it should be unique. *** auto_unit_test.hpp.orig Thu Feb 13 03:11:34 2003 --- auto_unit_test.hpp.new Tue Mar 25 20:20:17 2003 *** *** 52,58 #define BOOST_AUTO_UNIT_TEST( func_name ) \ static void func_name();\ static boost::unit_test_framework::auto_unit_test_registrar \ ! BOOST_JOIN( test_registrar, __LINE__) \ ( BOOST_TEST_CASE( func_name ) ); \ static void func_name() \ /**/ --- 52,58 #define BOOST_AUTO_UNIT_TEST( func_name ) \ static void func_name();\ static boost::unit_test_framework::auto_unit_test_registrar \ ! BOOST_JOIN( test_registrar_, func_name) \ ( BOOST_TEST_CASE( func_name ) ); \ static void func_name() \ /**/ __ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com auto_unit_test.hpp.patch Description: auto_unit_test.hpp.patch ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: boost::optional feature request.
Joe Gottman [EMAIL PROTECTED] escribió en el mensaje news:[EMAIL PROTECTED] It would be nice if boost::optionalT had operator defined whenever operator was defined for T. This would allow us to use optionalT as the key of an associative container. I suggest the following semantics: bool operator(optionalT const x, optionalT const y); Returns: If y is uninitialized, false. If y is initialized and x is uninitialized, true. If x and y are both initialized, (*x *y). This results in a strict weak ordering with uninitialized optionalT objects being sorted first. I don't see any problem introducing this with the given semantic as long as the choice is well documented and a rationale for it is included. I like the semantic you are proposing, it looks right to me: 'nothing' is always less than 'something' but never less then 'nothing'. I'll try to find some other background on this sort of ordering to see other possible semantics (if any), and if there are any subtelties with this one. If it still looks OK after that, I'll add it. Thank you. Fernando Cacciola ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] patch: BOOST_AUTO_UNIT_TEST in auto_unit_test.hpp
The new (Boost 1.30.0) BOOST_AUTO_UNIT_TEST macro appends the current file line number to the generated function name. This can cause name collisions across source files. My patch appends the function name. The function name has global visibility, so it should be unique. BOOST_AUTO_UNIT_TEST couldn't work with multiple source files anyway, since header supply init function and you could not include it twice in separate modules. If you have solution that solve all the issues with multiple modules I will be happy to discuss it. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: boost::optional feature request.
It would be nice if boost::optionalT had operator defined whenever operator was defined for T. This would allow us to use optionalT as the key of an associative container. I suggest the following semantics: bool operator(optionalT const x, optionalT const y); Returns: If y is uninitialized, false. If y is initialized and x is uninitialized, true. If x and y are both initialized, (*x *y). This results in a strict weak ordering with uninitialized optionalT objects being sorted first. Yes, I previously implemented this functionality -- exactly in the manner you described -- in my nilableT implementaton. It's quite useful to have. (If anyone is curious, nilableT was inspired by optionalT, though the implementation is not derived from optional's. The main differences are that nilableT doesn't use pointer deferencing for access to the internal value. Instead, it provides a direct, checked conversion to T (using boost::throw_exception with a bad cast error when the object obj is nil), obj.nil() returning bool, and obj.unsafe_reference() and obj.unsafe_value() for when one has previously ensured obj.nil() is false and want to make further accesses without that being tested repeatedly.) Dave ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] patch: BOOST_AUTO_UNIT_TEST in auto_unit_test.hpp
Hmmm. It works for me. I'm using BOOST_AUTO_UNIT_TEST across several of my source files without name collisions (after my patch). I'm also using the GCC #pragma interface feature, which might make a difference. Pardon my ignorance, since I'm not very familiar with the auto unit test implementation. __ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] random and msvc6
Lapshin, Kirill wrote: I don't have time at the moment, will look into it tonight. I will try to fix all the tests and submit patches to the list. Please find attached patch which makes random compile and pass random_test on msvc6. It fixes random_demo and random_speed as well. Nondetermenistic tests seemed to be designed for linux only and statistic_test fails due to lack of lgamma. Basically I made one change: #ifndef BOOST_NO_OPERATORS_IN_NAMESPACE --- #if !defined(BOOST_NO_OPERATORS_IN_NAMESPACE) !defined(BOOST_NO_MEMBER_TEMPLATE_FRIENDS) to following files(line): uniform_01.hpp(43) exponential_distribution.hpp(42) normal_distribution.hpp(48) xor_combine.hpp(70) uniform_smallint.hpp(124) Also I had to tweak tests a little. I am supplying a Jamfile, which is not exactly correct, because it attempts to compile all cpps as unit tests, while only random_test is a test, everything else are mere demos. It makes more sense to compile them via exe rule, but I did not manage to make it work. Given that boost.random does not have an active maintainer, who could take a look into this? -Kirill random_msvc6.tar.gz Description: Binary data ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: patch: BOOST_AUTO_UNIT_TEST in auto_unit_test.hpp
Hmmm. It works for me. I'm using BOOST_AUTO_UNIT_TEST across several of my
source files without name collisions (after my patch). I'm also using the
GCC
#pragma interface feature, which might make a difference. Pardon my
ignorance, since I'm not very familiar with the auto unit test
implementation.
I couldn't imagine how it may work. Each module will have following:
static boost::unit_test_framework::test_suite* test = BOOST_TEST_SUITE(
Auto Unit Test );
boost::unit_test_framework::test_suite*
init_unit_test_suite( int /* argc */, char* /* argv */ [] ) {
return test;
}
So. You should get symbols conflicts. Even if compiler/linker is able to
somehow choose and bind one of multiple init_unit_test_suite with library
call, it still should only run tests registered in selected module.
I would not play on such shaky grounds.
Gennadiy.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: Repost: [boost] Problems using iterator_adaptor withistreambuf_iterator
David Abrahams wrote: The following message seems to be written at an 'untime', because nobody responded, especially nobody of the maintainers. Nevertheless IMHO this question is worth thinking about to find a resolution. Hi all, I have a problem while using the iterator_adaptor templates in conjunction with a istreambuf_iteratorchar (an input_iterator type). The problem shows up, because the istreambuf_iteratorchar::operator*() implementation of the STL I'm using returns a value_type (char), but the dereference policy member expects to return it a reference. It seems, that there should be a similar return type deduction for the iterator_adaptor::operator*() function as already implemented for the iterator_adaptor::operator-() function. Regards Hartmut Which template are you having problems with? Can you post some code which reproduces the problem? Did you try explicitly specifying the iterator's reference type? I'll try to come up with a small sample. Thanks so far. Regards Hartmut ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
