همیشه خطر از درون زبان ساطع نمیشه! در طرز پیاده‌سازی ما و نحوهٔ بیان به وجود میاد:
https://www.youtube.com/watch?v=PcerWZRm_eA
در ++C خودِ bool خطرناک نیست؛ خطر اصلی اینه که bool خیلی راحت و بی‌صدا وارد جاهایی میشه که معنی کد رو مبهم، شکننده و اشتباه‌پذیر میکنه. عنوان ویدیو هم همین را می‌گوید: Bool - Implicitly Dangerous؛ یعنی «بولین، به‌خاطر ضمنی بودنش خطرناک است». ویدیو جزو Lightning Talkهای CppCon 2025 است و مدت کوتاهی دارد.
به این کد دقت کنید:
createUser("Kambiz", true, false, true);
این کد از نظر کامپایلر کاملاً درست است، ولی برای انسان فاجعه است.
true یعنی چی؟ ادمین است؟ فعال است؟ ایمیل تأیید شده؟ لاگ بگیرد؟ رونویسی کند؟ چه کار کند؟
مشکل وقتی بدتر می‌شود که جای true و false را اشتباه بزنی و کامپایلر هیچ چیزی نگوید:
setWindow(true, false);
پس یکی از پیام‌های اصلی این است: bool در API عمومی، مخصوصاً به‌عنوان پارامتر تابع، اغلب بوی بد طراحی است.
راه بهتر این است که معنی را داخل نوع بیاوریم:
enum class Fullscreen : bool { no, yes };
enum class Resizable : bool { no, yes };
void setWindow(Fullscreen fullscreen, Resizable resizable);
setWindow(Fullscreen::yes, Resizable::no);
اینجا دیگر کد خودش توضیح می‌دهد چه می‌کند و اشتباه جابه‌جا کردن پارامترها هم سخت‌تر می‌شود.
یا مثلاً به‌جای این:
save(file, true);
بهتر است این باشد:
enum class Overwrite {
no,
yes
};
save(file, Overwrite::yes);
یک خطر دیگر bool در ++C، تبدیل‌های ضمنی است. چیزهای مختلف می‌توانند به bool تبدیل شوند: pointerها، عددها، بعضی objectها با operator bool و غیره. این گاهی مفید است:
if (ptr) {
// pointer is not null
}
ولی در طراحی API می‌تواند باعث رفتارهای ناخواسته شود؛ مخصوصاً وقتی overloadها یا constructorها درگیر شوند.
جمع‌بندی ساده‌اش:
از bool برای state داخلی ساده مشکلی نیست.
برای مثال:
bool isConnected = false;
ولی برای APIهایی که خوانایی و امنیت مهم است، مخصوصاً وقتی تابع چند تا bool می‌گیرد، بهتر است از enum class، type wrapper، یا option struct استفاده کنی.
مثلاً این:
connect(server, true, false, true);
بهتر است اینگونه باشد:
struct ConnectionOptions {
bool