Tại sao tài liệu về một số ngôn ngữ lại nói tiếng Đức tương đương với tên lửa chứ không phải là tiếng Anh?


23

Tại sao tài liệu về một số ngôn ngữ nói "tương đương" thay vì "là"?

Ví dụ: Tài liệu Python nói

itertools.chain(*iterables)

...

Tương đương với:

def chain(*iterables):
    # chain('ABC', 'DEF') --> A B C D E F
    for it in iterables:
        for element in it:
            yield element

Hoặc tài liệu tham khảo C ++ này trên find_if:

Hành vi của mẫu hàm này tương đương với:

template<class InputIterator, class UnaryPredicate>
  InputIterator find_if (InputIterator first, InputIterator last, UnaryPredicate pred)
{
  while (first!=last) {
    if (pred(*first)) return first;
    ++first;
  }
  return last;
}

Nếu đó không phải là mã thực tế, họ có thể đăng nó không? Và nếu đó là mã thực tế, tại sao họ phải nói đó là "Tương đương" chứ không đơn giản là "là"?


2
Lưu ý rằng những gì bạn nhìn thấy cho find_ifkhông "the" tài liệu cho C ++. Nếu đúng như vậy, thì việc chọn diễn viên bool(mà bạn thấy trong câu trả lời bên dưới) sẽ sai.
Mehrdad

3
Trong trường hợp python nếu bạn tìm mã nguồn, bạn sẽ thấy nó chainđược triển khai trực tiếp trong C, do đó nó "tương đương" với mã python đó vì nó tạo ra kết quả tương tự, nhưng nó tránh được một chút chi phí trong việc diễn giải điều đó mã byte.
Bakuriu

@Mehrdad Tôi biết đó không phải là tài liệu chính thức, đây chỉ là tài nguyên tôi thấy hữu ích nhất trong việc tìm hiểu các chi tiết của C ++
Jon McClung

Họ sẽ bị buộc phải sử dụng bất kỳ cách tiếp cận nào được đặt ra trong tiêu chuẩn, ngay cả khi có sẵn một phương pháp tốt hơn đáng kể.
Kevin

Câu trả lời:


67

Bởi vì các nhà văn tiêu chuẩn không muốn thực sự khẳng định việc thực hiện. Họ muốn xác định những gì nó làm , nhưng không nhất thiết phải làm như thế nào. Vì vậy, ví dụ, nếu bạn nhìn vào phiên bản GNU C ++find_if , bạn sẽ thấy việc triển khai hơi khác so với những gì bạn đưa ra, dựa trên tiêu chuẩn C ++:

template<typename _InputIterator, typename _Predicate>
inline _InputIterator
__find_if(_InputIterator __first, _InputIterator __last,
    _Predicate __pred, input_iterator_tag)
{
    while (__first != __last && !bool(__pred(*__first)))
     ++__first;
       return __first;
}

Đây là chức năng tương đương với những gì tiêu chuẩn có, nhưng không hoàn toàn giống nhau. Điều này cho phép trình biên dịch nhà văn linh hoạt. Có thể có một cách tốt hơn để làm điều đó cho một nền tảng cụ thể. Người triển khai có thể muốn sử dụng một kiểu mã hóa khác.

Điều này đặc biệt đúng đối với các ngôn ngữ script như python ở chỗ người triển khai có thể quyết định thực hiện bằng một ngôn ngữ hoàn toàn khác vì lý do hiệu suất. Ai đó thực hiện python có thể, ví dụ, viết itertools.chain(*iterables)bằng C ++. Điều này là hoàn toàn tốt nếu tiêu chuẩn nói "tương đương" miễn là mã làm giống như con trăn được cung cấp. Nếu tiêu chuẩn nói "là" thay vào đó, thì người triển khai sẽ được yêu cầu thực hiện bằng ngôn ngữ đó hoặc không đáp ứng tiêu chuẩn.

Tóm tắt:

  1. Bởi vì họ không muốn ngăn việc triển khai viết mã tốt hơn tiêu chuẩn được cung cấp
  2. Bởi vì họ không muốn ngăn việc triển khai sử dụng một ngôn ngữ hoàn toàn khác, để cải thiện hiệu suất

Cảm ơn bạn đã trả lời khai sáng! Tôi nghi ngờ câu trả lời là một cái gì đó dọc theo những dòng đó.
Jon McClung

@lerenard, bạn có thể thấy rõ hơn nữa khi đọc toàn bộ quá trình find_if từ liên kết của Steven. (Những gì anh ấy có ở đó thực sự chỉ là một đoạn trích.)
Winston Ewert

@WinstonEwert, Thật không may, tôi không hoàn toàn ở mức độ hiểu mã hoàn toàn như thế, nhưng việc sử dụng tự do của dấu gạch dưới chắc chắn là một điểm đáng quan tâm!
Jon McClung

9
@lerenard: Những dấu gạch dưới hàng đầu bổ sung đó nằm ở đó để các phần bên trong thư viện chuẩn không can thiệp vào mã bạn có thể viết (tên có dấu gạch dưới hàng đầu gấp đôi được dành cho sử dụng bởi trình biên dịch / người viết thư viện chuẩn).
Bart van Ingen Schenau

5
Chà, trong C và C ++, luôn có quy tắc như thể, vì vậy ngay cả khi tiêu chuẩn được nói thay vì tương đương với, việc triển khai thực tế có thể khác nhau.
Ded repeatator
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.