Điều gì là quá khó khăn về con trỏ / đệ quy? [đóng cửa]

Trong những nguy hiểm của các trường java, Joel thảo luận về kinh nghiệm của anh ấy tại Penn và sự khó khăn của "lỗi phân khúc". Anh ta nói

[segfaults rất khó cho đến khi bạn] "hít một hơi thật sâu và thực sự cố gắng buộc tâm trí của bạn phải làm việc ở hai mức độ trừu tượng khác nhau cùng một lúc."

Đưa ra một danh sách các nguyên nhân phổ biến cho segfaults, tôi không hiểu làm thế nào chúng ta phải làm việc ở 2 mức độ trừu tượng.

Vì một số lý do, Joel coi những khái niệm này là cốt lõi để một lập trình viên có khả năng trừu tượng hóa. Tôi không muốn giả định quá nhiều. Vì vậy, những gì là khó khăn về con trỏ / đệ quy? Ví dụ sẽ tốt đẹp.

Đầu tiên tôi nhận thấy rằng con trỏ và đệ quy là khó khăn trong trường đại học. Tôi đã tham gia một vài khóa học năm đầu tiên điển hình (một là C và Assembler, hai là ở Scheme). Cả hai khóa học bắt đầu với hàng trăm sinh viên, nhiều người trong số họ có nhiều năm kinh nghiệm lập trình cấp trung học (điển hình là BASIC và Pascal, trong những ngày đó). Nhưng ngay khi con trỏ được giới thiệu trong khóa C, và đệ quy được giới thiệu trong khóa Scheme, một số lượng lớn sinh viên - có lẽ thậm chí là đa số - đã hoàn toàn thất vọng. Đây là những đứa trẻ đã viết RẤT NHIỀU mã trước đây và không có vấn đề gì, nhưng khi chúng đánh con trỏ và đệ quy, chúng cũng đánh vào tường về khả năng nhận thức của chúng.

Giả thuyết của tôi là con trỏ và đệ quy giống nhau ở chỗ chúng yêu cầu bạn giữ hai mức độ trừu tượng trong đầu cùng một lúc. Có một cái gì đó về sự trừu tượng nhiều cấp độ đòi hỏi một loại năng khiếu tinh thần mà rất có thể một số người sẽ không bao giờ có.

• Với con trỏ, "hai mức độ trừu tượng" là "dữ liệu, địa chỉ dữ liệu, địa chỉ địa chỉ dữ liệu, v.v." hoặc theo cách chúng ta thường gọi là "giá trị so với tham chiếu". Đối với học sinh chưa được đào tạo, rất khó để thấy sự khác biệt giữa địa chỉ của x và x .
• Với đệ quy, "hai mức độ trừu tượng" đang hiểu làm thế nào để một hàm có thể tự gọi chính nó. Thuật toán đệ quy đôi khi là thứ mà mọi người gọi là "lập trình bằng suy nghĩ mơ ước" và việc nghĩ ra thuật toán theo "trường hợp cơ bản + trường hợp quy nạp" thay vì danh sách các bước tự nhiên hơn mà bạn thực hiện để giải quyết vấn đề là rất tự nhiên. . " Đối với học sinh chưa được huấn luyện nhìn vào một thuật toán đệ quy, thuật toán xuất hiện để đặt câu hỏi .

Tôi cũng sẽ hoàn toàn sẵn sàng chấp nhận rằng có thể dạy con trỏ và / hoặc đệ quy cho bất cứ ai ... Tôi không có bất kỳ bằng chứng nào bằng cách này hay cách khác. Tôi biết rằng theo kinh nghiệm, việc có thể thực sự hiểu hai khái niệm này là một yếu tố dự báo rất tốt về khả năng lập trình chung và trong quá trình đào tạo CS đại học thông thường, hai khái niệm này là một trong những trở ngại lớn nhất.

