C / C++ / MFC

3-Oct-03 9:45

While writing some code for a class, wich also contains oveloads for the assignment operator ( = ), VC++ keeps giving C2801 errors. According to MSDN, C2801 means that assignment, class member access, subscripting or function call operators must be a non-static class member.

This is my code:

class Foo<br />
{<br />
private:<br />
   CString m_String;<br />
public:<br />
   Foo();<br />
   Foo(CString);<br />
   ~Foo();<br />
   friend Foo& operator= (const class Bar);<br />
}<br />
<br />
Foo::Foo (CString string)<br />
{<br />
   m_String = string;<br />
}<br />
<br />
Foo& operator= (const class Bar BarInstance)<br />
{<br />
   return Foo (BarInstance.m_String);<br />
}<br />
<br />
class Bar<br />
{<br />
private:<br />
   CString m_String;<br />
public:<br />
   Bar();<br />
   ~Bar();<br />
}

But that's not the whole story; the code

char* yourName = "DaFrawg";<br />
MessageBox("Hello there, %s", yourName);

will generate a messagebox with the prompt "Hello there, %s" and the caption "DaFrawg". What I want is, of course, to have the message "Hello there, DaFrawg" displayed.

Can somebody help me, please?

//Please don't mind my bad English

Michael P Butler3-Oct-03 10:00

Michael P Butler

3-Oct-03 10:00

DaFrawg wrote:
But that's not the whole story; the code
char* yourName = "DaFrawg";
MessageBox("Hello there, %s", yourName);
will generate a messagebox with the prompt "Hello there, %s" and the caption "DaFrawg". What I want is, of course, to have the message "Hello there, DaFrawg" displayed.

Can somebody help me, please?

CString strMessage;<br />
<br />
strMessage.Format("Hello there, %s", yourName);<br />
MessageBox(strMessage);

Michael

'Logic, my dear Zoe, merely enables one to be wrong with authority.' - The Doctor: The Wheel in Space

DaFrawg10-Oct-03 8:42

10-Oct-03 8:42

Then why doesn't TRACE1("Hello %s", name) fail?

---QUOTE---

"ERROR: Keyboard not present - Press F1 to continue" - Most BOIS chips

Michael P Butler10-Oct-03 9:03

Michael P Butler

10-Oct-03 9:03

DaFrawg wrote:
Then why doesn't TRACE1("Hello %s", name) fail?

Because the TRACE1 function supports variable arguments. MessageBox does not.

Michael

'Logic, my dear Zoe, merely enables one to be wrong with authority.' - The Doctor: The Wheel in Space

DaFrawg27-Oct-03 2:05

27-Oct-03 2:05

Thanks, it works really good.

David Crow3-Oct-03 10:07

David Crow

3-Oct-03 10:07

Try this:

class Bar
{
public:
    Bar();
    ~Bar();
    
    CString m_String;
};
 
class Foo
{
private:
    CString m_String;
 
public:
    Foo();
    Foo(CString);
    ~Foo();
    
    const Foo& operator=( const Bar& bar );
};
 
Foo::Foo (CString string)
{
    m_String = string;
}
 
const Foo& Foo::operator=(const Bar& BarInstance)
{
    m_String = BarInstance.m_String;
 
    return (*this);
}

Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?

DaFrawg4-Oct-03 2:23

4-Oct-03 2:23

It still doesn't work. I now have the real code I use:

<br />
class Foo<br />
{<br />
public:<br />
	Foo();<br />
	virtual ~Foo();<br />
private:<br />
	CString m_String;<br />
public:<br />
	friend const Foo& operator= (const class Bar& BarInst);    //2x C2801<br />
};<br />
<br />
class Bar<br />
{<br />
public:<br />
	Bar();<br />
	virtual ~Bar();<br />
private:<br />
	CString m_String;<br />
};<br />
<br />
const Foo& operator=(const class Bar& BarInst)   //C2801<br />
{<br />
	m_String = Bar.m_String;   //C2673, C2227 and C2248. Ignore C2248<br />
	return (this*);   //C2673 and C2059<br />
}<br />

