Tại sao Java không hỗ trợ ints không dấu?

Tại sao Java không bao gồm hỗ trợ cho các số nguyên không dấu?

Tôi dường như là một thiếu sót kỳ lạ, vì họ cho phép một người viết mã ít có khả năng tạo ra tràn vào đầu vào lớn bất ngờ.

Hơn nữa, sử dụng số nguyên không dấu có thể là một hình thức tự viết tài liệu, vì chúng chỉ ra rằng giá trị mà số nguyên không dấu được dự định giữ không bao giờ được coi là âm.

Cuối cùng, trong một số trường hợp, số nguyên không dấu có thể hiệu quả hơn cho các hoạt động nhất định, chẳng hạn như phân chia.

Nhược điểm bao gồm những gì?

Đây là từ một cuộc phỏng vấn với Gosling và những người khác , về sự đơn giản:

Gosling: Đối với tôi là một nhà thiết kế ngôn ngữ, điều mà tôi không thực sự coi mình như những ngày này, điều "đơn giản" thực sự có nghĩa là gì, tôi có thể mong đợi J. Random Developer giữ thông số kỹ thuật trong đầu. Định nghĩa đó nói rằng, chẳng hạn, Java không - và trên thực tế, rất nhiều ngôn ngữ này kết thúc với rất nhiều trường hợp góc, những điều mà không ai thực sự hiểu. Kiểm tra bất kỳ nhà phát triển C nào về unsign, và bạn sẽ sớm phát hiện ra rằng hầu như không có nhà phát triển C nào thực sự hiểu những gì diễn ra với unsign, số học không dấu là gì. Những điều như thế làm cho C phức tạp. Phần ngôn ngữ của Java là, tôi nghĩ, khá đơn giản. Các thư viện bạn phải tìm kiếm.

Đọc giữa các dòng, tôi nghĩ logic là như thế này:

• nói chung, các nhà thiết kế Java muốn đơn giản hóa các tiết mục của các kiểu dữ liệu có sẵn
• cho các mục đích hàng ngày, họ cảm thấy rằng nhu cầu phổ biến nhất là các loại dữ liệu đã ký
• để thực hiện một số thuật toán nhất định, đôi khi số học không dấu là cần thiết, nhưng loại lập trình viên sẽ thực hiện các thuật toán đó cũng sẽ có kiến ​​thức để "làm việc tròn" thực hiện số học không dấu với các loại dữ liệu đã ký

Hầu hết, tôi muốn nói rằng đó là một quyết định hợp lý. Có thể, tôi sẽ có:

• tạo byte không dấu, hoặc ít nhất đã cung cấp một lựa chọn thay thế được ký / không dấu, có thể với các tên khác nhau, cho một loại dữ liệu này (làm cho nó được ký là tốt cho tính nhất quán, nhưng khi nào bạn cần một byte đã ký?)
• thực hiện với 'short' (lần cuối bạn sử dụng số học có chữ ký 16 bit là khi nào?)

Tuy nhiên, với một chút loại bỏ, các thao tác trên các giá trị không dấu lên đến 32 bit không có gì xấu và hầu hết mọi người không cần phân chia hoặc so sánh 64 bit không dấu.

Đây là một câu hỏi cũ hơn và pat đã đề cập ngắn gọn về char, tôi chỉ nghĩ rằng tôi nên mở rộng điều này cho những người khác sẽ xem xét điều này trên đường. Chúng ta hãy xem xét kỹ hơn về các kiểu nguyên thủy của Java:

byte - Số nguyên có chữ ký 8 bit

short - Số nguyên có chữ ký 16 bit

int - Số nguyên có chữ ký 32 bit

long - Số nguyên có chữ ký 64 bit

char - Ký tự 16 bit (số nguyên không dấu)

Mặc dù charkhông hỗ trợ unsignedsố học, nhưng về cơ bản nó có thể được coi là một unsignedsố nguyên. Bạn sẽ phải đưa các phép toán số học trở lại một cách rõ ràng char, nhưng nó cung cấp cho bạn một cách để xác định các unsignedsố.

char a = 0;
char b = 6;
a += 1;
a = (char) (a * b);
a = (char) (a + b);
a = (char) (a - 16);
b = (char) (b % 3);
b = (char) (b / a);
//a = -1; // Generates complier error, must be cast to char
System.out.println(a); // Prints ? 
System.out.println((int) a); // Prints 65532
System.out.println((short) a); // Prints -4
short c = -4;
System.out.println((int) c); // Prints -4, notice the difference with char
a *= 2;
a -= 6;
a /= 3;
a %= 7;
a++;
a--;

