C / C++ / MFC

25-Feb-08 2:38

Hello everyone,

The following code will result in C4373 warning message. In MSDN,

[url]http://msdn2.microsoft.com/en-us/library/bb384874.aspx[/url]

I do not quite understand the following statement,

1. What means "bind"? Putting function pointer into the vtable of the related class?

2. const is ignored in derived class?

--------------------
This means the compiler must bind a function reference to the method in either the base or derived class.

Versions of the compiler prior to Visual C++ 2008 bind the function to the method in the base class, then issue a warning message. Subsequent versions of the compiler ignore the const or volatile qualifier, bind the function to the method in the derived class, then issue warning C4373. This latter behavior complies with the C++ standard.
--------------------

class Base {
public:
	virtual int goo (const int input) {return 200;}
};

class Derived : public Base {
public:
		virtual int goo (int input) {return 200;} // change const property of input parameter
};

int main()
{
	Derived d;
	const int a = 1000;
	d.goo (a); // pass const to non-const

	return 0;
}

Compile warning message,

1>d:\visual studio 2008\projects\test_overriding1\test_overriding1\main.cpp(8) : warning C4373: 'Derived::goo': virtual function overrides 'Base::goo', previous versions of the compiler did not override when parameters only differed by const/volatile qualifiers
1>        d:\visual studio 2008\projects\test_overriding1\test_overriding1\main.cpp(3) : see declaration of 'Base::goo'

regards,
George

Rajkumar R25-Feb-08 5:07

Rajkumar R

25-Feb-08 5:07

"function arguments of a type modified by const or volatile are not treated differently
than the base type for the purposes of overloading." from msdn;

that is
"int goo (const int)" and "int goo (int)" are not considered as two overloaded function,
it causes redeclaration error. you cannot have two definitions for each of this.

So, while overriding, "virtual int goo (const int )" and "virtual int goo (int input)"
is not considered as two different functions and compiler prior to VS 2008 binds to the
method in base class and issues warning "C4301: 'Derived::goo': overriding virtual function
only differs from 'Base::goo' by const/volatile qualifier"
while VS 2008 bind the function to the method in the derived class, then issue
warning C4373 ignoring qualifiers. "This latter behavior complies with the C++ standard."

George_George wrote:
1. What means "bind"?
Putting function pointer into the vtable of the related class?

yes.

George_George wrote:
2. const is ignored in derived class?

explained above.

George_George25-Feb-08 18:30

25-Feb-08 18:30

Thanks Rajkumar,

Your reply is so comprehensive covers not only overriding (my question) and overloading (which I do not know).

regards,
George

Matthew Faithfull25-Feb-08 5:41

Matthew Faithfull

25-Feb-08 5:41

The bug in MCVC prior to 2008 is that the compiler doesn't recognise cv-qualifiers
(const and volatile or combination) as modifying the type in all cases. For example when matching template
parameters so int myfunc<volatile int=""> is the same function as int myfunc<int> in some circumstances but not
in others. This is part of the legacy of the almost completely broken template implementation in VC6. I'm
very glad to hear MS have finally fixed the last gits of this that I'm aware of. I would have helped if they'd
admitted to the full reality of how far out of spec their compiler was at some point in the past so we
could have predicted what would and would ot work rather than having to rely on trial an error but that
M$ for you.

Nothing is exactly what it seems but everything with seems can be unpicked.

George_George25-Feb-08 18:33

25-Feb-08 18:33

Thanks Matthew,

I do not quite understand your sample below. Could you show some pseudo code please? Code clarifies everything. Smile | :)

Matthew Faithfull wrote:
For example when matching template
parameters so int myfunc is the same function as int myfunc in some circumstances but not
in others.

regards,
George

Matthew Faithfull25-Feb-08 22:59

Matthew Faithfull

25-Feb-08 22:59

Sorry George the template parameters got dropped, very Confused | :confused:

.

what I meant was older MS compilers get int myfunc<const int> confused with int myfunc<int> and similar. Except that in some cases they get it right so it's very difficult to know exactly what will work and what won't.

Nothing is exactly what it seems but everything with seems can be unpicked.

George_George25-Feb-08 23:35

25-Feb-08 23:35

Thanks Matthew,

I think you mean something like this? I have tested in Visual Studio 2008, it will result in compile error,

error C2995: 'int myfunc(T)' : function template has already been defined

template <class T> int myfunc (T a) {};

template <class T> int myfunc (const T a) {};

regards,
George

Matthew Faithfull25-Feb-08 23:43

Matthew Faithfull

25-Feb-08 23:43