The compiler is getting berzerk. Not only a C2801, but also two C2673 (Global functions do not have 'this' pointers), C2227 (left of m_String must point to class/struct/union), C2248 (but that's not a real problem) and C2059 (Syntax error: ';').

David Crow6-Oct-03 2:59

David Crow

6-Oct-03 2:59

Please refer to M. Dimmick's reply. Friend functions are not considered class members; they are normal external functions that are given special access privileges. Also, friends are not in the class’s scope, and they are not called using the member-selection operators (. and –>). The code snippet that I provided you is correct. If it is not the correct solution to your problem, however, then you must reconsider the design.

Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?

Mike Dimmick3-Oct-03 23:52

Mike Dimmick

3-Oct-03 23:52

It's not weird at all, it's standard: operator= must be implemented as a member function, according to the definition of the language.

The error message also tells you that any overloads of operator->, operator[] or operator() must also be implemented as a member function. I believe it also applies to compound assignments, such as +=, /=, etc.

operator= must be a function that modifies the object to which it's applied, i.e. the left-hand side of the assignment statement, which is pointed to by this inside the function body. It should return a reference to the object that was modified.

DaFrawg27-Oct-03 2:00

SDK creation (export of variables)?

27-Oct-03 2:00

1) the operator function IS a member of the class
2) my (new) code IS using the this pointer and returns it

And still VC++ keeps saying "Operator '=' must be an <unknown> member.

sjcomp3-Oct-03 9:25

3-Oct-03 9:25

Hello, everyone.

I am making a program with plug-ins. So I designed SDK (header files + lib file). This sdk is being used by the main program and plug-ins. I am working VC6. Now to the problem. I want to have a global object, which can be used and modified by the main program and all plug-ins (so it is a global object in the sdk). I am confused about how this object is used by main program and dll's. It looks like main program has its own version and each dll has its own version, while I want it to be shared. How do I do it?

And another concern: for right now my sdk is a static linked library, but can I make it to be a dll too? My confustion is that program must load dll and import its functions (like plug-ins), while I want a case, when implimentation of the sdk functions are in the shared dll. I would like to have more information about this topic, does anyone know a good reading material on the subject?

Thank you.

Regards,
Alexander.

Peter Weyzen3-Oct-03 9:34

3-Oct-03 9:34

For DLLs:

First, every class or independent function, or variable should be exported:
see __declspec(dllexport) and __declspec(dllimport)

Second, header for objects that are exported should be included into your exe. Look into using "interfaces". Interfaces help make it possible to upgrade the DLL without relinking the EXE.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<br />
Peter Weyzen<br />
Staff Engineer<br />
<A HREF="http://www.santacruznetworks.com">Santa Cruz Networks</A>

sjcomp3-Oct-03 9:45

3-Oct-03 9:45

Could you be more specific about "interfaces" for me it looks more like a COM termenology.

Regards,
Alexander.

Peter Weyzen3-Oct-03 9:55

3-Oct-03 9:55

COM does use interfaces.

Each object basically has 2 class descriptors.

class __declspec(dllexport) CFredInterface
{
virtual void DoSomething() = 0;
};

class __declspec(dllexport) CFred : public CFredInterface
{
// variable definitions
// other method definitions

// and...
virtual void DoSomething() {}
};

CFredInterface __declspec(dllexport) *FredFactory()
{
return new CFred();
}

The interfaces let you publish only the parts of the classes that you want to other people. You only give out the headers to the interfaces, which defines how people interact with your objects, and doesn't make you share everything with the people that use your code.

The FredFactory gives you a way to instantiate a CFredInterface based class. The user only thinks they are getting a CFredInterface class, they don't need to what they are really getting (CFred).

You should read up on this stuff in "Design Patterns" -- a very important book for most OOP concepts. See: Amazon: http://www.amazon.com/exec/obidos/tg/detail/-/0201633612/002-6725511-1144041?v=glance[^]

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<br />
Peter Weyzen<br />
Staff Engineer<br />
<A HREF="http://www.santacruznetworks.com">Santa Cruz Networks</A>

sjcomp3-Oct-03 10:06

3-Oct-03 10:06

__declspec(dllexport) does not answer the problem of shared objects.

Regards,
Alexander.

Peter Weyzen3-Oct-03 10:27

3-Oct-03 10:27

When you refer to "shared", what exactly do you mean?

It could mean that the DLL lives as only one instance among many programs. This would mean that data in the DLL is shared among all...

It could mean that code lives in a DLL, and is used by each program independently... Each program has it's own copy of DLL data loaded.

Please define what you mean by shared.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<br />
Peter Weyzen<br />
Staff Engineer<br />
<A HREF="http://www.santacruznetworks.com">Santa Cruz Networks</A>

