C / C++ / MFC

_bstr_t bstr(*text);<br />
bstr += _bstr_t(" appened string here");<br />
AfxMessageBox(bstr);

Dihirk wrote:

convert that bstr into a character string?

CBaseClass
{
};

CChildClass : public CBaseClass
{
};

CBaseClass* pNewClass = new CChildClass;
// Do stuff

class Base
{
public:
	virtual void Message() const = 0;
};
 
class Derived1
{
public:
	virtual void Message() const
	{
		cout << "Hello from Derived1" << endl;
	}
};
 
class Derived2
{
public:
	virtual void Message() const
	{
		cout << "Hello from Derived2" << endl;
	}
};
 
void PrintMessage(const Base &b)
{
	b.Message();
}
 
void Driver()
{
	CDerived1 d1;
	CDerived2 d2;

	PrintMessage(d1);
	PrintMessage(d2);
}

TechyMaila wrote:

CTest1 c ;
c.Hello() ;

CTest1& Voodoo()
{
    CTest1 c;
    // Stuff goes here.
    return c; // Bad code!!!
}

CTest1* Voodoo()
{
    CTest1 *pObject = new CTest1;
    // Stuff goes here.
    return pObject;
}

TechyMaila wrote:

So what you are saying is that it is better to use new and delete? Thanks.

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