|
woah, you gotta be kidding me, I'm going to try this now. It kind of makes sense too!
|
|
|
|
|
I'm including a class that has an inline function called
GetOldNodeIndex defined in the header file for that class.
When I try to access it, say in the main() function, the compiler
spills out (seemingly unrelated) unresolved symbol errors....
Here's the class definition
<code>
#if !defined(AFX_SPRINGNODE_H__7DC1CC9F_C211_478F_B542_9B71B4A3C4EA__INCLUDED_)
#define AFX_SPRINGNODE_H__7DC1CC9F_C211_478F_B542_9B71B4A3C4EA__INCLUDED_
#include "CM3DVector2f.h"
#if _MSC_VER > 1000
#pragma once
#endif // _MSC_VER > 1000
class CSpringNode
{
public:
unsigned int m_uiEntryTracker;
unsigned int m_uiNodeIndex;
unsigned int m_uiValence;
double m_dEnergy;
CM3DVector2f m_M3DPosition;
CSpringNode(unsigned int Index, CM3DVector2f& rPosition);
virtual ~CSpringNode();
bool operator<(const CSpringNode& rNode) const
{
return (m_dEnergy < rNode.m_dEnergy);
};
protected:
CSpringNode(){};
private:
unsigned int m_uiPreSortIndex;
public:
unsigned int GetOldNodeIndex() { return (m_uiPreSortIndex); };
};
#endif // !defined(AFX_SPRINGNODE_H__7DC1CC9F_C211_478F_B542_9B71B4A3C4EA__INCLUDED_)
</code>
and the main function
<code>
#include "stdafx.h"
#include "SpringNode.h"
#include "CM3DVector2f.h"
int main(int argc, char* argv[])
{
CM3DVector2f Vector;
Vector.x = 5.5;
Vector.y = -4.6;
CSpringNode aNode(0, Vector);
cout << aNode.GetOldNodeIndex() << endl;
return 0;
}
</code>
and the errors:
Compiling...
TrustRegion.cpp
Linking...
nafxcwd.lib(afxmem.obj) : error LNK2005: "void __cdecl operator delete(void *)" (??3@YAXPAX@Z) already defined in LIBCD.lib(dbgdel.obj)
nafxcwd.lib(thrdcore.obj) : error LNK2001: unresolved external symbol __endthreadex
nafxcwd.lib(thrdcore.obj) : error LNK2001: unresolved external symbol __beginthreadex
Debug/TrustRegion.exe : fatal error LNK1120: 2 unresolved externals
Error executing link.exe.
TrustRegion.exe - 4 error(s), 0 warning(s)
I should mention that if I remove everything that relates to the
inline function all those errors go away and everything works fine....
Anyone know what's going on here???
|
|
|
|
|
So if you comment out the cout << aNode.GetOldNodeIndex() << endl; line, all is well with the linker?
|
|
|
|
|
|
Then the next obvious question is what happens if you make the function non-inline?
|
|
|
|
|
The same thing. However, if I remove:
<br />
cout << temp << endl;<br />
cout << aNode.GetOldNodeIndex() << endl;<br />
<br />
it's okay. 
|
|
|
|
|
Which implies that you cannot use any method of that class, inline or otherwise. Correct?
|
|
|
|
|
Hmmmmmmmmmmmmm.....I suppose....
|
|
|
|
|
This doesn't work either:
<code>
int main(int argc, char* argv[])
{
CM3DVector2f Vector;
Vector.x = 5.5;
Vector.y = -4.6;
CSpringNode aNode(0, Vector);
unsigned int temp = aNode.GetOldNodeIndex();
cout << temp << endl;
return 0;
}
</code>
|
|
|
|
|
Are you building your application in multithreaded mode? This might be required when you use streams.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
That's just it - I'm not using any threads at all - the app is as
simple as you see it before you. The CM3DVector2f.h file contains
our own vector implementation and has been used EXTENSIVELY in MANY
projects, so I know it's not that - only seems to be related to
the inline function I described...
This is just a simple console app to demonstrate the problem - it's
driving me nutz!
|
|
|
|
|
I know this talks about old versions of the compiler and MFC but I think the result is the same.
SYMPTOMS
When compiling an MFC application using the single-threaded run-time library, you receive the following two unresolved external error messages:
nafxcwd.lib(thrdcore.obj) : error LNK2001:
unresolved external symbol "__beginthreadex"
nafxcwd.lib(thrdcore.obj) : error LNK2001:
unresolved external symbol "__endthreadex"
CAUSE
Starting with version 3.0, all MFC classes are "thread safe" and require the multi-threaded run-time libraries to link successfully. Many people try to use the single-threaded run-time libraries because they assume these libraries are needed to enable the application to run in Win32s. This is not the case. MFC versions 3.0 and later will use a single thread, so as long as you are not creating additional threads in the application, the application will run under Win32s.
RESOLUTION
To avoid these unresolved external errors, do not set the Project Settings to Single-Threaded for an MFC version 3.0 or later application. This setting can be changed by doing the following:
On Visual C 2.x and 5.0:
Select the PROJECT menu (and continue Steps 2 through 5 below).
On Visual C 4.x:
Select the Build menu.
Select the SETTINGS... option.
Select the tab, C/C++.
Select CODE GENERATION on the Category list box.
Finally, make a selection other than SINGLE-THREADED on the Use Run Time Library list box.
STATUS
This behavior is by design.
John
|
|
|
|
|
Hi John,
Thanks for the reply. I tried using Debug-Multithreaded as the setting
to enable multi-threading in the project, however, it has only served to
reduce the umber of errors by half. Now I get:
Compiling...
StdAfx.cpp
Compiling...
TrustRegion.cpp
SpringNode.cpp
Generating Code...
Linking...
nafxcwd.lib(afxmem.obj) : error LNK2005: "void __cdecl operator delete(void *)" (??3@YAXPAX@Z) already defined in LIBCMTD.lib(dbgdel.obj)
Debug/TrustRegion.exe : fatal error LNK1169: one or more multiply defined symbols found
Error executing link.exe.
TrustRegion.exe - 2 error(s), 0 warning(s)
Good God but this is frustrating! 
Surely you can use an inline function to dump data to console????? What kind of "by design" behaviour is this??!?!
I have visions of an extensive re-write flashing before my eyes.....
|
|
|
|
|
The inline function is a red herring, it is perfectly fine and can link against the function. Accessing any other function from the object should produce the same spew. This spew is normally associated when accidentally linking against the wrong threaded libraries. Although you may have changed your project settings to multithreaded, can you be sure that all the other projects in your workspace (and indeed libraries) are of the same thread specification? Check out MSDN Index and type in LNK2005 for more info. Also I notice you use a dummy constructor that is inlined, but not a dummy destructor, have you defined this in your .cpp implementation?
|
|
|
|
|
I concur on the inline function being the red herring. However, the odd thing is is that I noticed this behaviour in another project and couldn't resolve it there. So I
created a simple console application in the Project Wizard (VS 6.0) and attempted to
reproduce it. It is easy to see that I did. Which confuses me....This is just
a simple console app with a main function - no other projects in the workspace - thus
all are of the same thread specification. I have mucked about with the thread options in the project settings to no avail. Actually the dummy constructor can be removed and no, I haven't implemented a dummy destructor, but I don't think this should have much of an effect (??).
|
|
|
|
|
John Theal wrote:
Surely you can use an inline function to dump data to console?????
It has nothing to to with inline functions I use them all over the place in my applications, console or not. Are you using MFC in this application? Is it set in the Project Settings?
John
|
|
|
|
|
I'm not exactly sure why is this but maybe you can try to remove the 2 semi-colons from your code and retry...
class CSpringNode<br />
{<br />
public: <br />
...<br />
bool operator<(const CSpringNode& rNode) const<br />
{<br />
return (m_dEnergy < rNode.m_dEnergy);<br />
};<-- Remove this semi-colon<br />
<br />
unsigned int GetOldNodeIndex()<br />
{ return (m_uiPreSortIndex); };<-- Remove this semi-colon<br />
<br />
...<br />
};
|
|
|
|
|
Thanks for your help, but that didn't seem to clear up the problem.
Surely someone has run into this before???
=[ Abin ]= wrote:
I'm not exactly sure why is this but maybe you can try to remove the 2 semi-colons from your code and retry...
class CSpringNode
{
public:
...
bool operator<(const CSpringNode& rNode) const
{
return (m_dEnergy < rNode.m_dEnergy);
};<-- Remove this semi-colon
unsigned int GetOldNodeIndex()
{ return (m_uiPreSortIndex); };<-- Remove this semi-colon
...
};
|
|
|
|
|
After trying out various ways, and NOT finding a truly successful way to pass "enum" as parametric values, it leaves me using *enums* as global variables.
I don't have a problem with the compiler. It accepts the syntactical manner in which I apply its usage. It is when I start turning on and turning off certain of its values, that I noticed (after extensive debugging) that the values weren't being turned on and turned off when they should've been, which led me to suspect that values weren't being passed correctly to the function parameter. (I don't now what to think at this point.)
IOW, all I'm saying is that the function which receives that parametric value, is not behaving the way it ought to behave (meaning, when a certain value is specifically turned on just before calling that function, when the function is executed, it doesn't react as though the value was turned on, and debugging confirms this).
Thanks.
and 
William
Fortes in fide et opere!
|
|
|
|
|
WREY wrote:
After trying out various ways, and NOT finding a truly successful way to pass "enum" as parametric values, it leaves me using *enums* as global variables.
class MyClass
{
public:
MyClass()
{
}
~MyClass()
{
}
enum Day
{
Sunday,
Monday,
Tuesday,
Wednesday
};
void Foo( Day day )
{
TRACE("day = %d\n", day);
}
};
...
MyClass mc;
mc.Foo(MyClass::Tuesday);
|
|
|
|
|
You did answer the question (according to way I asked it). Thanks!
However, in actuality where things began going murky for me, is when I'm inside Foo() I make a change to "day" (the object of "Day") by giving it a different value when I'm about to exit. This I do by including in the definition of "Day" a generic value (let's call it "anyday") so that every time I call Foo(), I don't have to use a specific value, I just use "anyday" and check its value inside Foo() to see what the specific value is that I really need. I do this to avoid having to hard-code a specific "Day" value in the function parameter every time I call Foo().
IOW, I assign the new value to "anyday" while I'm inside Foo(), using "anyday" as my parametric value and then check "anyday" to see what the specific value is that I had assigned to it when I was previously inside Foo(). (I think I might be outsmarting myself here, because the compiler accepts the code as well.)
That is what I meant to ask, but made it sound in a way I believe I may have misled you. It was inadvertent and I regret any mislead.
While it is true that the compiler is accepting my code, I believe I might be abiding by the rules of C++, but not by its intent.
William
Fortes in fide et opere!
|
|
|
|
|
Remember that changes to formal parameters have no effect on the caller's variable, unless you're using a reference.
--Mike--
"Big handwavy generalizations made from a position of deep ignorance is one of the biggest wastes of time on the net today.
-- Joel Spolsky
Ericahist | Homepage | RightClick-Encrypt | 1ClickPicGrabber
|
|
|
|
|
Halo, I still have problems with list box..
The idea is to have a set of data in a list box..like..list1, list2 ,list 3...etc,
and then to retrieve the data which was clicked,
I have created list box but i dont know how to fill it in with data,
BOOL CdcsetDlg::OnInitDialog()
{
CDialog::OnInitDialog();
CString str;
for( int i=0; i
|
|
|
|
|
Have you created the listbox before filling them ?
how are they created, in a resource file or dynamically ?
Maximilien Lincourt
"Never underestimate the bandwidth of a station wagon filled with backup tapes." ("Computer Networks" by Andrew S Tannenbaum )
|
|
|
|
|
You need to be more specific about your problem? What is the Assert msg? Where is it?
You appear to be mixing different loops in your code here as you have two for loops intertwined where the code refers both to i and j and it's not obvious what you're trying to do.
1. Add a ListBox to the dialog
2. Create a DDX variable by right clicking the control and selecting Add Variable.
3. Variable name = m_List (to match your code) - You'll also need to delete your own manually defined m_List
You should now be able to add and remove items as well as respond to user events.
Cheers,
Tom Archer
Inside C#,
Extending MFC Applications with the .NET Framework
It's better to listen to others than to speak, because I already know what I'm going to say anyway. - friend of Jörgen Sigvardsson
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
