如果在std::ofstream没有openmode标志的情况下ios_base::out调用构造函数,则默认标志为.但这是暗示ios_base::trunc还是ios_base::app？
换句话说,如果您的文件系统中已经有一个非空文件"past.txt"并且您正在调用
std::ofstream stream( "past.txt" );
stream << "new content";
"新内容"是否会附加到"past.txt"的先前内容中,还是会替换先前的内容？
我想bind()从派生类到我的基类的函数版本.该功能在基础中标记为受保护.当我这样做时,代码在Clang(Apple LLVM编译器4.1)中快速编译,但在g ++ 4.7.2和Visual Studio 2010中都出错.错误是:"'Base :: foo':不能访问受保护的成员."
这意味着参考的上下文实际上在bind()其中,当然这个函数被视为受保护.但是不应该bind()继承调用函数的上下文 - 在这种情况下,Derived::foo()- 因此将基本方法看作是可访问的？
以下程序说明了该问题.
struct Base
{
protected: virtual void foo() {}
};
struct Derived : public Base
{
protected:
virtual void foo() override
{
Base::foo(); // Legal
auto fn = std::bind( &Derived::foo,
std::placeholders::_1 ); // Legal but unwanted.
fn( this );
auto fn2 = std::bind( &Base::foo,
std::placeholders::_1 ); // ILLEGAL in G++ 4.7.2 and VS2010.
fn2( this );
}
};
为什么行为上的差异？哪个是对的？错误提供编译器有哪些可用的解决方法？
直观地说,从C++规范来看,它看起来好像istream::putback( c )应该总是安排输入缓冲区,以便下一次调用istream::peek()应该读取字符c.这不正确吗？我问,因为随Xcode 4.6发布的最新版本的libc ++似乎并未在所有情况下强制执行此行为 - 特别是当最后一个字符位于EOF时.如果您使用unget()而不是,也是如此putback( c ).
libc ++的行为是正确的,还是我对如何putback()/unget()正确行事的直觉？
考虑这个示例代码,它与libstdc ++一起使用但不与libc ++一起使用(断言失败).
#include <sstream>
#include <cassert>
int main(int argc, const char * argv[])
{
std::istringstream in( "[Test]" );
while( in )
{
int c = in.get();
if( c == ']' )
{
in.putback( c );
assert( in.peek() == c ); // Fails with libc++. Succeeds with libstdc++.
break;
}
}
return 0;
}
我发现在实践中,对于各种C++ 11/C++ 14编译器,a std::atomic具有未定义的初始值,就像它是"原始"类型一样.也就是说,我们希望表达方式
int a;
a可能有任何价值.对于表达而言,事实证明也是如此
std::atomic< int > b;
b也可能有任何价值.换句话说,
std::atomic< int > b; // b is undefined
不等于
std::atomic< int > b{ 0 }; // b == 0
或者
std::atomic< int > b{}; // b == 0
因为后两种情况b被初始化为已知值.
我的问题很简单:在C++ 11或C++ 14规范中,这种行为记录在哪里？
应该使用std :: ws操纵器从流中提取是否会引发失败位？在以下代码中,Clang编译(在Xcode 4.5.1中)程序未通过最终断言.显然s >> std::ws,EOF会导致失败.然而,GCC 4.7.2通过了断言.哪个是对的？
#include <iostream>
#include <sstream>
#include <cassert>
int main(int argc, const char * argv[])
{
{
// Read string with trailing ws.
std::istringstream s( "test " );
std::string test;
s >> std::ws;
assert( !s.fail() ); // No ws to skip, but no failure.
s >> test;
assert( test == "test" );
assert( !s.fail() );
s >> std::ws;
assert( !s.fail() ); // No prob skipping trailing ws.
}
{
// Retry with …我试图使用std :: bind()来创建一个函数,该函数将调用虚函数的基类版本,而不是调用派生类的版本.
struct Base
{
virtual void foo() { cout << "Base\n"; }
};
struct Derived : public Base
{
virtual void foo() { cout << "Derived\n"; }
};
int main(int argc, const char * argv[])
{
Base* base = new Derived;
auto baseMethodHopefully = std::bind( &Base::foo, base );
baseMethodHopefully(); // Want call to Base::foo(), but get call to Derived::foo().
return 0;
}
我从其他地方了解到你通常不能以"反虚拟"方式调用基本功能,例如这样.一个明显的例外是常见的范例:
void Derived::bar() { Base::bar(); }
由于表达Base::bar()被认定为"反虚"(在这个意义上,我暗指)派生的方法中,是可以绑定到Base::bar()从希望的方式内源性的方法之一？例如:
void …在C++ 11 关键字的各种 解释中final,我看到的是这样的例子.
class base
{
public:
virtual void f() final;
};
class derived : public base
{
public:
virtual void f(); // Illegal due to base::f() declared final.
};
这实际上是一个有用的用途final吗？为什么要在基类中声明一个虚函数(意味着它在派生类中可以有效地重写)然后立即将其标记为final(否定该含义)？有什么用处virtual void f() final？
我可以看到标记derived::f()最终的价值而不是base::f().在这种情况下,base::f()可能有一个很好的基于设计的原因,为什么f()应该是虚拟的,并且derived::f()单独有一个很好的基于设计的原因,为什么没有进一步派生的类应该覆盖它的实现.
如果您不希望多态地覆盖该函数,为什么不放弃虚拟关键字？当然,派生类可能仍会以非多态方式覆盖该函数.virtual void f() final因此,基类中的目的base::f()是以任何方式牢固地不可重写 - 作为虚函数还是非虚函数？如果是这样,那么virtual在这种情况下我们必须添加关键字才能启用它似乎有点不幸final.我认为将非虚拟函数标记为final是合法的.
为什么使用virtual void f() final起源于基类的函数时感觉virtual和感觉final似乎相互矛盾？
以下程序演示了std :: istream(特别是在我的测试代码中,std :: istringstream)设置eof()的方式不一致.
#include <sstream>
#include <cassert>
int main(int argc, const char * argv[])
{
// EXHIBIT A:
{
// An empty stream doesn't recognize that it's empty...
std::istringstream stream( "" );
assert( !stream.eof() ); // (Not yet EOF. Maybe should be.)
// ...until I read from it:
const int c = stream.get();
assert( c < 0 ); // (We received garbage.)
assert( stream.eof() ); // (Now we're EOF.)
}
// THE MORAL: EOF only happens when actually …我正在使用Dir.glob来访问与通配符模式匹配的所有文件集.
Dir.glob( '**/*.txt' ) { |file_name|
parse file_name
}
因为这个glob调用是递归的,并且由于涉及大量文件,所以在块启动之前,glob需要很长时间来构建文件数组.
我想要的是一种访问所有相同文件的方法,但是在Ruby"发现"每个文件之后立即调用该块,以便立即处理第一个文件而不是在等待整个目录树完成搜索之后.
有这样的建筑吗？
在至少一个实施标准库,的第一次调用std::uniform_int_distribution<>并不能返回一个随机值,而是分布的最小值.也就是说,给出代码:
default_random_engine engine( any_seed() );
uniform_int_distribution< int > distribution( smaller, larger );
auto x = distribution( engine );
assert( x == smaller );
...... x其实会smaller为任何值any_seed(),smaller或larger.
要在家中玩,您可以尝试在gcc 4.8.1中演示此问题的代码示例.
我相信这是不正确的行为？如果它是正确的行为,为什么随机分布会返回这个明显非随机的值？