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
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
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 jus
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::Referen
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< ...
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 seq
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 preferre
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
> guideli
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
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" wou
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 &quo
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
--
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 hold
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 ma
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() an
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
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 remo
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:
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, t
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
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 s
21 matches
Mail list logo
