string_view‑bẫy: đào sâu quy tắc thời gian sống

1. std::string_view vừa hữu ích vừa nguy hiểm

Khi bạn lần đầu nhìn thấy std::string_view, nó trông như "chuỗi nhẹ không sao chép": truyền vào hàm — mọi thứ nhanh, gọn, hiện đại. Và điều đó đúng, miễn là bạn giữ trong đầu một điểm quan trọng: string_view không sở hữu văn bản. Nó giống như một "cửa sổ" vào dữ liệu của người khác. Cửa sổ thì tiện để xem, nhưng không thể mang dữ liệu về nhà.

Giá trị thực tiễn của string_view thường ở hai chỗ. Thứ nhất, ta có thể nhận văn bản vào hàm mà không sao chép: dù là std::string, literal chuỗi, hay một mảnh của chuỗi. Thứ hai, có thể làm các phần con (substring) cũng không sao chép: "trỏ vào một phạm vi ký tự".

Nhưng chính từ những ưu điểm đó lại nảy sinh rủi ro: nếu chủ sở hữu dữ liệu biến mất hoặc di chuyển bộ nhớ của họ, view vẫn giữ địa chỉ và độ dài cũ — và bạn đọc thứ không còn là "văn bản" nữa, mà là sự ngẫu nhiên.

Để cố định vai trò, hữu ích khi giữ trong đầu bảng sau:

std::string

std::string

std::string_view

Bên trong thực sự của std::string_view

Rất dễ nhầm nếu nghĩ rằng string_view là "gần như string". Thật ra nó có bản chất khác: chỉ là một cặp "con trỏ tới ký tự + số ký tự". Không có đảm bảo về null-terminator, không có đảm bảo "dữ liệu sẽ tồn tại", không có đảm bảo "dữ liệu không đổi". Do đó string_view thường hành xử như một "lát cắt" mảng ký tự rất cẩn thận.

Ví dụ nhỏ dưới đây đáng để xem một lần:

#include <iostream>
#include <string_view>

int main() {
    std::string_view sv = "hello";

    std::cout << sv.size() << '\n'; // 5
    std::cout << sv << '\n';        // hello
}

Tại sao điều này an toàn? Vì "hello" là literal chuỗi. Nó sống rất lâu (gần như "luôn luôn"), nên view trỏ vào nó không trở thành treo.

Suy nghĩ hữu ích: std::string_view có thể trỏ tới văn bản hoàn toàn không được null-terminate. Ví dụ, trỏ vào giữa chuỗi. Điều đó bình thường. Nhưng điều này có nghĩa là mọi logic "truyền data() tới nơi chờ C-string" có thể đổ vỡ bất ngờ. Và thường nó đổ vỡ vào ngày bạn nghĩ rằng "mọi thứ đã được test".

2. Quy tắc ngày: view không nên sống lâu hơn chủ sở hữu

Ý chính của toàn bài nghe giống như quy tắc an toàn: view không nên sống lâu hơn chủ sở hữu dữ liệu. Nếu bạn chỉ nhớ một câu — hãy nhớ câu này.

Tương tự dễ hiểu: std::string là một cuốn sách, std::string_view là bookmark ghi trang và dòng. Bookmark không lưu văn bản. Nó lưu "nơi đọc". Nếu cuốn sách bị vứt đi, bookmark còn đó nhưng không có gì để đọc. Nếu cuốn sách được in lại và trang bị di chuyển, bookmark chỉ vào chỗ không tồn tại, dù nhìn có vẻ hợp lệ.

Một chi tiết quan trọng khác: thời gian sống của view (biến std::string_view) và thời gian sống của dữ liệu mà nó trỏ tới — là hai thứ khác nhau. View có thể sống lâu, trong khi dữ liệu thì không. Đó chính là tình huống "dangling string_view".

3. Các bẫy phổ biến về thời gian sống của std::string_view

Bẫy #1: string_view từ std::string tạm thời