Có, không có hỗ trợ trực tiếp cho các số nguyên không dấu (rõ ràng, tôi sẽ không phải chuyển hầu hết các hoạt động của mình trở lại char nếu có hỗ trợ trực tiếp). Tuy nhiên, chắc chắn tồn tại một kiểu dữ liệu nguyên thủy không dấu. Tôi cũng muốn thấy một byte không dấu, nhưng tôi đoán tăng gấp đôi chi phí bộ nhớ và thay vào đó sử dụng char là một lựa chọn khả thi.

Biên tập

Với JDK8, có các API mới cho Longvà Integercung cấp các phương thức của trình trợ giúp khi xử lý longvà intcác giá trị là các giá trị không dấu.

• compareUnsigned
• divideUnsigned
• parseUnsignedInt
• parseUnsignedLong
• remainderUnsigned
• toUnsignedLong
• toUnsignedString

Ngoài ra, Guava cung cấp một số phương thức trợ giúp để thực hiện những điều tương tự tại các loại số nguyên giúp thu hẹp khoảng cách còn lại do thiếu hỗ trợ riêng cho unsignedsố nguyên.

Java có các kiểu không dấu hoặc ít nhất một kiểu: char là một dấu ngắn không dấu. Vì vậy, bất cứ lý do gì mà Gosling ném lên, đó thực sự chỉ là sự thiếu hiểu biết của anh ta tại sao không có loại không dấu nào khác.

Ngoài ra các loại ngắn: quần short được sử dụng tất cả các thời gian cho đa phương tiện. Lý do là bạn có thể ghép 2 mẫu trong một dấu dài 32 bit không dấu và vectơ nhiều thao tác. Điều tương tự với dữ liệu 8 bit và byte không dấu. Bạn có thể phù hợp với 4 hoặc 8 mẫu trong một đăng ký để vector hóa.

Ngay sau khi ints đã ký và không dấu được trộn lẫn trong một biểu thức, mọi thứ bắt đầu trở nên lộn xộn và bạn có thể sẽ mất thông tin. Việc giới hạn Java đối với các int đã ký chỉ thực sự làm sáng tỏ mọi thứ. Tôi rất vui vì tôi không phải lo lắng về toàn bộ doanh nghiệp đã ký / chưa ký, mặc dù đôi khi tôi bỏ lỡ bit thứ 8 trong một byte.

http://skimecoder.blogspot.com/2006/09/java-tutorials-why-no-unsign.html

Anh chàng này nói bởi vì tiêu chuẩn C định nghĩa các hoạt động liên quan đến ints không dấu và đã ký được coi là không dấu. Điều này có thể khiến các số nguyên có dấu âm cuộn quanh thành một số nguyên lớn không dấu, có khả năng gây ra lỗi.

Tôi nghĩ rằng Java là tốt như nó là, thêm không dấu sẽ làm phức tạp nó mà không đạt được nhiều. Ngay cả với mô hình số nguyên được đơn giản hóa, hầu hết các lập trình viên Java cũng không biết các kiểu số cơ bản hoạt động như thế nào - chỉ cần đọc cuốn sách Java Puzzlers để xem những hiểu lầm nào bạn có thể nắm giữ.

Đối với lời khuyên thực tế:

• Nếu giá trị của bạn có kích thước tùy ý và không phù hợp int, hãy sử dụng long. Nếu chúng không phù hợp để longsử dụng BigInteger.

• Chỉ sử dụng các loại nhỏ hơn cho mảng khi bạn cần tiết kiệm không gian.

• Nếu bạn cần chính xác 64/32/16/8 bit, hãy sử dụng long/ int/ short/ bytevà ngừng lo lắng về bit dấu, ngoại trừ việc phân chia, so sánh, dịch chuyển phải và truyền.

Xem thêm câu trả lời này về "chuyển một trình tạo số ngẫu nhiên từ C sang Java".

Với JDK8, nó có một số hỗ trợ cho họ.

Chúng tôi có thể vẫn thấy sự hỗ trợ đầy đủ của các loại không dấu trong Java bất chấp những lo ngại của Gosling.

