Tại sao chúng ta có gia tăng postfix?

Tuyên bố miễn trừ trách nhiệm : Tôi biết rất rõ ngữ nghĩa của việc tăng tiền tố và hậu tố. Vì vậy xin đừng giải thích cho tôi cách họ làm việc.

Đọc các câu hỏi về stack stack, tôi không thể không nhận thấy rằng các lập trình viên bị nhầm lẫn bởi toán tử gia tăng postfix nhiều lần. Từ đây, câu hỏi sau đây được đặt ra: có trường hợp sử dụng nào trong đó việc tăng tiền tố cung cấp một lợi ích thực sự về chất lượng mã không?

Hãy để tôi làm rõ câu hỏi của tôi với một ví dụ. Đây là một triển khai siêu ngắn gọn của strcpy:

while (*dst++ = *src++);

Nhưng đó không chính xác là mã tự viết tài liệu nhất trong cuốn sách của tôi (và nó tạo ra hai cảnh báo khó chịu trên trình biên dịch lành mạnh). Vì vậy, những gì sai với sự thay thế sau đây?

while (*dst = *src)
{
    ++src;
    ++dst;
}

Sau đó chúng ta có thể thoát khỏi nhiệm vụ khó hiểu trong điều kiện và nhận được mã hoàn toàn không có cảnh báo:

while (*src != '\0')
{
    *dst = *src;
    ++src;
    ++dst;
}
*dst = '\0';

(Có, tôi biết srcvà dstsẽ có các giá trị kết thúc khác nhau trong các giải pháp thay thế này, nhưng vì strcpyngay lập tức trả về sau vòng lặp, nên trong trường hợp này không thành vấn đề.)

Có vẻ như mục đích của việc tăng tiền tố là làm cho mã càng ngắn càng tốt. Tôi chỉ đơn giản là không thấy làm thế nào đây là một cái gì đó chúng ta nên cố gắng. Nếu điều này ban đầu là về hiệu suất, nó vẫn còn liên quan đến ngày hôm nay?

Mặc dù nó đã từng có một số ý nghĩa về hiệu suất, tôi nghĩ lý do thực sự là để thể hiện ý định của bạn một cách sạch sẽ. Câu hỏi thực sự là liệu một cái gì đó while (*d++=*s++);thể hiện ý định rõ ràng hay không. IMO, nó có, và tôi thấy các lựa chọn thay thế mà bạn cung cấp ít rõ ràng hơn - nhưng đó có thể (dễ dàng) là kết quả của việc dành hàng thập kỷ để làm quen với cách mọi thứ được thực hiện. Sau khi học C từ K & R (vì có là hầu như không có cuốn sách khác trên C vào thời điểm đó) có thể giúp quá.

Ở một mức độ nào đó, sự thật là sự căng thẳng được đánh giá ở mức độ lớn hơn nhiều trong mã cũ. Cá nhân, tôi nghĩ rằng đây phần lớn là một điều tốt - hiểu một vài dòng mã thường khá tầm thường; Điều khó khăn là hiểu được khối mã lớn. Các thử nghiệm và nghiên cứu đã cho thấy nhiều lần, rằng việc phù hợp với tất cả các mã trên màn hình cùng một lúc là một yếu tố chính để hiểu mã. Khi màn hình mở rộng, điều này dường như vẫn đúng, vì vậy việc giữ mã (hợp lý) vẫn còn có giá trị.

Tất nhiên là có thể quá nhiệt tình, nhưng tôi không nghĩ là vậy. Cụ thể, tôi nghĩ rằng nó quá mức khi việc hiểu một dòng mã trở nên cực kỳ khó khăn hoặc tốn thời gian - cụ thể, khi hiểu ít dòng mã hơn sẽ tiêu tốn nhiều công sức hơn là hiểu nhiều dòng hơn. Điều đó thường xuyên xảy ra ở Lisp và APL, nhưng dường như (ít nhất là với tôi) là trường hợp ở đây.