Lỗi phổ biến và đáng tiếc nhất: tạo một string tạm và ngay lập tức làm từ nó một string_view. Mã vẫn biên dịch tốt. Trên review trông "hiện đại". Rồi bắt đầu các crash bí ẩn "chỉ trên server và chỉ vào thứ sáu".

#include <iostream>
#include <string>
#include <string_view>

int main() {
    std::string_view sv = std::string("hi");
    std::cout << sv << '\n'; // UB: sv trỏ tới std::string đã bị hủy
}

Tại sao vậy? Vì std::string("hi") là một đối tượng tạm. Nó tồn tại tới cuối biểu thức đầy đủ, nghĩa là gần như tới ;. Sau ; chuỗi tạm bị hủy, và sv còn lại với địa chỉ của "quá khứ".

Chuỗi tạm ẩn: substr của std::string

Có kiểu còn tinh vi hơn. Bạn thậm chí không cần tạo std::string("...") thủ công. Chỉ cần gọi phương thức trả về std::string, không phải string_view. Ví dụ, std::string::substr.

#include <string>
#include <string_view>

int main() {
    std::string s = "command: add milk";

    std::string_view v = s.substr(0, 7); // UB: substr trả về std::string tạm
    (void)v;
}

Ở đây vấn đề không phải ở s — nó còn sống. Vấn đề là s.substr(...) tạo một std::string mới (tạm), và view được dựng trên nó.

Làm thế nào cho đúng? Nếu bạn muốn thật sự view không sao chép, hãy làm view từ chuỗi gốc, sau đó gọi substr trên view:

#include <string>
#include <string_view>

int main() {
    std::string s = "command: add milk";

    std::string_view v = std::string_view{s}.substr(0, 7); // OK
    (void)v;
}

Bây giờ substr cắt lát bên trong view, và view trỏ vào bộ nhớ của s, vốn còn sống.

Khía cạnh thực tế: tại sao dễ nhầm ở đây

Ngay cả trong ủy ban C++ cũng thảo luận chi tiết về các constructor của string_view cho kịch bản range và tính chặt chẽ của chuyển đổi — tức là chủ đề "làm sao dễ vô tình tạo view từ nguồn không đúng" thực sự nhạy cảm. Ví dụ, có thắc mắc rằng constructor range của string_view nên là explicit.

Bẫy #2: hàm trả string_view, nhưng bên trong tạo chuỗi

Sau bẫy đầu, dễ mắc bẫy thứ hai: "ok, tôi sẽ không tạo tạm trong main, tôi viết hàm trả view". Và đây gần như chắc chắn sinh dangling, vì chuỗi bên trong hàm là local và bị tiêu hủy khi thoát hàm.

#include <string>
#include <string_view>

std::string_view bad_prefix() {
    std::string p = "cmd:";
    return p; // UB: p sẽ bị hủy khi thoát hàm
}

Đây là tương tự trực tiếp của "trả tham chiếu tới biến local", chỉ xảy ra trong thế giới chuỗi.

Có thể trả string_view, nhưng chỉ khi bạn trả view lên dữ liệu chắc chắn sống lâu hơn. Ví dụ, literal chuỗi:

#include <string_view>

std::string_view ok_prefix() {
    return "cmd:"; // OK: literal sống tới khi chương trình kết thúc
}

Hoặc trả view lên chuỗi được truyền vào từ ngoài (nhưng lúc này rủi ro khác xuất hiện: caller có thể truyền chuỗi tạm).

Bẫy #3: trả view trên tham số nhưng truyền đối tượng tạm

Bẫy này trông rất tinh tế. Bạn viết hàm "không sao chép", nhận std::string_view, trả std::string_view — đẹp. Vấn đề là hợp đồng của bạn bắt đầu phụ thuộc vào chính xác thứ được truyền vào.

#include <string_view>

std::string_view first_word(std::string_view line) {
    std::size_t pos = line.find(' ');
    return (pos == std::string_view::npos) ? line : line.substr(0, pos);
}

Giờ đây một gọi nguy hiểm:

#include <iostream>
#include <string>
#include <string_view>