Tôi biết bài này quá cũ; tuy nhiên, đối với sở thích của bạn, trong Java 8 trở lên, bạn có thể sử dụng intkiểu dữ liệu để biểu thị một số nguyên 32 bit không dấu, có giá trị tối thiểu là 0 và giá trị tối đa là 2 ³² 1. Sử dụng Integerlớp để sử dụng intkiểu dữ liệu như một số nguyên không dấu và các phương thức tĩnh như compareUnsigned(), divideUnsigned()v.v. đã được thêm vào Integerlớp để hỗ trợ các phép toán số học cho các số nguyên không dấu.

Tôi đã nghe những câu chuyện rằng chúng sẽ được đưa vào gần với bản phát hành Java gốc. Oak là tiền thân của Java và trong một số tài liệu cụ thể có đề cập đến các giá trị được gán. Thật không may, những điều này không bao giờ làm cho nó thành ngôn ngữ Java. Theo như bất cứ ai đã có thể tìm ra họ chỉ không được thực hiện, có thể là do hạn chế về thời gian.

Tôi đã từng tham gia khóa học C ++ với một người trong ủy ban tiêu chuẩn C ++, ngụ ý rằng Java đã đưa ra quyết định đúng đắn để tránh có số nguyên không dấu vì (1) hầu hết các chương trình sử dụng số nguyên không dấu có thể làm tốt với số nguyên đã ký và điều này tự nhiên hơn các điều khoản về cách mọi người nghĩ và (2) sử dụng số nguyên không dấu dẫn đến rất nhiều vấn đề dễ tạo nhưng khó gỡ lỗi như tràn số học số nguyên và mất bit đáng kể khi chuyển đổi giữa các loại đã ký và không dấu. Nếu bạn trừ nhầm 1 từ 0 bằng cách sử dụng các số nguyên có chữ ký, nó thường nhanh chóng khiến chương trình của bạn gặp sự cố và giúp tìm lỗi dễ dàng hơn nếu nó bao quanh đến 2 ^ 32 - 1, và trình biên dịch và các công cụ phân tích tĩnh và kiểm tra thời gian chạy phải giả sử bạn biết những gì bạn đang làm kể từ khi bạn chọn sử dụng số học không dấu. Cũng thế,

Từ lâu, khi bộ nhớ bị hạn chế và bộ xử lý không tự động hoạt động trên 64 bit cùng một lúc, mỗi bit được tính nhiều hơn rất nhiều, do đó, việc ký kết với các byte hoặc quần short không dấu thực sự quan trọng hơn rất nhiều và rõ ràng là quyết định thiết kế đúng đắn. Ngày nay, chỉ cần sử dụng một int đã ký là quá đủ trong hầu hết các trường hợp lập trình thông thường và nếu chương trình của bạn thực sự cần sử dụng các giá trị lớn hơn 2 ^ 31 - 1, bạn thường chỉ muốn một thời gian dài. Khi bạn đã vào lãnh thổ của việc sử dụng lâu dài, việc đưa ra lý do tại sao bạn thực sự không thể có được với 2 ^ 63 - 1 số nguyên dương thậm chí còn khó hơn. Bất cứ khi nào chúng tôi đi đến bộ xử lý 128 bit, vấn đề sẽ ít hơn.

Câu hỏi của bạn là "Tại sao Java không hỗ trợ ints không dấu"?

Và câu trả lời của tôi cho câu hỏi của bạn là Java muốn rằng tất cả các kiểu nguyên thủy của nó: byte , char , short , int và long phải được coi là byte , word , dword và qword , tương tự như trong lắp ráp và các toán tử Java được ký hoạt động trên tất cả các loại nguyên thủy của nó ngoại trừ char , nhưng chỉ trên char chúng không được ký 16 bit.

Vì vậy, các phương thức tĩnh giả sử là các hoạt động không dấu cũng cho cả 32 và 64 bit.

Bạn cần lớp cuối cùng, có phương thức tĩnh có thể được gọi cho dấu không dấu hoạt động .

Bạn có thể tạo lớp cuối cùng này, gọi nó là bất kỳ tên nào bạn muốn và thực hiện các phương thức tĩnh.

Nếu bạn không biết về cách thực hiện các phương thức tĩnh thì liên kết này có thể giúp bạn.

Theo tôi, Java là không giống với C ++ ở tất cả , nếu nó không hỗ trợ các kiểu unsigned hay khai thác quá tải, vì vậy tôi nghĩ rằng Java phải được coi là ngôn ngữ hoàn toàn khác nhau từ cả hai C ++ và từ C.

Nhân tiện, nó cũng hoàn toàn khác nhau trong tên của các ngôn ngữ.

