gcc4

Consider the following code: template < typename T > struct A { struct B { }; }; template < typename T > void f( typename A<T>::B ) { } int main() { A<int>::B x; f( x ); // fails for gcc-4.1.2 f<int>( x ); // passes return 0; } So here gcc-4.1.2 requires the template argument of f to be explicitly specified. Is this meet the standard? Does the newer versions of GCC have this issue fixed? How can I avoid explicitly specifying int while calling f ? Update: Here is a workaround. #include <boost/static_assert.hpp> #include <boost/type_traits/is_same.hpp> template < typename T > struct A { typedef

Premise I’m using a C library (from C++) which provides the following interface: void register_callback(void* f, void* data); void invoke_callback(); Problem Now, I need to register a function template as a callback and this is causing me problems. Consider the following code: template <typename T> void my_callback(void* data) { … } int main() { int ft = 42; register_callback(reinterpret_cast<void*>(&my_callback<int>), &ft); invoke_callback(); } This gives me the following linker error (using g++ (GCC) 4.5.1 on OS X but works on most other combinations of compiler version / platform ):

I am observing a difference when trying to do the same operation on GCC 4.4 and GCC 4.5. Because the code I am doing this with is proprietary, I am unable to provide it, but I am observing a similar failure with this simple test case. What I am basically trying to do is have one shared library (libb) depend on another shared library (liba). When loading libb, I assume that liba should be loaded as well - even though libb is not necessarily using the symbols in liba. What I am observing is when I compile with GCC 4.4, I observe that the liba is loaded, but if I compile with GCC 4.5, libb is not

Update - Many people are insisting I need to declare an iVar for the property. Some are saying not so, as I am using Modern Runtime (64 bit). I can confirm that I have been successfully using @property without iVars for months now. Therefore, I think the 'correct' answer is an explanation as to why on 64bit I suddenly have to explicitly declare the iVar when (and only when) i'm going to access it from a child class. The only one I've seen so far is a possible GCC bug (thanks Yuji). Not so simple after all... To clarify the possible bug is this: When inheriting from a base class, a child can

In chapter 3 of Programming: Principles and Practice using C++ (sixth printing), Stroustrup states (p.68): "Note that sqrt() is not defined for an int " . Here is a simple C++ program based on that chapter: #include "std_lib_facilities.h" int main() { int n = 3; cout << "Square root of n == " << sqrt(n) << "\n"; } Given the quote above, I would expect the process of compiling or running this program to fail in some way. To my surprise, compiling it (with g++ (GCC) 4.2.1) and running it succeeded without errors or warnings, and produced the following perfectly decent output: Square root of n ==

I am porting an application to an ARM platform in C, the application also runs on an x86 processor, and must be backward compatible. I am now having some issues with variable alignment. I have read the gcc manual for __attribute__((aligned(4),packed)) I interpret what is being said as the start of the struct is aligned to the 4 byte boundry and the inside remains untouched because of the packed statement. originally I had this but occasionally it gets placed unaligned with the 4 byte boundary. typedef struct { unsigned int code; unsigned int length; unsigned int seq; unsigned int request;