unit testing with boost

[Andrea Crotti]

I finally managed to change my build system (with autoconf) and now I
can even use boost auto-magically.

Now I understand also why using the single header is not the only choice
http://www.boost.org/doc/libs/1_44_...ide/usage-variants/single-header-variant.html
it's terribly slower...

But I can't get running the other version, no matter what I do.
I used boost.m4 from
https://github.com/tsuna/boost.m4

but it can't find the library in any way...
In the end this command is executed
/bin/sh ./libtool --tag=CXX --mode=link g++ -g -O2 -lboost_unit_test_framework-mt -o mobpad mobpad-test.o libwifi-fw.la
libtool: link: g++ -g -O2 -o .libs/mobpad mobpad-test.o -Wl,-bind_at_load -lboost_unit_test_framework-mt ./.libs/libwifi-fw.dylib
ld: library not found for -lboost_unit_test_framework-mt

what I see missing is "-L/opt/local/lib" but following the guide in the
Makefile.am I have

bin_PROGRAMS = mobpad
mobpad_SOURCES = test.cpp
mobpad_LDADD = $(lib_LTLIBRARIES)
mobpad_LIBS = $(BOOST_UNIT_TEST_FRAMEWORK_LIBS)
mobpad_LDFLAGS = $(BOOST_UNIT_TEST_FRAMEWORK_LIBS)
mobpad_CPPFLAGS = $(BOOST_CPPFLAGS)

whish should be all I need... Is there anything else??

And another problem.
I have a "class Stream".
which I'm very happy to know that also BOOST uses!

test.cpp:34: error: redefinition of ‘struct Stream’
Stream.hpp:13: error: previous definition of ‘struct Stream

Shouln't it use its own namespace?
I'm using the simple version

#define BOOL_TEST_MAIN 1
#define BOOST_TEST_MODULE MobPad

#include <boost/test/included/unit_test.hpp>

which maybe has some drawbacks...

 

[Andrea Crotti]

I finally managed to change my build system (with autoconf) and now I
can even use boost auto-magically.

Now I understand also why using the single header is not the only choice
http://www.boost.org/doc/libs/1_44_...ide/usage-variants/single-header-variant.html
it's terribly slower...

But I can't get running the other version, no matter what I do.
I used boost.m4 from
https://github.com/tsuna/boost.m4

but it can't find the library in any way...
In the end this command is executed
/bin/sh ./libtool --tag=CXX --mode=link g++ -g -O2 -lboost_unit_test_framework-mt -o mobpad mobpad-test.o libwifi-fw.la
libtool: link: g++ -g -O2 -o .libs/mobpad mobpad-test.o -Wl,-bind_at_load -lboost_unit_test_framework-mt ./.libs/libwifi-fw.dylib
ld: library not found for -lboost_unit_test_framework-mt

what I see missing is "-L/opt/local/lib" but following the guide in the
Makefile.am I have

bin_PROGRAMS = mobpad
mobpad_SOURCES = test.cpp
mobpad_LDADD = $(lib_LTLIBRARIES)
mobpad_LIBS = $(BOOST_UNIT_TEST_FRAMEWORK_LIBS)
mobpad_LDFLAGS = $(BOOST_UNIT_TEST_FRAMEWORK_LIBS)
mobpad_CPPFLAGS = $(BOOST_CPPFLAGS)

whish should be all I need... Is there anything else??

And another problem.
I have a "class Stream".
which I'm very happy to know that also BOOST uses!

test.cpp:34: error: redefinition of ‘struct Stream’
Stream.hpp:13: error: previous definition of ‘struct Stream

Shouln't it use its own namespace?
I'm using the simple version

#define BOOL_TEST_MAIN 1
#define BOOST_TEST_MODULE MobPad

#include <boost/test/included/unit_test.hpp>

which maybe has some drawbacks...

That's the situation with a quite fast machine adding one line in
test.cpp.
(the library linked not touched)

ip1-201:mob_pad andrea$ time make
make all-am
g++ -DHAVE_CONFIG_H -I. -I/opt/local/include -g -O2 -MT mobpad-test.o -MD -MP -MF .deps/mobpad-test.Tpo -c -o mobpad-test.o `test -f 'test.cpp' || echo './'`test.cpp
mv -f .deps/mobpad-test.Tpo .deps/mobpad-test.Po
/bin/sh ./libtool --tag=CXX --mode=link g++ -g -O2 -o mobpad mobpad-test.o libwifi-fw.la
libtool: link: g++ -g -O2 -o .libs/mobpad mobpad-test.o -Wl,-bind_at_load ./.libs/libwifi-fw.dylib

real 0m26.467s
user 0m23.611s
sys 0m1.471s

not really fast...
But the namespace problem is more important at the moment...

 

[Andrea Crotti]