Tôi ít quan tâm đến các cảnh báo của trình biên dịch - đó là kinh nghiệm của tôi khi nhiều trình biên dịch phát ra các cảnh báo hoàn toàn vô lý trên cơ sở khá thường xuyên. Mặc dù tôi chắc chắn nghĩ rằng mọi người nên hiểu mã của họ (và bất kỳ cảnh báo nào nó có thể tạo ra), mã tốt xảy ra để kích hoạt cảnh báo trong một số trình biên dịch không nhất thiết là sai. Phải thừa nhận rằng, người mới bắt đầu không phải lúc nào cũng biết những gì họ có thể bỏ qua một cách an toàn, nhưng chúng tôi không ở lại người mới bắt đầu và cũng không cần phải viết mã như chúng tôi.

Đó là, lỗi, là, một điều phần cứng

Thú vị mà bạn sẽ nhận thấy. Sự gia tăng của hậu tố có lẽ là có một số lý do hoàn toàn chính đáng, nhưng giống như nhiều điều trong C, sự phổ biến của nó có thể được truy nguyên từ nguồn gốc của ngôn ngữ.

Mặc dù C được phát triển trên nhiều loại máy đầu tiên và không đủ mạnh, C và Unix lần đầu tiên đạt được thời gian lớn tương đối với các mô hình được quản lý bộ nhớ của PDP-11. Đây là những máy tính tương đối quan trọng trong ngày của họ và Unix là đến nay tốt hơn - theo cấp số nhân tốt hơn - hơn 7 hệ điều hành dể thương khác có sẵn cho -11.

Và, điều đó xảy ra, trên PDP-11,

*--p

và

*p++

... đã được thực hiện trong phần cứng như các chế độ địa chỉ. (Ngoài ra *p, nhưng không có sự kết hợp khác.) Trên những máy sớm, tất cả ít hơn 0,001 GHz, tiết kiệm một hai hướng dẫn hoặc trong một vòng lặp phải gần như đã chờ đợi-một-thứ hai hoặc chờ đợi-một phút hoặc đi-ra-cho -lunch khác biệt. Điều này không nói chính xác với postincrement, nhưng một vòng lặp với postincrement có thể tốt hơn rất nhiều so với lập chỉ mục trước đó.

Kết quả là, các mẫu thiết kế vì các thành ngữ C đã trở thành các macro tinh thần.

Nó giống như khai báo các biến ngay sau khi {... không phải vì C89 là hiện tại nên đây là một yêu cầu, nhưng giờ đây nó là một mẫu mã.

Cập nhật: Rõ ràng, lý do chính *p++là trong ngôn ngữ là bởi vì đó là chính xác những gì một người thường muốn làm. Sự phổ biến của mẫu mã được củng cố bởi phần cứng phổ biến đi kèm và phù hợp với mẫu đã có của ngôn ngữ được thiết kế một chút trước khi PDP-11 xuất hiện.

Ngày nay, không có sự khác biệt nào khi bạn sử dụng mẫu hoặc nếu bạn sử dụng lập chỉ mục và chúng tôi thường lập trình ở mức cao hơn, nhưng nó phải có vấn đề rất lớn trên các máy 0,001GHz đó và sử dụng bất cứ thứ gì khác ngoài *--xhoặc *x++có nghĩa là bạn đã không "lấy" PDP-11, và bạn có thể sẽ có người đến gặp bạn và nói "bạn có biết rằng ..." :-) :-)

Tiền tố và hậu tố --và ++các nhà khai thác đã được giới thiệu trong các ngôn ngữ B (người tiền nhiệm C) bởi Ken Thompson - và không có, họ không được lấy cảm hứng từ PDP-11, trong đó không tồn tại vào thời điểm đó.

Trích dẫn từ "Sự phát triển của ngôn ngữ C" của Dennis Ritchie :

Thompson đã tiến một bước xa hơn bằng cách phát minh ra ++và--toán tử, tăng hoặc giảm; vị trí tiền tố hoặc hậu tố của chúng xác định xem sự thay đổi xảy ra trước hay sau khi lưu ý giá trị của toán hạng. Chúng không phải là phiên bản đầu tiên của B, nhưng xuất hiện trên đường đi. Mọi người thường đoán rằng chúng được tạo ra để sử dụng các chế độ địa chỉ tự động tăng và giảm tự động được cung cấp bởi DEC PDP-11, trong đó C và Unix lần đầu tiên trở nên phổ biến. Điều này là không thể trong lịch sử, vì không có PDP-11 khi B được phát triển. Tuy nhiên, PDP-7 đã có một vài ô nhớ 'tự động tăng', với thuộc tính tham chiếu bộ nhớ gián tiếp thông qua chúng làm tăng ô. Tính năng này có thể gợi ý các nhà khai thác như vậy cho Thompson; khái quát hóa để làm cho cả hai tiền tố và hậu tố là của riêng mình. Thật,++xlà nhỏ hơn so với x=x+1.

