- Boost - lists.boost.org

improved version of compiler_status.cpp uploaded to the new vault
by Robert Ramey 12 Jan '05

12 Jan '05

I've added to the vault an enhanced versionof the Boost compiler_status.cpp file. It is named compiler_status2.cpp. The original version creates a table showing one row for each test and one column for each compiler. When there are several results for each compiler such as debug, release, different variants, etc, the only the "first" set of results is displayed. This version displays ALL results for each compiler. The included example shows part of the testing done for the serialization library. In all other respects it is identical to the orginal program. Robert Ramey

1 0

Re: boost.test covered in testing frameworks rundown
by Noel Llopis 12 Jan '05

12 Jan '05

Gennadiy Rozental wrote: > Boost.Test does support fixtures. At least in a sense author using this > term. Noel found proper thread in mailing list to refer, but made > completely wrong conclusion from it. To implement fixtures one needs to > use constructor and destructor *for fixture*. Thanks for pointing that out, Gennadiy. After so many years of using NUnit setup/teardown, I was missing the obvious way of doing the same thing in C++. I've updated the article to reflect that fixtures are perfectly possible with Boost.Test. http://www.gamesfromwithin.com/articles/0412/000061.html With that, Boot.Test definitely makes it to my list of finalists. The only two drawbacks I see are the reliance of some of the other Boost libraries (it would be ideal if something this low level could be fully self-contained), and the verbosity needed to create suites. Cheers. --Noel Games from Within http://www.gamesfromwithin.com

5 11

Wike hacked again
by Robert Ramey 12 Jan '05

12 Jan '05

The wiki has been hacked again. Robert Ramey

3 2

Boost Thread - Read Write Mutex Problem
by David Brownell 11 Jan '05

11 Jan '05

When running the simple program listed below, the scoped_read_lock appears to never acquire a read lock on the mutex and, as a result, the program never finishes. In looking through the documentation, I don't think there is anything additional I need to do and was a bit surprised that this didn't work. Here is the code: boost::read_write_mutex m(static_cast<boost::read_write_scheduling_policy::read_write_scheduling_pol icy_enum>(alternating_many_reads)); std::cout << "Before\n"; { boost::read_write_mutex::scoped_write_lock l(m); } std::cout << "Middle\n"; { boost::read_write_mutex::scoped_read_lock l(m); } std::cout << "After\n"; And some more details: - Windows XP SP2 - Microsoft Visual Studio 2003 - I am compiling with the Multithreaded DLL version of the CRT, so boost_thread-vc71-mt-gd-1_32.lib is being used - test_read_write_mutex.cpp completed without problems - writer_priority and reader_priority completed without problems. Only alternating_many_reads and alternating_single_read seem to have problems. Thanks for your help! David Brownell

3 2

Fxns as io::filters
by christopher diggins 11 Jan '05

11 Jan '05

I mentioned in an earlier response to JT that I have written a function to filter adapter. The entire code is now online at http://www.cdiggins.com/iostreams_fxn_filters.hpp I can't help but wonder if the syntax for chaining streams to filters shouldn't be cin >> fxn_filter(fxn) >> cout; instead of cin | fxn_filter(fxn) | cout; Anyone have any thoughts on the subject? Would anyone else, other than me, like to see this functionality added to iostreams? - Christopher Diggins Object Oriented Template Library (OOTL) http://www.ootl.org

3 2

Singleton
by CHAOS 11 Jan '05

11 Jan '05

This post refers to the following code: http://www.ezequal.com/chaos/libs/singleton.h I have developed a templated singleton class which enforces almost every rule of the singleton pattern at compile time. This library provides a very clean, flexible format for client code to implement its own singleton classes which may have dependencies on each other. I have three questions. Does it make any sense to use a template allocator parameter, like the standard container types, to control creation and destruction of my instance, or are new and delete sufficient? Is there any other functionality that should be added? Specifically, is it sufficient to enforce that singletons are created in a specific order before main and destroyed in the reverse order after main (using dependency instances), or should I provide some way to support alternate lifetimes (ex: create on first reference to instance)? Is there any interest in adding this library to Boost?

