Please reply to the mailing list (use "reply all").
On Thu, Apr 20, 2017 at 4:39 AM, hui zhang <fastfad...@gmail.com> wrote:
> Thank you , I believe most function will return string instead of string&
> I test return string function , as expected it return the wrong value
> as the string is invalid out of function.
>
> strdup is easier , thank you.
>
> call GoString(getpath().c_str()) in the CGetPath function
>
> Is that possible ?
>
Please refer to the end of that sentence, which you didn't quote: "but I'm
not familiar enough with cgo to know if that's possible."
(This is why replying to the mailing list is better, someone there might be
more familiar with cgo)
> 2017-04-19 16:40 GMT+08:00 Frits van Bommel <fvbom...@gmail.com>:
>
>> On Wednesday, April 19, 2017 at 9:10:16 AM UTC+2, hui zhang wrote:
>>>
>>> for 1) you mean
>>>>
>>>> char *CGetPath() {
>>>> return getpath().c_str();
>>>> }
>>>
>>>
>>> this code will work ?
>>>
>>
>> That depends on whether getpath() returns a std::string or a (const)
>> std::string& (a (const) reference). It will work if it returns a reference
>> or const reference, but is not guaranteed to work if it doesn't (though it
>> may appear to do so in some cases, or for some implementations of the C++
>> standard lib) because the standard lib is not required to use a
>> reference-counted dynamic array. For example, it might instead choose to
>> copy the array every time or to allocate small strings using an in-object
>> buffer to avoid the overhead of dynamic allocation, and in both of those
>> cases the return value of c_str() is no longer valid when the function
>> returns.
>>
>> Also, if do you need to copy the string in C++ code:
>> strdup(getpath().c_str()) is better than malloc+strcpy (shorter and harder
>> to get wrong). Case in point: your implementation malloc'ed str.length()
>> bytes, failing to allocate an extra byte for the '\0' at the end.
>> Even better might be to call GoString(getpath().c_str()) in the CGetPath
>> function to ensure only a single copy is made, but I'm not familiar enough
>> with cgo to know if that's possible.
>>
>>
>>
>>> 2017-04-19 14:43 GMT+08:00 Konstantin Khomoutov <
>>> flat...@users.sourceforge.net>:
>>>
>>>> On Wed, 19 Apr 2017 14:23:09 +0800
>>>> hui zhang <fastf...@gmail.com> wrote:
>>>>
>>>> > 1) getpath() return a temp string, its c_str() pointer will be
>>>> > free out of function. So I use malloc
>>>>
>>>> I'm not completely sure you're correct. C++ does not implement garbage
>>>> collection and the object on which you have called c_str() continues to
>>>> live on after getpath() returns. Now let's cite the manual on c_str():
>>>>
>>>> | The pointer obtained from c_str() may be invalidated by:
>>>> | * Passing a non-const reference to the string to any standard library
>>>> | function, or
>>>> | * Calling non-const member functions on the string, excluding
>>>> | operator[], at(), front(), back(), begin(), rbegin(), end() and
>>>> | rend().
>>>>
>>>> So I'd say in the sequence of calls I propose there's no chance of
>>>> anything quoted to happen -- basically the pointer returned by c_str()
>>>> gets passed to Go where C.GoString() copies the memory pointed to by it.
>>>>
>>>> Things may break if you somehow concurrently call into your C++ side
>>>> and those calls may access the same std::string object we're talking
>>>> about. But if you do this, all bets are already off.
>>>>
>>>> > 2) Assume we use the malloc way , are C.GoString() copying the
>>>> > pointer memory ? for we need C.free() malloc memory.
>>>>
>>>> Yes, C.GoString() copies the memory.
>>>>
>>>> Yes, you always need to free() what was malloc()ed for you -- because
>>>> you own the returned pointer.
>>>>
>>>
>>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "golang-nuts" group.
>> To unsubscribe from this topic, visit https://groups.google.com/d/to
>> pic/golang-nuts/u7EtqL9SKV4/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> golang-nuts+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
