Re: [dev] rtl::Reference vs. [com::sun::star::]uno::References
Ollie,
sorry for not replying earlier.
Oliver Braun wrote:
Kay Ramme - Sun Germany - Hamburg wrote:
Some of the reasons for the namespace problems we are facing are IMHO
simply non optimal placings, e.g. "com::sun::uno::Reference" would
have belonged into "cppu" ("cppu::Reference" or may be simply
"uno::Reference". As probably most people agree with, the whole
"com::sun::star" namespace became obsolete when open sourcing
StarOffice and should have been renamed to "OOo" (or similar), and I
am sure there are more aspects one currently would like to see being
reflected in the namespaces, but ... we want to stay API and ABI
compatible, more or less rendering these thoughts useless ;-)
What about new interfaces / services ? Would it be feasible to create
"uno::" aliases for "com::sun::star::uno::" and "com::sun::star::lang"
and start using org::openoffice namespace for new interface/service
definitions ?
In general I think it would be feasible, but please see below ...
Or even better, move the basic types to ::uno and make aliases for those
in the old namespace(s) ?!
To preserve API (build) compatibility, right?
Other aliases (e.g. for beans etc.) might need to get added over time,
but at least we could start the transition.
I take the opportunity to comment on compatibility ;-) though we are
going to have a BOF at the OOo Conf 2007 regarding this topic, lead by
Juergen.
Wikipedia differentiates between forward and backward compatibility
(http://en.wikipedia.org/wiki/Computer_compatibility), the compatibility
we are here talking about is backward compatibility.
There are two types of compatibility,
- ABI (Application Binary Interface) compatibility - meaning that a
program compiled for one binary environment is able to run on another
binary environment, as long as these environments are binary (or ABI)
compatible.
- API (Application Programming Interface) compatibility - meaning that
the source code of a program compilable for one API environment may be
compiled for another API environment (without change) as long as these
environments are API compatible.
ABI compatibility is in general harder to achieve (you must know the
very detail regarding how parameters are passed, how symbols are mangled
etc. etc.) and offers less opportunity for improvement (e.g. you can not
change a function from being outline to inline). ABI compatibility is
what proprietary software vendors classical provide / require through
their lines of operating systems, applications etc.
API compatibility is superior wrt optimization, simplification,
flexibility etc., but requires the source code to be recompiled. API
compatibility is what most / many open source products provide only,
leading to the situation that it is some times hard for commercial
(without the source) vendors to provide binary (ABI compatibility
requiring) products e.g. for different Linux distributions. This is what
the LSB (Linux Standards Base) deals with.
Compatibility in general is about the "cost of adaption". Staying
compatible reduces the cost of ISVs etc. to adapt their products to
later environments, while it increases the costs of the environment
provider, as he/she explicitly needs to take steps to preserve backward
compatibility.
With OOo we currently provide ABI and API compatibility. The compatible
interfaces OOo offers are AFAIK:
- Various Uno language bindings
- Binary Uno
- C++ Uno
- Java Uno
- CLI Uno
- Python Uno
- Remote Uno
- ...
- OOo BASIC
- OOo API
- Configuration Items
- Some deployment parameters (e.g. "UserInstallation")
(http://wiki.services.openoffice.org/wiki/Uno/Binary/Spec/Bootstrapping)
- Other: Document compatibility (e.g. ODF, .DOC), ...
As we stay compatible on all these interfaces, we carry the costs of
doing so, allowing ISVs and others to reduce their costs of adaption to
a minimum. At least until now we thought this to be necessary, to get
new ISVs interested and to keep already supporting ISVs
Unfortunately it seems, and this is actually the reason for my long
comment, that staying backwards compatible hinders us to clean up stuff,
which really deserves it ...
From a theoretical standpoint, compatibility could be ensured by
leaving old things alone (may be after a reasonable life time) and only
introducing new stuff, though in practice this seems to be unreasonable.
Taking a look at Mozilla, it seems that they become incompatible once a
while, at least with every major version (please correct if am wrong),
and that this seems to acceptable for ISVs etc. The Linux kernel seems
to become incompatible as so often, only keeping the system call
interface stable, once a while leading to problems with binary only
drivers e.g. from NVidia or ATI.
So, the questions is, would it be acceptable for our ISVs etc. that we
become incompatible e.g. with every major? That would give us the
opportunity to clean up things (fix the namespaces), may be
Re: [dev] rtl::Reference vs. [com::sun::star::]uno::References
Kay Ramme - Sun Germany - Hamburg wrote:
Some of the reasons for the namespace problems we are facing are IMHO
simply non optimal placings, e.g. "com::sun::uno::Reference" would have
belonged into "cppu" ("cppu::Reference" or may be simply
"uno::Reference". As probably most people agree with, the whole
"com::sun::star" namespace became obsolete when open sourcing StarOffice
and should have been renamed to "OOo" (or similar), and I am sure there
are more aspects one currently would like to see being reflected in the
namespaces, but ... we want to stay API and ABI compatible, more or less
rendering these thoughts useless ;-)
What about new interfaces / services ? Would it be feasible to create "uno::"
aliases for "com::sun::star::uno::" and "com::sun::star::lang" and start using
org::openoffice namespace for new interface/service definitions ?
Or even better, move the basic types to ::uno and make aliases for those in the
old namespace(s) ?!
Other aliases (e.g. for beans etc.) might need to get added over time, but at
least we could start the transition.
Just my 2 cents,
Oliver
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] rtl::Reference vs. [com::sun::star::]uno::References
Ok, for the nitpickers:
Something* pS = NULL;
css::uno::Reference x( ps = new Something() );
pS->privateNonUnoFunction();
;-)
Kind regards, pl
Stephan Bergmann wrote:
Philipp Lohmann wrote:
Hi,
regarding that example I would normally do
Something* pS = new Something();
css::uno::Reference x( pS );
pS->privateNonUnoFunction();
I would consider the approach I showed below more robust (code that can
throw slipping in between the first two lines, someone removing the
second line out of ignorance, ...).
-Stephan
class Something: public cppu::WeakImplHelper1 { ... };
rtl::Reference s(new Something);
s->privateNonUnoFunction();
css::uno::Reference x(s.get());
etc.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
If you give someone a program, you will frustrate them for a day;
if you teach them how to program, you will frustrate them for a lifetime.
-- Author unknown
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] rtl::Reference vs. [com::sun::star::]uno::References
In message "Re: [dev] rtl::Reference vs. [com::sun::star::]uno::References",
Stephan Bergmann wrote...
>Philipp Lohmann wrote:
>> Hi,
>>
>> regarding that example I would normally do
>>
>> Something* pS = new Something();
>> css::uno::Reference x( pS );
>> pS->privateNonUnoFunction();
>
>I would consider the approach I showed below more robust (code that can
>throw slipping in between the first two lines, someone removing the
>second line out of ignorance, ...).
+1
I think it is easier to make it guarantee exception handling.
>
>-Stephan
>
>>> class Something: public cppu::WeakImplHelper1 { ... };
>>> rtl::Reference s(new Something);
>>> s->privateNonUnoFunction();
>>> css::uno::Reference x(s.get());
>>>
>>> etc.
>
>-
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
Takashi Ono(HK Freak)
mailto:[EMAIL PROTECTED] or [EMAIL PROTECTED]
(Personal Address, checked every morning/evening and holidays)
mailto:[EMAIL PROTECTED]
(Address for business, checked every working days)
http://www.hkfreak.net
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] rtl::Reference vs. [com::sun::star::]uno::References
Philipp Lohmann wrote:
Hi,
regarding that example I would normally do
Something* pS = new Something();
css::uno::Reference x( pS );
pS->privateNonUnoFunction();
I would consider the approach I showed below more robust (code that can
throw slipping in between the first two lines, someone removing the
second line out of ignorance, ...).
-Stephan
class Something: public cppu::WeakImplHelper1 { ... };
rtl::Reference s(new Something);
s->privateNonUnoFunction();
css::uno::Reference x(s.get());
etc.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] rtl::Reference vs. [com::sun::star::]uno::References
Hi,
regarding that example I would normally do
Something* pS = new Something();
css::uno::Reference x( pS );
pS->privateNonUnoFunction();
Even if privateNonUnoFunction does somehow influence the refcount of the
object this has kept the reference.
However you explained the difference between boost::shared_ptr and
rtl::Reference very well.
Kind regrads, pl
Stephan Bergmann wrote:
Philipp Lohmann wrote:
Hi,
just as a side note: which added value does rtl::Reference provide
over boost::shared_ptr anyway ?
rtl::Reference requirs T to have acquire() and release(), whereas
boost::shared_ptr manages the refcount externally . That makes
rtl::Reference a good fit when holding references to C++ implementations
of UNO objects:
class Something: public cppu::WeakImplHelper1 { ... };
rtl::Reference s(new Something);
s->privateNonUnoFunction();
css::uno::Reference x(s.get());
etc.
--
If you give someone a program, you will frustrate them for a day;
if you teach them how to program, you will frustrate them for a lifetime.
-- Author unknown
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] rtl::Reference vs. [com::sun::star::]uno::References
Hubert Figuiere <[EMAIL PROTECTED]> writes: > On Wed, 2007-07-11 at 18:22 +0200, Stephan Bergmann wrote: > > Philipp Lohmann wrote: > > > just as a side note: which added value does rtl::Reference provide over > > > boost::shared_ptr anyway ? > > > > rtl::Reference requirs T to have acquire() and release(), whereas > > boost::shared_ptr manages the refcount externally . That makes > > rtl::Reference a good fit when holding references to C++ implementations > > of UNO objects: > > You mean like boost::intrusive_ptr<> ? (but with a different interface) > Exactly. Mixing shared_ptr and uno::Reference is safely possible on the same object, but I do find the rtl::Reference solution cleaner. Saves on heap space, on top of that. Cheers, -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] rtl::Reference vs. [com::sun::star::]uno::References
On Wed, 2007-07-11 at 18:22 +0200, Stephan Bergmann wrote: > Philipp Lohmann wrote: > > Hi, > > > > just as a side note: which added value does rtl::Reference provide over > > boost::shared_ptr anyway ? > > rtl::Reference requirs T to have acquire() and release(), whereas > boost::shared_ptr manages the refcount externally . That makes > rtl::Reference a good fit when holding references to C++ implementations > of UNO objects: You mean like boost::intrusive_ptr<> ? (but with a different interface) Hub - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] rtl::Reference vs. [com::sun::star::]uno::References
Philipp Lohmann wrote:
Hi,
just as a side note: which added value does rtl::Reference provide over
boost::shared_ptr anyway ?
rtl::Reference requirs T to have acquire() and release(), whereas
boost::shared_ptr manages the refcount externally . That makes
rtl::Reference a good fit when holding references to C++ implementations
of UNO objects:
class Something: public cppu::WeakImplHelper1 { ... };
rtl::Reference s(new Something);
s->privateNonUnoFunction();
css::uno::Reference x(s.get());
etc.
-Stephan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] rtl::Reference vs. [com::sun::star::]uno::References
Hi, just as a side note: which added value does rtl::Reference provide over boost::shared_ptr anyway ? Kind regards, pl -- If you give someone a program, you will frustrate them for a day; if you teach them how to program, you will frustrate them for a lifetime. -- Author unknown - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] rtl::Reference vs. [com::sun::star::]uno::References
In message "Re: [dev] rtl::Reference vs. [com::sun::star::]uno::References", Andreas_Schl・s wrote... > From my point of view there can be one "general rule" only: >prevent using of "incomplete" namespace declarations. >Means: >- do not use "using namespace ::rtl" >- use intsead "using namespace ::rtl::OUString" >- or use namespaces explicit in your code as e.g. >"::rtl::OUString sTest;" +1 IMHO using directives are too much dangerous. As they are used in many source codes, getting rid of them may not be realistic. But when we have to introduce names in a new namespace in a source code, I think we should rely on using declarations only. Takashi Ono(HK Freak) mailto:[EMAIL PROTECTED] or [EMAIL PROTECTED] (Personal Address, checked every morning/evening and holidays) mailto:[EMAIL PROTECTED] (Address for business, checked every working days) http://www.hkfreak.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] rtl::Reference vs. [com::sun::star::]uno::References
Guys,
my originally mail was not meant to press anybody into any corset, but
just to solve the noticed problems regarding the usage of using "using
rtl;" :-)
Some of the reasons for the namespace problems we are facing are IMHO
simply non optimal placings, e.g. "com::sun::uno::Reference" would have
belonged into "cppu" ("cppu::Reference" or may be simply
"uno::Reference". As probably most people agree with, the whole
"com::sun::star" namespace became obsolete when open sourcing StarOffice
and should have been renamed to "OOo" (or similar), and I am sure
there are more aspects one currently would like to see being reflected
in the namespaces, but ... we want to stay API and ABI compatible, more
or less rendering these thoughts useless ;-)
Personally I tend to use aliases as Andreas does, e.g. "css" for
"com::sun::star" respectively "cssu" for "com::sun::star::uno".
Regards
Kay
Andreas Schlüns wrote:
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] rtl::Reference vs. [com::sun::star::]uno::References
Mathias Bauer <[EMAIL PROTECTED]> writes: > Honestly speaking I doubt that the three letters "rtl" are worth a > "using" declaration at all. I always prefer to use the fully qualified > names. In conjunction with "using namespace com::sun::star" as the only > "using" directive in my files I never get any clashes and OTOH get a > manageable namespace overhead in my source code. > Seconded. Because namespaces are there for a reason (except ::com::sun::star, which does not convey any useful information, and which I'd therefore really like to have aliased to css in one of the commonly used headers). Cheers, -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] rtl::Reference vs. [com::sun::star::]uno::References
Frank Schönheit - Sun Microsystems Germany <[EMAIL PROTECTED]> writes: > As a related note, I sometimes got the impression (I never was able to > track this to the root cause) that there must be headers involved which > contain a "using namespace ...". I suggest we add this to our coding > guidelines: Don't use "using namespace" in (exported?) header files. > Well - http://wiki.services.openoffice.org/wiki/Cpp_Coding_Standards/HEADERS notes exactly that ;-) Cheers, -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] rtl::Reference vs. [com::sun::star::]uno::References
Hi Frank, Hi Andreas, why not preventing "using namespace" in general As a general rule? No, I wouldn't like to impose this on everybody, this is an unnecessary restriction, IMO. As a personal habit? Well, why not. It was not realy thought as "general rule" .-) And yes ... it's my preferred solution so you are right with "personal habit". From my point of view there can be one "general rule" only: prevent using of "incomplete" namespace declarations. Means: - do not use "using namespace ::rtl" - use intsead "using namespace ::rtl::OUString" - or use namespaces explicit in your code as e.g. "::rtl::OUString sTest;" and using namespace alias instead ... ... Personally, my preferred solution is a sequence of using ::com::sun::star::foo::XBar; statements. With the proper IDE (i.e. *not* the Visual C++ /Express Edition/), it's a matter of a single keystroke to insert such a declaration automatically ... Why not go the next step and make the same then NetBeans it does ... There you have an item within the context menu named "Fix Imports ..." which does what it means. It actualize your list of imports; add new missing ones and remove(!) obsolete ones. But tell me an usable C++ IDE providing the same ... which works within our environment with thousands of unknown possible header files .-) Ciao Frank Ciao Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] rtl::Reference vs. [com::sun::star::]uno::References
Hi Andreas, > why not preventing "using namespace" in general As a general rule? No, I wouldn't like to impose this on everybody, this is an unnecessary restriction, IMO. As a personal habit? Well, why not. > and using namespace alias instead ... > ... Personally, my preferred solution is a sequence of using ::com::sun::star::foo::XBar; statements. With the proper IDE (i.e. *not* the Visual C++ /Express Edition/), it's a matter of a single keystroke to insert such a declaration automatically ... Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] rtl::Reference vs. [com::sun::star::]uno::References
Hello,
why not preventing "using namespace" in general and using
namespace alias instead ...
E.g.
#include
#include
#include
namespace css = ::com::sun::star;
void test()
{
css::uno::Reference< css::uno::XInterface > xFoo;
::rtl::OUString sFoo;
::rtl::Reference< ... > rFoo;
}
Btw; this can be used even in exported header files.
The trick ...
// Place ALL(!) includes here
#include ...
#include ...
// Define CSS after all includes was done so this wont influence
// other files.
#ifdef css
#error "Clash on using namespace alias."
#else
#define css ::com::sun::star
#endif
// Place your code here ...
// Make sure that following header files dont see these define.
#undef css
Regards
Andreas
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] rtl::Reference vs. [com::sun::star::]uno::References
Kay Ramme - Sun Germany - Hamburg wrote: > Hi developers, > > Ause made me recently aware of the fact, that ambiguities regarding the > RTL Reference type (sal/inc/rtl/ref.hxx - rtl::Reference) and the Uno > Reference type (cppu/inc/com/sun/star/uno/Reference.h - > com::sun::star::uno::Reference) are showing up more frequently, because > of some (don't know yet which) changed headers now including the RTL > Reference, precompiled headers (I actually have to admit, that I don't > know the exact relationship yet) and multiple "using" declarations. > > E.g. > #include "myheader.hxx" > > using rtl; > using com::sun::star::uno; > > ... > > Reference xBla; > > ... > > did compile as long as myheader.hxx did not include (neither directly > nor indirectly) rtl/ref.hxx . Somehow adding rtl/ref.hxx now leads to > ambiguities because of the unclear usage of "Reference". > > I briefly talked to Malte, Matthias Huetsch and Michael Brauer about > this, and we found various possible solutions leading to disambiguate > resolution, from which we favored the following. > > We assume, that people using "using rtl;" mostly intend to use the RTL > string and string buffer classes. Therefor we suggest to just be a > little bit more precise regarding the things being "usable" from the RTL > namespace, by making the "using rtl;" somewhat more precise: > > using rtl::OUString; > using rtl::OUStringBuffer; > > respectively everything else :-) Honestly speaking I doubt that the three letters "rtl" are worth a "using" declaration at all. I always prefer to use the fully qualified names. In conjunction with "using namespace com::sun::star" as the only "using" directive in my files I never get any clashes and OTOH get a manageable namespace overhead in my source code. Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "[EMAIL PROTECTED]". I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] rtl::Reference vs. [com::sun::star::]uno::References
Hi Kay, > We assume, that people using "using rtl;" mostly intend to use the RTL > string That's my experience, too. Whenever I stumbled upon the problem you described, replacing "using namespace rtl" with "using ::rtl::OUString" fixed it. > and string buffer classes. Therefor we suggest to just be a > little bit more precise regarding the things being "usable" from the RTL > namespace, by making the "using rtl;" somewhat more precise: > > using rtl::OUString; > using rtl::OUStringBuffer; +1 As a related note, I sometimes got the impression (I never was able to track this to the root cause) that there must be headers involved which contain a "using namespace ...". I suggest we add this to our coding guidelines: Don't use "using namespace" in (exported?) header files. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