Yes, that's another case of the same thing. It looks like they still haven't fixed it properly Frown | :(

Nothing is exactly what it seems but everything with seems can be unpicked.

George_George26-Feb-08 15:09

Re: Compiler Warning C4373 about virtual methods [modified]

26-Feb-08 15:09

Hi Matthew,

In your mind, you mean they will be treated as different thing? Does C++ Spec mention this?

regards,
George

Rajkumar R26-Feb-08 3:11

Rajkumar R

26-Feb-08 3:11

actually, this is not problem / bug. They have reasons to do that.
This is because, how initializers can be used.

int myfunc (int );
int myfunc (const int);

myfunc (100); refers to which one?

"They are considered the same because they take the same initializers." from msdn.

compiler determine the corresponding overloaded function, according to the actual parameter type in the function call.

while
int myfunc (int &a);
int myfunc (const int &a); are different as the initializers are unique.

And VS2008 chooses to ignore overrided qualifiers conforming to ISO C++, may be its behaviour is undefined before in C++. And where ever undefined is in standards, implementation takes its own choice.

modified on Wednesday, February 27, 2008 1:23 AM

George_George26-Feb-08 15:13

26-Feb-08 15:13

Hi Rajkumar,

For your sample,

int myfunc (int a);
int myfunc (const int &a);

even if they are different, they will result in ambiguity in function call. Right? Here is my below code and related compile error message. So, is there any practical benefits to define them both?

int myfunc (int a) {return 100;}

int myfunc (const int &a) {return 200;}

int main()
{
	myfunc (100);
	return 0;
}

Compile errors

1>d:\visual studio 2008\projects\test_const5\test_const5\main.cpp(7) : error C2668: 'myfunc' : ambiguous call to overloaded function
1>        d:\visual studio 2008\projects\test_const5\test_const5\main.cpp(3): could be 'int myfunc(const int &)'
1>        d:\visual studio 2008\projects\test_const5\test_const5\main.cpp(1): or       'int myfunc(int)'
1>        while trying to match the argument list '(int)'

regards,
George

Rajkumar R26-Feb-08 19:24

Rajkumar R

26-Feb-08 19:24

yes, you are right, i corrected my typo error.

And I assume ambiguity is the generic case of the same issue iam discussed.

George_George26-Feb-08 21:18

Casting ULARGE_INTEGER as FILETIME

26-Feb-08 21:18

Thanks Rajkumar,

My question is answered.

regards,
George

Ben Aldhouse25-Feb-08 2:07

Ben Aldhouse

25-Feb-08 2:07

I've been wondering why my recent article 'How To Calculate The Age Of A File' has been getting poor votes. I wondered if the fact that I hadn't used the 'HighPart' and 'LowPart' members of the ULARGE_INTEGER was bad. Then again is my use of the following code bad?

SystemTimeToFileTime (& NowSystemTime, (FILETIME *) & ulSysTime);
SystemTimeToFileTime (&FileSystemTime, (FILETIME *) & ulFileTime);

Since posting my article, I have read 'Date and Time in C++' by RK_2000 and noted that he said

<quote>
Although [FILETIME and LARGE_INTEGER] have the same binary format, the address of all FILETIME structures must begin on a 32 bit boundary whereas the address of all LARGE_INTEGER must begin on 64 bit boundary. So, do not use these interchangeably.

... so this cast I've been using is wrong, then?

In the meantime, I will assume that this is a flaw that people have spotted in my code and rewrite it without this cast.

Thanks for your help,

Ben.

David Crow25-Feb-08 2:19

David Crow

25-Feb-08 2:19

Ben Aldhouse wrote:
I've been wondering why my recent article 'How To Calculate The Age Of A File' has been getting poor votes.

Because if people have the ability to vote low, then for no other reason, they will. Ignore the vote and move on.

Ben Aldhouse wrote:
...I will assume that this is a flaw that people have spotted in my code...

Doubtful. A truly interested and worthy reader will let you know.

"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman

"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne

Ben Aldhouse25-Feb-08 3:10

Ben Aldhouse

25-Feb-08 3:10

Thanks, David, for your encouraging reply.

I have tried the code without the cast and I can't get sensible results.

This is what I now have...

WIN32_FIND_DATA FindFileData;
HANDLE hFind;
hFind = FindFirstFile(strPath, &FindFileData);
CString strYears, strMonths, strDays;

SYSTEMTIME stNow;
GetSystemTime(&stNow);
const FILETIME  ftFile = FindFileData.ftCreationTime;

FILETIME ftNow;
ULARGE_INTEGER ulNowTime, ulFileTime, ulAge;

SystemTimeToFileTime (& stNow, &ftNow);

ulNowTime.HighPart = ftNow.dwHighDateTime;
ulNowTime.LowPart = ftNow.dwLowDateTime;
ulFileTime.HighPart = ftFile.dwHighDateTime;
ulFileTime.LowPart = ftFile.dwLowDateTime;

ulAge.HighPart = ulNowTime.HighPart - ulFileTime.HighPart;
ulAge.LowPart = ulNowTime.LowPart - ulFileTime.LowPart;

FILETIME ftAge;
SYSTEMTIME stAge;

ftAge.dwHighDateTime = ulAge.HighPart;
ftAge.dwLowDateTime = ulAge.LowPart;

SystemTimeToFileTime(&stAge,&ftAge);

strYears.Format("%d", stAge.wYear-1601);
strMonths.Format("%d",stAge.wMonth-1);
strDays.Format("%d",stAge.wDay-1);

I'm foxed. I should really take your advice and move on...

Ben.

David Crow25-Feb-08 3:53

David Crow

25-Feb-08 3:53

What exactly is this code snippet supposed to be doing?

Ben Aldhouse25-Feb-08 5:02

Ben Aldhouse

25-Feb-08 5:02

I was trying to find the difference between a file's creation date, the current time and get the resulting data in a useful format. Doing this I was aware of the following warning from the MSDN library

Remarks
    It is not recommended that you add and subtract values from the SYSTEMTIME 
    structure to obtain relative times. Instead, you should 

    -Convert the SYSTEMTIME structure to a FILETIME structure. 
    -Copy the resulting FILETIME structure to a ULARGE_INTEGER structure. 
    -Use normal 64-bit arithmetic on the ULARGE_INTEGER value.

However, I think at this point I was put off because the promised 'HighPart' and 'LowPart' members of ULARGE_INTEGER didn't appear in the autocomplete list on my editor. I have since written in the members anyway and found that they work without any trouble.

Since your last reply I have had a walk around the block and had another look at the code. I discovered that when I was removing some lines whilst taking out the code that used that (FILETIME *)&ULARGE_INTEGER cast, I removed one line I should have left in and edited and left in another line towards the end of the code that should have been removed...

Here is the (now, at last) working code with comments.

Thanks for your encouragement and for showing an interest,

Ben

	WIN32_FIND_DATA FindFileData;
	HANDLE hFind;
	hFind = FindFirstFile(strPath, &FindFileData);
	CString strYears, strMonths, strDays;

	SYSTEMTIME stNow; 
	
//The current time is aquired and stored in SYSTEMTIME format
	GetSystemTime(&stNow);

//The creation time of the file in question is obtained and
//stored in FILETIME format
	const FILETIME  ftFile = FindFileData.ftCreationTime;

//A reference to the current time in FILETIME format is created
	FILETIME ftNow;
	WIN32_FIND_DATA FindFileData;
	HANDLE hFind;
	hFind = FindFirstFile(strPath, &FindFileData);
	CString strYears, strMonths, strDays;

	SYSTEMTIME stNow; 
	
//The current time is aquired and stored in SYSTEMTIME format

	GetSystemTime(&stNow);
	
//The creation time of the file in question is aquired in a FILETIME
//structure then converted inta a SYSTEMTIME structure

	const FILETIME  ftFile = FindFileData.ftCreationTime;
	FILETIME ftNow;
	SystemTimeToFileTime (& stNow, &ftNow);

//The contents of the FILETIME versions of the current time
//and the creation time of the file are now stored in 
//ULARGE_INTEGER structures

	ULARGE_INTEGER ulNowTime, ulFileTime, ulAge;
	ulNowTime.HighPart = ftNow.dwHighDateTime;
	ulNowTime.LowPart = ftNow.dwLowDateTime;
	ulFileTime.HighPart = ftFile.dwHighDateTime;
	ulFileTime.LowPart = ftFile.dwLowDateTime;

//The difference between the current time and the creation time
//of the file can now be created

	ulAge.HighPart = ulNowTime.HighPart - ulFileTime.HighPart;
	ulAge.LowPart = ulNowTime.LowPart - ulFileTime.LowPart;
	
	FILETIME ftAge;
	SYSTEMTIME stAge;

//The ULARGE_INTEGER data can then be copied back to a FILETIME
//structure, this can then be converted to SYSTEMTIME
//which is the convenient format we want our data to be in....

	ftAge.dwHighDateTime = ulAge.HighPart;
	ftAge.dwLowDateTime = ulAge.LowPart;

	FileTimeToSystemTime(&ftAge,&stAge);
	// not SystemTimeToFileTime(&stAge,&ftAge);!

	strYears.Format("%d", stAge.wYear-1601);
	strMonths.Format("%d",stAge.wMonth-1);
	strDays.Format("%d",stAge.wDay-1);