int main() {
    std::string_view w = first_word(std::string("add milk"));
    std::cout << w << '\n'; // UB: chuỗi tạm đã chết sau ';'
}

Hàm first_word "thật thà": nó làm việc với view và trả view trên cùng bộ đệm. Nhưng hợp đồng của hàm trở nên mong manh: "giá trị trả hợp lệ chừng nào nguồn văn bản còn sống".

Làm thế nào để an toàn hơn cho mã người mới? Thường câu trả lời đơn giản: trả std::string theo giá trị, nếu kết quả dự định được lưu trữ.

#include <string>
#include <string_view>

std::string first_word_copy(std::string_view line) {
    std::size_t pos = line.find(' ');
    std::string_view w = (pos == std::string_view::npos) ? line : line.substr(0, pos);
    return std::string(w); // sao chép đúng mảnh cần thiết
}

Đúng, có sao chép. Nhưng hợp đồng minh bạch: kết quả tồn tại độc lập.

Bẫy #4: lưu std::string_view làm trường cấu trúc

Khi bạn bắt đầu mô hình hóa dữ liệu, có cám dỗ: "hãy lưu string_view thay vì string để nhanh hơn". Đây là một trong những "tối ưu vi mô" đắt giá nhất, vì nó thường biến thành mìn thời gian sống.

Một mẫu mô hình rất tệ trông như sau:

#include <string_view>

struct Task {
    int id = 0;
    std::string_view title; // nguy hiểm: ai là chủ sở hữu văn bản?
    bool done = false;
};

Tại sao nguy hiểm? Vì Task giờ lưu "bookmark của người khác". Sách ở đâu? Ai đảm bảo sách không biến mất? Thường thì — không ai.

Phiên bản "nhàm chán" nhưng đúng là sở hữu chuỗi:

#include <string>

struct Task {
    int id = 0;
    std::string title; // sở hữu
    bool done = false;
};

Và string_view dùng ở nơi thật sự tốt: tham số hàm, parsing, so sánh, tìm kiếm, nhưng không phải lưu trữ lâu dài.

Bẫy #5: view trên std::string, rồi chuỗi bị thay đổi

Ngay cả khi chủ sở hữu dữ liệu sống đủ lâu, còn một nguyên nhân khác khiến view "hỏng": chủ có thể sửa bộ đệm. Với std::string điều này có nghĩa khi sửa chuỗi có thể tái cấp phát bộ nhớ, chuỗi di chuyển chỗ khác — và địa chỉ cũ không còn trỏ tới dữ liệu hợp lệ.

#include <iostream>
#include <string>
#include <string_view>

int main() {
    std::string s = "abc";
    std::string_view v = s;

    s += "defghijklmnopqrstuvwxyz"; // có thể tái cấp phát bộ đệm
    std::cout << v << '\n';         // UB, nếu bộ đệm đã di chuyển
}

Sự nguy hiểm là đôi khi bộ đệm không di chuyển (ví dụ do small string optimization hoặc do capacity() đủ lớn). Vì vậy lỗi có thể "không xuất hiện" với chuỗi nhỏ và xuất hiện với chuỗi lớn, trên compiler khác, hoặc chỉ vào một lúc ngẫu nhiên.

Kết luận thực tế cho mã người mới: nếu bạn lấy string_view lên một chuỗi, không sửa chuỗi đó khi view còn cần. Nếu cần sửa chuỗi — tạo lại view sau khi sửa, coi view như "tham chiếu một lần tới phiên bản hiện tại".

4. Phong cách an toàn cho TaskBoard: nhận view, lưu string

Muốn không chỉ hoảng sợ mà có phong cách làm việc thực tế áp dụng trong dự án. Pattern cơ bản tốt là: trong mô hình và kho lưu trữ chúng ta sở hữu dữ liệu, còn string_view dùng ở biên hàm — như tham số "đọc ngay bây giờ".

Giả sử chúng ta có thao tác thêm công việc. Chữ ký thuận tiện: nhận std::string_view title, nhưng lưu vào model một bản sao (sở hữu).