Đệ quy không chỉ là "một hàm gọi chính nó." Bạn sẽ không thực sự đánh giá cao tại sao việc đệ quy lại khó khăn cho đến khi bạn thấy mình vẽ ra các khung stack để tìm ra điều gì sai với trình phân tích cú pháp gốc đệ quy của bạn. Thông thường bạn sẽ có các hàm đệ quy lẫn nhau (hàm A gọi hàm B, gọi hàm C, có thể gọi hàm A). Có thể rất khó để tìm ra điều gì đã sai khi bạn N stackframes nằm sâu trong một chuỗi các hàm đệ quy lẫn nhau.

Đối với con trỏ, một lần nữa, khái niệm con trỏ khá đơn giản: một biến lưu trữ một địa chỉ bộ nhớ. Nhưng một lần nữa, khi có sự cố xảy ra với cấu trúc dữ liệu phức tạp của void**con trỏ trỏ đến các nút khác nhau, bạn sẽ thấy lý do tại sao nó có thể trở nên khó khăn khi bạn đấu tranh để tìm ra lý do tại sao một trong những con trỏ của bạn lại trỏ đến một địa chỉ rác.

Java hỗ trợ con trỏ (chúng được gọi là tài liệu tham khảo) và nó hỗ trợ đệ quy. Vì vậy, trên bề mặt, lập luận của ông xuất hiện vô nghĩa.

Những gì anh ấy thực sự nói về là khả năng gỡ lỗi. Một con trỏ Java (err, Reference) được đảm bảo để trỏ đến một đối tượng hợp lệ. Con trỏ AC không. Và mẹo trong lập trình C, giả sử rằng bạn không sử dụng các công cụ như valgrind , là tìm ra chính xác nơi bạn vặn con trỏ (hiếm khi tại điểm được tìm thấy trong stacktrace).

Vấn đề với con trỏ và đệ quy không phải là chúng khó hiểu, mà là chúng được dạy rất tệ, đặc biệt là đối với các ngôn ngữ như C hoặc C ++ (chủ yếu là vì bản thân các ngôn ngữ đang được dạy kém). Mỗi khi tôi nghe (hoặc đọc) ai đó nói "một mảng chỉ là một con trỏ" tôi chết một chút bên trong.

Tương tự như vậy, mỗi khi ai đó sử dụng hàm Fibonacci để minh họa đệ quy tôi muốn hét lên. Đó là một ví dụ tồi vì phiên bản lặp không khó viết hơn và nó hoạt động ít nhất hoặc tốt hơn so với phiên bản đệ quy và nó không cho bạn cái nhìn sâu sắc thực sự về lý do tại sao một giải pháp đệ quy sẽ hữu ích hoặc mong muốn. Quicksort, cây traversal, vv, là xa ví dụ tốt hơn cho lý do tại sao và làm thế nào đệ quy.

Phải làm quen với con trỏ là một yếu tố làm việc trong một ngôn ngữ lập trình phơi bày chúng. Các thế hệ lập trình viên Fortran đang xây dựng danh sách, cây và ngăn xếp và hàng đợi mà không cần loại con trỏ chuyên dụng (hoặc cấp phát bộ nhớ động) và tôi chưa bao giờ nghe ai cáo buộc Fortran là ngôn ngữ đồ chơi.

Có một số khó khăn với con trỏ:

