Solved

tricky Q = strange compiler error ?

Posted on 2002-06-12
22
354 Views
Last Modified: 2010-08-05
Hi there,

I have the following phenomenon (at least it's strange for me):
Why does the compiler indicate an error regarding the first method an why there's no error reported regarding the second method ?

//*****************************1st method
class A
{public:
   virtual const int f() const;
};

class B : public A
{public:
   virtual const int f() const
   {
      int(A::f());               // compiler error: 'A::f' : unable to resolve function overload
      const int(A::f());    // compiler error: 'A::f' : unable to resolve function overload
   }    
};

//*****************************2nd method
void main()
{
   A a;
   B b;
   int(a.f());      // no compiler error reported
   int(b.f());      // no compiler error reported
   int(b.A::f());  // no compiler error reported
   int(b.B::f());  // no compiler error reported
}

Any hints would be greatly appreciated !

Cheers
-Stavi-
0
Comment
Question by:mitrakis
  • 10
  • 4
  • 3
  • +3
22 Comments
 
LVL 22

Expert Comment

by:nietod
ID: 7072433
Did you try making the return value an int, not a const int?
0
 
LVL 22

Expert Comment

by:nietod
ID: 7072438
That isn't it.    The fix is to name the integers, i.e.

    int i1(A::f())

works fine.

The question is why....  I'll let you know.   maybe.
0
 
LVL 22

Expert Comment

by:nietod
ID: 7072446
I have no idea what is happening there.   I'm not sure if it is a VC quirk or the actuall correct behavior.   My thought was that

  int(A::f());      

could be interpretted as something other than the declaration of an initialized int.   But if so, I can't figure out what.   Note that if f() takes parameters, the problem also goes away..      That seems to make it a little suspicious to me--like it is a compiler error.

Also note, that this can happen in an unrelated member function in B.  i.e. in a function like B::X()
0
 
LVL 3

Author Comment

by:mitrakis
ID: 7072452
Thanks for feedback nietod !

I found out that *only* the following works fine *within* the method:
int(this->A::f());

whereas *outside* the method the following can be definded also:
int(A::f());

That means I had to change the above code as follows:

class B : public A
{public:
   virtual const int f() const
   {
      int(A::f());
      const int(A::f());

      int(this->A::f());       // works fine now !

      return 0;
   }    
};


But I have no (good) idea why it has to be this way :-))
0
 
LVL 22

Expert Comment

by:ambience
ID: 7072466
interesting .....

first the easy thing

>> int(a.f());      // no compiler error reported

creates a unnamed int variable that is initialized with returned value from a.f() and destroys it immediately. Its just like a constructor for primitive int type, which is valid in C++.

>>     int(A::f());              

this however is interesting, as different compilers have different opinion on that

VC: compiler error: 'A::f' : unable to resolve function overload
GCC: cannot declare member function `A::f' within `B'

in fact it appears that both think A::f is being declared inside B.

try this
const int(A::f() const);              

strangely enough VC doesnt complain about that, but even stranger is the fact that no call to A::f() is made and this statement is treated as a declaration inside B.

GCC however still complains.

Looks like i have to check what the standard has to say about that.
0
 
LVL 22

Expert Comment

by:nietod
ID: 7072487
>> GCC: cannot declare member function `A::f' within `B'
I was tryign to interpret the statemetn as a declaration for a function, but I couldn't.  I still can't.  But apparently I am missing something, because GCC can.   i.e. somehow it looks like a function declaration.  If you add the parameters to f, or if you add a name to the int, it no longer looks like a function definition.


AH I got it now.  Thanks to ambience.   Those parentheseis can be ignored   Se what happens is that

int (A::f());    

is identical to

int A::f();    

try it, you can declare a funcion like

int (F(int i));

instead of

int F(int i);


