【问题标题】:C++ returning boolean as 95C++ 将布尔值返回为 95
【发布时间】:2011-09-16 22:19:43
【问题描述】:

在 c++ 中返回布尔值的问题..

bool find( const TrieNode &node, const string word )
{

    if (word.length() == 0)
    {
         if (node.isWord)
         {
         cout << "TRUE" << endl;
         return true;
         }

         else
         {
         cout << "FALSE" << endl;
         return false;
         }
    }

    char firstletter = word.at(0);
    int index = firstletter - 'a';

    if (node.letters[index] == NULL)
    {
    return false;
    }

    else
    {
    find (*node.letters[index],word.substr(1,(word.length() - 1)));
    }

}

我主要有

cout << find(*mynode,"word") << endl;

将屈服于:

错误

95

显然,FALSE 的 cout 意味着该函数返回 false。但是,当我打印出函数的结果时,我得到 95,它的计算结果为 true。有什么理由这样做吗?

谢谢

【问题讨论】:

    标签: c++ return boolean


    【解决方案1】:

    问题在于你最后的if 声明:

    if (node.letters[index] == NULL) {
        return false;
    }
    else {
        //if execution gets here, the return value of the function is undefined
        find (*node.letters[index],word.substr(1,(word.length() - 1)));
    }
    

    ...也许可以试试:

    if (node.letters[index] == NULL) {
        return false;
    }
    else {
        return find (*node.letters[index],word.substr(1,(word.length() - 1)));
    }
    

    【讨论】:

    • 谢谢。它解决了这个问题。我的印象是 return 是隐含的?我的一个朋友做同样的任务不需要写return语句(尽管他的代码有些不同)
    • 一个有助于避免此类错误的习惯(以及更简洁和可读性 - 至少在你习惯它之后 - 是更喜欢return ...,例如return node.letters[index] &amp;&amp; find(...);。只要有@ 987654326@ 这是一个好主意,但特别是当有一个带有硬编码的true 和/或falsereturn 时。它鼓励您理清逻辑以从语句中做出积极的断言——就像变量一样应该称为 is_x 而不是 is_not_x - 这样做始终有助于代码理解和正确性。
    • @IrWin: return 仅从 int main(...) 隐含,如果离开范围而没有执行显式 return 语句,则返回 EXIT_SUCCESS(通常为 0)。 (这是 C++ 特有的 - 您必须在 C 中返回。)
    【解决方案2】:

    您缺少最终的 return 语句,因此您得到了 EAX 的低字节中的任何内容,这是随机垃圾。您可能希望在函数的最后使用return true;

    您应该提高编译器的警告级别,因为它应该告诉您这一点(类似于“并非所有控制路径都返回值”)。

    【讨论】:

    • 很好奇,虽然流插入运算符实际上打印了 95,这可能意味着没有“bool”插入,它只是转换为 int?
    • @edA-qa:它很可能已扩展/提升为 int,但在大多数 (x86) 系统下,bool 是一个字节,这使它成为一个数字而不限于1/0。
    • 令人恐惧的是,一个明显的错误(C 中未定义的行为,C++ 中非法)编译时没有警告,除非您明确要求它。永远不要使用超出最高警告级别的任何内容进行编译的另一个好理由。
    猜你喜欢
    • 1970-01-01
    • 2018-01-24
    • 1970-01-01
    • 2013-08-18
    • 2015-04-07
    • 2015-09-10
    • 1970-01-01
    • 1970-01-01
    • 2011-12-14
    相关资源
    最近更新 更多