Why can't I have a global named "log"

[kberson]

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'

// 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;
}

[mdmd]

Maybe because its a bug ? Or maybe because a header is looking
in something different depending on the build settings. Try the
MS newsgroups ?

You can comment out #include <afxdtctl.h> from your
stdafx.h if you wan't to use log. You'll probably want to
keep away from naming your variables like that anyways - there
are funcs called log().

[kberson]

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?

[VladimirF]

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>

[Paul McKenzie]

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.

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.

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.

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

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

[mdmd]

From ATLComTime.h, which is at some point included with the mfc header

#ifndef _DEBUG
#define ATLCOMTIME_INLINE inline
#include <atlcomtime.inl>
#endif

From AtlComTime.Inl

#include <math.h>

So it seems math.h is being brought into your code by inlining
with the release builds, not the debug builds.
When I was thinking possible bug, I quickly thought name
lookup - that was the wrong thing to think about .
Second guess was the right one, I guess.

Unless you have the same headers as VladimirF, than what
he said !

edit: But still, change it

[Paul McKenzie]

This is not an #include issue. What if I want to use the Log class to log some output from some trigonometric functions (sin(), cos(), etc)? How do you get around not including <math.h> or <cmath>?

This is solely an issue with an improperly written application that uses ANSI standard function names for their own purposes. As I stated before, there is no guarantee that such an application should compile, link, or even run correctly.

The bottom line is to never use standard library names for your own purposes.

Regards,

Paul McKenzie

[mdmd]

Heh, professors We were just experimenting, man. Rules are
for the man, man.

[VladimirF]

Originally posted by Paul McKenzie
The bottom line is to never use standard library names for your own purposes.

Yes, it is. Unfortunately, it requires the programmer to know ALL the names from the standard library, and from whatever SDK is used.
However, the OP did not ask for solution, only for an explanation of that name collision...

[Paul McKenzie]

Originally posted by VladimirF
Yes, it is. Unfortunately, it requires the programmer to know ALL the names from the standard library, and from whatever SDK is used.

Well, log() is a well known function.

However, the OP did not ask for solution, only for an explanation of that name collision...

Yes, no one can know every single name. However, once you find out that your application is using the standard name, it makes no sense to try every scheme in the book to keep using the name, or in frustration, place the blame on the compiler.

Regards,

Paul McKenzie

[Mick]

How can the OP not be asking for a solution? it's a problem is it not?

Use a namespace, it's not just what's for breakfast anymore.

[VladimirF]

Paul, Mick - I am NOT arguing with you. I truly agree that one should not use names already known in the global namespace.

Originally posted by Paul McKenzie
Well, log() is a well known function.

Well, for math majors I can hardly remember last time I used log() (for charting in non-linear scale). Or was it logn()? Or log2()?

Question:

Originally posted by Mick
How can the OP not be asking for a solution?

Answer:

Originally posted by kberson
Can some one tell me why this compiles under VC.Net in Debug but not Release mode?

and

Originally posted by kberson
I wonder what option setting is bringing in the log() function and causing the problem on the release build?

at which point OP left...

[Mick]

Originally posted by VladimirF
Paul, Mick - I am NOT arguing with you.

Didn't say you were just a difference in how we view things...

I truly agree that one should not use names already known in the global namespace.

which is at the heart of what I said....use a namespace

[mdmd]

Heh, from your title.

Why can't I have a global named "log"

If you're asking this because you can have a local one named log,
I guess you can check out "3.3 Declarative regions and scopes"
and some of the "3.4 Name look up" sections here
( or in your own real version )

But still, change it