Re: Re: [udk-dev] Another question on Clear Separation of C and CPP andCore Componenets.
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. :(
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?
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?
Awaiting for your earliest reply!
May you and your family have a bright Christmas!
Best regards,
Cynthia ^_^
2007-12-10
Welcome to China!
Beijing Redflag CH2000 Software Co., Ltd. China
http://www.redflag2000.com.cn/english/index.htm
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] Another question on Clear Separation of C and CPP andCore Componenets.
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]
[udk-dev] Are you going to discuss about to do it or not?
hi, Stephan,
Thank you very much for your explain! And I got it then. :)
hi, Kay,
As the task whether is a useful todo is somewhat controversial, I am not sure
we are going to do it or not.
http://wiki.services.openoffice.org/wiki/Uno/Todo/Clear_Separation_of_C_and_Cpp_and_Core_Components
If it is not useful to do at present, I think I'd better find another task of
the project to do.
Do you have any suggestion about this? Or what can do I for the project?
Thank you very much for all of your support!
Best regards,
Cynthia ^_^
2007-12-11
Stephan Bergmann wrote;
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]
Welcome to China!
Beijing Redflag CH2000 Software Co., Ltd. China
http://www.redflag2000.com.cn/english/index.htm
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