5 7

Re: [boost] Anyone received Dave A's MPL book yet?
by Steve Ramsey 11 Jan '05

11 Jan '05

On Tue, 4 Jan 2005, "Brian Braatz" <brianb(a)rmtg.com> wrote: > I ordered it on amazon, and it now says it will arrive Feb 16th. > > If anyone knows of a faster way to get it, Ill cancel my amazon order. I ordered mine in mid-September from Amazon and it just shipped today; the website says they can ship new orders within 24 hours. Maybe Obidos doesn't like you... Steve

2 1

[iostreams] Version of Iostreams compatible with 1.32 available
by Jonathan Turkanis 11 Jan '05

11 Jan '05

Hi All, A version of the Iostreams library designed to work with release 1.32 is now available: http://home.comcast.net/~jturkanis/iostreams/ This version does not incorporate all the changes decided on during the review, but most of the name changes have been applied. In particular, - The library is now contained entirely in the iostreams subdirectories of <boost> and <libs>. - Resources are now called Devices - The i/o mode Inout has been renamed Bidirectional - The concept Buffered has been renamed Multi-Character - Filters are now located in the directory boost/iostreams/filter - Devices are now located in the directory boost/iostreams/device The library has been tested on VC7.1, Intel 7.1-8.0 for Windows, Codewarrior 8.3 and GCC 3.2 (mingw). Unfortunately, I have noticed some regressions of GCC 3.3-4, but am working to correct them. I am confident that the library will eventually work on GCC 3.3+ and Borland 5.6.4. In addition, I may be able to provide limited support for VC6-7.0. I'm hoping to get a version into CVS soon. Also, several of the fixes that people sent me during the review have been removed because they caused regressions. They have not been forgotten -- they will be incorporated in to the final version in modified form. -- Jonathan Turkanis technews(a)kangaroologic.com

10 35

RE: [boost] Re: Interesting Boost Implementation Details?
by Brian Braatz 11 Jan '05

11 Jan '05

> [ David Abrahams] > I'll be giving two talks at SD West in March, one about template > metaprogramming, and another called "Inside the Boost Libraries," where > I plan to discuss some of the more interesting Boost internals. You can > see a synopsis at > http://www.cmpevents.com/SDw5/a.asp?option=G&V=3&id=271893 > > I'm trying to decide exactly what to cover there. I've listed some of > my ideas below, but I'm obviously not familiar with the entire Boost > codebase, so I thought I'd solicit suggestions. Thoughts, anyone? More thoughts to add to this thread. Background: * I have attended presentations from folks that they have taken VERY interesting material and made it EXTREMELY boring * I have also attended presentations from folks and it has been exciting and thrilling to watch the information unfold. I was kept on the edge of my seat waiting to see what was going to happen next * I have noticed that the crowd's at the shows are not always the "Type A" programmers, and frequently don't seem to engage or have the background information necessary to really understand the topic being presented * With complex subjects, for myself, I have noticed that once I know how to "think about something" and then I "get it". I can than think about any aspect of that, because I understand the concepts necessary to process the information. * if one can find the "sweet spot" early in the presentation for getting the crowd to "think" the right way to grasp the rest of the presentation, then you have a much better chance of ending the talk with everyone excited. (because you have taught them something and then took them along for a ride where you showed how to USE that new way of thinking) * I spent *A LOT* of time with Boost.Lamda. Writing sample code, re-reading the documentation, over and over and over and over again. It took me many passes to "get it". This is an excellent library, and the document IS well done. I think this is just the classic problem of really smart people having a hard time figuring out how to present something to someone who does not "know how to think about it". I took a look at the phoenix v2 docs. What is cool is THIS PAGE: http://tinyurl.com/3khbu What stood out about it was THIS ONE PAGE would have saved me many many hours had it been in the original Lambda docs. Because it describes for me, how to "think" about the currying. My advice to you is to find a way, in your presentation of the boost internals, to make sure that you thread it such that the people watching "can think about it". If you establish this early on, you will have an excited audience and you will (hopefully) get more people to use boost. Detailed Suggestions: * the pics in the above link are conceptually excellent for describing how to think about currying. If you can accomplish something along the same lines with the techniques you are going to show, then you will really knock em dead. * Boost internals is an excellent subject matter, I think if you first hit common concepts- and THEN delve into those concepts and how the internals of the library(ies) use that concept you will give people something they can use. * in a previous mail I made the suggestion, which I will make again. Try to think of the most important techniques the boost libraries depend on, get them in peoples heads, and then delve into the internals. * a technique I have seen used in the mags, is to decompose the templates, I.e. show what the code looks like after the compiler has gone through the generation steps. * hopefully my suggestions, though not exactly what you asked for, will be of some use to you. :) Brian

4 7

Re: boost.test covered in testing frameworks rundown
by Noel Llopis 11 Jan '05

11 Jan '05

Gennadiy Rozental wrote: > Actually Boost.Test doesn't impose that many dependencies (in other > case it wouldn't be able to use it for boost internal testing). > It does depend config subsystem and some other core part of boost (like > smart_ptr for example), which are mostly targeted for TR1. But namely > due to this dependencies (not in spite of) Boost.Test achieve > it's portability. That's something that in general, I would love to see for every Boost library: A list of what other libraries it depends on. Ideally, I'd love to see a dependency graph between all the libraries. That way I can use a library without the fear of pulling in tons of other libraries (or having to wade through tons of headers). I'm glad to hear that Boost.Test doesn't pull in too many other libraries. When I saw the shared_ptr I feared the worst. By the way, why is it using shared_ptr? Sure, it's convenient, but wouldn't it be better to minimize dependencies completely from other parts of Boost? > TEST ( MyFixture, TestCase1) > { > BOOST_CHECK_CLOSE ( someValue, 2.0f, 0.005f); > } > > If you find it generally useful I could add this helper macro into > framework. That would be truly excellent! Please go ahead and add it to the framework. > Boost.Test supply 2 predefined log formats (human readable and XML, which > you could select by command-line) and unit_test_log_formatter interface > you could implement for you own formats. What else do you need? One that we would need right off the bat is the ability to output the log to DebugOutputString() when running in Windows doing development in Visual Studio. What would be necessary to do that? Write a new unit_test_log? > Adding test_suites usually means only something like this: > > test_suite* test = BOOST_TEST_SUITE( "Master test suite" ); > > test_suite* ct = BOOST_TEST_SUITE( "Constructors test" ); > test->add( ct ); Right. The problem is that suites will be spread across multiple cpp files. So for each suite not only do need to put it together in each cpp file, but then I have to go to main.cpp and add it to the master suite. After looking at it some more, I was able to simplify it further to something like this: test_suite * GetSuite1() { test_suite * suite = BOOST_TEST_SUITE("my_test_suite"); boost::shared_ptr<MyTest> instance( new MyTest() ); suite->add (BOOST_CLASS_TEST_CASE( &MyTest::TestCase1, instance )); suite->add (BOOST_CLASS_TEST_CASE( &MyTest::TestCase2, instance )); return suite; } It still requires me to explicitly call GetSuiteX() from main for every suite though, which is unfortunate. I will look at the method you suggested for making suite registration more streamlined. > Did you really mean that Boost.Test is only PC oriented? Or it's actually > something different? Like: "If you aren't doing embedded development..." I meant it from the point of view of game development. If you're not doing PC development, you're doing something close to embedded systems development (game consoles, handhelds, etc). Thanks again for the discussion. The more we discuss Boost.Test, the closest it's getting to my ideal test framework. Thanks :-) --Noel

2 1