top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

Template meta programming code compiles on MSVC but not on G++

0 votes
441 views

This code compiles on MSVC but not on G++ :

template
class B
{
public:
 static void SomeMethod()
 {
 A::SomeMethod();
 }
};

class A
{
public:
 static void SomeMethod();
};

void test()
{
 B::SomeMethod();
}

The error with g++ is :

test.cpp: In static member function "static void B::SomeMethod()":
test.cpp:7:3: error: "A" has not been declared

Is there is a option to indicate to g++ to evaluate the template functions only when a specialization is called, and not before ?

posted Jul 19, 2013 by anonymous

Share this question
Facebook Share Button Twitter Share Button LinkedIn Share Button

1 Answer

0 votes

The C++ standard is very specific on which names in a template definition are bound when that definition is initially parsed vs. which are bound only after the template parameters are given.

You are asking for the compiler to violate those rules.

I expect gcc has no such option. I'm not 100% certain it has no such option, but if there were such an option, I would advise against using it.

When MSVC compiles incorrect code, that is not a good justification for leaving your code incorrect.

answer Jul 20, 2013 by anonymous
Also, MS recently committed to fixing their compiler to correctly implement two-phase lookup in templates, so even MSVC will reject the code at some point, so it's better to fix the code.
Similar Questions
0 votes

I'm not a c++/template guru and i can't decide if this is really a valid code or i have encountered a gcc bug:

template  struct A {
 void *p;
};
template  struct B : A {
 void *foo() { return p; }
};

g++ says "error: 'p' was not declared in this scope". microsoft's compiler is happy with the same code.

Can anyone help?

–1 vote

I have a c++ shared object that I am compiling using the following command.
g++ -g -Wall -c -o cpplib.o cpplib.cpp

And I am creating the shared object using the following command.
g++ -shared -o libcpplib.so cpplib.o

(I am aware that I can do this one single command, these are two separate invocations because I had the project setup on eclipse and that's how eclipse cdt does it.).

My host runs a RedHat 6.x x86_64 OS.

The compilation fails with the following error.

$ g++ -g -Wall -fPIC -c -o cpplib.o cpplib.cpp
$ g++ -shared -fPIC -o libcpplib.so cpplib.o
/usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/4.4.7/libstdc++.a(ios_init.o): relocation R_X86_64_32 against `pthread_cancel' can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-redhat-linux/4.4.7/libstdc++.a: could not read symbols: Bad value
collect2: ld returned 1 exit status

I am certain that I haven't used the 'pthread_cancel' function in my code. Please help me.

0 votes

Reading the gcc 5.1 manual it seems that VLA parameters must be accepted by g++. For example the following is fine when compiled with gcc --std=gnu11

float sum (int M, float x[M]) {
 return x[0] + x[1];
}

int main (void) {
 float xs[2] = {1, 2};
 float acc = sum (2, xs);
 return 0;
}

But it is rejected by g++ --std=gnu++11. Is this possible at all with g++?

0 votes

I am new to C+ and I wonder why this code compiles fine with g+ and MSVC:

 namespace t {

 class A {
 public:
 int i;
 };

 int b(int k, A a) {
 return k;
 }

 }

 int main()
 {
 t::A cl;
 return b(5, cl);
 }

I thought that b should not be visible from the main function.

0 votes

I recently encountered a problem with a function was marked as a constructor. The source file was compiled with -O0, but it appears the function was optimized to the point it skipped some of the startup
code and jumped into the failure state (which called exit). I was able to restore desired behavior with '#pragma GCC optimize("O0")' around the function (even volatile tricks did not help).

The startup code had to do with an integrity check. The expected fingerprint was back-patched after compiling, and then recalculated at runtime. Then, a memcmp was made. It appears the compiler deduced that the allocation was a string of 0's and could never be equal to the runtime fingerprint, so its just omitted the code.

Is this expected behavior for functions marked as constructors (compiled with -O0)?

...