C / C++ / MFC

Stephen Hewitt wrote:

No, I'm not saying that.

// file foo.h
#include "bar.h"
class foo
{
  bar  _MyBar;
  // ...
};

// file foo.h
// #include "bar.h"
class bar;  // <----------
class foo
{
  //  bar  _MyBar;
  bar*  _pMyBar;  // <-----------
  // ...
};

Axter wrote:

should avoid using leading underscores in your code, because it makes it non-portable.

Axter wrote:

a trialing underscore

Phil C wrote:

Is that where all the leading underscores are coming from????
I've been wondering why I've been seeing them more and more lately.

m_MyValue;
_MyValue;
mMyValue;
MyValueMember;
ThisIsTheMemberVariableNamedMyValue;
thisismygoddamnmembervariable;
// ......

Phil C wrote:

I'll be damned if i'm going to pay $291 so I can download a 2MB file of instructions telling me how I'm supposed to name my variables.

Phil C wrote:

I've been listening to this grand promise of making code portable for over 20 years now and I've lost count of how many times I've been told we're all doing it wrong.

Phil C wrote:

to run along with ISO/IEC

Maxwell Chen wrote:

Nothing but just my habbit.
But you may write a letter to Microsoft to ask them: Why _tcstol(...) has that underscore.

Axter wrote:

Microsoft is allowed to use leading underscore, because they're considered the implementation.

Leading underscores are reserved for the implementation, which is a cobination of the compiler and the OS.
So Microsoft is allowed to use the leading underscore, but IAW the standard, your own code should not.

One thing Microsoft is doing wrong, is using a leading underscore name followed by a lowercase name that can intrude all namespaces.

Since _tcstol is a macro, it can enter all namespaces.
If Microsoft use _Tcstol instead, then the name is allowed to intrude into all namespaces.

Maxwell Chen wrote:

Section 17.4.3.1.2 in ISO/IEC 14882:2003

1. Certain sets of names and function signatures are always reserved to the implementation:

-- Each name that contains a double underscore (__) or begins with an underscore followed by an uppercase letter (2.11) is reserved to the implementation for any use.

-- Each name that begins with an underscore is reserved to the implementation for use as a name in the global namespace.

Axter wrote:

I'm not sure why you posted the standard.
But I'll explain what the standard is stating, incase you think it contridicts my comment.

Phil C wrote:

At least 5 times I've changed to suit some imaginary standard and guess what?

Phil C wrote:

I'll be damned if i'm going to pay $291 so I can download a 2MB file of instructions telling me how I'm supposed to name my variables.

Phil C wrote:

I've been listening to this grand promise of making code portable for over 20 years now and I've lost count of how many times I've been told we're all doing it wrong.

Axter wrote:

use a trialing underscore instead

Maxwell Chen wrote:

Stephen and I are still interested in what a trialing underscore you mentioned is...

Axter wrote:

Trailing underscore, meaning put it at the end, instead of the beginning.

maybe your error is(I guess)

you declare one function in header file but you havent this file in your code
like this:

this is one example

//////in header file CAnswer.h/////////
class CAnswer : public CDialog
...
...
public:
	int  test();
....
};


then you call this function in your file

void CAnswer::OnBnClickedButton2()
{
	test();//Now you get this error
	you need to delete this function(test) or you need to write test(function)
}


Answer error LNK2019: unresolved external symbol "public: int __thiscall CAnswer::test(void)" (?test@CAnswer@@QAEHXZ) referenced in function "public: void __thiscall CAnswer::OnBnClickedButton2(void)" (?OnBnClickedButton2@CAnswer@@QAEXXZ)

Answer fatal error LNK1120: 1 unresolved externals

or maybe this function is in your code  like this

int test()
{
	return 0;
}

again you get this error

-----------------------------------------------

or you need to import lib file to your project