That's the situation with a quite fast machine adding one line in
test.cpp.
(the library linked not touched)

ip1-201:mob_pad andrea$ time make
make all-am
g++ -DHAVE_CONFIG_H -I. -I/opt/local/include -g -O2 -MT mobpad-test.o -MD -MP -MF .deps/mobpad-test.Tpo -c -o mobpad-test.o `test -f 'test.cpp' || echo './'`test.cpp
mv -f .deps/mobpad-test.Tpo .deps/mobpad-test.Po
/bin/sh ./libtool --tag=CXX --mode=link g++ -g -O2 -o mobpad mobpad-test.o libwifi-fw.la
libtool: link: g++ -g -O2 -o .libs/mobpad mobpad-test.o -Wl,-bind_at_load ./.libs/libwifi-fw.dylib

real 0m26.467s
user 0m23.611s
sys 0m1.471s

not really fast...
But the namespace problem is more important at the moment...

Reading on stackoverflow I learnt many nice things about namespace, so
with an Emacs macro, I added to all my .hpp file

namespace MYPROG {

//code
}

and removed also from all the .hpp files the "using namespace std"

Now I guess I have to add
"using namespace MYPROG" to all the .cpp files, right?
But is that enough?
In the headers they should "see" each other already since they're in the
same namespace, correct?

And what if I still have to import the "Stream" in the testing code that
uses boost, do I fall again in the same problem??

 

[Andrea Crotti]

Nope, you should enclose the contents of .cpp files (except #include
lines) in the namespace in the same way as the headers are. And I hope
you do not use all-caps for real names, such are commonly used only for
macros.

The reason why "using namespace ..." would not work is that local classes
and functions defined only in the .cpp file would not be enclosed in the
namespace. Also defining free functions and global (namespace scope)
variables would become more cumbersome and lead to strange linker errors
(global variables are doomed anyway, but still...).

Ok good thanks, now the funny thing is that I'm trying to get the same
"error" with small examples but no way, I never get a clash with that
Stream in boost (which should be boost::Stream)

#define BOOL_TEST_MAIN 1
#define BOOST_TEST_MODULE MobPad

#include <boost/test/included/unit_test.hpp>

#include <iostream>
#include "ns1.hpp"

int fun() { return glob; }
Stream::Stream() {}

BOOST_AUTO_TEST_CASE( stupid )
{
Stream st;
BOOST_CHECK(false);
}


using namespace std;
int glob = 10;
int fun();
class Stream
{
public:
Stream();
};

I even do everything it should not be done but it compiles without
problems.
Anyway I will use a namespace now, it just take some time to modify
everything..

You don't have to "import" anything, in case of conflicts you just use
boost::Stream. Actually I would suggest to use this form always for more
clarity.

hth
Paavo

Yes the thing is that I don't know why it conflicts in my case, the only
thing that could cause this would be (I think) a "using namespace
boost", but it's not the case...

 

[Andrea Crotti]

Yes the thing is that I don't know why it conflicts in my case, the only
thing that could cause this would be (I think) a "using namespace
boost", but it's not the case...

Argh I got it, THIS was making the compiler go nuts

BOOST_AUTO_TEST_CASE( Stream )

Also without namespaces it works perfectly, but that thing it really
didn't like it, who knows why?

 

[Andrea Crotti]

Argh I got it, THIS was making the compiler go nuts

BOOST_AUTO_TEST_CASE( Stream )

Also without namespaces it works perfectly, but that thing it really
didn't like it, who knows why?

Now the last question is why it can't also compile against the library
without including the gigantic header every time..
Isn't that correct (using boost.m4)?

# only the testing program actually uses boost!
bin_PROGRAMS = mobpad
mobpad_SOURCES = test.cpp
# another option is to add the unit_test_framework here
mobpad_LDADD = $(lib_LTLIBRARIES)
mobpad_CPPFLAGS = $(BOOST_CPPFLAGS)
# add also those when also compiling against the library
mobpad_LIBS = $(BOOST_UNIT_TEST_FRAMEWORK_LIBS)
mobpad_LDFLAGS = $(BOOST_UNIT_TEST_FRAMEWORK_LIBS)

I don't define a main but as they say on the doc this should be enough
(before including the header)

#define BOOL_TEST_MAIN 1
#define BOOST_TEST_MODULE MobPad

 

[Andrea Crotti]

Sorry, I have never used boost unit tests myself. Maybe you should ask in
a boost forum? In general, for using a library you must include its
headers however gigantic they are.

Cheers
Paavo

Yes sure you're right, but there are different ways to use unit_test
http://www.boost.org/doc/libs/1_44_0/libs/test/doc/html/utf/user-guide/usage-variants.html

and actually I think they provide also the header + library linking
because using only the header gets quite slow..

Anyway in general I knew that C++ compilers were slow but I never
thought so slow...