Cynthia,
regarding the separation of Binary ('C') Uno and C++ Uno, the importance
certainly depends on your goals. And unfortunately especially this item
may require to become ABI or API incompatible, which by now is forbidden.
For Unos acceptance in the FOSS world it actually is quite important to
have clear boundaries between C' and C++, though this actually has only
low importance for Sun currently.
It is for no particular reason that the separation is on top of the Uno
todos list, but for coincidence only.
I plan to rework the todos list soon and to add priorities, to make
navigation and selection easier.
Hope that helps
Kay
Cynthia Qu wrote:
> 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]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
