Boost.Tests: Unit test defines own main() function, why?

[Gennadiy Rozental-2]

eg <egoots <at> gmail.com> writes:

>
> Gennadiy Rozental wrote:
> >>
> >>>> This seems to be one of the most important questions: Why do you not
> >>>> replace http://www.boost.org/libs/test/doc/index.html with
> >>>> http://www.patmedia.net/~rogeeff/html/index.html?
> >>>> Does the content need to be transferred from HTML first or what steps
are
> >>>> missing?
> >>> 1. I do not how to do it
> >>> 2. I do not know if it possible at all.
> >> Oh, come on, man.  That's just too hard to swallow.
> >> http://lists.boost.org/Archives/boost/2005/08/91786.php
> >
> > Yeah. Since I never got to do it, I forgot about it. At this point I will
wait
> > for 1.35
> >
>
> It appears to me that the new docs are not yet in the 1.35 release
> branch. Should they be?

Yes, they should. And yes they are not there yet. I've spent last couple weeks
updating them with recent changes in Boost.Test. New beta now in regular
location in patmedia.net/~rogeeff.

The only one major problem that's left is incorporating my docs with official
boostbook. The primary obstacle from me is lack of any support for this
component. I am not even sure there is any particular person responsible for
it. I need to introduce quite big changes into boostbook and in a past I was
not able to get any responce for even simple support requests. I am planing to
follow up un Boost.docs list with conreate list of changes I need. Also I'll
need changes in boost.Build since I need additional options for xsltproc.

Gennadiy

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Benoit Sigoure]

On Jan 11, 2008, at 7:50 PM, Gennadiy Rozental wrote:

> Benoit Sigoure <tsuna <at> lrde.epita.fr> writes:
>> Would it be possible for you to give me the smallest dumb code that
>> exercises the most basic feature of Boost.Test + compilation and
>> linkage against Boost.Test?
>
> Test for single header variant; no need to link with the library:
>
> #define BOOST_TEST_MODULE boost.m4
> #include <boost/test/included/unit_test.hpp>
>
> BOOST_AUTO_TEST_CASE( case )
> {
>    BOOST_ERROR( "expected" );
> }
>
> ---------------------
>
> Standalone library variants:
>
> #define BOOST_TEST_MODULE boost.m4
> #include <boost/test/unit_test.hpp>
>
> BOOST_AUTO_TEST_CASE( case )
> {
>    BOOST_ERROR( "expected" );
> }
>
> This should work both for static and shared library variants. In  
> later case
> you need to add BOOST_TEST_DYN_LINK to the compiler options and  
> corresponding
> link options to enforce linking with shared library.
>
> Some specific features of Boost.Test (like floating point  
> comparisons) require
> additional headers. We can come up with corresponding tests as well.

Thanks for your code.  It grieves me that Boost.Test is the *only*  
library for which I have to write "special cases" only because it's  
not "well-behaved".

--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Gennadiy Rozental-2]

Benoit Sigoure <tsuna <at> lrde.epita.fr> writes:
> Thanks for your code.  It grieves me that Boost.Test is the *only*  
> library for which I have to write "special cases" only because it's  
> not "well-behaved".

In what sence? How do you define well behaved?




_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Benoit Sigoure]

On Jan 12, 2008, at 3:26 AM, Gennadiy Rozental wrote:

> Benoit Sigoure <tsuna <at> lrde.epita.fr> writes:
>> Thanks for your code.  It grieves me that Boost.Test is the *only*
>> library for which I have to write "special cases" only because it's
>> not "well-behaved".
>
> In what sence? How do you define well behaved?


What is this whole thread about?  Boost.Test is non standard because  
it messes up your `main' and must be used differently whether you're  
linking with it as a shared library or a static archive.

--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Gennadiy Rozental-2]

"Benoit Sigoure" <tsuna@...> wrote in message
news:805924BB-31B0-44E8-88CE-9538D89B082C@......

> On Jan 12, 2008, at 3:26 AM, Gennadiy Rozental wrote:
>
>> Benoit Sigoure <tsuna <at> lrde.epita.fr> writes:
>>> Thanks for your code.  It grieves me that Boost.Test is the *only*
>>> library for which I have to write "special cases" only because it's
>>> not "well-behaved".
>>
>> In what sence? How do you define well behaved?
>
>
> What is this whole thread about?  Boost.Test is non standard because
> it messes up your `main'

