Hello Yan Wu ,

Hello Andreas,

I want to change the code:
String SvtUserOptions_Impl::GetFirstName() const
{
        ::rtl::OUString sFirstName;
        try
        {
            m_xData->getPropertyValue(s_sgivenname) >>= sFirstName;
        }
        catch ( const css::uno::Exception& ex)
        {
            LogHelper::logIt(ex);
        }
        return String(sFirstName);
}

TO:
const String& SvtUserOptions_Impl::GetFirstName() /*const*/
{
    ::rtl::OUString sFirstName;
    try
    {
        m_xData->getPropertyValue(s_sgivenname) >>= sFirstName;
    }
    catch ( const css::uno::Exception& ex )
    {
        LogHelper::logIt(ex);
    }
m_aUserString = String( sFirstName); //m_aUserString is defined in the SvtUserOptions_Impl
    return  m_aUserString;
}

So the other similar code will be like:
const String& SvtUserOptions_Impl::GetLastName() /*const*/
{
    ::rtl::OUString sLastName;
    try
    {
        m_xData->getPropertyValue(s_ssn) >>= sLastName;
    }
    catch ( const css::uno::Exception& ex)
    {
        LogHelper::logIt(ex);
    }
    m_aUserString = String( sLastName );
    return  m_aUserString;
}
...

If changes like above, there will be no necessary to change the define of Class SvtUserOptions.
How do you think of above changes comparing the incompatible changes?

No - you shouldnt use "const String&" as return value ever.
It's never a good idea to return a reference to an internal member or variable. You cant make sure that those variable will live for the same time then it's used outside.

BTW: Returning a string by value isnt a performance problem (as you might think) ... because our string classes uses a ref count mechanism. So the internal buffer will be shared between different string variables referring the same content ... till you change one instance. Then a new buffer will be created automaticly.

So please use "String SvtUserOptions::GetXXX() const" for all methods you will find, where "const String& Svt.." was used before. It's no problem doing so ... it's an incompatible change (right) ... but it's an important refactoring to make OOo more stable.

Regards
Yan Wu

Regards
Andreas

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to