standards

struct A { void f() {} }; void f() {} int main() { auto p1 = &f; // ok auto p2 = f; // ok auto p3 = &A::f; // ok // // error : call to non-static member function // without an object argument // auto p4 = A::f; // Why not ok? } Why must I use address-of operator to get a pointer to a member function? auto p1 = &f; // ok auto p2 = f; // ok The first is more or less the right thing. But because non-member functions have implicit conversions to pointers, the & isn't necessary. C++ makes that conversion, same applies to static member functions. To quote from cppreference : An lvalue of function

On this question , there's an answer that states: You can use typedef to make Colour enumeration type accessible without specifying it's "full name". typedef Sample::Colour Colour; Colour c = Colour::BLUE; That sounds correct to me, but someone down-voted it and left this comment: Using the scope resolution operator :: on enums (as in "Colour::BLUE") is a compiler-specific extension, not standard C++ Is that true? I believe I've used that on both MSVC and GCC, though I'm not certain of it. I tried the following code: enum test { t1, t2, t3 }; void main() { test t = test::t1; } Visual C++ 9

Does anybody know Why argument type of putchar() , fputc() and putc() is not char , but argument type of putwchar() , fputwc() and putwc() is wchar_t ? See also this and this . The answer is 'legacy' (or 'history'). Before the C90 standard, there were no function prototypes and all arguments to all functions were subject to default promotion rules, so a char was automatically passed as an int ( short was promoted to int too, and float to double , and similarly for unsigned types). The standard couldn't afford to break existing code, so it kept that type for these functions. It makes very

We found something similar to the following (don't ask ...): namespace N { struct A { struct B; }; } struct A { struct B; }; using namespace N; struct ::A::B {}; // <- point of interest Interestingly, this compiles fine with VS2005, icc 11.1 and Comeau (online), but fails with GCC: global qualification of class name is invalid before '{' token From C++03, Annex A, it seems to me like GCC is right: the class-head can consist of nested-name-specifier and identifier nested-name-specifier can't begin with a global qualification ( :: ) obviously, neither can identifier ... or am i overlooking

Assume the following two pieces of code: char *c = "hello world"; c[1] = 'y'; The one above doesn't work. char c[] = "hello world"; c[1] = 'y'; This one does. With regards to the first one, I understand that the string "hello world" might be stored in the read only memory section and hence can't be changed. The second one however creates a character array on the stack and hence can be modified. My question is this - why don't compilers detect the first type of error? Why isn't that part of the C standard? Is there some particular reason for this? C compilers are not required to detect the

I'm taking a class in which I'm required to write some C++ apps for Linux. I really, really dislike the dev tools available under Linux, but I love VS2010. Is there any sort of compiler switch which will enforce ANSI or gcc compatibility in VC++? Or can I swap the compiler out for gcc and still use the VS environment? You can disable Microsoft extensions to the ANSI C and ANSI C++ standards by specifying the /Za flag, which will make the compiler emit errors if you use non-standard C and C++ features. http://msdn.microsoft.com/en-us/library/0k0w269d(v=VS.100).aspx However, this doesn't

There's this other question asking about how comparing pointers is supposed to be interpreted wrt the C++ Std. So I was wondering what the C++ Std has to say about using pointers as keys in ordered standard library (STL) containers -- i.e. is one allowed to have std::map<T1*, T2> and is this due to the specification of std::less or builtin operator < ? Yes, because it uses std::less , which is required to result in a total order even if < doesn't. ( < would be allowed to treat different pointers from distinct sequences as equal, which would result in an odd behaviour of map etc if you insert