Why do you care? how does it make Boost.Test behave badly?

> and must be used differently whether you're
> linking with it as a shared library or a static archive.

As you have seen in my example, it is exactly the same for both usage
variants. The only difference is additional macro in makefile. But, than,
link command is going to be different anyway.

Gennadiy



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Jens Seidel]

On Mon, Jan 14, 2008 at 01:16:51AM -0500, Gennadiy Rozental wrote:

> "Benoit Sigoure" <tsuna@...> wrote in message
> news:805924BB-31B0-44E8-88CE-9538D89B082C@......
> > On Jan 12, 2008, at 3:26 AM, Gennadiy Rozental wrote:
> >
> >> Benoit Sigoure <tsuna <at> lrde.epita.fr> writes:
> >>> Thanks for your code.  It grieves me that Boost.Test is the *only*
> >>> library for which I have to write "special cases" only because it's
> >>> not "well-behaved".
> >>
> >> In what sence? How do you define well behaved?
> >
> > What is this whole thread about?  Boost.Test is non standard because
> > it messes up your `main'
>
> Why do you care? how does it make Boost.Test behave badly?

Normally one is able to test for the existence of a library by just
calling a function inside main() or by creating an instance of a special
type:

#include <required_lib_header.h>

int main(int argc, char* argv[])
{
  double a = function_from_lib();
  type_in_lib object;
}

If this links successfully (using current compiler flags maybe after
extented with -l <libname>) one can be sure that the library is
properly installed. This is a very common task. That's why Autoconf
provides a macro AC_TRY_LINK which expects the arguments "#include
<required_lib_header.h>" and the body of main.

A example of one of my configure.ac files (the last two arguments
specify the code used if the linkage works or not, resp., I nested it):
AC_TRY_LINK([#include <math.h>],
            [double f=3.14; return isnan(f);],,
            [AC_TRY_LINK([#include <math.h>
                          int __isnand(double x) { return x != x; }],
                         [double f=3.14; return isnan(f);],
                          AC_DEFINE(NEED___ISNAND, 1, [Use own
implementation of __isnand (cygwin)]))])
 
Beeing forced to also write

int main(int argc, char* argv[])
{

}

is just not required for nearly all library tests and error prone. This
is probably the argument of Benoit. He also wrapped AC_TRY_LINK to
simplify his tests (it is necessary to test all library variants
(multithreaded or not, ...) so a own macro makes sense) and expects a
single header file name only. See e.g. the following excerpt of
boost.m4:

# BOOST_WAVE([PREFERRED-RT-OPT])
# ------------------------------
# Look for Boost.Wave.  For the documentation of PREFERRED-RT-OPT, see the
# documentation of BOOST_FIND_LIB above.
AC_DEFUN([BOOST_WAVE],
[BOOST_FIND_LIB([wave], [$1],
                [boost/wave.hpp],
                [boost::wave::token_id id; get_token_name(id);])])

There is in general no guarantee that a single header file is sufficent
for a test but it worked for all other Boost libraries as well. That's
why he was looking for the most simple test.

> > and must be used differently whether you're
> > linking with it as a shared library or a static archive.
>
> As you have seen in my example, it is exactly the same for both usage
> variants. The only difference is additional macro in makefile. But, than,
> link command is going to be different anyway.

No, you're wrong. There is no need to specify different link commands
for shared or static libraries in general.

I tried to compile your proposed test:

#define BOOST_TEST_MODULE boost.m4
#include <boost/test/unit_test.hpp>

BOOST_AUTO_TEST_CASE( MyCase )
{
  BOOST_ERROR( "expected" );
}

Normally (for at least 95% of all libraries) one just adds -l <libname>
to get it compile:

$ g++ test.cpp -lboost_unit_test_framework
/usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/crt1.o: In function `_start':
(.text+0x18): undefined reference to `main'
collect2: ld returned 1 exit status

It works indeed well with
$ g++ -DBOOST_TEST_DYN_LINK test.cpp -lboost_unit_test_framework

Once I remove /usr/lib/libboost_unit_test_framework.so so that only
the static library /usr/lib/libboost_unit_test_framework.a (which is a
symbolic (filesystem) link to
libboost_unit_test_framework-gcc41-1_34_1.a in Debian testing) exists
one can also (normally) just specify -l <libname>. But I get:

$ g++ -DBOOST_TEST_DYN_LINK test.cpp -lboost_unit_test_framework
/tmp/ccKcB2Ps.o: In function `main':
test.cpp:(.text+0x3d4): undefined reference to `boost::unit_test::unit_test_main(bool (*)(), int, char**)'
/usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/libboost_unit_test_framework.a(framework.o): In function `boost::unit_test::framework::init(int, char**)':
(.text+0x6fa): undefined reference to `init_unit_test_suite(int, char**)'
collect2: ld returned 1 exit status

Without -DBOOST_TEST_DYN_LINK
$ g++ test.cpp -lboost_unit_test_framework
it works.

You're right that it is also possible to enforce using the static
library (even if the shared one exists) by using different arguments:
$ g++ test.cpp /usr/lib/libboost_unit_test_framework.a

But in general everyone probably just uses -l <libname> and let's the
compiler decide (which defaults to shared library variant if available).
This normally works even if only one variant of a library is installed
except with Boost.Test.

Jens
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Benoit Sigoure]

On Jan 14, 2008, at 9:31 AM, Jens Seidel wrote:

> $ g++ -DBOOST_TEST_DYN_LINK test.cpp -lboost_unit_test_framework
> /tmp/ccKcB2Ps.o: In function `main':
> test.cpp:(.text+0x3d4): undefined reference to  
> `boost::unit_test::unit_test_main(bool (*)(), int, char**)'
> /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/
> libboost_unit_test_framework.a(framework.o): In function  
> `boost::unit_test::framework::init(int, char**)':
> (.text+0x6fa): undefined reference to `init_unit_test_suite(int,  
> char**)'
> collect2: ld returned 1 exit status

I /worked around/ this issue by always defining a dummy  
init_unit_test_suite symbol (which was an idea and a contribution of  
Hubert Figuiere).  This seems totally wrong to me but "It Gets The  
Job Done".  I'm just sad that I have to write such kludge to satisfy  
the weird need of a library.  Most of the lib I know which need to  
interact directly with `main' require you to invoke a function  
directly from within main. Qt is a great example, you must  
instantiate a QApplication and give it argc and argv.  It's a very  
common idiom.  Yet Boost.Test decided that it was a good idea to  
embed a `main' in a library (!).  What if I want to link with two  
libraries that decided that it was their own right to define `main'?  
Come on, this is almost ridiculous and it seems that Gennadiy is not  
willing to make any effort to understand the problem.

