Re: A simple unit test framework
On May 8, 12:13 am, Branimir Maksimovic <b...@hotmail.com> wrote:
On May 7, 10:42 pm, Gianni Mariani <gi3nos...@mariani.ws> wrote:
James Kanze wrote:
On May 7, 10:55 am, Gianni Mariani <gi3nos...@mariani.ws> wrote:
...
std::string is not thread safe
........
And a well run code review doesn't find just the obvious bugs.
It also finds those which no test will find. (I found the bug
in the g++ implementation of std::string by reviewing the code.)
I don't consider this one a bug. It's expected to fail IMHO.
All the time I want to point out that code with undefined
behavior is expected to do anything. This is first what I have
learned on this newsgroup.
That's actually an important point. Gianni's first example:
void thread1()
{
globalString += 'A' ;
}
void thread2()
{
globalString += 'B' ;
}
entails undefined behavior with STLport, g++ and (I think) VC++,
but is defined using Sun CC (with the Rogue Wave library).
Logically, I would expect it to be undefined behavior, and
consider the behavior of Sun CC an extension (defining undefined
behavior)---I'm fairly sure that this will be the situation in
the next version of the standard.
Now, suppose that you are developping on Sun CC, but the
requirements are that your code be portable. How do you test
this?
Seems that your test code also employs undefined behavior:
I'm not sure myself. I don't know enough about his framework to
say for sure. But there are supicious points.
[tst_string.cpp]/**
* Test std::string.
*
*/
.........
template <int N, int ThreadCount = 3 >
class String_TaskBase
: public at::Task
{
..........
void Work();
};
...........
class HardTask
: public String_TaskBase< 2 >
{
}
..........
HardTask()
{
Start();
}
........
~HardTask()
{
Wait();
}
};
These two are sure sign of possible undefined behavior.
I can bet that Task's start function, passes context
of object into other thread while construction still works
in first one.
I think that HardTask is the most derived class. While
formally, it is true that you cannot use a pointer to the class
until having finished construction, in practice, it's safe to
say that once all subobjects have been constructed and
initialized, as the last thing in the constructor of the most
derived class, it should be safe. (Provided, of course, that
Start() ensures proper synchronization everywhere.)
Since call to member function is made,
no wonder that you can't do this in constructor/destructor
of base class.
Did I miss something? I didn't see any derivation from HardTask.
--
James Kanze (Gabi Software) email: james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34