RE: [Devel] 2.1.0 branch created

[Boris Letocha]

> > 2.) Next is usage of MLib. I think (I am not sure) that 
> usage of longjmp
> > is not as portable as C code without longjmp.
> 
> I do not think so. longjmp did exist since the advent of C in 
> the 70's,
> and even if it was not consistently implemented in the 80's, 
> it is part
> of the ANSI standard and now (remember, ANSI standard is 
> about 15 years
> old now), almost every C implementation does have a 
> reasonable longjmp.
> 
> 
> > Also IMHO if you use longjmp in C++ you will not get C++ 
> stack cleaning.
> 
> This should be tested. I have no information, but if you feel this is
> a problem (where?), it should be investigated.
Directly from MSDN:

Observe the following restrictions when using longjmp: 
- Be careful when using setjmp and longjmp in C++ programs. Because
these functions do not support C++ object semantics, it is safer to use
the C++ exception-handling mechanism. 


I think that David already test this, I want only be sure that if you
implement callback in C++ which will call back MLib code which will
throw exception or clearly state that this is imposible and callbacks
has to be used with caution.

Example:

// Mlib code - very simplified
void MLibAlwaysThrowException()
{
   MLibThrow(???)
}

typedef void (*Callback)();

void MLibCallCallback(Callback aCB)
{
MLibTry // it has different "keyword" but I thig that all you know what
I mean
   {
   (*aCB)();
   }
MLibcatch
   {
   }
}

// C++ code
void CPPCallback()
{
   std::string s="Test";
   MLibAlwaysThrowException();
}

void main()
{
   MLibCallCallback(&CPPCallback);
}

So will be std::string automatically deallocated??? I think no.

> > 3.) And leave it in "plain" C - for us it is no problem, but for you
> > I think it is pain and really lost of time.
> 
> What do you mean?
> 
I am my self too much confident to write in "plain" C. Clearly for me it
would be disaster have to write something in C and not in C++ even such
low level library.
Of course I understand that if someone is good in plain C it is may be
not that hard.

Boris Letocha