1. Aliasing Khả năng thay đổi giá trị của một đối tượng bằng cách sử dụng các tên / biến khác nhau.
2. Không cục bộ Khả năng thay đổi giá trị đối tượng trong ngữ cảnh khác với bối cảnh được khai báo (điều này cũng xảy ra với các đối số được truyền bằng tham chiếu).
3. Sự không phù hợp trọn đời Thời gian tồn tại của một con trỏ có thể khác với thời gian tồn tại của đối tượng mà nó trỏ đến và điều đó có thể dẫn đến các tham chiếu không hợp lệ (SEGFAULTS) hoặc rác.
4. Số học con trỏ . Một số ngôn ngữ lập trình cho phép thao tác con trỏ dưới dạng số nguyên và điều đó có nghĩa là con trỏ có thể trỏ đến bất kỳ đâu (kể cả những nơi không mong đợi nhất khi có lỗi). Để sử dụng số học con trỏ một cách chính xác, một lập trình viên phải nhận thức được kích thước bộ nhớ của các đối tượng được trỏ đến, và đó là điều cần suy nghĩ nhiều hơn.
5. Kiểu phôi Khả năng truyền con trỏ từ loại này sang loại khác cho phép ghi đè lên bộ nhớ của một đối tượng khác với mục đích.

Đó là lý do tại sao một lập trình viên phải suy nghĩ thấu đáo hơn khi sử dụng con trỏ (tôi không biết về hai mức độ trừu tượng ). Đây là một ví dụ về những sai lầm điển hình được thực hiện bởi một người mới:

Pair* make_pair(int a, int b)
{
    Pair p;
    p.a = a;
    p.b = b;
    return &p;
}

Lưu ý rằng mã như trên là hoàn toàn hợp lý trong các ngôn ngữ không có khái niệm về con trỏ mà chỉ là một trong các tên (tham chiếu), đối tượng và giá trị, như ngôn ngữ lập trình chức năng và ngôn ngữ có bộ sưu tập rác (Java, Python) .

Khó khăn với các hàm đệ quy xảy ra khi những người không có đủ nền tảng toán học (trong đó đệ quy là kiến ​​thức phổ biến và bắt buộc) cố gắng tiếp cận họ nghĩ rằng hàm này sẽ hoạt động khác nhau tùy thuộc vào số lần nó được gọi trước đó . Vấn đề đó trở nên trầm trọng hơn vì các hàm đệ quy thực sự có thể được tạo ra theo cách mà bạn phải nghĩ theo cách đó để hiểu chúng.

Hãy nghĩ về các hàm đệ quy với các con trỏ được truyền xung quanh, giống như trong quá trình thực hiện thủ tục của Cây Đỏ-Đen trong đó cấu trúc dữ liệu được sửa đổi tại chỗ; đó là một cái gì đó khó khăn hơn để suy nghĩ về một đối tác chức năng .

Nó không được đề cập trong câu hỏi, nhưng vấn đề quan trọng khác mà người mới gặp khó khăn là đồng thời .

Như những người khác đã đề cập, có một vấn đề bổ sung, phi khái niệm với một số cấu trúc ngôn ngữ lập trình: đó là ngay cả khi chúng ta hiểu, những lỗi đơn giản và trung thực với các cấu trúc đó có thể cực kỳ khó gỡ lỗi.

Con trỏ và đệ quy là hai con thú riêng biệt và có những lý do khác nhau khiến chúng trở nên "khó khăn".

