[Lldb-commits] [PATCH] D76111: Create basic SBEnvironment class

[Pavel Labath via lldb-commits]

[Splitting this off to not derail the review]

On 14/03/2020 00:45, Greg Clayton via Phabricator wrote:
> labath wrote:
>> This will return a dangling pointer as Envp is a temporary object. It's intended to be used to pass the environment object to execve-like function. 
>> The current "state of the art" is to ConstStringify all temporary strings that go out of the SB api. (Though I think we should start using std::string).
>>
>> Also, constructing the Envp object just to fetch a single string out of it is pretty expensive. You can fetch the desired result from the Environment object directly.
>>
>> Putting it all together, this kind of an API would be implemented via something like:
>> ```
>>   if (idx >= m_opaque_up->size())
>>     return nullptr;
>>   return ConstString(Environment::compose(*std::next(m_opaque_up.begin(), idx)).AsCString();
>> ```
>>
>> ... but I am not sure this is really the right api. More on that in a separate comment.
> Yes, any C strings returned from the SB API should use ConstString(cstr).AsCString() as the ConstString puts the string into a string pool and there is no need to clients to destruct the string or take ownership.
> 
> No STL in the SB API please, so no std::string. std::string isn't stable on all platforms and competing C++ runtimes on different platforms can cause problems. If we need string ownership, we can introduce SBString as a class.

What do you exactly mean by "not stable"? All major C++ standard
libraries I have knowledge of (libstdc++, libc++, msvc stl) take abi
stability very seriously (more seriously than we do for SB api).

I can see how returning std::strings would be a problem if one builds
liblldb with one c++ library (say libstdc++) and then tries to build the
dependant program with libc++ (are those the competing runtimes you
mentioned?), but.. is that something we have signed up to support?

The main reason I am even thinking about this is because swig already
knows how to map common stl types onto native types of other languages.
This is particularly important if we are going to have multiple
scripting languages, as we wouldn't need to redo the mapping for each
script language and each stl-like class we have (e.g. all SBXXXLists)

pl