Tại sao việc sử dụng bộ dữ liệu trong C ++ không phổ biến hơn?

Tại sao dường như không ai sử dụng bộ dữ liệu trong C ++, Thư viện Boost Tuple hoặc thư viện chuẩn cho TR1? Tôi đã đọc rất nhiều mã C ++ và rất hiếm khi tôi thấy việc sử dụng các bộ dữ liệu, nhưng tôi thường thấy rất nhiều nơi mà các bộ dữ liệu sẽ giải quyết nhiều vấn đề (thường trả về nhiều giá trị từ các hàm).

Tuples cho phép bạn làm tất cả những thứ hay ho như thế này:

tie(a,b) = make_tuple(b,a); //swap a and b

Điều đó chắc chắn tốt hơn thế này:

temp=a;
a=b;
b=temp;

Tất nhiên bạn luôn có thể làm điều này:

swap(a,b);

Nhưng nếu bạn muốn xoay ba giá trị thì sao? Bạn có thể làm điều này với bộ dữ liệu:

tie(a,b,c) = make_tuple(b,c,a);

Tuples cũng làm cho việc trả lại nhiều biến từ một hàm dễ dàng hơn nhiều, đây có thể là trường hợp phổ biến hơn nhiều so với các giá trị tráo đổi. Sử dụng tài liệu tham khảo để trả về giá trị chắc chắn không phải là rất thanh lịch.

Có bất kỳ nhược điểm lớn nào đối với các bộ dữ liệu mà tôi không nghĩ đến không? Nếu không, tại sao chúng hiếm khi được sử dụng? Họ có chậm hơn không? Hay chỉ là mọi người không quen với họ? Nó có phải là một ý tưởng tốt để sử dụng bộ dữ liệu?

Bởi vì nó chưa chuẩn. Bất cứ điều gì không chuẩn có một trở ngại cao hơn nhiều. Pieces of Boost đã trở nên phổ biến vì các lập trình viên đang kêu gọi họ. (hash_map nhảy vào tâm trí). Nhưng trong khi tuple là tiện dụng, nó không phải là một chiến thắng quá lớn và rõ ràng mà mọi người bận tâm với nó.

Một câu trả lời cay độc là nhiều người lập trình trong C ++, nhưng không hiểu và / hoặc sử dụng chức năng cấp cao hơn. Đôi khi, vì họ không được phép, nhưng nhiều người chỉ đơn giản là không thử (hoặc thậm chí không hiểu).

Như một ví dụ không tăng: có bao nhiêu người sử dụng chức năng được tìm thấy trong <algorithm>?

Nói cách khác, nhiều lập trình viên C ++ chỉ đơn giản là lập trình viên C sử dụng trình biên dịch C ++, và có lẽ std::vectorvà std::list. Đó là một lý do tại sao việc sử dụng boost::tuplekhông phổ biến hơn.

Cú pháp tuple C ++ có thể dài hơn một chút so với hầu hết mọi người mong muốn.

Xem xét:

typedef boost::tuple<MyClass1,MyClass2,MyClass3> MyTuple;

Vì vậy, nếu bạn muốn sử dụng rộng rãi các bộ dữ liệu, bạn có thể nhận được các bộ dữ liệu ở khắp mọi nơi hoặc bạn có được các tên loại dài khó chịu ở mọi nơi. Tôi thích tuples. Tôi sử dụng chúng khi cần thiết. Nhưng nó thường bị giới hạn trong một vài tình huống, như chỉ số phần tử N hoặc khi sử dụng đa khung để buộc các cặp vòng lặp phạm vi. Và nó thường trong một phạm vi rất hạn chế.

Tất cả đều trông rất xấu xí và đáng sợ khi được so sánh với một thứ như Haskell hoặc Python. Khi C ++ 0x đến đây và chúng tôi nhận được các bộ từ khóa 'tự động' sẽ bắt đầu trông hấp dẫn hơn rất nhiều.

Tính hữu dụng của bộ dữ liệu tỷ lệ nghịch với số lượng tổ hợp phím cần thiết để khai báo, đóng gói và giải nén chúng.

