- Boost - lists.boost.org

RE: [boost] Why do we build debug variants of our compiled libraries?
by Brian Braatz 23 Mar '05

23 Mar '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of John Maddock > Sent: Wednesday, March 23, 2005 9:13 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] Why do we build debug variants of our compiled > libraries? > > > Anyway, my recommendation is that we stop building debug variants of > > compiled libraries by default. It's easy for the user to build them if > > they are really required. > > There is one exception: if you're using VC++ or some other compiler that > ships with multiple runtimes, then you *must* link against a Boost lib > that's built against the same runtime as your application is using > (probably > a debug runtime during development). Of course on Linux (and probably > most > Unix variants) this is a non-issue. > > John. > [Brian Braatz Writes:] thanks John- that is a good point I recall you CAN also accomplish rolling in a "release" version of the std runtime with debug build of an exe, but it is brittle and does not work in all cases for all types of projects- this solution requires you to very carefully tweak all the right compiler settings across all the libraries. In other words, just because you can doesn't mean you should :)

4 3

[Boost-bugs] [ boost-Bugs-1169273 ] dead links in uBLAS page
by SourceForge.net 23 Mar '05

23 Mar '05

Bugs item #1169273, was opened at 2005-03-23 17:49 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1169273&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Scott Otterson (scotto36) Assigned to: Nobody/Anonymous (nobody) Summary: dead links in uBLAS page Initial Comment: At: http://www.boost.org/libs/numeric/ublas/doc/#further_information there are many dead links. For example, none of the links under "uBLAS Concept definitions" work. Sorry, I couldn't figure out where else to post this! Scott ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1169273&group_… ------------------------------------------------------- This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005 Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows Embedded(r) & Windows Mobile(tm) platforms, applications & content. Register by 3/29 & save $300 http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[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