#include <string>
#include <string_view>
#include <vector>

struct Task {
    int id = 0;
    std::string title;
    bool done = false;
};

void add_task(std::vector<Task>& tasks, int id, std::string_view title) {
    tasks.push_back(Task{id, std::string(title), false});
}

Chú ý ý tưởng: view sống chỉ trong phạm vi gọi add_task, và bên trong Task ta ngay lập tức tạo chuỗi sở hữu. Đây là đúng thời điểm sao chép: biến văn bản "mượn" bên ngoài thành trạng thái "sở hữu" của ta.

Phong cách tương tự hữu ích cho tìm kiếm. Ví dụ, kiểm tra xem tiêu đề bắt đầu bằng "#" hay không:

#include <string_view>

bool starts_with_hash(std::string_view s) {
    return !s.empty() && s[0] == '#';
}

Hàm này hoàn hảo cho string_view, vì nó không lưu gì và không trả "mượn" ra ngoài. Nó chỉ đọc và trả lời.

Bộ parsing nhỏ với string_view

Để thấy string_view "trong môi trường tự nhiên", xem đoạn parsing lệnh nhỏ cho TaskBoard. Người dùng nhập các dòng như "add Buy milk" hoặc "done 3". Ta đọc dòng vào std::string line, sau đó parse nó, tránh sao chép thừa ở bước trung gian.

Bắt đầu với "cắt bỏ khoảng trắng bên trái". Nó trả string_view, điều này ổn, vì view trả về vẫn trỏ vào cùng dữ liệu gốc.

#include <string_view>

std::string_view ltrim(std::string_view s) {
    while (!s.empty() && s.front() == ' ') {
        s.remove_prefix(1);
    }
    return s;
}

Bây giờ "chia một lần" theo khoảng trắng: lệnh và phần còn lại của chuỗi.

#include <string_view>
#include <utility>

std::pair<std::string_view, std::string_view> split_once(std::string_view s) {
    s = ltrim(s);
    std::size_t pos = s.find(' ');
    if (pos == std::string_view::npos) return {s, std::string_view{}};
    return {s.substr(0, pos), ltrim(s.substr(pos + 1))};
}

Những hàm này an toàn với điều kiện: view đầu vào phải hợp lệ. Với phong cách của chúng ta điều đó dễ đảm bảo: đọc chuỗi vào std::string line, và truyền std::string_view{line} vào parser, và parser chỉ chạy trong vòng lặp xử lý lệnh hiện tại.

Bây giờ ta tạo kết quả parsing, thứ sở hữu dữ liệu. Đây là điểm mấu chốt: parser có thể dùng view bên trong, nhưng trả ra chuỗi sở hữu.

#include <string>

struct ParsedAdd {
    std::string title;
};

Và hàm parse cho lệnh add:

#include <optional>
#include <string>
#include <string_view>

std::optional<ParsedAdd> parse_add(std::string_view line) {
    auto [cmd, rest] = split_once(line);
    if (cmd != "add" || rest.empty()) return std::nullopt;
    return ParsedAdd{std::string(rest)};
}

Ở đây diễn ra "toán học thời gian sống" đúng đắn: rest là view trên line, nhưng ta ngay lập tức sao chép nó vào std::string. Do đó ParsedAdd có thể lưu trữ an toàn và dùng ở bất cứ đâu.

Và đây là nơi bắt đầu kỷ luật "người lớn": nếu bạn trả một đối tượng ra bên ngoài mà nó sẽ sống lâu hơn, đối tượng đó phải sở hữu những gì nó cần. View tốt cho công việc nội bộ trong hàm, nhưng không phù hợp làm phần của kết quả nếu bạn không muốn ép hợp đồng "nguồn chắc chắn sống".

5. Ghi nhớ: nơi nào string_view phù hợp, nơi nào nguy hiểm

Khi viết mã, đầu óc thích "đơn giản hóa": nếu kiểu phù hợp thì mọi thứ ổn. Nhưng với string_view không thể như vậy — cần kiểm tra nhanh về thời gian sống. Tin tốt: kiểm tra này rất nhanh nếu bạn tự hỏi đúng câu hỏi.

