[sldev] Uses of LLString and std::string ?

[Richard Nelson]

Keep in mind that LLString derives from std::string and can be used  
anywhere a std::string is.  But, as Steve notes, you can't arbitrarily  
convert a reference to a std::string to a reference to a LLString, so any  
conversion back to LLString will involve a copy.

Before any C++ purists complain, let me note that std::string does not  
have a virtual destructor and hence we can never add any member variables  
or implement a non-trivial destructor in LLString.  It serves merely as a  
convenient wrapper for std::string that tests for the null char* case, as  
Steve mentioned, and provides some handy functions (e.g. case-insensitive  
string comparison) that would otherwise require boilerplate code.

Note that all of the custom functions are implemented as statics, and not  
member functions.  This is to support the ultimate goal of having LLString  
simply be a namespace for string helper functions that operate on  
std::strings.

R.

On Wed, 23 Jan 2008 08:52:22 -0800, Steve Linden <steve at lindenlab.com>  
wrote:

> Correct, LLString exists specifically to protect against passing a NULL  
> char* to a function that takes a const std::string&. C++ will quietly  
> attempt to convert the NULL char* into a std::string causing a crash.
>
> e.g.
>
> foo (const std::string& s)
> {
> }
> bar (const char* c)
> {
>     foo(c); // crashes if c is NULL
> }
> main()
> {
>     const char* s = fetchSomeString(); // returns NULL if it fails
>     foo(s); // crash!
> }
>
> Note: we -still- have thousands of char arrays and char*'s in the code,  
> and this pattern exists all over the place, especially in the UI code.  
> We are actively working on eliminating this pattern. Once we do, we can  
> safely replace LLString with std::string.
>
> Because of the expense of converting a std::string to a LLString, we try  
> to use LLString anywhere we will pass it as a std::string. However, in  
> the grand scheme of things this is unlikely to be a significant  
> performance bottleneck so we are not as paranoid about it as we might be.
>
> -Steve
>
> Dave Parks wrote:
>> I believe the point of LLString is to protect against NULL pointer  
>> assignments.  It's legacy from a time when we used char* strings and  
>> began mixing in std::string.  Assigning a standard string to NULL  
>> dereferences NULL, causing a crash.  LLString protects against this by  
>> checking for NULL on assignment for char* strings.
>>
>> Alissa Sabre wrote:
>>> I have a question.
>>>
>>> SL viewer uses two data types LLString and std::string, that are
>>> almost identical.  They are sometimes intermixed.  LLString to
>>> std::string conversion is by a simple upcasting, but the opposit is by
>>> a deep copy through a constructor that requires some overhead.
>>>
>>> What is the purpose of LLString?  In case it has some, then the next
>>> question is why LL uses both LLString and std::string?  (Cf. LL never
>>> uses C++ bool type.)
>>>
>>> Assuming there is a good reason to use both LLString and std::string
>>> in SL viewer, what is the criteria (or guidelines) to choose from
>>> LLString and std::string?
>>>
>>>     Alissa Sabre
>>> --------------------------------------
>>> Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar
>>> http://pr.mail.yahoo.co.jp/toolbar/
>>> _______________________________________________
>>> Click here to unsubscribe or manage your list subscription:
>>> /index.html
>>>
>>
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html



-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/