So remove those ( for the intializer and you have

int A::f();

this looks like a declaration for a function.  

0
 
LVL 22

Accepted Solution

by:
nietod earned 75 total points
ID: 7072504
Note that the following works fine.
class B : public A
{
public:
   int(A::f() const);               // compiler error: 'A::f' : unable to resolve function overload
};

what this does is to redeclae the f() function in B.   (This is often done to make a private function public, etc).

Tha is how the compiler is trying to interpret the statement.  the overload problem that VC complains about is the missing "const" at the end of your declaration.
0
 
LVL 22

Expert Comment

by:ambience
ID: 7074653
>>  the overload problem that VC complains about is the missing "const" at the end of your declaration.

I am pretty much sure he didn't intend classify it as a declaration. Its only treated so by the compiler.

>> in fact it appears that both think A::f is being declared inside B.

* rather inside B::f() *

What is strange is that it is inside B::f(), and is it viable to declare a member function inside another member function ?? (only if it is valid somehow). I certainly dont see any reason such a declaration make any sense, and if not why wouldn't the compiler differentiate it from an ordinary declaration.

virtual const int f() const
{
     int(A::f());  // If a declaration here is not allowed
                   // and i think it shouldn't be
                   // this should be treated differently
     .....    
}    

Although GCC complains here but it doesn't bother to treat it the way the programmer has wanted it to, and VC doesn't even complain.

So this leads me to the question, is VC doing the right thing or GCC ?
0
 
LVL 22

Expert Comment

by:nietod
ID: 7075118
>> I am pretty much sure he didn't intend classify it as a
>> declaration. Its only treated so by the compiler.
I'm sure.   But it is a declaration--even if no human would read it as such..  I have a lengthy descussion in my book  about the fact that unlike humans compiler's don't ever "know what we meant".  

>> What is strange is that it is inside B::f(), and is it viable to declare a
>> member function inside another member function
You can declare it, but not define it.   this is useful for forward declarations of functions that are defined later and for "using declarations" of functions from other namesaces when you want these declarations confined to the scope of the function.

>> So this leads me to the question, is VC doing the right thing or GCC ?
According to the standard if a program is ill formed, the compiler must not sucessfully compile it.   Both do this, bot are doing the right thing   It is not uncommon in C++ to encounter syntax errors that are ambiguous.  The compiler can't tall what is intended, so it different compilers may report the error in very different ways.   (This is one of the worst things about the C/C++ language.  syntax errors are much much harder to comprehend than in most other languages.  And typoes and mistakes by the programmer are more likely to be compiled succesfully, but operate not as intended, more than most other languages)
0
 
LVL 8

Expert Comment

by:fl0yd
ID: 7080599
Well, the answer is way easier than any of you guessed:

Why isn't method 1 compiling? Because f is defined as a virtual function, thus it needs some sort of v-table to be resolved. As we all know, a class definition does *NOT* produce code/data unless an actual object of that class is instantiated. With that said, how is a compiler to resolve A::f()? It simply cannot since no object has been created and thus there is no v-table to be accessed to look up the address of f.
But why do the same lines of code work in a different context? Because in method 2 they are called, AFTER one of each classes has been instantiated.
0
 
LVL 22

Expert Comment

by:ambience
ID: 7082860
>> Because f is defined as a virtual function, thus it needs some sort of v-table to be resolved

I seriously doubt the validity of such comment.

try this and you'll know

void B::f()
{
    A::f();
}
0
Maximize Your Threat Intelligence Reporting

Reporting is one of the most important and least talked about aspects of a world-class threat intelligence program. Here’s how to do it right.

 
LVL 8

Expert Comment

by:fl0yd
ID: 7083568
ambience,
   if you want to back your point with an example, that's perfectly ok. In that case, however, make it complete enough so that one can follow. If you don't put those 4 lines into a context you're invalidating them as a basis for discussion.
0
 
LVL 22

Expert Comment

by:nietod
ID: 7084625
>> As we all know, a class definition does *NOT*
>> produce code/data unless an actual
>> object of that class is instantiated.
I don't know that!   The C++ standard has nothing to say about that.   However practical considerations do and most compilers will be unable to work that way.   (consider some counter examples, derived classes when there are no base classes.  (The base  classes might even appear in a seprately compiled translation unit.  the resulting object code must contain the class's compiled code and static data.))

