by Michael Goulish on this 11th day of April, 2008
Programmer! Turn back now, if you can, to the daylit world!
But if you must walk this road - take with you this map! Do not stray into the mires and pits where I have wandered and despaired.
Herein I will describe what I can of the perils I have encountered in the antique land of RHEL4.
I believe this is a compiler problem with the -> operator, in the neighborhood of any kind of iterators.
Code like this will not compile:
ConsumerImplMap::iterator i = consumers.find(delivery.getTag());
if (i != consumers.end())
{ get_pointer(i)->acknowledged(delivery); // <--- Bad! }
|
Do this instead:
ConsumerImplMap::iterator i = consumers.find(delivery.getTag());
if (i != consumers.end())
{ (*i).second->complete(delivery); // <--- Good! }
|
( Thanks, Kim! )
Because it Doesn't Exist.
All it does is allow you to use a class (or struct) declaration in many test cases without declaring it in every one.
So what? Big deal! Just declare your structure in each test case, and use the QPID_AUTO_TEST_CASE macro instead!
If you have this struct:
struct ClientSessionFixture : public Foo
{ int bar; }
|
Don't do this:
BOOST_FIXTURE_TEST_CASE(testQueueQuery, ClientSessionFixture)
{ bar = 666; BOOST_CHECK_EQUAL ( bar, 666 ); }
|
Do do this:
QPID_AUTO_TEST_CASE(testQueueQuery)
{ ClientSessionFixture fix; fix.bar = 666; BOOST_CHECK_EQUAL ( fix.bar, 666 ); }
|
(Thanks, Alan!)
If you are tempted to use
BOOST_AUTO_TEST_SUITE, or BOOST_AUTO_TEST_CASE, or BOOST_AUTO_TEST_SUITE_END, |
dont!
Use instead:
QPID_AUTO_TEST_SUITE, or QPID_AUTO_TEST_CASE, or QPID_AUTO_TEST_SUITE_END ! |
They turn into Appropriate Things depending on the version of Boost you are using.
Sometimes the Appropriate Thing is whitespace...
(Thanks, Alan and Kim !)
They don't exist.
/usr/include/boost/iostreams/: No such file or directory |
Instead, use low-level Unix IO, from the Dawn of Time.
open() read() write() |