Cynthia Qu wrote:
hi,Stephan,
Happy holiday season! And thank you very much for your reply! :-)
Stephan Bergmann wrote;
First and foremost (even though you probably will not like to hear
that), I personally think the "Clear Separation of C and Cpp and Core
Components" thing is nothing we should waste our time with. (I know,
Kay Ramme thinks differently, hence he put that on the todo list.) Too
much potential to break existing client code, with only very little
(IMO) to gain.
Yes? I thought anything put on "to do list" is need to do. But I am not sure if
it is assigned to me or not. And I am confussed about I need to keep on doing it or not.
:(
I cannot really give you advice on this. As I said, whether or not this
is a useful todo is somewhat controversial. (Sorry, I could have
raised my concerns earlier in this thread; if I remember correctly I did
bring this up in discussion with Xiuzhi a while ago, though.)
3.I don't understand what has done in the fuction "_defaultConstructUnion" :
****************
inline void _defaultConstructUnion(
void * pMem,
typelib_TypeDescription * pTypeDescr )
SAL_THROW( () )
{
::uno_type_constructData(
(char *)pMem + ((typelib_UnionTypeDescription
*)pTypeDescr)->nValueOffset,
((typelib_UnionTypeDescription *)pTypeDescr)->pDefaultTypeRef );
*(sal_Int64 *)pMem = ((typelib_UnionTypeDescription
*)pTypeDescr)->nDefaultDiscriminant;
}
*******************
At some places in the UNO code, there is provision for a union (aka sum)
data type construct, which obviously was planned for at the beginning of
UNO, but never implemented completely nor removed completely.
I am sorry, I am not sure what you mean about "aka sum". Is it "also known as sum"? Why can't I
find out "sum" key word in "cppu" module? Am I misunderstand?
Sorry, that probably confused more than it clarified: In some circles,
"union" data types are called "sum" data types (google for "algebraic
type systems" for further details).
4.Can I just move out the code "class Enterable" in cppu/inc/cppu/Enterable.hxx and put it into a
file in cppuhelper/inc/Enterable.hxx (new created in this folder), but keep the other "extern
"C" inline" stuff without moving?
No. At compile time, client code expects #include "cppu/Enterable.hxx"
to define class cppu::Enterable. We have a policy in place to not break
(legal) client code, neither at compile time nor at runtime.
I am sorry. What does the "client code" refer to ? And as the "extern "C" " stuffs are
compiled with C compiler(I thought), then it should offer C APIs, why is it dependent on C++ at runtime ? How to know
the "policy" you refered above, could you give me some reference or explain? And do you know how to make
dependency against C++ is only at compile time to use the C++ compiler, but nothing at runtime?
"Client code" is any code external to the URE that uses the URE.
I am not sure we have our compatibility policy written down somewhere
explicitly, but the idea is simple: Do not change the URE's published
interface in any way that makes existing, legal (i.e., only relying on
the published interface) code fail, either at compile or a runtime.
Awaiting for your earliest reply!
May you and your family have a bright Christmas!
Have a nice time, too.
-Stephan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