>> how is a compiler to resolve A::f()? It simply
>> cannot since no object has been created and
>> thus there is no v-table to be accessed to look
>> up the address of f.
This "problem" occurs without virtual functions.   It has nothing to do with a v-table or anything of the sort.

>> Because in method 2 they are called,
>> AFTER one of each classes has been instantiated.
Well consider

class A
{
   public:
   virtual const int f() const;
};

class B : public A
{
   public:
   virtual const int f() const
   {
      A AnA;   // Add these
      B AB;

      int(A::f());               // compiler error: 'A::f' : unable to resolve function overload
      const int(A::f());    // compiler error: 'A::f' : unable to resolve function overload
}    

You should see no difference.  (I don't have time to test, but I would be shocked if there was a change.)



mitrakis,  we need to hear from you.  
0
 
LVL 1

Expert Comment

by:jmccay
ID: 7099081
This may seem simple, and it may be just an oversite in the posting of the code.  There is no function definition for A::f and it is not declared as a pure virtual function. try one of these:
class A
{public:
  virtual const int f() const = 0;
};

class B : public A
{public:
  virtual const int f() const
  {
     int(A::f());               // compiler error: 'A::f' : unable to resolve function overload
     const int(A::f());    // compiler error: 'A::f' : unable to resolve function overload
  }    
};

or

class A
{public:
  virtual const int f() const{};
};

class B : public A
{public:
  virtual const int f() const
  {
     int(A::f());               // compiler error: 'A::f' : unable to resolve function overload
     const int(A::f());    // compiler error: 'A::f' : unable to resolve function overload
  }    
};
0
 
LVL 22

Expert Comment

by:nietod
ID: 7099658
I don't understand that.  What is the point you are making?  
0
 
LVL 3

Author Comment

by:mitrakis
ID: 7102985
back again...

First aof all I'd like to thank you all for the helpful comments and also for the various code examples.
What I understood is that the compiler behaves quite different when trying to understand what the programmer wanted to achieve by using certain statements...correct me if I'm wrong...but that will be the problem for the next couple of milleniums ;)

I really would like to award nietod and ambience the points since their comments pointed me to the right direction.
I'm sure now, I didn't make an error in my code. Just had to change my dialect so the compiler can understand easily what my intention was ;)

I suggest to give points to nietod and to open a new Q to be answered by ambience.
Give me a feedback if this is ok for you.

Best regards
-Stavi-

P.S.:
I'm sure this topic can be discussed another hundred years concerning the ability or inability of good or bad compilers...thanks a lot anyway.
0
 
LVL 8

Expert Comment

by:fl0yd
ID: 7103737
That is not quite true. A compiler doesn't want to understand what the programmer wanted to achieve - neither does it have to to produce code. The constructs you were handing to the compiler didn't resemble what you meant to say to begin with.

As for the next couple of milleniums (millenia? anyone?) compilers will evolve, surely. Not in the way that they will UNDERSTAND what the programmer meant but in complying with the standard. A compiler's job is a lot like blindly translating a document into a different language using a dictionary. There is very little interpretation involved. In fact, I only came across one single instance in my life when a line of c++-code was truely ambiguous and could have been - legally - interpreted in two different ways by a standard conforming compiler. If the compiler did care about my intentions it would have compiled. But a compiler simply doesn't care.

The right direction for you, though, would be to UNDERSTAND the compiler more thoroughly as well as the language it takes as an input. In c++ there is no such thing as dialect - at least not as far as the standard goes.

I hope this made things a bit clearer for you.
0
 
LVL 22

Expert Comment

by:nietod
ID: 7105516
>> What I understood is that the compiler behaves quite different when
>> trying to understand what the programmer wanted to achieve by
>> using certain statements.
It behaves differently only in how it interprets a mistake, not in whethor or not it is a mistake.  that is understandable, the compiler is not psychic , or even smart, so it has to try to guess at what you entended as best as possible.   So for example if it sees

if (X =! Y)

One compiler  might guess that the user placed the two symbols in the wrong order and really meant (X != Y) while another compiler might guess that the user meant to place a space before the ! and really mean (X = !Y).  But compilers are right that the code is wrong, but they may not know what was really intended.

>> The constructs you were handing to the compiler didn't resemble what
>> you meant to say to begin with.
I'm not sure about that.   anonomous objects are a very useful feature of C/C++.  But I would recommend you restrict their use to within expressions, i.e.  if you want to pass point objects to a function you would do something like