Nói chung, con trỏ đòi hỏi một mô hình tinh thần khác với việc gán biến thuần túy. Khi tôi có một biến con trỏ, nó chỉ là: một con trỏ tới một đối tượng khác, dữ liệu duy nhất mà nó chứa là địa chỉ bộ nhớ mà nó trỏ đến. Vì vậy, ví dụ nếu tôi có một con trỏ int32 và gán giá trị trực tiếp cho nó, tôi sẽ không thay đổi giá trị của int, tôi đang chỉ đến một địa chỉ bộ nhớ mới (có rất nhiều thủ thuật gọn gàng bạn có thể làm với điều này ). Điều thú vị hơn nữa là có một con trỏ tới một con trỏ (đây là điều xảy ra khi bạn truyền biến Ref làm hàm Tham số trong C #, hàm có thể gán một đối tượng hoàn toàn khác cho Tham số và giá trị đó sẽ vẫn nằm trong phạm vi khi hàm hoạt động lối thoát hiểm

Đệ quy có một bước nhảy vọt về tinh thần khi học lần đầu tiên bởi vì bạn đang xác định một chức năng theo chính nó. Đó là một khái niệm hoang dã khi bạn lần đầu tiên bắt gặp nó, nhưng một khi bạn nắm bắt được ý tưởng, nó sẽ trở thành bản chất thứ hai.

Nhưng trở lại chủ đề trong tầm tay. Lập luận của Joel không phải là về con trỏ hoặc đệ quy trong chính họ, mà là thực tế là các sinh viên đang bị loại bỏ khỏi cách máy tính thực sự hoạt động. Đây là Khoa học về Khoa học Máy tính. Có một sự khác biệt rõ rệt giữa việc học lập trình và học cách các chương trình hoạt động. Tôi không nghĩ đó là vấn đề quá lớn "Tôi đã học theo cách này vì vậy mọi người nên học theo cách này" khi ông cho rằng nhiều chương trình CS đang trở thành trường thương mại được tôn vinh.

Tôi cho P. Brian +1, vì tôi cảm thấy như anh ta: đệ quy là một khái niệm cơ bản đến nỗi anh ta có những khó khăn nhỏ nhất với nó nên xem xét việc tìm kiếm một công việc tại mac donalds, nhưng sau đó, thậm chí còn có đệ quy:

make a burger:
   put a cold burger on the grill
   wait
   flip
   wait
   hand the fried burger over to the service personel
   unless its end of shift: make a burger

Chắc chắn, sự thiếu hiểu biết cũng có liên quan đến các trường học của chúng tôi. Ở đây người ta nên giới thiệu những con số tự nhiên như Peano, Dedekind và Frege đã làm, vì vậy chúng ta sẽ không gặp quá nhiều khó khăn sau này.

Tôi không đồng ý với Joel rằng vấn đề là một trong những suy nghĩ ở nhiều cấp độ trừu tượng, tôi nghĩ rằng nhiều vấn đề hơn và đệ quy là hai ví dụ điển hình về vấn đề đòi hỏi sự thay đổi trong mô hình tinh thần của mọi người về cách thức hoạt động của các chương trình.

Con trỏ là, tôi nghĩ, trường hợp đơn giản hơn để minh họa. Đối phó với các con trỏ đòi hỏi một mô hình tinh thần về thực thi chương trình, giải thích cho cách các chương trình thực sự hoạt động với địa chỉ bộ nhớ và dữ liệu. Kinh nghiệm của tôi là thường các lập trình viên thậm chí không nghĩ về điều này trước khi họ tìm hiểu về con trỏ. Ngay cả khi họ biết nó theo nghĩa trừu tượng, họ vẫn không áp dụng nó vào mô hình nhận thức của họ về cách thức một chương trình hoạt động. Khi con trỏ được giới thiệu, nó đòi hỏi một sự thay đổi cơ bản trong cách họ nghĩ về cách thức hoạt động của mã.

Đệ quy là vấn đề bởi vì có hai khối khái niệm để hiểu. Đầu tiên là ở cấp độ máy, và giống như con trỏ có thể khắc phục bằng cách phát triển sự hiểu biết tốt về cách các chương trình thực sự được lưu trữ và thực thi. Vấn đề khác với đệ quy là, tôi nghĩ rằng mọi người có xu hướng tự nhiên cố gắng giải mã một vấn đề đệ quy thành một vấn đề không đệ quy, làm vấy bẩn sự hiểu biết về chức năng đệ quy như một cử chỉ. Đây là một vấn đề với những người có nền tảng toán học không đủ hoặc một mô hình tinh thần không gắn kết lý thuyết toán học với sự phát triển của các chương trình.

Vấn đề là, tôi không nghĩ rằng con trỏ và đệ quy là hai lĩnh vực duy nhất có vấn đề đối với những người bị mắc kẹt trong một mô hình tinh thần không đủ. Song song dường như là một lĩnh vực khác mà một số người đơn giản gặp khó khăn và gặp khó khăn trong việc điều chỉnh mô hình tinh thần của họ để giải quyết, đó chỉ là những lần con trỏ và đệ quy dễ kiểm tra trong một cuộc phỏng vấn.

  DATA    |     CODE
          |
 pointer  |   recursion    SELF REFERENTIAL
----------+---------------------------------
 objects  |   macro        SELF MODIFYING
          |
          |

Khái niệm dữ liệu tự tham chiếu và mã làm cơ sở cho định nghĩa của con trỏ và đệ quy tương ứng. Thật không may, sự tiếp xúc rộng rãi với các ngôn ngữ lập trình cấp bách đã khiến sinh viên khoa học máy tính tin rằng họ phải hiểu việc thực hiện thông qua hành vi hoạt động của thời gian chạy của họ khi họ phải tin vào bí ẩn này về khía cạnh chức năng của ngôn ngữ. Tổng hợp tất cả các số lên đến một trăm dường như là một vấn đề đơn giản khi bắt đầu bằng một và thêm nó vào chuỗi tiếp theo và thực hiện ngược lại với sự trợ giúp của các chức năng tự tham chiếu vòng tròn có vẻ gian tà và thậm chí nguy hiểm đối với nhiều người không được sử dụng để đảm bảo an toàn cho chức năng thuần túy.

Khái niệm tự sửa đổi dữ liệu và mã làm cơ sở cho định nghĩa của các đối tượng (tức là dữ liệu thông minh) và macro tương ứng. Tôi đề cập đến những điều này vì chúng thậm chí còn khó hiểu hơn đặc biệt là khi sự hiểu biết vận hành về thời gian chạy được mong đợi từ sự kết hợp của cả bốn khái niệm - ví dụ như macro tạo ra một tập hợp các đối tượng thực hiện một trình phân tích cú pháp đệ quy với sự trợ giúp của một cây con trỏ . Thay vì theo dõi toàn bộ hoạt động của trạng thái từng bước của chương trình qua từng lớp trừu tượng cùng một lúc, các lập trình viên bắt buộc phải học cách tin rằng các biến của chúng chỉ được gán một lần trong các hàm thuần túy và các lệnh lặp lại của cùng một hàm thuần túy với các đối số tương tự luôn mang lại cùng một kết quả (nghĩa là độ trong suốt tham chiếu), ngay cả trong một ngôn ngữ cũng hỗ trợ các hàm không tinh khiết, như Java. Chạy lòng vòng trong vòng tròn sau thời gian chạy là một nỗ lực không có kết quả. Trừu tượng nên đơn giản hóa.

Rất giống với câu trả lời của Anon.
Bên cạnh những khó khăn về nhận thức cho người mới, cả con trỏ và đệ quy đều rất mạnh mẽ và có thể được sử dụng theo những cách khó hiểu.

Nhược điểm của sức mạnh lớn, là chúng cung cấp cho bạn sức mạnh tuyệt vời để làm hỏng chương trình của bạn theo những cách tinh tế.
Lưu trữ một giá trị không có thật vào một biến bình thường là đủ tệ, nhưng lưu trữ một cái gì đó không có thật vào một con trỏ có thể khiến tất cả các loại thảm họa bị trì hoãn xảy ra.
Và tệ hơn, những hiệu ứng đó có thể thay đổi khi bạn cố gắng chẩn đoán / gỡ lỗi nguyên nhân của hành vi chương trình kỳ quái.

Tương tự với đệ quy. Nó có thể là một cách rất mạnh mẽ để tổ chức các công cụ phức tạp - bằng cách nhét sự khó khăn vào cấu trúc dữ liệu ẩn (ngăn xếp).
Nhưng, nếu một cái gì đó được thực hiện sai một cách tinh tế, có thể khó để tìm ra những gì đang xảy ra.