- 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

Some thoughts below > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Doug Gregor > Sent: Wednesday, March 23, 2005 8:23 AM > To: Boost mailing list > Subject: [boost] Why do we build debug variants of our compiled libraries? > > Looking at the Jamfiles for Signals, Python, and the other libraries in > Boost that have compiled parts that users link against, I'm wondering > why we create so many variants by default. Why would a user want to > link against the debug version of Signals, for instance? The only > reason I imagine would be to debug Signals, but I should hope that the > average user does not need to debug that code. > > If I dig around /usr/lib and /usr/local/lib on my Mac, I only find > optimized libraries: nobody else seems to bother building debug > variants, so why should we? > [Brian Braatz Writes:] At least when I use signals (and other libraries) I always build against the debug for development. While I may not be debugging signals specifically, I may be wanting to see: 1- Signal calls on the call stack in my IDE 2- How my code is using signals - i.e. the focus is on MY code, but being able to step in and out of the signals stuff *=(or any boost lib for that matter) helps me see how my code is working WITH it 3- You may recall I am the same guy who occasionally begs\whines\offers to wash your car FOR: some kind of metadata in signals, I the reason is when you use this lib extensively, you may have a hard time figuring out WHERE something came from. Occasionally, I step into signals and look at the internal data to figure out where the slot came from > 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. > > Doug [Brian Braatz Writes:] Are you just talking about when you do a bjam build of boost (or specific lib)? I use the debug from this mode, but would be happy to change my script to pass in an extra param. The NICE thing about the "build everything" model is it is a catch all for peoples usage.

3 2

Sun C++ regression tests missing?
by Peter Dimov 23 Mar '05

23 Mar '05

Where did our Sun C++ test results go? I wanted to make sure that I haven't introduced any regressions with my latest changes to bind. -- Peter Dimov http://www.pdimov.com

6 17

RE: [boost] Re: boost::iostreams: only with std::cout?
by Dirk Griffioen 23 Mar '05

23 Mar '05

Hi Jonathan, Thanks for helping me out!! I've tried your proposition below and it does the trick, even with actual encryption going on: out << "test" << std::endl; //this works //out << "test" << "\n"; //this does not One remark: he code above works on my vc71 debug setup (cl called through bjam v2 build v10), but if I read your earlier mail correctly it should be the other way around and hang as well? One question: is this behaviour intended? I will try some more stuff (with some other containers , the copy/adapt etc) and source/sink - apart from encryption I am in need of a audio source/sink. I'll let you know :) - It's great stuff! Cheers, Dirk (Sorry the code didn't compile, forgot to match the filter names). (And what do you mean by 'red herring' ? :) -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Jonathan Turkanis Sent: Tuesday 22 March 2005 22:32 To: boost(a)lists.boost.org Subject: [boost] Re: boost::iostreams: only with std::cout? Dirk Griffioen wrote: > I would love to use the boost::iostreams lib, so I created a filter > (which, in this case, does encryption) > > but instead of passing it std::cout I would like to pass it some other > stream, a stringstream for instance (or any kind of ostream/istream, > depending on the direction). > However, I was very surprised to find the following code taking 100% > cpu and not returning. It probably means I did something wrong, but I > can't seem to find it. Here's a cleaned up example that reproduces the bug (when endl is replaces by "\n"). It seems the filter is a red herring. Jonathan #include <iostream> #include <sstream> #include <boost/iostreams/filtering_stream.hpp> int main() { boost::iostreams::filtering_ostream out; std::ostringstream os; out.push(os); out << "test" << std::endl; //out << "test" << "\n"; std::cout << os.str(); } _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient, any disclosure, copying, use, or distribution of the information included in this message and any attachments is prohibited. If you have received this email in error please notify our system management at postmaster(a)optiver.com and immediately and permanently delete this message and any attachments. ********************************************

4 3

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