【问题标题】:Why specifying std::ios::in for ifstream?为什么要为 ifstream 指定 std::ios::in?
【发布时间】:2020-08-19 06:48:32
【问题描述】:

我想使用ifstream 将字体文件加载到内存中并交给FreeType。我发现标准的 I/O 设施有点令人沮丧。现在我的问题是为什么我必须为ifstream 指定std::ios::inifstream 这个名字已经暗示了输入操作,那么为什么我们需要这个不必要的混乱的东西呢?我们可以用out 指定ifstream 吗?如果我不指定会发生什么?来自 cppreference 的示例:

std::ifstream f1("test.bin", std::ios::binary);

这里没有使用默认参数std::ios::in。为什么?

【问题讨论】:

    标签: c++ std fstream ifstream


    【解决方案1】:

    现在我的问题是为什么我必须为 ifstream 指定std::ios::in

    你没有。它将始终通过按位或运算附加相应的标志。 documentation 明确指出:

    首先,执行与默认构造函数相同的步骤,然后 通过调用rdbuf()->open(filename, mode | std::ios_base::in)将流与文件相关联

    我们可以不指定 ifstream 吗?

    是的。这只会请求文件缓冲区也以写入模式打开文件,可能会在进程中创建它。当然,istream 接口不允许任何输出操作,但您可以将filebuf 重新用于其他操作/流,而无需关闭/重新打开文件。

    【讨论】:

    • 有趣,那为什么要在默认情况下重复std::ios_base::in,如果在实现中无论如何都会使用它?这让我感到困惑,因为我认为当我提供参数时,不会使用默认值。现在我必须真正去看看实现,看看我是否应该提供它或提供什么。
    • @olekstolar 我不能告诉你为什么某些东西是标准库中的。众所周知,C++ 的 I/O 流接口有些晦涩难懂。无论如何,您不必查看任何实现,只需查看接口的文档,因为它清楚地告诉您必须提供什么。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2013-09-21
    • 1970-01-01
    • 2013-05-09
    • 1970-01-01
    • 2016-09-07
    • 1970-01-01
    相关资源
    最近更新 更多