sjcomp3-Oct-03 10:41

3-Oct-03 10:41

By shared I mean the same object is used by all dlls, so it is your first statement. I want all the programms to modify the same object. But right now I have a library (not dll), let's call it sdk.lib which has definition of the global object. My main program is linked with this library (so it has access to the global object). Then I have a dll, which is also linked with the sdk.lib. The question is what is the way to have main program and dll use the same global object defined in sdk.lib (not to have different instances, but to refer to the same one). Maybe I can not do it with a statically linked library sdk.lib?

In general, I want to have an sdk (like Photoshop SDK for example), so people could design their own plug-ins to be used in my program. And I am trying to understand the proper way to set-up my vc projects.

Regards,
Alexander.

Peter Weyzen3-Oct-03 11:24

3-Oct-03 11:24

Do you want 2 programs that run concurrently to be able to affect changes to objects in this DLL.

Process 1 changes something in the DLL and Process 2 can use this change? Or do you just want to share code among different programs.

You say you want to share data -- but it seems like you don't really need to. Shared DLLs with shared live data is a difficult thing to do.... And not often is it really needed.

Plug-ins are really just shared code packaged into a DLL. They often do not intend to be a machine wide data resource....

Consider your needs carefully.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<br />
Peter Weyzen<br />
Staff Engineer<br />
<A HREF="http://www.santacruznetworks.com">Santa Cruz Networks</A>

sjcomp3-Oct-03 11:46

3-Oct-03 11:46

There is no need for two programs to change objects in DLL.

I want to enable plug-ins to modify objects, that are used by the main program. Plug-ins are loaded by the main program. Once plug-in is loaded I want to call a function from the plug-in and this function will do something, that changes objects in the main program (I could pass these objects as function parameters, but there is another way, because all sdk's do that). Example: My program draws a cube, cube has color for each side, I want that any plug-in could change these colors. So I create library (sdk.lib), which has definition of the cube class (CCube) and global instance of this class (CCube global_cube;). Then I create program, which setups window and calls global_cube.Draw() function. This works fine, but... I want to load a dll, which has function DoIt() and this function should call global_cube.ChangeColors(). This requires both main program and dll to refer to the same global_cube object.
And this is the point, where I have problems.

Regards,
Alexander.

Peter Weyzen3-Oct-03 12:10

3-Oct-03 12:10

I predict __declspec and interfaces will be in your future....

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<br />
Peter Weyzen<br />
Staff Engineer<br />
<A HREF="http://www.santacruznetworks.com">Santa Cruz Networks</A>

Gopalakrishna Palem3-Oct-03 19:18

Gopalakrishna Palem

3-Oct-03 19:18

sjcomp wrote:
It looks like main program has its own version and each dll has its own version, while I want it to be shared.

Dear sir,

Have you declared the global object as "extern" ?? In that way all the modules would share the same variable Otherwise each would create its own version.
For example,
Suppose In sdk.cpp we have the global object

//sdk.cpp
CGlobalClass gObject; //This is the actual instance

Now in Main.cpp and all plugins declare like..,

//Main.cpp
extern CGlobalClass gObject;

Do the same in all cpp files where the Global object appears.

Thanking you,
Yours,
P.GopalaKrishna.

sjcomp4-Oct-03 7:01

4-Oct-03 7:01

What about functions, which refer to the same objects? Let's say I have my global object gObject and I have function DoSome(); in my sdk.cpp. Which does something with gObject. Would it still work properly? My confusion is, that once object is decleared external, it means, that it will be referenced at linking. But it will be linked with main program and the dll separately, which would cause them to have two different versions of the same object. I have a feeling that extern works only for the code in the same project, i.e. object files linked together. So it will not solve my problem. Maybe I am wrong, so I will try it.
Thanks everyone, who is helping me, I really appreciate your help.

Regards,
Alexander.

Gopalakrishna Palem4-Oct-03 14:39

Gopalakrishna Palem

4-Oct-03 14:39

Dear sir,

You were right. Extern helps only with in the same project. Since others have already have already given the correct mechanisms for dll's I just didnt mention them. we should, as every one pointed out, use those dll export and import mechanism across executalbes. Sorry for that.

By the way as a matter of fact, if you distribute the SDK in Object files (rahter than in dlls) then we could as well get along with the externs !!

Thanking you,
Yours,
P.GopalaKrishna.

sjcomp6-Oct-03 4:19