Vì vậy, tôi không khuyên Java nên nhập mã tương tự như C và tôi không khuyên bạn nên nhập mã tương tự như C ++, vì khi đó trong Java bạn sẽ không thể làm những gì bạn muốn làm tiếp theo trong C ++, tức là mã sẽ không tiếp tục giống như C ++ và đối với tôi, điều này thật tệ khi viết mã như vậy, để thay đổi kiểu ở giữa.

Tôi cũng khuyên bạn nên viết và sử dụng các phương thức tĩnh cho các hoạt động đã ký, vì vậy bạn không thấy trong hỗn hợp mã của các toán tử và phương thức tĩnh cho cả các hoạt động đã ký và không dấu, trừ khi bạn chỉ cần các hoạt động được ký trong mã và không sao cả chỉ sử dụng các toán tử.

Ngoài ra tôi khuyên bạn nên tránh sử dụng các kiểu nguyên thủy ngắn , int và dài , và sử dụng từ , dword và qword tương ứng, và bạn sẽ gọi các phương thức tĩnh cho các hoạt động không dấu và / hoặc các hoạt động được ký thay vì sử dụng các toán tử.

Nếu bạn chỉ thực hiện các hoạt động đã ký và chỉ sử dụng các toán tử trong mã, thì việc sử dụng các kiểu nguyên thủy này ngắn , int và long là ổn .

Trên thực tế từ , DWORD và qword làm không tồn tại trong ngôn ngữ, nhưng bạn có thể tạo lớp mới cho mỗi và việc thực hiện của mỗi nên rất dễ dàng:

Lớp từ nắm giữ các loại nguyên thủy ngắn chỉ, lớp dword giữ kiểu nguyên thủy int chỉ và lớp qword giữ kiểu nguyên thủy dài mà thôi. Bây giờ tất cả các phương thức không dấu và phương thức đã ký là tĩnh hoặc không phải là lựa chọn của bạn, bạn có thể thực hiện trong mỗi lớp, tức là tất cả các hoạt động 16 bit cả không dấu và được ký bằng cách đặt tên ý nghĩa trên lớp từ , tất cả các hoạt động 32 bit đều không dấu và được ký bằng cách đặt tên ý nghĩa trên lớp dword và tất cả các hoạt động 64 bit cả không dấu và được ký bằng cách đặt tên ý nghĩa trên lớp qword .

Nếu bạn không muốn đưa ra quá nhiều tên khác nhau cho mỗi phương thức, bạn luôn có thể sử dụng quá tải trong Java, thật tốt khi đọc rằng Java cũng không loại bỏ điều đó!

Nếu bạn muốn các phương thức thay vì các toán tử cho các hoạt động được ký 8 bit và các phương thức cho các hoạt động không dấu 8 bit hoàn toàn không có toán tử, thì bạn có thể tạo lớp Byte (lưu ý rằng chữ cái đầu tiên 'B' là vốn, vì vậy đây không phải là kiểu byte nguyên thủy ) và thực hiện các phương thức trong lớp này.

Về việc chuyển theo giá trị và chuyển qua tham chiếu:

Nếu tôi không sai, giống như trong C #, các đối tượng nguyên thủy được truyền theo giá trị tự nhiên, nhưng đối tượng lớp được thông qua tham khảo một cách tự nhiên, do đó phương tiện mà đối tượng của kiểu Byte , từ , dword và qword sẽ được thông qua tham khảo và không phải bởi giá trị theo mặc định Tôi ước Java có các đối tượng struct như C #, vì vậy tất cả Byte , word , dword và qword có thể được triển khai thành struct thay vì class, do đó, theo mặc định, chúng được truyền theo giá trị chứ không phải theo tham chiếu theo mặc định, giống như bất kỳ đối tượng cấu trúc nào trong C #, giống như các kiểu nguyên thủy, được truyền theo giá trị và không theo tham chiếu theo mặc định, nhưng vì Java kém hơn C # và chúng tôi có để đối phó với điều đó, sau đó chỉ có các lớp và giao diện, được truyền bằng tham chiếu chứ không phải theo giá trị theo mặc định. Vì vậy, nếu bạn muốn truyền các đối tượng Byte , word , dword và qword theo giá trị chứ không phải bằng tham chiếu, giống như bất kỳ đối tượng lớp nào khác trong Java và cả trong C #, bạn sẽ chỉ cần sử dụng hàm tạo sao chép và đó là nó.