Gennadiy, don't take this remark as an attack against you, I have  
nothing against you, it's just that you don't seem to be inclined to  
understand the issue.

--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Gennadiy Rozental-2]

Jens Seidel <jensseidel <at> users.sf.net> writes:

>
> On Mon, Jan 14, 2008 at 01:16:51AM -0500, Gennadiy Rozental wrote:
> > "Benoit Sigoure" <tsuna <at> lrde.epita.fr> wrote in message
> > news:805924BB-31B0-44E8-88CE-9538D89B082C <at> lrde.epita.fr...
> > > On Jan 12, 2008, at 3:26 AM, Gennadiy Rozental wrote:
> > >
> > >> Benoit Sigoure <tsuna <at> lrde.epita.fr> writes:
> > >>> Thanks for your code.  It grieves me that Boost.Test is the *only*
> > >>> library for which I have to write "special cases" only because it's
> > >>> not "well-behaved".
> > >>
> > >> In what sence? How do you define well behaved?
> > >
> > > What is this whole thread about?  Boost.Test is non standard because
> > > it messes up your `main'
> >
> > Why do you care? how does it make Boost.Test behave badly?
>
> Normally one is able to test for the existence of a library by just
> calling a function inside main() or by creating an instance of a special
> type:

[...]

> Beeing forced to also write
>
> int main(int argc, char* argv[])
> {
>
> }
>
> is just not required for nearly all library tests and error prone. This

You are not required to do above with  Boost.Test. In fact it's plain wrong
for your purposes.


> > > and must be used differently whether you're
> > > linking with it as a shared library or a static archive.
> >
> > As you have seen in my example, it is exactly the same for both usage
> > variants. The only difference is additional macro in makefile. But, than,
> > link command is going to be different anyway.
>
> No, you're wrong. There is no need to specify different link commands
> for shared or static libraries in general.

I disagree. In general you do need to specify what you want to link with. The
fact that your compiler allows some shortcuts and "smart" enough to have some
defaults doesn't make it general.
 

> I tried to compile your proposed test:
>
> #define BOOST_TEST_MODULE boost.m4
> #include <boost/test/unit_test.hpp>
>
> BOOST_AUTO_TEST_CASE( MyCase )
> {
>   BOOST_ERROR( "expected" );
> }
>
> Normally (for at least 95% of all libraries) one just adds -l <libname>
> to get it compile:
>
> $ g++ test.cpp -lboost_unit_test_framework
> /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/crt1.o: In function

`_start':
> (.text+0x18): undefined reference to `main'
> collect2: ld returned 1 exit status

You need to enforce static library here *with link options*.
 
> It works indeed well with
> $ g++ -DBOOST_TEST_DYN_LINK test.cpp -lboost_unit_test_framework

as expected
 
> Once I remove /usr/lib/libboost_unit_test_framework.so so that only
> the static library /usr/lib/libboost_unit_test_framework.a (which is a
> symbolic (filesystem) link to
> libboost_unit_test_framework-gcc41-1_34_1.a in Debian testing) exists
> one can also (normally) just specify -l <libname>. But I get:
>
> $ g++ -DBOOST_TEST_DYN_LINK test.cpp -lboost_unit_test_framework
> /tmp/ccKcB2Ps.o: In function `main':
> test.cpp:(.text+0x3d4): undefined reference to
`boost::unit_test::unit_test_main(bool (*)(),
> int,
> char**)'
> /usr/lib/gcc/i486-linux-
gnu/4.2.3/../../../../lib/libboost_unit_test_framework.a(framework.o):
> In function `boost::unit_test::framework::init(int, char**)':
> (.text+0x6fa): undefined reference to `init_unit_test_suite(int, char**)'
> collect2: ld returned 1 exit status

Why would you expect it to work? You specified dynamic library, but linking
with static.
 
> Without -DBOOST_TEST_DYN_LINK
> $ g++ test.cpp -lboost_unit_test_framework
> it works.

As expected. It would have work from the begininng would you specify -static
(if I am not mistaken) during linking.
 
> You're right that it is also possible to enforce using the static
> library (even if the shared one exists) by using different arguments:
> $ g++ test.cpp /usr/lib/libboost_unit_test_framework.a

You should be able to do it without absilute path to the library.

> But in general everyone probably just uses -l <libname> and let's the
> compiler decide (which defaults to shared library variant if available).
> This normally works even if only one variant of a library is installed
> except with Boost.Test.

The real cause of the problem is that both static and dynamic library have the
same name in *nix. So you need to specify which one you need explicetly. I
hope by now you should understand why static library behaves the way it is.

All you need to work without problem is to stop relying on linker guessing
what library to link with and explicetly specify it (and stop misusing the
library - saying you want dynamic, but supplying static is not gonna work).

Gennadiy

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Gennadiy Rozental-2]

Benoit Sigoure <tsuna <at> lrde.epita.fr> writes:

>
> On Jan 14, 2008, at 9:31 AM, Jens Seidel wrote:
>
> > $ g++ -DBOOST_TEST_DYN_LINK test.cpp -lboost_unit_test_framework
> > /tmp/ccKcB2Ps.o: In function `main':
> > test.cpp:(.text+0x3d4): undefined reference to  
> > `boost::unit_test::unit_test_main(bool (*)(), int, char**)'
> > /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/
> > libboost_unit_test_framework.a(framework.o): In function  
> > `boost::unit_test::framework::init(int, char**)':
> > (.text+0x6fa): undefined reference to `init_unit_test_suite(int,  
> > char**)'
> > collect2: ld returned 1 exit status
>
> I /worked around/ this issue by always defining a dummy  
> init_unit_test_suite symbol (which was an idea and a contribution of  
> Hubert Figuiere).  This seems totally wrong to me but "It Gets The  

It *is* totally wrong.

> Job Done".  I'm just sad that I have to write such kludge to satisfy  
> the weird need of a library.  Most of the lib I know which need to  

You don't. You just misuse the library. Did you try snippets I recommend?

> interact directly with `main' require you to invoke a function  
> directly from within main. Qt is a great example, you must  
> instantiate a QApplication and give it argc and argv.  It's a very  
> common idiom.  Yet Boost.Test decided that it was a good idea to  
> embed a `main' in a library (!).  What if I want to link with two  
> libraries that decided that it was their own right to define `main'?  
> Come on, this is almost ridiculous and it seems that Gennadiy is not  
> willing to make any effort to understand the problem.

