[opensource-dev] A CALL FOR HHHEEELLLPPP

Thickbrick Sleaford thickbrick.sleaford at gmail.com
Wed Mar 16 03:04:46 PDT 2011


That error message is basically saying "you can't assign to a const variable." 
Line 21 in your paste is reusing file_name, which is one of the method's 
arguments, and is const. You need a local variable which isn't const there.

But, I don't think this makes sense otherwise. In what cases will from_id be 
null? I would guess you will have no way to recover a name in those cases. If 
that really happens, I think that's a server bug.

I think a better approach is to look for the places that call this method, and 
make sure it is passed a username and not a "legacy name" or "complete name" 
as its first argument. You can convert a "legacy name" (but not a "complete 
name"!) to a username with the static method LLCacheName::buildUsername(), 
without needing to look it up in the name cache.

I see these occurrences:

llgiveinventory.cpp
314:                    LLIMModel::instance().logToFile(full_name, 
LLTrans::getString("SECOND_LIFE"), im_session_id, 
LLTrans::getString("inventory_item_offered-im"));

llimview.cpp
859:    if (log2file) logToFile(session_id, from_name, from_id, utf8_text);
2471:                   LLIMModel::instance().logToFile(session_name, 
SYSTEM_FROM, LLUUID::null, message.getString());

llnotificationhandlerutil.cpp
278:            LLIMModel::instance().logToFile(session_name, from, from_id, 
message);


/* rant, please ignore... */
Considering the level of scrutiny trivial patches get here, how did the 
display names code got merged into the viewer in the first place? It made 
already messy code much more messy and inconsistent. Name-handling methods now 
rely on the caller knowing which of the different 4-5 kinds a "name" argument 
is expected to be (username, legacy (2 kinds of that?), complete, or display). 
"Display" and legacy names should have been banished to the lest steps of the 
chain, leaving them for display only, and everything else should have been 
converted to usernames, or preferably, a new type (not std::string.) Looks 
like there was some attempt to do that with LLAvatarName, but logic that 
depends on knowledge of internals of this class is all over the place.


On Wednesday 16 March 2011 03:30:02 WolfPup Lowenhar wrote:
> First References:
> 
> Jira : https://jira.secondlife.com/browse/STORM-941
> 
> 
> 
> Code Snippet : http://codepad.org/9cVTMJTD
> 
> 
> 
> Now the problem:
> 
> When I compile the code I get error C2678: binary '=' : no operator found
> which takes a left-hand operand of type 'const std::string' (or there is no
> acceptable conversion) in reference to line 21of the code snippet. I need
> to be able to force the user name in this case.
> 
> 
> 
> Here is how this case can happen:
> 
> PersonA dose not use Display Names or is on a non-Display Names viewer.
> 
> PersonB dose use Display Names and also keeps logs of all chat, Group and
> P2P messages.
> 
> 
> 
> PersonA offers PersonB and inventory item after PersonA has talked to
> PersonB in P2P conversation. PersonB checks their logs later to read about
> item again to discover there are now two logs for the same person one log
> is using the Legacy name and contains only the system message about the
> inventory offer while the other log that is named using the user name
> contains the conversation about that item.

-- 
Thickbrick


More information about the opensource-dev mailing list