Đó là giải pháp duy nhất mà tôi có thể nghĩ đến. Tôi chỉ ước rằng tôi chỉ có thể gõ các kiểu nguyên thủy thành từ, từ và qword, nhưng Java không hỗ trợ typedef cũng như không sử dụng, không giống như C # hỗ trợ sử dụng , tương đương với typedef của C.

Về đầu ra:

Đối với cùng một chuỗi bit , bạn có thể in chúng theo nhiều cách: Dưới dạng nhị phân, dưới dạng thập phân (như ý nghĩa của% u trong C printf), dưới dạng bát phân (như ý nghĩa của% o trong C printf), dưới dạng thập lục phân (như ý nghĩa của% x trong C printf) và dưới dạng số nguyên (giống như ý nghĩa của% d trong C printf).

Lưu ý rằng C printf không biết loại biến được truyền dưới dạng tham số cho hàm, vì vậy printf chỉ biết loại của từng biến từ đối tượng char * được truyền cho tham số đầu tiên của hàm.

Vì vậy, trong mỗi lớp: Byte , word , dword và qword , bạn có thể thực hiện phương thức in và nhận chức năng của printf, mặc dù kiểu nguyên thủy của lớp được ký, bạn vẫn có thể in dưới dạng không dấu bằng cách tuân theo một số thuật toán liên quan hoạt động logic và dịch chuyển để có được các chữ số để in ra đầu ra.

Thật không may, liên kết tôi đưa cho bạn không chỉ ra cách triển khai các phương thức in này, nhưng tôi chắc chắn rằng bạn có thể google cho các thuật toán bạn cần để thực hiện các phương pháp in này.

Đó là tất cả những gì tôi có thể trả lời câu hỏi của bạn và đề nghị bạn.

Vì unsignedloại là tà ác.

Thực tế là trong C unsigned - intsản xuất unsignedthậm chí còn ác hơn.

Dưới đây là một ảnh chụp nhanh về vấn đề đã đốt cháy tôi hơn một lần:

// We have odd positive number of rays, 
// consecutive ones at angle delta from each other.
assert( rays.size() > 0 && rays.size() % 2 == 1 );

// Get a set of ray at delta angle between them.
for( size_t n = 0; n < rays.size(); ++n )
{
    // Compute the angle between nth ray and the middle one.
    // The index of the middle one is (rays.size() - 1) / 2,
    // the rays are evenly spaced at angle delta, therefore
    // the magnitude of the angle between nth ray and the 
    // middle one is: 
    double angle = delta * fabs( n - (rays.size() - 1) / 2 ); 

    // Do something else ...
}

Bạn đã nhận thấy lỗi chưa? Tôi thú nhận tôi chỉ nhìn thấy nó sau khi bước vào với trình gỡ lỗi.

Bởi vì nlà loại không dấu size_t, toàn bộ biểu thức n - (rays.size() - 1) / 2đánh giá là unsigned. Biểu thức đó được dự định là vị trí đã ký của ntia thứ từ vị trí giữa: tia thứ nhất từ ​​giữa ở bên trái sẽ có vị trí -1, tia thứ nhất ở bên phải sẽ có vị trí +1, v.v. lấy giá trị abs và nhân với deltagóc tôi sẽ có được góc giữa ntia thứ và tia giữa.

Thật không may cho tôi, biểu thức trên chứa ác không dấu và thay vì đánh giá, giả sử, -1, nó đã ước tính thành 2 ^ 32-1. Việc chuyển đổi tiếp theo để doubleniêm phong lỗi.

Sau một hoặc hai lỗi do sử dụng sai unsignedsố học, người ta phải bắt đầu tự hỏi liệu một bit thừa nhận được có đáng để thêm rắc rối không. Tôi đang cố gắng hết sức có thể để tránh sử dụng các unsignedloại trong số học, mặc dù vẫn sử dụng nó cho các hoạt động phi số học như mặt nạ nhị phân.

Có một vài viên đá quý trong thông số 'C' mà Java đã bỏ vì những lý do thực tế nhưng đang dần trở lại với nhu cầu của nhà phát triển (đóng cửa, v.v.).

Tôi đề cập đến cái đầu tiên vì nó liên quan đến cuộc thảo luận này; sự tuân thủ của các giá trị con trỏ đến số học số nguyên không dấu. Và, liên quan đến chủ đề chủ đề này, khó khăn trong việc duy trì ngữ nghĩa Unsign trong thế giới đã ký của Java.