Lý do rõ ràng để toán tử hậu sinh tồn tại là do bạn không phải viết các biểu thức như (++x,x-1)hoặc ở (x+=1,x-1)khắp mọi nơi hoặc tách các câu lệnh tầm thường vô dụng với các tác dụng phụ dễ hiểu thành nhiều câu lệnh. Dưới đây là một số ví dụ:

while (*s) x+=*s++-'0';

if (x) *s++='.';

Bất cứ khi nào đọc hoặc viết một chuỗi theo hướng chuyển tiếp, postincrement, và không preincrement, hầu như luôn luôn là hoạt động tự nhiên. Tôi gần như chưa bao giờ gặp phải việc sử dụng trong thế giới thực cho tiền sử dụng và việc sử dụng chính duy nhất tôi tìm thấy để dự đoán là chuyển đổi số thành chuỗi (vì hệ thống chữ viết của con người viết số ngược).

Chỉnh sửa: Trên thực tế, nó sẽ không quá xấu xí; thay vì (++x,x-1)bạn tất nhiên có thể sử dụng ++x-1hoặc (x+=1)-1. Vẫn x++dễ đọc hơn.

PDP-11 cung cấp các hoạt động tăng sau và giảm trước trong tập lệnh. Bây giờ đây không phải là hướng dẫn. Chúng là các công cụ sửa đổi hướng dẫn cho phép bạn chỉ định rằng bạn muốn giá trị của một thanh ghi trước khi nó được tăng lên hoặc sau khi nó bị giảm.

Đây là một bước sao chép từ trong ngôn ngữ máy:

movw (r1)++,(r2)++

đã di chuyển một từ từ vị trí này sang vị trí khác, được chỉ ra bởi các thanh ghi và các thanh ghi sẽ sẵn sàng để làm lại từ đó.

Vì C được xây dựng trên và cho PDP-11, rất nhiều khái niệm hữu ích được tìm thấy trong C. C được dự định là một sự thay thế hữu ích cho ngôn ngữ trình biên dịch. Tăng trước và giảm sau được thêm vào cho đối xứng.

Tôi nghi ngờ nó đã thực sự cần thiết. Theo như tôi biết, nó không biên dịch thành bất kỳ thứ gì nhỏ gọn hơn trên hầu hết các nền tảng hơn là sử dụng mức tăng trước như bạn đã làm, trong vòng lặp. Chỉ là tại thời điểm nó được tạo ra, độ chặt của mã quan trọng hơn sự rõ ràng của mã.

Điều đó không có nghĩa là sự rõ ràng của mã không (hoặc không) quan trọng, nhưng khi bạn nhập vào một modem baud thấp (bất cứ điều gì bạn đo trong baud đều chậm) trong đó mọi thao tác gõ phím phải làm cho nó máy tính lớn và sau đó được lặp lại một byte mỗi lần với một bit được sử dụng làm kiểm tra chẵn lẻ, bạn không muốn phải nhập nhiều.

Đây là loại giống như & và | toán tử có độ ưu tiên thấp hơn ==

Nó được thiết kế với mục đích tốt nhất (phiên bản ngắn mạch của && và ||), nhưng bây giờ nó gây nhầm lẫn cho các lập trình viên hàng ngày và có lẽ nó sẽ không bao giờ thay đổi.

Dù sao, đây chỉ là một câu trả lời mà tôi nghĩ rằng không có câu trả lời hay cho câu hỏi của bạn, nhưng có lẽ tôi sẽ được chứng minh là sai bởi một lập trình viên guru hơn tôi.

--BIÊN TẬP--

Tôi nên lưu ý rằng tôi thấy có cả hai cực kỳ hữu ích, tôi chỉ chỉ ra rằng nó sẽ không thay đổi cho dù có ai thích hay không.

Tôi thích công cụ khai vị postfix khi làm việc với con trỏ (cho dù tôi có bỏ qua chúng hay không) bởi vì

