On Sun, Jun 12, 2016 at 4:26 PM, Ben Boeckel <ben.boec...@kitware.com> wrote:
> On Fri, Jun 10, 2016 at 15:30:05 +0200, Daniel Pfeifer wrote:
>> Passing and returning strings: We have `const char*`, `std::string`,
>> and `std::string const&`. Unifying this can affect performance.
>> Storing `const char*` in a `std::string` creates a (potentially
>> unneded) copy (assuming it is not null).
>
> I went through and changed all `const char*` paramters to `std::string
> const&` where the pointer was given to a string within the function
> (unless it was an error path or such). This allows eliding another
> allocation.

I am aware of that. In case of passing `foo.c_str()`, this moved the
creation of the unnecessary copy from inside the function to the call
site, resulting in more allocations rather than less, assuming the
function is called more than once. It is important to run clang-tidy
after each such refactoring to remove the now unnecessary c_str()
calls.

>> `const char*` can distinguish
>> invalid from empty. Do we actually need this distinction?
>
> It's used all over the place.

Can you show an example? To be clear: We are looking for a function,
that has a code path for `str == NULL` and a *different* codepath for
`str[0] = '\0'`.
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Reply via email to