   Line(Point(0,0),Point(100,100));

but there is little reaason to declare anonomous objects, like

   Point(0,0);

such an object cannot ever be used for anything.  The only "useful" result from this can come out of its constructor and destructor.  Now sometimes that does happen.  i.e. some classes might start an action in the constructor and complete it in the destructor.  If you have a class like that you can still use it, but just don't make it anonomous, give it a name like

   LockFileObject ALock();

(millenia? anyone?)
yes, millenia.   (And by the way all you programmers out there "data" is plural.  "datum" is the signular!)

>> Not in the way that they will UNDERSTAND what the
>> programmer meant but in complying with the standard
Do you think a millenium is enough to comply with the standard?  :-)

>>  I only came across one single instance in my life when a line of
>> c++-code was truely ambiguous and could have been - legally -
>> interpreted in two different ways by a standard conforming compiler.
Ther are actually about a dozen of these problems known.

>>  In c++ there is no such thing as dialect - at least not as
>> far as the standard goes.
Well as far as the sandard goes, yes there is only one C++ (its few known problems aside).  Unfortunately, there are no fully compliant C++ compilers in the world and there probably will never be.  Thus each compiler "understands" a slightly different language. Many are fairly similar, but some are quit different.   VC is probalby one of the least compliant of the major compilers, so if that's what you are using, you might need to be prepared for a little hardship.  Fortunately MS is now committed to make it fully compliant (which is impossible).
0
 
LVL 8

Expert Comment

by:fl0yd
ID: 7105623
> Fortunately MS is now committed to make it fully
> compliant (which is impossible).

How can you say that? Does the language have built-in contradictions? If not then a compiler can be made fully compliant - at least that's what the theory of computation demands.
0
 
LVL 22

Expert Comment

by:nietod
ID: 7105767
>> How can you say that?
I am a realist.  A compiler that is 100% compliant is certanly theoreticaly possible, but practically impossible.  The language is just too complex.  There will always be bugs, at least until we can someday appply programatic solutions to generating the perfect compiler, but that is not even possible (much less realstic) until the language is perfect, and there are flaws with it too.   Even if there was programmers that could write the perfect compiler, it would probably still have flaws due to his/her missunderstanding of the standard.    You need to find someone that understands the standard perfectly and can write a program with no flaws.  You'd have better odds looking for 1 honest man.  (he's the one that says he can't program perfectly....)

0
 
LVL 1

Expert Comment

by:Computer101
ID: 7131802
Points have been reduced for split.  Now you can accept an experts comment as an answer.  After that, make another question in this topic are for the other expert.  Label the question, "Question for (Expert Name)and post the desired points.

Computer101
E-E moderator
0
 
LVL 3

Author Comment

by:mitrakis
ID: 7132166
Thanks a lot for your input on this issue guys.

Regards
-Stavi-
0

Featured Post

How to improve team productivity

Quip adds documents, spreadsheets, and tasklists to your Slack experience
- Elevate ideas to Quip docs
- Share Quip docs in Slack
- Get notified of changes to your docs
- Available on iOS/Android/Desktop/Web
- Online/Offline

Join & Write a Comment

Introduction This article is the first in a series of articles about the C/C++ Visual Studio Express debugger.  It provides a quick start guide in using the debugger. Part 2 focuses on additional topics in breakpoints.  Lastly, Part 3 focuses on th…
C++ Properties One feature missing from standard C++ that you will find in many other Object Oriented Programming languages is something called a Property (http://www.experts-exchange.com/Programming/Languages/CPP/A_3912-Object-Properties-in-C.ht…
The viewer will learn how to use the return statement in functions in C++. The video will also teach the user how to pass data to a function and have the function return data back for further processing.
The viewer will learn how to clear a vector as well as how to detect empty vectors in C++.

746 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

16 Experts available now in Live!

Get 1:1 Help Now