Is this a bug in MinGW compiler?

For a base class and a derived class:

1
2
3
4
5
6
7
8
9
class MyBase
{
public:
    double mynum;
};
class MyDerived : public MyBase
{
    void start();
};


Now the weird thing is, if I want to access mynum through the derived class, I always have to put this->mynum, so:

1
2
3
4
5
void MyDerived::start()
{
    mynum = 0; //doesn't compile
    this->mynum = 0; //works
}


Is it like that in the C++ standard? because the first one compiles with no problems in VS2010, but not in MinGW.

Although MinGW is a crappy compiler, but anyway, I'd like to understand this strange behaviour!!!

Greetings :)
Last edited on
well, sir, I use MinGW too and I must inform you that your code compiles perfectly in my system. As to what might prevent it to compile in yours remains a mystery to me.

EDIT:
can you, please, notify us about the nature of the compile error??
Last edited on
hmmmmmmmmmm... weird. I'd like to add that I use class templates, not only classes. It just acts like this variable doesn't exist.


In file included from ..\BlochSim\/BlochsimSystem.h:7,
                 from ..\BlochSim\/glwidget.h:22,
                 from ..\BlochSim\/mainwindow.h:4,
                 from ..\BlochSim\main.cpp:3:
..\BlochSim\/../../SamLibs/SystemSim/OscillatorToFieldTransformer.h: In member function 'virtual void OscillatorToFieldTransformer<T>::progressTime()':
..\BlochSim\/../../SamLibs/SystemSim/OscillatorToFieldTransformer.h:38: error: 'enDirX' was not declared in this scope


Try it with templates. Probably that's what's special here
Last edited on
Are you sure you posted your actual code? The code you posted gives me no problems (using gcc 4.4.3), but if I use template classes I get your behavior.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
template <typename T>
class MyBase
{
public:
    T mynum;
};

template <typename T>
class MyDerived : public MyBase<T>
{
    void start();
};

template <typename T>
void MyDerived<T>::start()
{
    mynum = (T)0; //doesn't compile
    this->mynum = (T)0; //works
}


I don't fully understand why, but this is the behavior I always see when dealing with inheritance from template classes. Maybe someone who understands the inner workings of template classes can shed some light on why this occurs.
Yes exactly. I mentioned in my last post that it uses templates... but no idea at all why this happens. Could one call this a bug? since VS2010 doesn't have a problem with it?!

What does the C++ standard say about this?
MyBase<T>::mynum works though
MyBase<T>::mynum works though


It does??? that would be really weird!!!!!
template is something completely different from what you showed above.

Deriving from a template class is not a good idea. Having a virtual function in a template class isn't good either.

Your problem is that gcc wants the scope of variable form the template class.

A base class practically doesn't exist until you instantiate it with some proper types. Deriving from a not existing class is a problem...

Although MinGW is a crappy compiler
Huh? It's not MinGW (that only the environment) it's gcc and I don't think that it is crappy actually
coder777 wrote:
template is something completely different from what you showed above.

Deriving from a template class is not a good idea. Having a virtual function in a template class isn't good either.


Why is this a bad idea? please explain.

coder777 wrote:

Your problem is that gcc wants the scope of variable form the template class.

A base class practically doesn't exist until you instantiate it with some proper types. Deriving from a not existing class is a problem...


Why does this then work with VS2010 with no problems? What does the C++ standard say about this? I couldn't really find the part talking about this in the C++ standard.

coder777 wrote:
Huh? It's not MinGW (that only the environment) it's gcc and I don't think that it is crappy actually


gcc is good on linux, but MinGW is crappy + slow on Windows. Do your own speed tests and you'll be surprised!!!
Last edited on
closed account (S6k9GNh0)
gcc version 4.7.0 20120414 (Arch Linux) can't compile this either... with GNU extensions and laxative errors. I'm also unsure of how defined this behavior is... VS is known for allowing undefined and ill-defined behavior which may or may not be good (in my case, it's always been bad, costing me several days in the debugger).

To be fair, the situation is poor and should probably be avoided anyways.
Last edited on
cire wrote:
http://stackoverflow.com/questions/11405/gcc-problem-using-a-member-of-a-base-class-that-depends-on-a-template-argument


That explained the thing for me. Thanks a lot! But this means VS2010 isn't following the standard, which is a weird!!

Thanks again everyone :)
Why is this a bad idea? please explain.
Working with templates means working with unknown data type. It's extremely error prone.

Take std::map for example. It sorts it's content by key.

1
2
3
4
std::map<std::string, std::string> m1; // Ok, does what it's supposed to do
std::map<const char *, std::string> m2; // Doesn't sort. Why?
struct str { char val[100]; };
std::map<str, std::string> m2; // Spits out a bunch of errors. Why? 


If your template class works depends on the instantiation.

So keep your template as short as possible. And adding another level by deriving, well, it might be possible, but I wouldn't try ...
coder777 wrote:

Working with templates means working with unknown data type. It's extremely error prone.

Take std::map for example. It sorts it's content by key.

1
2
3
4
std::map<std::string, std::string> m1; // Ok, does what it's supposed to do
std::map<const char *, std::string> m2; // Doesn't sort. Why?
struct str { char val[100]; };
std::map<str, std::string> m2; // Spits out a bunch of errors. Why?  



If your template class works depends on the instantiation.

So keep your template as short as possible. And adding another level by deriving, well, it might be possible, but I wouldn't try ...


Well, this depends on how you use the class, and for cases like const char* there has to be specialisations. You're assuming that the programmer who utilises the class is totally blind and would just use "any" type that he thinks of. Usually such issues are mentioned in the manual of the class, while the templatisation I'm using is supposed to take ONLY floating types. It's the program writer's responsibility if he decides he wants to use a string there. Remember, we're talking about programmers, not Home Users!!!!

Anyway thanks for the info. I thought it's something serious.

Cheers :)
Last edited on
Usually such issues are mentioned in the manual of the class, while the templatisation I'm using is supposed to take ONLY floating types.


Usually such issues should also be enforced by the use of std::enable_if or the boost version if your compiler doesn't support it, yet.

http://en.cppreference.com/w/cpp/types/enable_if
cire wrote:

Usually such issues should also be enforced by the use of std::enable_if or the boost version if your compiler doesn't support it, yet.

http://en.cppreference.com/w/cpp/types/enable_if


That's useful! thanks a lot :)
Topic archived. No new replies allowed.