Đối với tôi, đó là thói quen, nương tay: Tuples không giải quyết bất kỳ vấn đề mới nào cho tôi, chỉ một vài điều tôi đã có thể xử lý tốt. Trao đổi giá trị vẫn cảm thấy dễ dàng hơn theo cách lỗi thời - và quan trọng hơn, tôi không thực sự nghĩ về cách trao đổi "tốt hơn". Nó đủ tốt như vốn có.

Cá nhân, tôi không nghĩ rằng bộ dữ liệu là một giải pháp tuyệt vời để trả về nhiều giá trị - nghe có vẻ như là một công việc cho structs.

Nhưng nếu bạn muốn xoay ba giá trị thì sao?

swap(a,b);
swap(b,c);  // I knew those permutation theory lectures would come in handy.

OK, vì vậy với 4 giá trị vv, cuối cùng n-tuple trở thành ít mã hơn so với hoán đổi n-1. Và với hoán đổi mặc định, nó thực hiện 6 bài tập thay vì 4 bài bạn có nếu bạn tự thực hiện một mẫu ba chu kỳ, mặc dù tôi hy vọng trình biên dịch sẽ giải quyết điều đó cho các kiểu đơn giản.

Bạn có thể đưa ra các tình huống trong đó các giao dịch hoán đổi khó sử dụng hoặc không phù hợp, ví dụ:

tie(a,b,c) = make_tuple(b*c,a*c,a*b);

là một chút vụng về để giải nén.

Mặc dù vậy, vấn đề là có nhiều cách xử lý các tình huống phổ biến nhất mà các bộ dữ liệu là tốt, và do đó không có sự khẩn cấp lớn nào để sử dụng các bộ dữ liệu. Nếu không có gì khác, tôi không tự tin rằng:

tie(a,b,c) = make_tuple(b,c,a);

không làm 6 bản sao, làm cho nó hoàn toàn không phù hợp với một số loại (bộ sưu tập là rõ ràng nhất). Hãy thuyết phục tôi rằng các bộ dữ liệu là một ý tưởng tốt cho các loại "lớn", bằng cách nói điều này không phải vậy :-)

Để trả về nhiều giá trị, bộ dữ liệu là hoàn hảo nếu các giá trị thuộc loại không tương thích, nhưng một số người không thích chúng nếu người gọi có thể đưa chúng theo thứ tự sai. Một số người không thích nhiều giá trị trả về, và không muốn khuyến khích việc sử dụng chúng bằng cách làm cho chúng dễ dàng hơn. Một số người chỉ thích các cấu trúc được đặt tên cho các tham số vào và ra, và có lẽ không thể bị thuyết phục với một cây gậy bóng chày để sử dụng bộ dữ liệu. Không có kế toán cho hương vị.

Như nhiều người đã chỉ ra, bộ dữ liệu không hữu dụng như các tính năng khác.

1. Các mánh lới hoán đổi và xoay chỉ là mánh lới quảng cáo. Chúng hoàn toàn khó hiểu với những người chưa từng nhìn thấy chúng trước đây và vì nó có khá nhiều người, những mánh lới quảng cáo này chỉ là thực hành kỹ thuật phần mềm kém.

2. Trả về nhiều giá trị bằng cách sử dụng các bộ dữ liệu ít hơn là tự ghi lại các lựa chọn sau đó - trả về các kiểu được đặt tên hoặc sử dụng các tham chiếu được đặt tên. Nếu không có tài liệu này, rất dễ nhầm lẫn thứ tự của các giá trị được trả về, nếu chúng có thể chuyển đổi lẫn nhau và không thể khôn ngoan hơn.

Không phải ai cũng có thể sử dụng boost và TR1 chưa có sẵn rộng rãi.

Khi sử dụng C ++ trên các hệ thống nhúng, việc kéo vào thư viện Boost trở nên phức tạp. Họ cặp với nhau, vì vậy kích thước thư viện phát triển. Bạn trả về cấu trúc dữ liệu hoặc sử dụng truyền tham số thay vì bộ dữ liệu. Khi trả về các bộ dữ liệu trong Python, cấu trúc dữ liệu theo thứ tự và loại của các giá trị được trả về, nó không rõ ràng.

