Why can't I have a global named "log"
Can some one tell me why this compiles under VC.Net in Debug but not Release mode?
The error message I get is C2365: 'log' : redefinition; previous definition was a 'member function'
Code:
// CString.cpp : Defines the entry point for the console application.
//
#include "stdafx.h"
#include <iostream>
#include "CString.h"
#ifdef _DEBUG
#define new DEBUG_NEW
#endif
using std::cout;
using std::endl;
class Log
{
int x;
public:
Log()
{
x = 5;
}
int GetX() { return x; }
};
Log log;
// The one and only application object
CWinApp theApp;
int _tmain(int argc, TCHAR* argv[], TCHAR* envp[])
{
int nRetCode = 0;
// initialize MFC and print and error on failure
if (!AfxWinInit(::GetModuleHandle(NULL), NULL, ::GetCommandLine(), 0))
{
nRetCode = 1;
}
else
{
cout << log.GetX() << endl;
}
return nRetCode;
}
It's definitely a change with .Net
Commenting out #include <afxdtctl.h> didn't make any difference.
A bug? In a Microsoft product. Heavens!
I'd like to continue using log, as I have it throughout all my projects and I don't want to replace it everywhere. It's an aptly named variable -- it lets me stream text with the time to a log file with the current date. It's been working fine in VC6; I keep finding more and more that they've changed, not the least of which is dropping the whole ftream.h header.
I wonder what option setting is bringing in the log() function and causing the problem on the release build?
Re: It's definitely a change with .Net
Quote:
Originally posted by kberson
Commenting out #include <afxdtctl.h> didn't make any difference.
Really? Did you rebuild?
The redefinition comes from including <math.h>. In the wizard-generated project, this file is pulled in by <afxdisp.h>, which, in turn, is included in <afxdtctl.h>
Re: It's definitely a change with .Net
Quote:
Originally posted by kberson
Commenting out #include <afxdtctl.h> didn't make any difference.
A bug? In a Microsoft product. Heavens!
It's not a bug. It's caused by your insistence on using names that are already function names.
Quote:
I'd like to continue using log, as I have it throughout all my projects and I don't want to replace it everywhere.
That's the price you have to pay when you start to use names of standard library functions. The "log" isn't Visual C++'s name, that is the name of the function defined by the C/C++ standard library. Since you decided (wrongly) to use it for your own purposes, then you have to live with the consequences of using such a name. BTW, you're lucky it compiled with Visual C++ 6.0 -- I can bet that it wouldn't compile on a vast majority of compilers.
Quote:
It's an aptly named variable -- it lets me stream text with the time to a log file with the current date. It's been working fine in VC6;
You don't choose names because the name sounds good, you have to make sure that the name chosen does not conflict with existing names, and the name you chose does conflict. Anyway, an editor with global file search and replace can easily change "log" to another name.
Quote:
I keep finding more and more that they've changed, not the least of which is dropping the whole ftream.h header.
Fstream.h is non-standard, there is no reason for VC++ to keep using a non-standard header. Again, this isn't VC++'s fault at all -- it's all a matter of
a) you using the name of a standard function for you own purposes, and
b) You using a non-standard header (fstream.h) that is not guaranteed to be around from version to version
Quote:
I wonder what option setting is bringing in the log() function and causing the problem on the release build?
That isn't the problem. You have an application that, by chance, builds with a certain version of a certain compiler. Using ANSI standard library names, constants, structures, etc. for your own purposes does not guarantee you that your application will compile on any compiler, let alone Visual C++. I'm sure that this is spelled out in the official ANSI spec for C and C+++.
I had an application once that had
#define FILE 0
in one of the headers. This compiles fine, until the header was included in another application. Of course, this interferes with the <stdio.h> FILE structure, and yes, the name was changed to something else.
Regards,
Paul McKenzie
