Felipe Magno de Almeida
2010-07-29 19:29:16 UTC
Hello,
I see that mico redefines assert macro with something specific. I hope
I'm missing something, but I don't think this should be done, because
it can lead to One Definition Rule violations, which causes undefined
behavior.
For example:
-- a.h --
inline void foo(int x)
{
assert(x != 0);
}
-- a.cpp --
#include "a.h"
void bar()
{
foo(1);
}
-- b.cpp --
#include <CORBA.h>
#include "a.h"
void my_bar()
{
foo(1);
}
-- --
And we have multiple implementations of foo which are different after
preprocessing.
Also, I don't see why mico should have the responsability to address
assert's for code outside its own.
If mico wants to optimize its assertions, it should define a
MICO_ASSERT macro that does whatever it wants it to do.
Regards,
I see that mico redefines assert macro with something specific. I hope
I'm missing something, but I don't think this should be done, because
it can lead to One Definition Rule violations, which causes undefined
behavior.
For example:
-- a.h --
inline void foo(int x)
{
assert(x != 0);
}
-- a.cpp --
#include "a.h"
void bar()
{
foo(1);
}
-- b.cpp --
#include <CORBA.h>
#include "a.h"
void my_bar()
{
foo(1);
}
-- --
And we have multiple implementations of foo which are different after
preprocessing.
Also, I don't see why mico should have the responsability to address
assert's for code outside its own.
If mico wants to optimize its assertions, it should define a
MICO_ASSERT macro that does whatever it wants it to do.
Regards,
--
Felipe Magno de Almeida
Felipe Magno de Almeida