Jason Hise wrote:

An example source file which demonstrates how a zombie singleton might be implemented has been uploaded to the sandbox singleton directory for those interested. It will eventually be revised and become part of the upcoming tutorial on extending the singleton library, in a section about writing custom creators. A zombie singleton, if destroyed and re-created, is re-created as an empty shell with all no-op functions. Comments are welcome.

Jason, this is exactly what I'm looking for. Many thanks! Angus

Is there a specific formal way that I should be writing test programs for the singleton library? I was initially planning on just writing program results to a file and providing a second file containing expected output. However, because I am relatively new to boost I thought that there might be some bigger testing framework that I need to use. Is there? Additionally, I don't quite understand what bjam is, but everything seems to use it. Should I be using it as well, or does it only apply to libraries that need to be compiled? Singleton uses only header files. Thanks in advance for all replies. -Jason

Gennadiy Rozental wrote:

"Jason Hise" <chaos@ezequal.com> wrote in message news:42264972.6040405@ezequal.com...

...

Is there a specific formal way that I should be writing test programs for the singleton library? I was initially planning on just writing program results to a file and providing a second file containing expected output. However, because I am relatively new to boost I thought that there might be some bigger testing framework that I need to use. Is there?

Additionally, I don't quite understand what bjam is, but everything seems to use it. Should I be using it as well, or does it only apply to libraries that need to be compiled? Singleton uses only header files.

Thanks in advance for all replies.

-Jason

You could use Boost.Test. It has several components. You may select the one that fit best to your habits/needs. Particularly Boost.Test tools includes output_test_stream that allows to match your output vs. pattern file. Check docs for more details.

Gennadiy

It would appear that such tests are required to execute completely inside of a function block. Unfortunately, the very nature of a singleton makes this impossible. I need to be able to check the lifetimes of singletons with relation to each other, and with relation to static and global objects. This means I cannot even use cout to report results, as the standard streams could close up shop before the last of my singletons is destroyed. At the moment I am thinking that I will need to write two test programs... one to test the singletons and generate an output file, and one to verify the contents of the file that was generated. Does anyone see a simpler way? Also, I should ask what the policy is on testing classes that use a policy based design. How many different combinations of policies are expected to be tested? -Jason

...

You could use Boost.Test. It has several components. You may select the one that fit best to your habits/needs. Particularly Boost.Test tools includes output_test_stream that allows to match your output vs. pattern file. Check docs for more details.

Gennadiy

It would appear that such tests are required to execute completely inside of a function block.

That not nesseserily true. I am not sure I fully understand you though

Unfortunately, the very nature of a singleton makes this impossible. I need to be able to check the lifetimes of singletons with relation to each other, and with relation to static and global objects.

Your design surely needs to cover function scope either (as any other scope), isn't it?

This means I cannot even use cout to report results, as the standard streams could close up shop before the last of my singletons is destroyed.

You may need to have separate program that specifically test that your library correctly deals with pre/post main processing, but majority of the logic should be testable on any scope.

At the moment I am thinking that I will need to write two test programs... one to test the singletons and generate an output file, and one to verify the contents of the file that was generated. Does anyone see a simpler way?

The second one could easily use Boost.Test. I am afraid thouhg you may have some difficulties integrating this solution with Boost.Build system

Also, I should ask what the policy is on testing classes that use a policy based design. How many different combinations of policies are expected to be tested?

You could use BOOST_TEST_CASE_TEMPLATE facility to test combinations based of mpl type sequences.

-Jason

Gennadiy

"Jonathan Turkanis" <technews@kangaroologic.com> wrote in message news:d06d1d$eqv$1@sea.gmane.org...

Gennadiy Rozental wrote:

...

You could use BOOST_TEST_CASE_TEMPLATE facility to test combinations based of mpl type sequences.

Could you point me to the docs for this facility?

Jonathan

This functionality present in 1.32.0. The semantics for this facility changes though. The best way to learn it would be to see how I use it for Boost.Test unit tests. Also check test_case_template_example in example directory. If you still have any question fell free to ask. I will update docs before release. Gennadiy

Gennadiy Rozental wrote:

You may need to have separate program that specifically test that your library correctly deals with pre/post main processing, but majority of the logic should be testable on any scope.

The thing is that the majority of the logic is in place just to handle the timing of automatic destruction. The actual act of creating and destroying is generally trivial by comparison. I suspect, though, that the biggest test of the library will be whether or not it compiles. If it compiles, it should almost certainly run correctly. -Jason

Gennadiy Rozental wrote:

...

The thing is that the majority of the logic is in place just to handle the timing of automatic destruction. The actual act of creating and destroying is generally trivial by comparison. I suspect, though, that the biggest test of the library will be whether or not it compiles. If it compiles, it should almost certainly run correctly.

-Jason

So you are saying that there is no way to initiate automatic destruction when leaving any given scope, only global scope?

I believe some lifetime management policies rely on cleanup of local static variables or on atexit. Jonathan

From: Jason Hise <chaos@ezequal.com>

It would appear that such tests are required to execute completely inside of a function block. Unfortunately, the very nature of a singleton makes this impossible. I need to be able to check the lifetimes of singletons with relation to each other, and with relation to static and global objects. This means I cannot even use cout to report results, as the standard streams could close up shop before the last of my singletons is destroyed.

They are supposed to survive however long your code needs them. How the implementation manages that is pure magic, as far as we know. It's just supposed to work. (27.3/2 plus footnote 265) -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;