I understand perfectly your problem. It seems you are not willing to listen to
the solution I present. You need to understand I am long time in this
buseness. I heard and thought of most possible issues with desing of the
library. This one is pretty old. I believe that though solution I came up with
may not be ideal for all involved, is the best under circomstances.

1. Embedding main into libtary has it's perks. Would you need to implement the
same main() routine 10 times a day for a year, I can imagine you would also
look for some way to avoid it. Avoiding to explain test runner API helps as
well. It shortens learning curve for new users.

2. My primary limitation is to be portable.

3. Starting 1.34 there is a valid simple solution to the situation above: use
shared library and you are good.
 
Gennadiy


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Benoit Sigoure]

On Jan 14, 2008, at 5:35 PM, Gennadiy Rozental wrote:

> Benoit Sigoure <tsuna <at> lrde.epita.fr> writes:
>> interact directly with `main' require you to invoke a function
>> directly from within main. Qt is a great example, you must
>> instantiate a QApplication and give it argc and argv.  It's a very
>> common idiom.  Yet Boost.Test decided that it was a good idea to
>> embed a `main' in a library (!).  What if I want to link with two
>> libraries that decided that it was their own right to define `main'?
>> Come on, this is almost ridiculous and it seems that Gennadiy is not
>> willing to make any effort to understand the problem.
>
> I understand perfectly your problem. It seems you are not willing  
> to listen to
> the solution I present. You need to understand I am long time in this
> buseness. I heard and thought of most possible issues with desing  
> of the
> library. This one is pretty old. I believe that though solution I  
> came up with
> may not be ideal for all involved, is the best under circomstances.
>
> 1. Embedding main into libtary has it's perks. Would you need to  
> implement the
> same main() routine 10 times a day for a year, I can imagine you  
> would also
> look for some way to avoid it. Avoiding to explain test runner API  
> helps as
> well. It shortens learning curve for new users.
>
> 2. My primary limitation is to be portable.
>
> 3. Starting 1.34 there is a valid simple solution to the situation  
> above: use
> shared library and you are good.

Look, you seem to believe that static and dynamic linking ought to be  
totally different.  That's a point on which we disagree.  In modern  
build systems, the user must be able to switch from one to the other  
transparently.  The build system takes care of adjusting the -lflags  
or whatever.  Your library requires extra special steps to make this  
work, it's just annoying.  I still think that embedding `main' in a  
library is wrong, and should I be in your situation of `same main()  
routine for 10 times a day' I'd make my `main' a one liner the way we  
delegate it to a QApplication for instance.

Your method that works for 1.34 is not good for me, I provide a  
*generic* build system tool which ought to work no matter which  
version of Boost you use, no matter which compiler you use, no matter  
whether you want to link dynamically or statically against the library.

I know you surely have good reasons for having done so, nevertheless  
I still think this design goes against "standard" expectations.  And  
once again, if everyone was to reason like you and said "OK let's  
factor `main' in a library" we'd end up with a big mess when trying  
to link with 2+ libraries that define their own `main'...

--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Jens Seidel]

On Fri, Dec 21, 2007 at 03:11:09PM +0100, Jens Seidel wrote:

> On Fri, Dec 21, 2007 at 02:51:40AM -0500, Gennadiy Rozental wrote:
> > Let's  see concrete examples.
>
> Old code was as simple as:
>
> #include <boost/test/unit_test.hpp>
> using boost::unit_test::test_suite;
>
> test_suite* Jacobi_test_suite();
>
> test_suite* init_unit_test_suite(int, char *[])
> {
>   Initialize_logging();
>   test_suite *test = BOOST_TEST_SUITE("Master test suite");
>   test->add(Jacobi_test_suite());
>   return test;
> }
>
> > >> > prefer to define main youself and invoke init function you can do it as
> > >> > well
> > >> > with shared library variant.
> > >
> > > And how?
> >
> > See example 9 on
> >
> > http://www.patmedia.net/~rogeeff/html/utf/user-guide/test-organization/manual-nullary-test-case.html
>
> Right. Thanks! Just changing
>
> test_suite* init_unit_test_suite(int, char *[])
> {
>   Initialize_logging();
>   test_suite *test = BOOST_TEST_SUITE("Master test suite");
>   test->add(Jacobi_test_suite());
>   return test;
> }
>
> into
>
> bool init_unit_test()
> {
>   Initialize_logging();
>   boost::unit_test::framework::master_test_suite().add(Jacobi_test_suite());
>
>   return true;
> }
>
> int main(int argc, char *argv[])
> {
>   return ::boost::unit_test::unit_test_main(&init_unit_test, argc, argv);
> }
>
> works. Please note that one has to read dozens of pages before as this
> is nearly at the end of the documentation.