p++

đọc tự nhiên hơn là "di chuyển đến vị trí tiếp theo" so với tương đương

p += 1

mà chắc chắn phải nhầm lẫn người mới bắt đầu lần đầu tiên họ nhìn thấy nó được sử dụng với một con trỏ trong đó sizeof (* p)! = 1.

Bạn có chắc là bạn nêu chính xác vấn đề nhầm lẫn? Không phải điều gây nhầm lẫn cho người mới bắt đầu thực tế là toán tử postfix ++ có quyền ưu tiên cao hơn toán tử dereference * sao cho

*p++

phân tích như

*(p++)

và không

(*p)++

như một số người có thể mong đợi?

(Bạn nghĩ điều đó có tệ không? Xem phần Đọc Tuyên bố C. )

Trong số các yếu tố tinh tế của lập trình tốt là nội địa hóa và tối giản hóa :

• đặt các biến trong một phạm vi sử dụng tối thiểu
• sử dụng const khi không cần truy cập ghi
• Vân vân.

Theo cùng một tinh thần, x++có thể được coi là một cách bản địa hóa một tham chiếu đến giá trị hiện tại xtrong khi ngay lập tức chỉ ra rằng bạn - ít nhất là bây giờ - đã hoàn thành với giá trị đó và muốn chuyển sang giá trị tiếp theo (hợp lệ cho dù xlà inthay một con trỏ hoặc lặp). Với một chút trí tưởng tượng, bạn có thể so sánh điều này với việc để giá trị / vị trí cũ xbị "vượt khỏi phạm vi" ngay lập tức sau khi không còn cần thiết và chuyển sang giá trị mới. Điểm chính xác nơi chuyển đổi có thể được đánh dấu bằng hậu tố++ . Hàm ý rằng đây có lẽ là lần sử dụng cuối cùng của "cái cũ" xcó thể là cái nhìn sâu sắc có giá trị về thuật toán, hỗ trợ người lập trình khi họ quét qua mã xung quanh. Tất nhiên, hậu tố++ có thể đặt lập trình viên tìm kiếm việc sử dụng giá trị mới, có thể tốt hay không tùy thuộc vào thời điểm giá trị mới đó thực sự cần thiết, vì vậy đó là khía cạnh của "nghệ thuật" hoặc "thủ công" của lập trình để xác định thêm gì nữa hữu ích trong hoàn cảnh.

Mặc dù nhiều người mới bắt đầu có thể bị nhầm lẫn bởi một tính năng, nhưng nó đáng để cân bằng với lợi ích lâu dài: người mới bắt đầu không ở lại người mới bắt đầu lâu.

Ồ, rất nhiều câu trả lời không hoàn toàn đúng (nếu tôi có thể quá táo bạo), và xin vui lòng tha thứ cho tôi nếu tôi chỉ ra điều hiển nhiên - đặc biệt là trong nhận xét của bạn để không chỉ ra ngữ nghĩa, nhưng rõ ràng (theo quan điểm của Stroustrup, tôi cho rằng) dường như chưa được đăng! :)

Postfix x++tạo ra một tạm thời được chuyển 'lên trên' trong biểu thức, trong khi biến xsau đó được tăng lên.

Tiền tố ++xkhông tạo ra một đối tượng tạm thời, nhưng tăng 'x' và chuyển kết quả cho biểu thức.

Giá trị là sự tiện lợi, cho những người biết điều hành.

Ví dụ:

int x = 1;
foo(x++); // == foo(1)
// x == 2: true

x = 1;
foo(++x); // == foo(2)
// x == 2: true

Tất nhiên, kết quả của ví dụ này có thể được tạo ra từ mã tương đương khác (và có lẽ ít xiên hơn).

Vậy tại sao chúng ta có toán tử postfix? Tôi đoán bởi vì đó là một thành ngữ vẫn tồn tại, bất chấp sự nhầm lẫn mà nó rõ ràng tạo ra. Đó là một cấu trúc di sản mà trước đây từng được coi là có giá trị, mặc dù tôi không chắc rằng giá trị cảm nhận đó là rất nhiều cho hiệu suất cũng như sự thuận tiện. Sự tiện lợi đó đã không bị mất, nhưng tôi nghĩ rằng sự đánh giá cao về khả năng đọc đã tăng lên, dẫn đến việc đặt câu hỏi về mục đích của nhà điều hành.

Chúng ta có cần toán tử postfix nữa không? Có khả năng là không. Kết quả của nó là khó hiểu và tạo ra một rào cản cho sự dễ hiểu. Một số lập trình viên giỏi chắc chắn sẽ biết ngay nơi tìm thấy nó hữu ích, thường là ở những nơi có vẻ đẹp "PERL-esque" đặc biệt. Chi phí của vẻ đẹp đó là khả năng đọc.

Tôi đồng ý rằng mã rõ ràng có lợi ích hơn độ căng, dễ đọc, dễ hiểu và khả năng duy trì. Nhà thiết kế và quản lý giỏi muốn điều đó.

Tuy nhiên, có một vẻ đẹp nhất định mà một số lập trình viên nhận ra rằng khuyến khích họ tạo mã bằng những thứ hoàn toàn đơn giản - chẳng hạn như toán tử postfix - mã mà họ chưa từng nghĩ đến - hoặc thấy kích thích trí tuệ. Có một cái gì đó cho nó chỉ làm cho nó đẹp hơn, nếu không muốn nói là hơn, mặc dù có lòng tốt.

Nói cách khác, một số người while (*dst++ = *src++);chỉ đơn giản là một giải pháp đẹp hơn, một cái gì đó lấy hơi thở của bạn bằng sự đơn giản của nó, giống như nó là một bàn chải để vẽ. Rằng bạn buộc phải hiểu ngôn ngữ để đánh giá cao vẻ đẹp chỉ làm tăng thêm sự tráng lệ của nó.

Hãy xem xét biện minh ban đầu của Kernighan & Ritchie (bản gốc của K & R trang 42 và 43):

Các khía cạnh khác thường là ++ và - có thể được sử dụng làm tiền tố hoặc tiền tố. (...) Trong bối cảnh không muốn có giá trị nào (..), hãy chọn tiền tố hoặc hậu tố theo sở thích. Nhưng htere là những tình huống mà người này hay người kia được đặc biệt kêu gọi.

Văn bản tiếp tục với một số ví dụ sử dụng gia số trong chỉ mục, với mục tiêu rõ ràng là viết mã " gọn hơn ". Vì vậy, lý do đằng sau các nhà khai thác này là sự tiện lợi của mã nhỏ gọn hơn.

Ba ví dụ được đưa ( squeeze(), getline()và strcat()) chỉ sử dụng postfix trong biểu thức sử dụng lập chỉ mục. Các tác giả so sánh mã với một phiên bản dài hơn không sử dụng gia số nhúng. Điều này xác nhận rằng tập trung vào sự nhỏ gọn.

Điểm nổi bật của K & R trên trang 102, việc sử dụng các toán tử này kết hợp với hội thảo con trỏ (ví dụ *--pvà *p--). Không có ví dụ nào được đưa ra, nhưng một lần nữa, họ nói rõ rằng lợi ích là sự nhỏ gọn.

Ví dụ, tiền tố được sử dụng rất phổ biến khi giảm chỉ mục hoặc con trỏ nhìn chằm chằm từ cuối.

 int i=0; 
 while (i<10) 
     doit (i++);  // calls function for 0 to 9  
                  // i is 10 at this stage
 while (--i >=0) 
     doit (i);    // calls function from 9 to 0 

Tôi sẽ không đồng ý với tiền đề rằng ++p, p++bằng cách nào đó khó đọc hoặc không rõ ràng. Một nghĩa là "tăng p và sau đó đọc p", còn lại có nghĩa là "đọc p và sau đó tăng p". Trong cả hai trường hợp, toán tử trong mã chính xác là vị trí của nó trong phần giải thích mã, vì vậy nếu bạn biết ++nghĩa là gì , bạn sẽ biết mã kết quả có nghĩa là gì.

Bạn có thể tạo mã obfuscated sử dụng bất kỳ cú pháp, nhưng tôi không thấy một trường hợp ở đây là p++/ ++plà vốn obfuscatory.

đây là từ POV của một kỹ sư điện:

có nhiều bộ xử lý có các toán tử tăng sau và giảm trước tích hợp cho mục đích duy trì ngăn xếp cuối cùng trước xuất trước (LIFO).

nó có thể giống như:

 float stack[4096];
 int stack_pointer = 0;

 ... 

 #define push_stack(arg) stack[stack_pointer++] = arg;
 #define pop_stack(arg) arg = stack[--stack_pointer];

 ...

i dunno, nhưng đó là lý do tôi mong đợi để thấy cả toán tử gia tăng tiền tố và hậu tố.

Để nhấn mạnh quan điểm của Barshe về sự nhỏ gọn, tôi muốn hiển thị cho bạn một số mã từ động cơ V6. Đây là một phần của trình biên dịch C gốc, từ http://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/c/c00.c :

/*
 * Look up the identifier in symbuf in the symbol table.
 * If it hashes to the same spot as a keyword, try the keyword table
 * first.  An initial "." is ignored in the hash.
 * Return is a ptr to the symbol table entry.
 */
lookup()
{
    int ihash;
    register struct hshtab *rp;
    register char *sp, *np;

    ihash = 0;
    sp = symbuf;
    if (*sp=='.')
        sp++;
    while (sp<symbuf+ncps)
        ihash =+ *sp++;
    rp = &hshtab[ihash%hshsiz];
    if (rp->hflag&FKEYW)
        if (findkw())
            return(KEYW);
    while (*(np = rp->name)) {
        for (sp=symbuf; sp<symbuf+ncps;)
            if (*np++ != *sp++)
                goto no;
        csym = rp;
        return(NAME);
    no:
        if (++rp >= &hshtab[hshsiz])
            rp = hshtab;
    }
    if(++hshused >= hshsiz) {
        error("Symbol table overflow");
        exit(1);
    }
    rp->hclass = 0;
    rp->htype = 0;
    rp->hoffset = 0;
    rp->dimp = 0;
    rp->hflag =| xdflg;
    sp = symbuf;
    for (np=rp->name; sp<symbuf+ncps;)
        *np++ = *sp++;
    csym = rp;
    return(NAME);
}

Đây là mã được thông qua trong samizdat như một nền giáo dục theo phong cách tốt, nhưng chúng tôi sẽ không bao giờ viết nó như thế này ngày hôm nay. Hãy xem có bao nhiêu tác dụng phụ đã được đóng gói vào ifvà các whileđiều kiện, và ngược lại, làm thế nào cả hai forvòng lặp không có biểu thức gia tăng bởi vì điều đó được thực hiện trong thân vòng lặp. Nhìn vào cách các khối chỉ được bọc trong niềng răng khi thực sự cần thiết.

Một phần của điều này chắc chắn là tối ưu hóa vi mô thủ công mà chúng tôi mong đợi trình biên dịch sẽ thực hiện cho chúng tôi hôm nay, nhưng tôi cũng sẽ đưa ra giả thuyết rằng khi toàn bộ giao diện của bạn với máy tính là một tty kính 80x25, bạn muốn mã của mình càng dày đặc càng tốt để bạn có thể nhìn thấy nhiều hơn cùng một lúc.

(Sử dụng bộ đệm toàn cầu cho mọi thứ có lẽ là một sự nôn nao từ việc cắt răng của một người bằng ngôn ngữ lắp ráp.)

Có lẽ bạn cũng nên nghĩ về mỹ phẩm.

while( i++ )

được cho là "có vẻ tốt hơn"

while( i+=1 )

Vì một số lý do, toán tử tăng sau trông rất hấp dẫn. Nó ngắn, ngọt ngào và tăng mọi thứ lên 1. So sánh nó với tiền tố:

while( ++i )

"Nhìn ngược" phải không? Bạn không bao giờ thấy một dấu cộng ĐẦU TIÊN trong toán học, ngoại trừ khi ai đó ngớ ngẩn với việc chỉ định một cái gì đó tích cực ( +0hoặc một cái gì đó tương tự). Chúng ta đã từng thấy ĐỐI TƯỢNG + SOMETHING

Nó có phải là một cái gì đó để làm với phân loại? A, A +, A ++? Tôi có thể nói với bạn rằng ban đầu tôi rất vui khi người Python xóa operator++ngôn ngữ của họ!

Đếm ngược 9 đến 0, bao gồm:

for (unsigned int i=10; i-- > 0;)  {
    cout << i << " ";
}

Hoặc vòng lặp while tương đương.