Tôi đoán rằng nếu ai đó muốn có một Dennis Ritchie thay đổi bản ngã để tư vấn cho đội ngũ thiết kế của Gosling thì họ đã đề nghị cho Signed là "số không ở vô cực", để tất cả các yêu cầu bù địa chỉ trước tiên sẽ thêm ALGEBRAIC RING SIZE của họ để làm giảm giá trị âm.

Bằng cách đó, bất kỳ phần bù nào được ném vào mảng không bao giờ có thể tạo ra SEGFAULT. Ví dụ, trong một lớp được đóng gói mà tôi gọi là RingArray của các nhân đôi cần hành vi không dấu - trong ngữ cảnh "vòng lặp tự xoay":

// ...
// Housekeeping state variable
long entrycount;     // A sequence number
int cycle;           // Number of loops cycled
int size;            // Active size of the array because size<modulus during cycle 0
int modulus;         // Maximal size of the array

// Ring state variables
private int head;   // The 'head' of the Ring
private int tail;   // The ring iterator 'cursor'
// tail may get the current cursor position
// and head gets the old tail value
// there are other semantic variations possible

// The Array state variable
double [] darray;    // The array of doubles

// somewhere in constructor
public RingArray(int modulus) {
    super();
    this.modulus = modulus;
    tail =  head =  cycle = 0;
    darray = new double[modulus];
// ...
}
// ...
double getElementAt(int offset){
    return darray[(tail+modulus+offset%modulus)%modulus];
}
//  remember, the above is treating steady-state where size==modulus
// ...

RingArray ở trên sẽ không bao giờ 'nhận' từ một chỉ số tiêu cực, ngay cả khi một người yêu cầu độc hại đã cố gắng. Hãy nhớ rằng, cũng có nhiều yêu cầu hợp pháp để yêu cầu các giá trị chỉ mục (âm) trước.

NB:% modulus bên ngoài tham chiếu các yêu cầu hợp pháp trong khi% modulus bên trong che giấu ác ý trắng trợn từ phủ định tiêu cực hơn -modulus. Nếu điều này đã từng xuất hiện trong Java + .. + 9 || 8 + .. + spec, sau đó, vấn đề thực sự sẽ trở thành một "lập trình viên không thể" tự xoay "FAULT".

Tôi chắc chắn cái gọi là "thiếu dấu" Java không dấu có thể được tạo ra với một lớp lót ở trên.

PS: Chỉ để cung cấp ngữ cảnh cho công việc dọn phòng RingArray ở trên, đây là thao tác 'set' của ứng viên để khớp với thao tác phần tử 'get' ở trên:

void addElement(long entrycount,double value){ // to be called only by the keeper of entrycount
    this.entrycount= entrycount;
    cycle = (int)entrycount/modulus;
    if(cycle==0){                       // start-up is when the ring is being populated the first time around
        size = (int)entrycount;         // during start-up, size is less than modulus so use modulo size arithmetic
        tail = (int)entrycount%size;    //  during start-up
    }
    else {
        size = modulus;
        head = tail;
        tail = (int)entrycount%modulus; //  after start-up
    }
    darray[head] = value;               //  always overwrite old tail
}

Tôi có thể nghĩ về một tác dụng phụ đáng tiếc. Trong cơ sở dữ liệu nhúng java, số id bạn có thể có với trường id 32 bit là 2 ^ 31, không phải 2 ^ 32 (~ 2 tỷ, không ~ 4 tỷ).

Lý do IMHO là vì họ đã / quá lười biếng để thực hiện / sửa lỗi đó. Đề xuất rằng các lập trình viên C / C ++ không hiểu không dấu, cấu trúc, liên kết, cờ bit ... Chỉ là vô lý.

Ether bạn đang nói chuyện với một lập trình viên cơ bản / bash / java trước khi bắt đầu lập trình a la C, không có kiến ​​thức thực sự về ngôn ngữ này hoặc bạn chỉ đang nói ra khỏi tâm trí của chính mình. ;)

Khi bạn giao dịch hàng ngày với định dạng từ tệp hoặc phần cứng, bạn bắt đầu đặt câu hỏi, họ đang nghĩ cái quái gì vậy.

Một ví dụ điển hình ở đây sẽ là cố gắng sử dụng một byte không dấu như một vòng lặp tự xoay. Đối với những người bạn không hiểu câu cuối cùng, làm thế nào trên trái đất bạn tự gọi mình là một lập trình viên.

DC