March 2005 - Boost - lists.preview.boost.org

[Regressions] Question for Mr Caleb Epstein.
by Hubert Holin 23 Mar '05

23 Mar '05

Somewhere in the E.U., le 16/03/2005 Bonjour I am currently investigating some regressions for my quaternion and octonion libraries, which appear in the report of the tests you run under SunOS5. I have the feeling that for "long double" variables, numeric_limits<long double>::epsilon() returns the correct value, but standard transcendental functions (atan at least) behave as if their input were "double" and not "long double". Do you know if this is the case? Merci Hubert Holin

2 2

[wave] tool/lib
by Gennadiy Rozental 23 Mar '05

23 Mar '05

Hi, I would like to reiterate my concern about wave tool/library. I did not want to continue original discussion, cause I did not want to interfere with the review (I actually believe wave is a valuable tool that needed to be accepted). In following items I will try to justify my position that it (wave tool/library) needs to be treated as a tool not a library: I. It doesn't really fit into our library review model 1. Any review period wouldn't be enough for the majority of reviewer to get any (if any) decent look on implementation. Not only because it quite big, but because it require special knowledge 2. To be able to give any opinion on the design, one need essentially detail knowledge of C++ specification in regards to preprocessor. And I couldn't see how reviewer could see how design meet the requirements within review period. 3. Reviewers couldn't run test to check this tool do what it supposed to do. II. It has different target audience then boost libs I believe that in 99.99% of use cases it is going to be used as a tool, not as a library. One could probably need custom C++ preprocessor, but only in academic purposes, and definitely not in production. III. It doesn't really fit a maintenance model I don't see that any tester will ever run regression tests for the wave. And definitely not on regular basic as we do with rest of boost libs. IV. It doesn't really fit distribution model We distribute our libraries in a form of source code. It doesn't seems reasonable for wave. It should be distributed in a binary form. As I said majority of it's target audience will use it as a tool and shouldn't be punished if they use a compiler that couldn't handle spirit for example. On the other hand we are adding meg of source code that nobody (almost) will ever look into (other then spend time to compile a tool). Also documentation for this tool should be really tool-user directed - no need for the implementation to blur the view unless one is interested in it. I believe we need to introduce formal division on tools and libraries within boost. We already have couple useful tools that my have usage outside of boost (we need to document the first), I see several others that could be added. The review procedure for the tools should be different from the libraries. Essentially we need to review only the users guides and run already rebuilt executables. There may be something else I missing, we should discuss it. I believe there is a reason why language working group is separate from library working group in standardization committee. Let's keep clear separation of concepts here also. Regards, Gennadiy

8 26

[Boost-Bugs] [ptr_container]
by Pavel Chikulaev 23 Mar '05

23 Mar '05

Hi all, It's quite strange that I can't write something like that: ptr_vector<int> v; ptr_vector<int>::const_iterator i = v.begin(); //won't compile on VC7.1 ptr_vector<int>::iterator j = v.begin(); //It works ptr_vector<int>::ptr_const_iterator ip = v.ptr_begin(); //won't compile on VC7.1 ptr_vector<int>::ptr_iterator jp = v.ptr_begin(); //it works but const ptr_vector<int> cv; ptr_vector<int>::const_iterator k = cv.begin(); //works as expected ptr_vector<int>::const_iterator kp = cv.ptr_begin(); //works as expected but std::vector<int *> v2; std::vector<int *>::const_iterator = v2.begin(); //works just fine Obviously, this is a bug. -- Pavel Chikulaev

2 1

Regression report for Releases?
by Jeff Garland 23 Mar '05

23 Mar '05

Do we have the results of the 1.32 regression tests somewhere? I'm curious what the actual final release results were, but I can't find them anywhere. I thought at one time we maintained them on the website? Anyway, it be really nice to snapshot the final test web pages and include them in the release package. That way everyone could simply look at the results and get an idea about how their compiler/platform might work with that release -- of course that should be on the website too. Jeff

7 45

[Boost-Bugs] [ptr_container]
by Pavel Chikulaev 23 Mar '05

23 Mar '05

Hi all, It's quite strange that I can't write something like that: ptr_vector<int> v; ptr_vector<int>::const_iterator i = v.begin(); //won't compile on VC7.1 ptr_vector<int>::iterator j = v.begin(); //It works ptr_vector<int>::ptr_const_iterator ip = v.ptr_begin(); //won't compile on VC7.1 ptr_vector<int>::ptr_iterator jp = v.ptr_begin(); //it works but const ptr_vector<int> cv; ptr_vector<int>::const_iterator k = cv.begin(); //works as expected ptr_vector<int>::const_iterator kp = cv.ptr_begin(); //works as expected but std::vector<int *> v2; std::vector<int *>::const_iterator = v2.begin(); //works just fine Obviously, this is a bug. -- Pavel Chikulaev

1 0

[program_options] Patch to fix 64bit error and warning
by Jonathan Wakely 23 Mar '05

23 Mar '05

The attached patch fixes a 64 bit portability problem where std::string::size_type is assigned to unsigned, which is shorter than size_t on x86-64 and so will be truncated. This means the following comparison to std::string::npos is always false. Patch also prevents a warning with GCC; since the compiler doesn't know that boost::throw_exception never returns it thinks that cmdline::translate_property() can reach the end of the function without returning. The patch simply removes the "else" so that throw_exception is always called if control reaches the end of the function. A better solution might be to mark boost::throw_exception() with __attribute__((unused)) for GCC. The first change is required, the second is optional. jon -- "More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason - including blind stupidity." - W.A. Wulf

