hi,Kay,
Thank you very much for your reply, I got it then!
I also wonder whether the project is going on or not. Why can't I see many
discussions in this maillist? Don't the other guys have any questions? Or
doesn't the UDK project have many things to do? I also want to know what you
are going to do on the project. And may I ask what you are doing now?
Awaiting for your reply! And thank you very much for your time!
Best regards,
Cynthia ^_^
2007-12-12
Kay Ramme - Sun Germany - Hamburg wrote;
>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]
----------------
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]
