Ok I am not an MFC user, but i DO want to make use of the windows CPtrList class. So what i have done is toggle that VisualC++ list box to say use MFC in a static library, and #include (containing the CPtrList stuff). All lovely jubbly, but when i compile i get errors saying you cant #''include in an MFC app! All i want is to use the CPtrList class. And windows.h is included in the d3d headers so i cant avoid it. Surely there is a way around this? or is there a better way to use linked lists (i want to use a standard one like MFCs, not code my own - i already did that). Thanks guys http://www.positech.co.uk

what is wrong with coding your own linked list ? They are quite easy if you know what you are doing. And if youdont know what you are doing then read a tutorial and ask questions here if you dont understand.

"Now go away or I shall taunt you a second time"
- Monty Python and the Holy Grail
themGames Productions

If CPtrList is the only reason you''re including MFC, I''d suggest not doing it. I happen to be a fan of MFC, but I write business apps for a living . When I use MFC, I do not use any of their container classes (List, Array or Map). I use STL.

STL is part of the C++ standard, so it''s not part of some 3rd-party library. If you get the latest service pack to Visual Studio, it works very well (both 5.0 and 6.0 have STL bugs in their un-patched state). With STL, you have list, array, dequeue, map, and set. STL has a steeper learning curve than MFC containers, but is well worth it. We converted over to using STL for containers here (were using our own linked list library before), and it''s hard to imagine life without it.

If, on the otherhand, you want to continue with your MFC app, I think the only thing you need to do is #include &ltafxcoll.h&gt. I don''t know why you got your weird error about "cannot include in MFC app". Obviously you can--it''d make the framework pretty useless if you couldn''t.

i fixed it. i just need to #include afxcoll before windows.h and its fine. works like a dream too.
Is using STL faster than the MFC version then? The documentation for STl seems very very vague to me. I can''t get my head around whether its just a framework i need to write my own code inside, or if it actually is a working list class. I am also a bit foggy about where this code is. I mean, somewhere there is a .dll or .exe with this STL stuff in right? or am i barking up the wrong tree here?

We wrote our own list but it dosent have all the features of some list classes, and i want to use a standard method to make it easier to work with other coders.

http://www.positech.co.uk

STL isn''t faster per se, since both MFC and STL use inline functions for their collections.

STL is not a framework; MFC is a framework, but if you''re just using the containers then you''re not using the framework part of MFC. The major framework benefits of MFC are message-mapping (instead of lots of switches in your WinProc), integrated resource editor, Document/View architecture and serialization. Some people would call some of these a liability, it''s all up to personal taste.

Yes, STL documentation is vague and very hard to learn, but it''s worthwhile once you do and it''s part of the C++ standard so it should work on ANY compliant compiler (while MFC will just work for MSVC).

You may have to write extra code to get STL to work with your classes, but you have to with MFC as well. With STL you have to either overload operator < or create a predicate object if you want to sort your containers; with MFC, you have to override CompareObject. Same deal.

There''s tons of resources on STL on the web and there have been many discussion on this board. I''d suggest looking into it.

Yo cliffski, I tried to do the same thing, and placed the include for afxcoll.h afore the others, but after compile I get the following errors:

nafxcw.lib(afxmem.obj) : error LNK2005: "void * __cdecl operator new(unsigned int)"(??2@YAPAXI@Z) already defined in LIBCMT.lib(new.obj)nafxcw.lib(afxmem.obj) : error LNK2005: "void __cdecl operator delete(void *)"(??3@YAXPAX@Z) already defined in LIBCMT.lib(delete.obj)Release/Atom Explorer 2.exe : fatal error LNK1169: one or more multiply defined symbols found 

I did all you did, using mfc as a static library etc - but how do I get round this problem?
r.


"The mere thought hadn''t even begun to speculate about the slightest possibility of traversing the eternal wasteland that is my mind..."

I looked up the fatal error code in the helpfile, and it says the /FORCE option overrides this - so I did that and the new function seems to work fine with things like ints; will it still work with the way it should have been redefined as? Or is there a way to completely avoid this problem?
r.

"The mere thought hadn''t even begun to speculate about the slightest possibility of traversing the eternal wasteland that is my mind..."

agghh:
Ok, the mfc CPtrList worked for what I needed it for back then, but unfortunately I cannot keep on tweaking the order of my #includes to keep afxcoll.h before windows.h in every file which needs to use the class which contains the cptrlist; I have now reached the situation where including windows.h afore afxcoll.h is unavoidable - and doing it this way seems to create problems when certain data types are used.

So to cut a long story short, does anybody know a quick and easy class readily available I can use with the ''ease'' I had with CPtrList? I have heard the STL is handy for this and I think I got a copy on my vc cd, but the included documentation is very vague, as was said above. So does anybody have any examples at hand of using the STL equivalent of CPtrList? I am using member functions like Find, GetAt, AddTail, Remove, etc...

Please answer my plea, I am at my wits end now.

First, about your include problem: most MFC programs have a pre-compiled header that MUST be included as the FIRST line of any file. This is where you would include afxcoll. I think if you worked at it, you could get the includes to not collide.

re: STL. There are endless STL tutorials on the web. However, I usually recommend getting a book. Maybe sitting down at a bookstore that serves coffee with a notepad and reading through one will help.

For your current problem, let me give you an example of using STL''s list to keep pointers:

  #include <list>#include <algorithm>using std::list;int main (){  list<MyObject*> obList; // creates blank list  MyObject* pObj = new MyObject; // create new object  obList.push_back (pObj); // add it to end of list  obList.push_front (pObj); // add it to beginning of list, too  obList.push_back (new MyObject); // add new object to end of list    // the next functions use iterators.  // iterators are pretty complicated, but you can think  // of them as pointers to objects in the container.  They  // are in fact much much more than that, but you need to  // understand STL to understand them better  list<MyObject*>::iterator it; // list iterator  // find is a function in algorithm that searches from one  // iterator to another for a value.  it = find (list.begin (), list.end (), pObj);  ASSERT (it != obList.end ()); // this is true if pObj isn''t found  ASSERT (pObj == *it); // it acts like a MyObject**  ASSERT (it == obList.begin ()); // should have been the                                  // first item in the list  // erase removes the entry represented by the iterator from  // the list, and returns the next item in the list  it = obList.erase (it);  // note, however, this does not delete the pointer; you have  // to do that yourself  for (it = obList.begin (); it != obList.end (); it++)  {    // be sure there are no duplicates in list when doing this    delete *it; // deleting each MyObject*  }  return 0;  // note--no need to erase the list, it''s done automatically}  

I think that covers all of your questions, except for GetAt, which in STL is just operator -> on an interator. Think of the iterator being the analog of the position in MFC containers. To get the object, just do *it. For instance, to call a member function func () of the MyObject, do (*it)->func ().

a minor, but important, correction

quote:
First, about your include problem: most MFC programs have a pre-compiled header that MUST be included as the FIRST line of any [.cpp] file