std::string_view

struct/class

Và giờ cùng checklist dạng sơ đồ nhỏ:

flowchart TD
    A["Muốn dùng string_view"] --> B{"Nó sẽ sống ở đâu?"}
    B -->|Chỉ bên trong cuộc gọi/hàm| C["Thường an toàn"]
    B -->|Sẽ lưu trong trường / toàn cục / container| D{"Có bảo đảm chắc chắn về thời gian sống của chủ sở hữu?"}
    D -->|Có, chủ sống lâu hơn và không thay đổi bộ đệm| E["Có thể dùng, nhưng hợp đồng phải rõ ràng"]
    D -->|Không / không chắc chắn| F["Hãy lưu std::string (sở hữu dữ liệu)"]

Nếu bạn tự nhủ "ừm, có vẻ chủ sẽ sống…" — đó gần như luôn là dấu hiệu: tốt hơn là sở hữu chuỗi. std::string rẻ hơn nhiều so với một tuần debug.

6. Lỗi điển hình khi làm việc với std::string_view

Lỗi #1: std::string_view sv = std::string("..."); và tin rằng "mình dùng ngay".
Đây là một trong những cái bẫy phổ biến, vì trông như tối ưu: không sao chép, rất hiện đại. Trên thực tế chuỗi tạm bị hủy ở cuối biểu thức đầy đủ, còn sv vẫn tồn tại. Thói quen đúng: nếu nguồn là tạm — hoặc tạo std::string sở hữu, hoặc không lưu view ra ngoài biểu thức.

Lỗi #2: std::string_view v = s.substr(...) trên std::string.
Trực giác nghĩ "substr là substring nên là view". Nhưng với std::string phương thức substr trả về một std::string mới, tức là tạo đối tượng tạm, và view bắt đầu trỏ lên nó. An toàn hơn là lấy substr trên std::string_view{s} — khi đó bạn thực sự có "lát cắt không sao chép".

Lỗi #3: trả std::string_view từ hàm mà chuỗi được tạo bên trong.
Đây là tương tự "trả tham chiếu tới biến local", nhưng trong dạng chuỗi. Nếu chuỗi tạo trong hàm, nó bị hủy khi thoát hàm, và view trở thành treo. Khắc phục: trả std::string theo giá trị, hoặc chỉ trả view trên dữ liệu có thời gian sống đảm bảo lâu hơn (ví dụ literal).

Lỗi #4: lưu std::string_view trong model dữ liệu (ví dụ struct Task { std::string_view title; }).
Thiết kế này khiến hệ thống phụ thuộc vào chủ sở hữu bên ngoài. Trong ứng dụng thực tế điều này gần như luôn dẫn tới "hôm qua chạy ổn". Phong cách an toàn hơn: lưu std::string trong model, còn string_view dùng cho tham số và parse.

Lỗi #5: giữ view trên std::string, rồi sửa chuỗi sau đó.
Ngay cả khi chuỗi còn "sống", bộ đệm có thể tái cấp phát khi thực hiện +=, append(), insert() và các thao tác khác. View cũ không được cập nhật và tiếp tục trỏ tới địa chỉ cũ. Trong phong cách an toàn, hoặc không sửa chuỗi khi view còn cần, hoặc tạo view lại sau sửa, hoặc ngay lập tức sao chép phần cần vào std::string.

1

Nhiệm vụ

C++ SELF, mức độ, bài học

Đã khóa

Kiểm tra tiền tố

Kiểm tra tiền tố

Mở

1

Nhiệm vụ

C++ SELF, mức độ, bài học

Đã khóa

Cửa sổ chuỗi

Cửa sổ chuỗi

Mở

1

Nhiệm vụ

C++ SELF, mức độ, bài học

Đã khóa

Từ đầu tiên

Từ đầu tiên

Mở

1

Nhiệm vụ

C++ SELF, mức độ, bài học

Đã khóa

Ghi chú và thẻ

Ghi chú và thẻ

Mở