Bạn hiếm khi nhìn thấy chúng bởi vì mã được thiết kế tốt thường không cần đến chúng - không có nhiều trường hợp trong tự nhiên khi sử dụng cấu trúc ẩn danh vượt trội hơn so với sử dụng mã được đặt tên. Vì tất cả các tuple thực sự đại diện là một cấu trúc ẩn danh, hầu hết các lập trình viên trong hầu hết các tình huống chỉ đi với thực tế.

Giả sử chúng ta có hàm "f" trong đó trả về tuple có thể có ý nghĩa. Theo nguyên tắc chung, các chức năng như vậy thường đủ phức tạp để chúng có thể thất bại.

Nếu "f" CÓ THỂ thất bại, bạn cần trả về trạng thái - sau tất cả, bạn không muốn người gọi phải kiểm tra mọi tham số để phát hiện lỗi. "f" có thể phù hợp với mẫu:

struct ReturnInts ( int y,z; }
bool f(int x, ReturnInts& vals);

int x = 0;
ReturnInts vals;
if(!f(x, vals)) {
    ..report error..
    ..error handling/return...
}

Điều đó không đẹp, nhưng hãy nhìn xem sự thay thế xấu xí như thế nào. Lưu ý rằng tôi vẫn cần một giá trị trạng thái, nhưng mã không thể đọc được và không ngắn hơn. Có lẽ nó cũng chậm hơn, vì tôi phải chịu chi phí cho 1 bản sao với bộ dữ liệu.

std::tuple<int, int, bool> f(int x);
int x = 0;
std::tuple<int, int, bool> result = f(x); // or "auto result = f(x)"
if(!result.get<2>()) {
    ... report error, error handling ...
}

Một nhược điểm đáng kể khác được ẩn giấu ở đây - với "ReturnInts" Tôi có thể thêm sự thay đổi của "f" bằng cách sửa đổi "ReturnInts" mà không thay đổi giao diện "f". Giải pháp tuple không cung cấp tính năng quan trọng đó, khiến nó trở thành câu trả lời kém hơn cho bất kỳ mã thư viện nào.

Chắc chắn các bộ dữ liệu có thể hữu ích, nhưng như đã đề cập, có một chút chi phí và một hoặc hai chướng ngại vật bạn phải nhảy qua trước khi bạn thực sự có thể sử dụng chúng.

Nếu chương trình của bạn luôn tìm thấy những nơi bạn cần trả về nhiều giá trị hoặc trao đổi một vài giá trị, thì có thể đáng để đi theo con đường tuple, nhưng nếu không, đôi khi việc thực hiện mọi thứ theo cách cổ điển sẽ dễ dàng hơn.

Nói chung, không phải tất cả mọi người đã cài đặt Boost và tôi chắc chắn sẽ không gặp rắc rối khi tải xuống và định cấu hình các thư mục bao gồm của tôi để làm việc với nó chỉ cho các tiện ích tuple của nó. Tôi nghĩ rằng bạn sẽ thấy rằng những người đã sử dụng Boost có nhiều khả năng tìm thấy việc sử dụng tuple trong các chương trình của họ hơn những người dùng không phải Boost và những người di cư từ các ngôn ngữ khác (Python nghĩ đến) có vẻ đơn giản là khó chịu về việc thiếu bộ dữ liệu trong C ++ hơn là khám phá các phương pháp thêm hỗ trợ tuple.

Là một kho lưu trữ dữ liệu std::tuplecó các đặc điểm tồi tệ nhất của cả a structvà mảng; tất cả quyền truy cập là vị trí thứ n nhưng người ta không thể lặp lại thông qua tupleviệc sử dụng forvòng lặp.

Vì vậy, nếu các phần tử trong tuplekhái niệm là một mảng, tôi sẽ sử dụng một mảng và nếu các phần tử không phải là một mảng về mặt khái niệm, một cấu trúc (có các phần tử được đặt tên) sẽ dễ duy trì hơn. ( a.lastnamelà giải thích nhiều hơn std::get<1>(a)).

Điều này để lại sự chuyển đổi được OP đề cập như là usecase khả thi duy nhất cho các bộ dữ liệu.

Tôi có cảm giác rằng nhiều người sử dụng Boost.Any và Boost.Variant (với một số kỹ thuật) thay vì Boost.Tuple.