standards

I attempted to answer a question a couple hours ago which I believed revealed a somewhat obscure bug in bash POSIX mode . I was hastily and vehemently told this was not so. The contradicting answer, which explicitly says this is not a bug, was selected as the correct answer. So I've been combing over the bash documentation, and I'm still coming away with very much the same impression, so I thought I should ask. My (alleged) bug: set -o histexpand (which is typically implicit) set -o posix echo "#!/" Should, well, echo #!/ . (It does in any other shell). But in bash it instead prints to

This question already has an answer here: Is a C++ preprocessor identical to a C preprocessor? 3 answers Are there any differences in behaviour between the C and C++ preprocessors? They are defined by different passages of standards text (section 6.10 of the C standard and section 16 of the C++ standard ). My motivation for asking this is that a proposal for making the single quote a digit separator that was recently accepted into C++14 extends the C++ preprocessor grammar to accomodate this change (specifically, it extends the definition of a pp-number ), and I'm wondering whether this

I test the code in the c++ standard ISO/IEC 14882-03 14.6.1/9 on Xcode 4.1 and Visual Studio 2008. The outputs of the two compiler are both different from the expected result of the standard. The code is pasted below. #include <stdio.h> #include <iostream> using namespace std; void f(char); template <class T > void g(T t) { f(1); f(T(1)); f(t); } void f(int); void h() { g(2); g('a'); } void f(int) { cout << "f int" << endl; } void f(char) { cout << "f char" << endl; } int main() { h(); return 0; } As the description of the standard. The expected output should be f char f int f int f char f

It's possible to do using namespace foo::bar; (i.e., using the inner namespace without using the outer namespace first / at all), why does the standard forbid to do the following? namespace foo::bar { // open nested namespace bar in foo and extend it... } I'm not looking for a workaround, just a possible rational on why this isn't allowed. I'm not sure "forbidden" is the right word - maybe it was just an oversight. It's a fairly small nice-to-have which isn't really a big deal. You could also take the point of view that the namespace foo isn't created yet when you write foo::bar , so allowing

I know there is -webkit-gradient and -moz-linear-gradient . But what is the standard way of defining a gradient? Like there is: -webkit-border-radius and -moz-border-radius and the standard is meant to be border-radius . An update for 2011, the Mozilla syntax is now the 'official' one, adopted by the CSS3 Image Values and Replaced Content Working Draft . Webkit has been updated to use this syntax too, and this has now been incorporated into the latest versions of Chrome and Safari. Kyle Not yet, the two examples you provided are the only coded gradients available as yet, as far as I know. Most

For example if I instantiate a std::mt19937 with the exact same seed and parameters under GCC and under MSVC, should I get the same sequence of random numbers? If so I assume this property would hold for mersenne_twister_engine in general since mt19937 is just one with specific parameters. This is not true for rand() in C. It looks like the standard documents the transformations applied in terms of specific code, so I suspect it should always be the same, but the devil is in the details... For the new random number engines, yes, for the same seed and parameters you'll get the same sequence of

struct A { A(const A& src); A(const char* src); }; struct B { operator A(); operator char*(); }; void test() { B v; A s(v); } EDG/Comeau and MSVC allows the code while GCC 4.4.4, CLANG and BCC reject it as ambiguous. A C++ committee member replied with this (initially): It's not ambiguous; the A(const A&) constructor is better than the A(const char*) constructor. The const A& parameter binds directly to the result of the conversion function, so the conversion sequence is considered to be a user-defined conversion followed by an identity conversion (13.3.3.1.4p1). The const char* parameter is a