2 3

Re: Asynchronous I/O
by Hans Malherbe 23 Mar '05

23 Mar '05

--- Don G skryf: >Of the mechanisms discussed, I am not sure I understand what you mean >by async I/O with only one thread. I can imagine a nonblocking/select >style approach that has no extra threads, but as soon as the main >thread is not waiting on I/O itself (my interpretation of "async"), >there needs to be threads to do the waiting. The main thread does the waiting. In Windows NT you will either wait on the event flag in the OVERLAPPED structure or specify a completion routine and wait in an alertable state with the SleepEx or one of the *WaitFor*ObjectsEx functions. Groete Hans Malherbe ______________________________________________ "This information is intended only for the person or entity to which it is addressed and may contain private, confidential, proprietary and/or privileged material and may be subject to confidentiality agreements. Any review, retransmission, dissemination, or any other use of or taking of any action in reliance upon this information, by persons or entities other than the intended recipient, is prohibited. If you received this in error, please contact the sender and delete the material from all storage media. The company is neither liable for proper, complete transmission of the information contained in this communication, any delay in its receipt or that the mail is virus-free"

1 0

Re: Re: FSM review
by Andreas Huber 22 Mar '05

22 Mar '05

Rob Stewart wrote: [snip] > Without digging out the previous messages and confirming the > matter, I think Jonathan's suggestion, quoted above, was simply > that *when* the user wants separate translation units *and* the > features that would typically require tight coupling, you could > introduce a weaker link -- some form of indirection -- that would > slow the resulting FSM or even complicate its specification, but > would at least permit the functionality. I think that's close to what I understood... [snip] > This is right on target. *Since* the current design, with all of > its requirements is so much slower, then the onus is on Andreas > to explain why the requirements his library meets exceed those > met by other FSM libraries and directly lead to the performance > overhead. Clear distinctions regarding the performance > improvements gained by avoiding the performance draining features > in an FSM while still using this library will help to demonstrate > that situation, too. [and] [snip] >> Normally, in designing a framework one considers a small handful >> (say two to six) of alternate designs which view the subject matter >> from completely different perspectives. In your case, what were >> those alternate designs? > > Note that Jonathan is asking that those alternatives be > documented. That way, other developers who wonder why you didn't > try X will see that you did and they'll see why you decided it > was not appropriate. I have agreed to add such documentation in one of my previous answers. >> Let me make one last attempt to explain what should be in the >> rationale. Look at section 16.2 of "The C++ Programming Language", >> 3d ed. Here Stroustrup gives two design criteria for a containers >> library, and then discusses three designs: >> >> "Specialized containers and iterators" - satisfies the first >> criterion "Based Containers" - satisfies the second criterion >> "STL" - satifies both criteria >> >> I'm not suggesting that you give such a detailed treatement as >> Stroustrup. However, if you were to give a similar overview of the >> landscape of possible FSM frameworks, and thoughtfully discuss the >> tradeoffs in flexibility and performace which each involves, >> reviewers might have some confidence that you are aware of the >> techniques which might be used to construct a fast, flexible FSM >> framework, and have carefully considered the design. >> >> This type of overview would probably be a useful component of any >> library's documentation; in your case it is made absolutely >> essential by the performance figures you cite. > > I don't think I can add any more to that. I think it is > reasonable and clear. It is but I'm not sure how this is relevant (I already agreed to add such documentation). -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.

1 0

implicit_cast has been removed, but this is sad
by Jens Theisen 22 Mar '05

22 Mar '05

implicit_cast was once in cast.hpp, but as the comments says, it has been removed due to uncertain purpose. I have to purposes of which I am wondering how to do them otherwise: 1. take the address of the conversion 2. initialise a std::vector< int > with a boost::assign::list_of in a constructor initialiser The latter is a bit subtle. list_of uses a templated conversion operator to containers (but technically everything) and std::vector's ctor are then all tried with taking converted arguments, which leads into an ambiguity. Using implicit_cast solves the problem, since then the constructor call to std::vector and the call to the conversion operator in list_of are both taken as user defined conversions, and there can only be one of them. vector< int > v = list_of(1)(2); // works vector< int > v(list_of(1)(2)); // ambiguous ctor() : v(implicit_cast< vector< int > >(list_of(1)(2))) { } // ambiguous ctor() : v(list_of(1)(2)) { } // ambiguous Any thoughts on this? Regards, Jens

4 12

Re: [boost] Re: [review] hash functions
by brangdon＠cix.compulink.co.uk 22 Mar '05

22 Mar '05

In-Reply-To: <d1on4o$ijr$1(a)sea.gmane.org> daniel(a)calamity.org.uk (Daniel James) wrote (abridged): > > Admittedly hash_combine is also (nearly) redundant, being definable > > as: > > > > void hash_combine( size_t &hash, const T &t ) { > > hash_range( hash, &t, &t+1 ); > > } > > > > if T does not overload address-of. Note this is currently true because hash_range is defined as having the effect of: void hash_range( size_t &hash, It first, It last ) { for (; first != last; ++first) hash_combine( hash, *first ); } so calling hash_range on a range of 1 element returns the same result as calling hash_combine with that element. > Since nested vectors give different hash values to their flattened > form, I don't think a single element vector should have the same hash > values as it's element. It doesn't. One is: return hash_value( t ); the other is: size_t hash = 0; hash_combine( hash, t ); return hash; All the proposed definitions of hash_combine make these different. There is at least an xor, and possible a constant added. -- Dave Harris, Nottingham, UK

2 1