But it does not work with Boost 1.33.1 in contrast to 1.34.1 as
master_test_suite() returns a const reference.

I switched now to inclusion of boost/test/included/unit_test_framework.hpp
instead of using libraries. Let's see whether it will break soon as well ...
 
Jens
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Jens Seidel]

On Tue, Jan 15, 2008 at 04:58:07PM +0100, Jens Seidel wrote:

> On Fri, Dec 21, 2007 at 03:11:09PM +0100, Jens Seidel wrote:
> > int main(int argc, char *argv[])
> > {
> >   return ::boost::unit_test::unit_test_main(&init_unit_test, argc, argv);
> > }
> >
> > works. Please note that one has to read dozens of pages before as this
> > is nearly at the end of the documentation.
>
> But it does not work with Boost 1.33.1 in contrast to 1.34.1 as
> master_test_suite() returns a const reference.

Oops, I forgot to mention that it even in 1.34.1 crashs if I provide 0
as init function pointer. This forced me during my tests to also define
a dummy function just to make unit_test_main() happy.

I suggest to overload a new function which doesn't take a init function
at all but 0 should also be a valid pointer.
 
> I switched now to inclusion of boost/test/included/unit_test_framework.hpp
> instead of using libraries. Let's see whether it will break soon as well ...

It still works :-))

Jens
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Gennadiy Rozental-2]

Jens Seidel <jensseidel <at> users.sf.net> writes:
> > But it does not work with Boost 1.33.1 in contrast to 1.34.1 as
> > master_test_suite() returns a const reference.

Using "auto" macros you can build version what works with both versions.
 
> Oops, I forgot to mention that it even in 1.34.1 crashs if I provide 0
> as init function pointer. This forced me during my tests to also define
> a dummy function just to make unit_test_main() happy.
>
> I suggest to overload a new function which doesn't take a init function
> at all but 0 should also be a valid pointer.

Ok. I'll consider this.
 
Gennadiy

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost