Gennadiy Rozental wrote:

...

I find Boost Test very valuable and use on a regular basis. I think that it would be even more useful if it had the following additional features:

a) automatic heap checking for memory leaks for libraries that can support it.

I am working on update that will include what you requested (VC specific)

The serialization library file test_tools.hpp which includes your test_tools.hpp has code that has worked well for me for this purpose. I was extremely easy to implement. If were any more difficult I would say its not worth it. But since its almost free, I think its a good idea

...

b) the ability to create a temporary fstream with a unique name in a safe way.

Could you give me more dtailes on that: what the problem, why it needs framework to resolve it e.t.c.

This isn't high priority and maybe not worth addressing - but here it is. The serialization library tests usually create a test file, serialize to it and read back. This entails a couple of problems. a) Creating the temporary file. mktemp gives ona file descriptor - not a stream. There is no easy way to turn this into a real stream - with facets, and everything else. b) geting a tempory name is considered security risk and now some compilers/linkers are starting to complain about it. c) I had difficulties as the temp direcotry sometimes end in back slash and sometimes not. If you look into serialization/test/test_tools.hpp you'll see what I had to do to address this. I guess ai was sort of looking for something like : temp_ofstream ots; .../serialize to ots ots.close() temp_ifstream its(ots) ../de-serialzie from temp stream. BTW, the problem with string stream is that it doesn't seem to handle facets with the libraries I use. Honestly, I'm really not even sure what I really what here. I'm just disatisfied about what I had to do here. Probably, its something that would be better in another library (temporary streambuffer?).

...

c) The ability to specify an execution time limit so that if the program goes off into space it doesn't waste an in ordinate amount of time. (perhaps this would be easier to include in bjam)

You could specify a timeout for the test case.

where do I do that? it would seem to me that this would have to be done by bjam or by a separate thread in the test library. (probably not a great idea)

...

d) The abtility to specify a maximum amount of memory to be allocated. When this allocation is passed, the program would terminate.

This require custom memory manager facility. I do need it but it's not amoung first things I plan to do.

...

e) Currently, all tests compiled with borland compilers fail immediatly when the program and library are built in release mode. I would like to see this fixed. I did spend a little time trying to track this down but was unsuccessful.

It's not that trivial to find a release mode specific issue. I will try to resolve it next update though. BTW how do you compile test in a release mode?

a) I deleted the compiled test and serialization libraries. b) I invoked export BUILD=release c) I set the subvariant <debug-symbols>on for one of my tests in the test Jamfile d) I ran bjam test for the borland compiler. I used the --preserve-test-target switch to keep the executable around after the test. e) After the test is run I can apply TD32 (for borland 5.51) to the executable and I can ivoke the debugger to step through the source. The only problem is that, as one would expect, it ain't all that easily to follow the optimized code. I felt some what hindered in not knowing what the code was intended to do. Clearly its an overly zealous optimization from a compiler bug - not that easy to find even with the debugger working. I also doubt that this is the only issue. I"m convincing myself to spend a little more time with it. On my machine, I now run all the tests in release mode as well as debug mode. My modified version of compiler_status (in the new vault) displays all configurations in one table. So now the fact that borland release versions all fail is really nagging me. Amazingly to me, with the help of Pavel Vo... I was able to make all the serialization tests pass (except one) with the borland compiler. A hollow achievement perhaps, but still satisfying in an obsessive/compulsive sort of way.

...

f) A more tutorial type manual.

That's for sure. Unfortunately I have a quete a backlog for features to implement/fix and writing docs taking enourmouse amount of time/efforts. So, you figure it out. There are couple articles online already. I will try to do something but I couldn't promise definetly.

The recent discussion regarding your test library was enlighteing to me. Actually, I don't thing the manual is bad. I think my concerns could be addressed with one or two more realistic and complete examples and maybe an expanded FAQ which paraphrases the recent thread on this subject. Robert Ramey

Jonathan Turkanis wrote:

Robert Ramey wrote:

...

a) Creating the temporary file. mktemp gives ona file descriptor -

I assume you mean mkstemp

...

not a stream. There is no easy way to turn this into a real stream - with facets, and everything else.

typedef stream_facade< code_converter< file_descriptor> > file_descriptor_stream_with_facets_and_stuff;

Coming soon to CVS nearest you. :-)

Excellent ! Could you please double check the file test_tools.hpp in libs/serialization/test to see what I had to do to make a crude but effective substitute for what I needed. I seem to remember a lot of aggravation in dealing with different compile implementations. Now that I've written the above, I wonder if a better string_stream might not be better in many cases. My files are small. When I looked at string stream before, it didn't handle codecvt facets which made me skeptical about using for my tests. Hmmm - maybe codecvt facets don't make any sense in string stream - more food for thought. In any case, your understanding of what I'm asking for is correct. Thanks a lot. Robert Ramey

Gennadiy Rozental wrote:

...

...

...

c) The ability to specify an execution time limit so that if the program goes off into space it doesn't waste an in ordinate amount of time. (perhaps this would be easier to include in bjam)

You could specify a timeout for the test case.

where do I do that? it would seem to me that this would have to be done by bjam or by a separate thread in the test library. (probably not a great idea)

You could specify timeout in a call test_suite::add( test_case*, expected_failures, timeout )

Maybe people consider the following an isolated situation not worth accommodating generally, but it really would have been convenient to have been able to have per-file compilation time limits in bjam during the (aborted) attempt to get tests to run in release mode on the mac. Memory size limits could also be good... of course on unix you can set these in the shell before you run bjam, but people wouldn't think to and funky behaviour could slip through. Don't know how this all works on windows. Just a FWIW... troy d. straszheim