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
_______________________________________________
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges
