làm {Lôi} trong khi (sai)

Tôi đã xem xét một số mã bởi một cá nhân và nhận thấy anh ta dường như có một mẫu trong các chức năng của mình:

<return-type> function(<params>)
{
 <initialization>

 do
 {
   <main code for function>
 }
 while(false);

 <tidy-up & return>
}

Nó không tệ , kỳ dị hơn (mã thực tế khá gọn gàng và không có gì đáng ngạc nhiên). Đó không phải là thứ tôi đã thấy trước đây và tôi tự hỏi liệu có ai có thể nghĩ ra bất kỳ logic nào đằng sau nó không - có lẽ là một ngôn ngữ khác?

Bạn có thể breakra khỏi do{...}while(false).

Rất nhiều người chỉ ra rằng nó thường được sử dụng để giải lao như một cách viết "goto" vụng về. Điều đó có thể đúng nếu nó được viết trực tiếp trong hàm.

Trong một macro, OTOH, do { something; } while (false)là một cách thuận tiện để FORCE một dấu chấm phẩy sau khi gọi macro, hoàn toàn không có mã thông báo nào khác được phép theo dõi.

Và một khả năng khác là đã từng có một vòng lặp ở đó hoặc lặp đi lặp lại được dự kiến ​​sẽ được thêm vào trong tương lai (ví dụ: trong phát triển dựa trên thử nghiệm, việc lặp lại không cần thiết để vượt qua các thử nghiệm, nhưng về mặt logic thì sẽ có ý nghĩa lặp lại ở đó nếu chức năng cần thiết để có phần chung hơn so với yêu cầu hiện tại)

Sự phá vỡ như goto có lẽ là câu trả lời, nhưng tôi sẽ đưa ra một ý tưởng khác.

Có lẽ anh ta muốn có một biến được xác định cục bộ và sử dụng cấu trúc này để có một phạm vi mới.

Hãy nhớ rằng trong khi C ++ gần đây cho phép {...}mọi nơi, điều này không phải lúc nào cũng đúng.

Tôi đã thấy nó được sử dụng như một mẫu hữu ích khi có nhiều điểm thoát tiềm năng cho hàm, nhưng mã dọn dẹp tương tự luôn được yêu cầu bất kể hàm thoát ra như thế nào.

Nó có thể làm cho mệt mỏi nếu / khác - nếu cây dễ đọc hơn rất nhiều, bằng cách chỉ cần ngắt bất cứ khi nào đạt đến điểm thoát, với phần còn lại của logic logic sau đó.

Mẫu này cũng hữu ích trong các ngôn ngữ không có câu lệnh goto. Có lẽ đó là nơi lập trình viên ban đầu học mô hình.

Tôi đã thấy mã như vậy để bạn có thể sử dụng breaknhư một gotoloại.

Đây chỉ là một sự đồi trụy whileđể có được các sơ đồ goto tidy-upmà không sử dụng từ goto.

Đó là hình thức xấu bởi vì khi bạn sử dụng các vòng lặp khác bên ngoài while, nó breakstrở nên mơ hồ với người đọc. "Đây có phải là để thoát khỏi goto không? Hay điều này chỉ nhằm thoát ra khỏi vòng lặp bên trong?"

Tôi nghĩ rằng nó thuận tiện hơn để viết breakthay vì goto end. Bạn thậm chí không phải nghĩ ra một tên cho nhãn làm cho ý định rõ ràng hơn: Bạn không muốn chuyển sang một nhãn với một tên cụ thể. Bạn muốn ra khỏi đây.

Ngoài ra cơ hội là bạn sẽ cần niềng răng nào. Vì vậy, đây là do{...}while(false);phiên bản:

do {
   // code
   if (condition) break; // or continue
   // more code
} while(false);

Và đây là cách bạn sẽ phải thể hiện nó nếu bạn muốn sử dụng goto:

{
   // code
   if (condition) goto end;
   // more code
}
end:

Tôi nghĩ rằng ý nghĩa của phiên bản đầu tiên dễ nắm bắt hơn nhiều. Ngoài ra, nó dễ viết hơn, dễ mở rộng hơn, dễ dịch sang ngôn ngữ không hỗ trợ goto, v.v.

Mối quan tâm được đề cập thường xuyên nhất về việc sử dụng breaklà nó được ngụy trang rất tệ goto. Nhưng thực sự breakcó nhiều điểm tương đồng với return: Cả hai hướng dẫn đều nhảy ra khỏi một khối mã được cấu trúc khá nhiều so với goto. Tuy nhiên, cả hai hướng dẫn đều cho phép nhiều điểm thoát trong một khối mã đôi khi có thể gây nhầm lẫn. Sau tất cả, tôi sẽ cố gắng đưa ra giải pháp rõ ràng nhất, bất cứ điều gì trong tình huống cụ thể.

Thủ thuật này được sử dụng bởi các lập trình viên quá ngại sử dụng một gotomã rõ ràng trong mã của họ. Tác giả của đoạn mã trên muốn có khả năng nhảy trực tiếp đến điểm "dọn dẹp và trả lại" từ giữa đoạn mã. Nhưng họ không muốn sử dụng nhãn hiệu và rõ ràng goto. Thay vào đó, họ có thể sử dụng breakbên trong cơ thể của chu kỳ "giả" ở trên để đạt được hiệu quả tương tự.

Đó là một thực tế rất phổ biến. Trong C . Tôi cố gắng nghĩ về nó như thể bạn muốn nói dối chính mình theo cách "Tôi không sử dụng goto". Nghĩ về nó, sẽ không có gì sai với việc gotosử dụng tương tự. Trong thực tế, nó cũng sẽ làm giảm mức độ thụt.

Điều đó nói rằng, mặc dù, tôi nhận thấy, rất thường xuyên do..whilecác vòng lặp này có xu hướng phát triển. Và sau đó họ nhận được ifs và elses bên trong, khiến cho mã thực sự không thể đọc được, chứ đừng nói là có thể kiểm tra được.

Những người do..whilethường được dự định để làm sạch . Bằng mọi cách có thể, tôi thích sử dụng RAII và quay lại sớm từ một chức năng ngắn . Mặt khác, C không cung cấp cho bạn nhiều tiện ích như C ++ , tạo ra một do..whiletrong những cách tiếp cận tốt nhất để dọn dẹp.

Nó trông giống như một lập trình viên C. Trong C ++, các biến tự động có các hàm hủy mà bạn sử dụng để dọn dẹp, do đó không nên dọn dẹp trước khi trả về. Trong C, bạn không có thành ngữ RAII này , vì vậy nếu bạn có mã dọn dẹp chung, bạn có thể gotosử dụng nó hoặc sử dụng vòng lặp một lần như trên.

Nhược điểm chính của nó so với thành ngữ C ++ là nó sẽ không gọn gàng nếu một ngoại lệ được ném vào cơ thể. C không có ngoại lệ, vì vậy đây không phải là vấn đề, nhưng nó khiến nó trở thành thói quen xấu trong C ++.

Một số giải thích. Cái đầu tiên là chung, cái thứ hai là dành riêng cho các macro tiền xử lý C với các tham số:

Kiểm soát lưu lượng

Tôi đã thấy điều này được sử dụng trong mã C đơn giản. Về cơ bản, đây là phiên bản an toàn hơn của goto, vì bạn có thể thoát ra khỏi nó và tất cả bộ nhớ được dọn sạch đúng cách.

Tại sao một cái gì đó gotogiống như là tốt? Vâng, nếu bạn có mã nơi khá nhiều mỗi dòng có thể trả về một lỗi, nhưng bạn cần phải phản ứng với tất cả chúng cùng một cách (ví dụ bằng cách bàn giao các lỗi để người gọi của bạn sau khi dọn dẹp), nó thường dễ đọc hơn để tránh if( error ) { /* cleanup and error string generation and return here */ }như nó tránh sự trùng lặp của mã dọn dẹp.

Tuy nhiên, trong C ++, bạn có ngoại lệ + RAII cho chính xác mục đích này, vì vậy tôi sẽ coi đó là phong cách mã hóa xấu.

Kiểm tra dấu chấm phẩy

Nếu bạn quên dấu chấm phẩy sau khi gọi macro giống như hàm, các đối số có thể co lại theo cách không mong muốn và biên dịch thành cú pháp hợp lệ. Tưởng tượng vĩ mô

#define PRINT_IF_DEBUGMODE_ON(msg) if( gDebugModeOn ) printf("foo");

Điều đó vô tình được gọi là

if( foo )
    PRINT_IF_DEBUGMODE_ON("Hullo\n")
else
    doSomethingElse();

Các "khác" sẽ được coi là liên quan đến việc gDebugModeOn, vì vậy khi foolà false, chính xác đảo ngược những gì đã được dự định sẽ xảy ra.

Cung cấp một phạm vi cho các biến tạm thời.

Vì do / while có dấu ngoặc nhọn, các biến tạm thời có phạm vi được xác định rõ ràng mà chúng không thể thoát.

Tránh các cảnh báo "có thể không mong muốn"

Một số macro chỉ được kích hoạt trong các bản dựng gỡ lỗi. Bạn định nghĩa chúng như:

#if DEBUG
#define DBG_PRINT_NUM(n) printf("%d\n",n);
#else
#define DBG_PRINT_NUM(n) 
#endif

Bây giờ nếu bạn sử dụng điều này trong một bản phát hành bên trong một điều kiện, nó sẽ biên dịch thành

if( foo )
    ;

Nhiều trình biên dịch xem điều này giống như

if( foo );

Mà thường được viết vô tình. Vì vậy, bạn nhận được một cảnh báo. Do {} while (false) ẩn điều này khỏi trình biên dịch và được nó chấp nhận như một dấu hiệu cho thấy bạn thực sự không muốn làm gì ở đây.

Tránh bắt các dòng bởi các điều kiện

Macro từ ví dụ trước:

if( foo )
    DBG_PRINT_NUM(42)
doSomething();

Bây giờ, trong một bản dựng gỡ lỗi, vì chúng ta cũng thường bao gồm dấu chấm phẩy, điều này biên dịch tốt. Tuy nhiên, trong bản phát hành, bản dựng này đột nhiên biến thành:

if( foo )

doSomething();

Hoặc được định dạng rõ ràng hơn

if( foo )
    doSomething();

Đó không phải là tất cả những gì đã được dự định. Việc thêm một {...} while (false) xung quanh macro sẽ biến dấu chấm phẩy bị thiếu thành một lỗi biên dịch.

Điều đó có nghĩa gì với OP?

Nói chung, bạn muốn sử dụng các ngoại lệ trong C ++ để xử lý lỗi và các mẫu thay vì macro. Tuy nhiên, trong trường hợp rất hiếm khi bạn vẫn cần macro (ví dụ: khi tạo tên lớp bằng cách sử dụng dán mã thông báo) hoặc bị giới hạn ở đồng bằng C, đây là một mẫu hữu ích.

Có lẽ nó được sử dụng để breakcó thể được sử dụng bên trong để hủy bỏ việc thực thi mã tiếp theo tại bất kỳ thời điểm nào:

do {
    if (!condition1) break;
    some_code;
    if (!condition2) break;
    some_further_code;
    // …
} while(false);

Tôi nghĩ rằng điều này được thực hiện để sử dụng breakhoặc continuebáo cáo. Một số loại mã "goto".

Thật đơn giản: Rõ ràng bạn có thể nhảy ra khỏi vòng lặp giả bất cứ lúc nào bằng cách sử dụng breakcâu lệnh. Hơn nữa, dokhối là một phạm vi riêng biệt (cũng có thể đạt được { ... }chỉ với ).

Trong tình huống như vậy, có thể nên sử dụng RAII (các đối tượng tự động hủy chính xác khi hàm kết thúc). Một cấu trúc tương tự khác là việc sử dụng goto- vâng, tôi biết điều đó là xấu , nhưng nó có thể được sử dụng để có mã dọn dẹp chung như vậy:

<return-type> function(<params>)
{
 <initialization>

 <main code for function using "goto error;" if something goes wrong>

 <tidy-up in success case & return>

 error:

 <commmon tidy-up actions for error case & return error code or throw exception>
}

(Như một bên: Cấu trúc do-while-false được sử dụng trong Lua để đưa ra continuetuyên bố bị thiếu .)

Nhiều người trả lời đã đưa ra lý do cho do{(...)break;}while(false). Tôi muốn bổ sung cho bức tranh bằng một ví dụ thực tế khác.

Trong đoạn mã sau tôi phải đặt liệt kê operationdựa trên địa chỉ được datatrỏ bởi con trỏ. Bởi vì trường hợp chuyển đổi chỉ có thể được sử dụng trên các loại vô hướng nên tôi đã làm nó không hiệu quả theo cách này

if (data == &array[o1])
    operation = O1;
else if (data == &array[o2])
    operation = O2;
else if (data == &array[on])
    operation = ON;

Log("operation:",operation);

Nhưng vì Log () và phần còn lại của mã lặp lại cho bất kỳ giá trị hoạt động được chọn nào, tôi đã đi lang thang làm thế nào để bỏ qua phần so sánh còn lại khi địa chỉ đã được phát hiện. Và đây là nơi do{(...)break;}while(false)có ích.

do {
    if (data == &array[o1]) {
        operation = O1;
        break;
    }
    if (data == &array[o2]) {
        operation = O2;
        break;
    }
    if (data == &array[on]) {
        operation = ON;
        break;
    }
} while (false);

Log("operation:",operation);

Người ta có thể tự hỏi tại sao anh ta không thể làm điều tương tự breaktrong một iftuyên bố, như:

if (data == &array[o1])
{
    operation = O1;
    break;
}
else if (...)

breaktương tác hoàn toàn với kèm theo gần nhất vòng lặp hoặc switch, cho dù đó là một for, whilehoặc do .. whileloại, vì vậy không may rằng sẽ không làm việc.

Tác giả bao nhiêu tuổi

Tôi hỏi bởi vì tôi đã từng bắt gặp một số mã Fortran thời gian thực đã làm điều đó, vào cuối những năm 80. Hóa ra đó là một cách thực sự tốt để mô phỏng các luồng trên HĐH mà không có chúng. Bạn chỉ cần đặt toàn bộ chương trình (trình lập lịch biểu của bạn) vào một vòng lặp và gọi từng "thói quen" luồng "của mình. Các luồng thường là các vòng lặp lặp đi lặp lại cho đến khi một trong số các điều kiện xảy ra (thường là một số lượng nhất định Thời gian đã trôi qua) Đó là "đa nhiệm hợp tác", theo đó, tùy thuộc vào các luồng riêng lẻ để từ bỏ CPU mọi lúc và sau đó các luồng khác không bị bỏ đói. Bạn có thể lồng các lệnh gọi chương trình con lặp để mô phỏng mức độ ưu tiên của luồng các ban nhạc.

Ngoài các 'ví dụ goto' đã được đề cập, thành ngữ do ... while (0) đôi khi được sử dụng trong định nghĩa macro để cung cấp dấu ngoặc trong định nghĩa và vẫn có trình biên dịch hoạt động với việc thêm dấu hai chấm vào cuối một cuộc gọi vĩ mô.

http://groups.google.com/group/comp.soft-sys.ace/browse_thread/thread/52f670f1292f30a4?tvc=2&q=fter + (0)

Tôi đồng ý với hầu hết các áp phích về việc sử dụng như một chiếc goto được ngụy trang mỏng. Macro cũng đã được đề cập như một động lực tiềm năng để viết mã theo phong cách.

Tôi cũng đã thấy cấu trúc này được sử dụng trong các môi trường C / C ++ hỗn hợp như một ngoại lệ của một người nghèo. Có thể sử dụng "do {} while (false)" với "break" để bỏ qua đến cuối khối mã nếu có gì đó thường đảm bảo sẽ gặp phải ngoại lệ trong vòng lặp.

Tôi cũng đã xây dựng cấu trúc này được sử dụng trong các cửa hàng nơi hệ tư tưởng "lợi nhuận duy nhất cho mỗi chức năng" được thi hành. Một lần nữa, điều này thay cho một "goto" rõ ràng - nhưng động lực là để tránh nhiều điểm trả về, không "bỏ qua" mã và tiếp tục thực thi thực tế trong chức năng đó.

Tôi làm việc với Adobe InDesign SDK và các ví dụ SDK InDesign có hầu hết mọi chức năng được viết như thế này. Đó là do thực tế là chức năng thường thực sự dài. Nơi bạn cần thực hiện QueryInterface (...) để lấy bất cứ thứ gì từ mô hình đối tượng ứng dụng. Vì vậy, thông thường mọi QueryInterface được theo sau bởi ifkhông hoạt động tốt, phá vỡ.

Nhiều người đã tuyên bố sự tương đồng giữa cấu trúc này và a goto, và bày tỏ sự ưa thích đối với goto. Có lẽ nền tảng của người này bao gồm một môi trường nơi goto bị nghiêm cấm bởi các nguyên tắc mã hóa?

Một lý do khác mà tôi có thể nghĩ đến là nó trang trí niềng răng, trong khi tôi tin rằng một niềng răng trần tiêu chuẩn C ++ mới hơn không ổn (ISO C không thích chúng). Nếu không để yên một máy phân tích tĩnh như lint.

Không chắc chắn tại sao bạn muốn chúng, có thể là phạm vi thay đổi hoặc lợi thế với trình gỡ lỗi.

Xem vòng lặp Trivial Do While và Niềng răng tốt từ C2.

Để làm rõ thuật ngữ của tôi (mà tôi tin là tuân theo cách sử dụng tiêu chuẩn):

Niềng răng trần :

init();
...
{
c = NULL;
mkwidget(&c);
finishwidget(&c);
}
shutdown();

Niềng răng trống (NOP):

{}

ví dụ

while (1)
   {}  /* Do nothing, endless loop */

Khối :

if (finished)
{
     closewindows(&windows);
     freememory(&cache);
}

mà sẽ trở thành

if (finished)
     closewindows(&windows);
freememory(&cache);

nếu các dấu ngoặc được loại bỏ, do đó thay đổi luồng thực hiện, không chỉ phạm vi của các biến cục bộ. Do đó, không "tự do" hay "trần trụi".

Niềng răng trần hoặc khối có thể được sử dụng để biểu thị bất kỳ phần mã nào có thể là tiềm năng cho hàm (nội tuyến) mà bạn muốn đánh dấu, nhưng không được cấu trúc lại tại thời điểm đó.

Đó là một cách giả tạo để mô phỏng GOTOvì hai cái này giống hệt nhau trên thực tế:

// NOTE: This is discouraged!
do {
    if (someCondition) break;
    // some code be here
} while (false);
// more code be here

và:

// NOTE: This is discouraged, too!
if (someCondition) goto marker;
// some code be here
marker:
// more code be here

Mặt khác, cả hai điều này thực sự nên được thực hiện với ifs:

if (!someCondition) {
    // some code be here
}
// more code be here

Mặc dù việc lồng có thể trở nên hơi xấu nếu bạn chỉ biến một chuỗi dài về phía trước GOTOthành ifs lồng nhau . Câu trả lời thực sự là tái cấu trúc thích hợp, mặc dù, không bắt chước các cấu trúc ngôn ngữ cổ xưa.

Nếu bạn đang cố gắng chuyển ngữ một thuật toán với GOTOs trong đó, bạn có thể làm điều đó với thành ngữ này. Tuy nhiên, đó chắc chắn là không chuẩn và là một chỉ báo tốt cho thấy bạn không tuân thủ chặt chẽ các thành ngữ dự kiến ​​của ngôn ngữ.

Tôi không nhận thức được bất kỳ ngôn ngữ giống như C trong đó thực sự là một giải pháp thành ngữ cho bất cứ điều gì.

Bạn có thể có thể cấu trúc lại toàn bộ mớ hỗn độn thành một cái gì đó hợp lý hơn để làm cho nó thành ngữ hơn và dễ đọc hơn nhiều.

Một số lập trình viên thích chỉ có một lối ra / trả lại duy nhất từ ​​các chức năng của họ. Việc sử dụng một hình nộm làm {....} while (false); cho phép bạn "thoát ra" khỏi vòng lặp giả sau khi bạn hoàn thành và vẫn có một lần quay lại.

Tôi là một lập trình viên java, vì vậy ví dụ của tôi sẽ giống như

import java.util.Arrays;
import java.util.List;
import java.util.Set;
import java.util.stream.Collectors;
import java.util.stream.Stream;

public class p45
{
    static List<String> cakeNames = Arrays.asList("schwarzwald torte", "princess", "icecream");
    static Set<Integer> forbidden = Stream.of(0, 2).collect(Collectors.toSet());

    public static  void main(String[] argv)
    {
        for (int i = 0; i < 4; i++)
        {
            System.out.println(String.format("cake(%d)=\"%s\"", i, describeCake(i)));
        }
    }


    static String describeCake(int typeOfCake)
    {
        String result = "unknown";
        do {
            // ensure type of cake is valid
            if (typeOfCake < 0 || typeOfCake >= cakeNames.size()) break;

            if (forbidden.contains(typeOfCake)) {
                result = "not for you!!";
                break;
            }

            result = cakeNames.get(typeOfCake);
        } while (false);
        return result;
    }
}

Trong những trường hợp như vậy tôi sử dụng

switch(true) {
   case condution1:
      ...
      break;
   case condution2:
      ...
      break;
}

Điều này thật thú vị. Có lẽ có những phá vỡ trong vòng lặp như những người khác đã nói. Tôi sẽ làm theo cách này:

while(true)
{
   <main code for function>
   break; // at the end.
}