|
|
Thanks, it works really good.
|
|
|
|
|
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?
|
|
|
|
|
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);
};<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)
{<br />
m_String = Bar.m_String;
return (this*);
}<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: ';').
|
|
|
|
|
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?
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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>
|
|
|
|
|
Could you be more specific about "interfaces" for me it looks more like a COM termenology.
Regards,
Alexander.
|
|
|
|
|
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>
|
|
|
|
|
__declspec(dllexport) does not answer the problem of shared objects.
Regards,
Alexander.
|
|
|
|
|
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>
|
|
|
|
|
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.
|
|
|
|
|
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>
|
|
|
|
|
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.
|
|
|
|
|
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>
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
Hi, everyone.
Thank you for your help. But I am still missing the whole picture. Let me try to explain my confusion once more. I will describe the setup and I would need to know how to connect it
--- sdk.cpp --- compiles into sdk.lib
// defines global object
int& GetGlobal()
{
static int global_int=1;
return global_int;
}
--- sdk.h ---
extern "C" __declspec(dllimport)
int& GetGlobal();
--- plugin.cpp --- compiles into plugin.dll
#include "sdk.h"
// does something with a global object
extern "C" __declspec(dllexport)
void DoIt()
{
int& val=GetGlobal();
cout<
|
|
|
|
|
I am not really expecting an answer, but some clues...
Upon opening a socket, the socket opening doesn't fail. Yet, WSGetLastError() is returning a "file not found" error (a non winsock error).
Upon watching the file system (using FILEMON from SysInternals.com), I notice that my attempts to open a socket yield an attempt to load PSAPI.DLL from my current directory (every time).
This is the file not found, yet does not cause an socket error.
Questions:
1) Should I worry about this?
2) Why is winsock attempting to load PSAPI.DLL each time I create a socket?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<br />
Peter Weyzen<br />
Staff Engineer<br />
<A HREF="http://www.santacruznetworks.com">Santa Cruz Networks</A>
|
|
|
|
|
I am currently working on a very important development project for my school, and a serious problem has occured. For some reason, DDX_Control() and GetDlgItem() will not work in CFormView, how am i sopposed to access control handles? I can't find another way around it, because i want to use a list control.
-- Steve
|
|
|
|
|
Don't you have member variables for the controls in your form ? use them directly.
Maximilien Lincourt
"Never underestimate the bandwidth of a station wagon filled with backup tapes." ("Computer Networks" by Andrew S Tannenbaum )
|
|
|
|
|
They should work because I use them in my CFormView. Maybe you deleted something by mistake?
void CMyFormView::DoDataExchange(CDataExchange* pDX)
{
CFormView::DoDataExchange(pDX);
DDX_Control(pDX, IDC_ICON_WINDOW, m_IconWindowCtrl);
DDX_Control(pDX, IDC_COMBO_ICONVIEW, m_ComboIconViewCtrl);
}
..
..
..
CListCtrl *pListCtrl = (CListCtrl *) GetDlgItem(IDC_ICON_WINDOW);
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
