Boost logo

Boost :

From: Robert Ramey (ramey_at_[hidden])
Date: 2005-01-22 19:35:20


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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk