Khi nào tôi nên sử dụng string_view trong giao diện?

Tôi đang sử dụng một thư viện nội bộ được thiết kế để bắt chước thư viện C ++ được đề xuất và đôi khi trong vài năm qua tôi thấy giao diện của nó thay đổi từ sử dụng std::stringsang string_view.

Vì vậy, tôi mạnh dạn thay đổi mã của mình, để phù hợp với giao diện mới. Thật không may, những gì tôi phải truyền vào là một tham số std :: string và một cái gì đó là giá trị trả về std :: string. Vì vậy, mã của tôi đã thay đổi từ một cái gì đó như thế này:

void one_time_setup(const std::string & p1, int p2) {
   api_class api;
   api.setup (p1, special_number_to_string(p2));
}

đến

void one_time_setup(const std::string & p1, int p2) {
   api_class api;
   const std::string p2_storage(special_number_to_string(p2));
   api.setup (string_view(&p1[0], p1.size()), string_view(&p2_storage[0], p2_storage.size()));
}

Tôi thực sự không thấy những thay đổi này đã mua cho tôi với tư cách là ứng dụng khách API, ngoài nhiều mã hơn (để có thể làm hỏng). Cuộc gọi API kém an toàn hơn (do API không còn sở hữu bộ nhớ cho các tham số của nó), có thể đã lưu chương trình 0 của tôi (do trình biên dịch tối ưu hóa di chuyển có thể thực hiện ngay bây giờ) và ngay cả khi nó đã lưu công việc, điều đó chỉ có thể một vài phân bổ sẽ không và sẽ không bao giờ được thực hiện sau khi khởi động hoặc trong một vòng lặp lớn ở đâu đó. Không dành cho API này.

Tuy nhiên, cách tiếp cận này dường như làm theo lời khuyên tôi thấy ở nơi khác, ví dụ câu trả lời này :

Bên cạnh đó, vì C ++ 17, bạn nên tránh truyền const std :: string & có lợi cho std :: string_view:

Tôi thấy lời khuyên đó đáng ngạc nhiên, vì dường như nó đang ủng hộ việc thay thế một đối tượng tương đối an toàn bằng một vật thể kém an toàn hơn (về cơ bản là một con trỏ và chiều dài được tôn vinh), chủ yếu cho mục đích tối ưu hóa.

Vì vậy, khi nào nên sử dụng string_view, và khi nào thì không?

1. Có phải chức năng lấy giá trị cần phải có quyền sở hữu chuỗi? Nếu vậy sử dụng std::string(không const, không ref). Tùy chọn này cho bạn lựa chọn di chuyển rõ ràng trong một giá trị nếu bạn biết rằng nó sẽ không bao giờ được sử dụng lại trong ngữ cảnh gọi.
2. Có chức năng chỉ đọc chuỗi? Nếu vậy sử dụng std::string_view(const, non-ref) điều này là bởi vì string_viewcó thể xử lý std::stringvà char*dễ dàng mà không có vấn đề và không tạo ra một bản sao. Điều này sẽ thay thế tất cả các const std::string&tham số.

Cuối cùng, bạn không bao giờ cần phải gọi nhà std::string_viewxây dựng như bạn. std::stringcó một toán tử chuyển đổi tự động xử lý chuyển đổi.

A std::string_viewmang lại một số lợi ích của a const char*cho C ++: không giống như std::string, chuỗi_view

• không có bộ nhớ
• không phân bổ bộ nhớ,
• có thể trỏ vào một chuỗi hiện có ở một số bù và
• có một mức độ ít hơn của con trỏ không xác định so với a std::string&.

Điều này có nghĩa là một chuỗi_view thường có thể tránh các bản sao mà không phải xử lý các con trỏ thô.

Trong mã hiện đại, std::string_viewnên thay thế gần như tất cả việc sử dụng các const std::string&tham số chức năng. Đây phải là một thay đổi tương thích với nguồn, vì std::stringkhai báo một toán tử chuyển đổi thành std::string_view.

Chỉ vì chế độ xem chuỗi không giúp ích trong trường hợp sử dụng cụ thể của bạn khi bạn cần tạo chuỗi dù sao không có nghĩa là đó là một ý tưởng tồi nói chung. Thư viện chuẩn C ++ có xu hướng được tối ưu hóa cho tính tổng quát hơn là để thuận tiện. Các đối số ít an toàn hơn không giữ được, vì không cần thiết phải tự tạo chế độ xem chuỗi.

Tôi thấy lời khuyên đó đáng ngạc nhiên, vì dường như nó đang ủng hộ việc thay thế một đối tượng tương đối an toàn bằng một vật thể kém an toàn hơn (về cơ bản là một con trỏ và chiều dài được tôn vinh), chủ yếu cho mục đích tối ưu hóa.

Tôi nghĩ rằng điều này là hơi hiểu lầm mục đích của việc này. Mặc dù nó là một "tối ưu hóa", nhưng bạn thực sự nên nghĩ về nó như giải quyết bản thân khỏi phải sử dụng a std::string.

Người dùng C ++ đã tạo ra hàng tá các lớp chuỗi khác nhau. Các lớp chuỗi có độ dài cố định, các lớp được tối ưu hóa SSO với kích thước bộ đệm là tham số mẫu, các lớp chuỗi lưu trữ giá trị băm được sử dụng để so sánh chúng, v.v. Một số người thậm chí sử dụng chuỗi dựa trên COW. Nếu có một điều mà các lập trình viên C ++ thích làm, đó là viết các lớp chuỗi.

Và bỏ qua các chuỗi được tạo và sở hữu bởi các thư viện C. Khỏa thân char*, có thể với một kích thước của một số loại.

Vì vậy, nếu bạn đang viết một số thư viện và bạn lấy một const std::string&, người dùng bây giờ phải lấy bất kỳ chuỗi nào họ đang sử dụng và sao chép nó vào một std::string. Có thể hàng chục lần.

Nếu bạn muốn truy cập vào std::stringgiao diện dành riêng cho chuỗi, tại sao bạn phải sao chép chuỗi? Đó là một sự lãng phí.

Những lý do chính yếu để không lấy string_viewtham số là:

1. Nếu mục tiêu cuối cùng của bạn là chuyển chuỗi đến một giao diện có chuỗi kết thúc NUL ( fopen, v.v.). std::stringđược đảm bảo chấm dứt NUL; string_viewkhông phải. Và thật dễ dàng để phân nhóm một khung nhìn để làm cho nó không bị chấm dứt NUL; chuỗi con a std::stringsẽ sao chép chuỗi con ra thành một phạm vi kết thúc NUL.

   Tôi đã viết một kiểu kiểu string_view kết thúc NUL đặc biệt cho chính xác kịch bản này. Bạn có thể thực hiện hầu hết các thao tác, nhưng không thực hiện các thao tác phá vỡ trạng thái kết thúc NUL của nó (ví dụ như cắt xén từ cuối).

2. Vấn đề trọn đời. Nếu bạn thực sự cần phải sao chép std::stringhoặc có các ký tự khác ngoài cuộc gọi hàm, tốt nhất là nêu rõ điều này bằng cách thực hiện const std::string &. Hoặc chỉ std::stringlà một tham số giá trị. Theo cách đó, nếu họ đã có một chuỗi như vậy, bạn có thể yêu cầu quyền sở hữu chuỗi đó ngay lập tức và người gọi có thể chuyển sang chuỗi nếu họ không cần giữ một bản sao của chuỗi đó.