C / C++ / MFC

15-Oct-01 11:38

I get a lot of these warning messages, when I compile a program that uses STL maps.

identifier was truncated to '255' characters in the debug information

I do not think that it is a problem. But thought would take second opinion. If it is not an issue, how can I make it go away, ie, the message not to appear so that I can see the *real* errors in the *Build* window.

Thanks in advance for any help on this.

-Thomas

modified 29-Aug-18 21:01pm.

C^hris L^osinger15-Oct-01 11:44

C^hris L^osinger

15-Oct-01 11:44

#pragma warning(disable:4786)
put this before (and sometimes after) any STL includes.

it's a harmless warning.

-c

Smaller Animals Software, Inc.
http://www.smalleranimals.com

User 988515-Oct-01 12:03

15-Oct-01 12:03

Thank you very much.

I also had another question. Do you have any idea of the performance benefit or degradation when using STL containers instead of MFC containers? I have a set of programs that makes extensive use of MFC containers. But, for a new version of the program, I wanted to use SMART pointers and found that MFC containers are not typesafe. Hence the reason to move to STL. But, I also do not want to find out later that there is a performance degradation.

How would you rate MFC vs STL container (specifically maps) performance? Would using a library from stlport.org help?

Thanks again

Thomas

modified 29-Aug-18 21:01pm.

C^hris L^osinger15-Oct-01 12:46

C^hris L^osinger

15-Oct-01 12:46

i've heard VC's STL maps can be slower than MFC's CMap. but, i've also heard that other STL implementations can be faster.

try www.deja.com

-c

Smaller Animals Software, Inc.
http://www.smalleranimals.com

Alvaro Mendez16-Oct-01 6:40

Alvaro Mendez

16-Oct-01 6:40

MFC containers are not typesafe??? What do you mean, which ones are you using?

Regards,
Alvaro

User 988516-Oct-01 6:48

16-Oct-01 6:48

CPtrList, CTypedPtrList, CMapStringToPtr etc...

None of them are typesafe.

-Thomas

modified 29-Aug-18 21:01pm.

Alvaro Mendez16-Oct-01 8:19

Alvaro Mendez

16-Oct-01 8:19

Woah!

CPtrList is not type safe since it holds a list of void pointers. But CTypedPtrList is a type-safe “wrapper” for objects of class CPtrList (according to MSDN).

The CTypedWhatever classes are type-safe. The only ones that aren't are the CPtrWhatever and the CObWhatever classes. Also, CArray, CMap, and CList are type-safe.

Regards,
Alvaro

Mike Burston15-Oct-01 12:13

Mike Burston

15-Oct-01 12:13

In general, you can suppress this warning using the pragma directive

#pragma warning(disable:4786)

However, this does not always work - in particular, I have noticed problems when mixing STL and MFC with the DEBUG macro (and adding in DLLs just for good measure). Microsoft has acknowledged that this pragma does not always work :

http://support.microsoft.com/support/kb/articles/Q167/3/55.ASP - "BUG: C4786 Warning Is Not Disabled with #pragma Warning"

You should also look at installing and using the "STL Error Message Filter" from BDSoft (http://www.bdsoft.com/tools/stlfilt.html) - it's free, and very, very good at turning STL errors into english!

-----------------------
Reg : "Well, what Jesus blatantly fails to appreciate is that it's the meek who are the problem."

User 988515-Oct-01 12:19

15-Oct-01 12:19

In my case the pragma directive works. Maybe because I am not using MFC in this application at all.

Also, I asked earlier also, do you have any experience using STL containers and their relative performance compared to MFC containers, especially maps?

Thanks a lot.

Thomas

modified 29-Aug-18 21:01pm.

Mike Burston15-Oct-01 12:38

Mike Burston

15-Oct-01 12:38

No, I have no idea of the relative efficiencies of MFC versus STL containers - I have been using STL heavily for the past 3 years, and prior to that I used a library of custom built containers. I have never used MFC containers. I would expect STL to be similar to MFC in performance, but I do know that there have been examples of STL running much slower than MFC in specific instances. I believe this is due mainly to the fact tht MFC was designed in the early ninties, when PCs were NOT equiped 1gig CPUs, and therefore a fair amount of effort went into building a libraray that had reasonable performance. STL, on the other hand, is designed for portability and flexibility (via extension), and the entire container/iterator/algorithm framework has at least some inherent overhead. I have never found STL to be a 'choke-point' in my code, however.

Your quickest answer is probably to code up a simple test - build a small MFC exe that has a std::map and a CMap, then try filling, sorting, searching, removing. put it all into a loop, run it 10000 times, see how long it takes.

-----------------------
Reg : "Well, what Jesus blatantly fails to appreciate is that it's the meek who are the problem."

User 988515-Oct-01 12:45

15-Oct-01 12:45

Yes .. I will be doing that. I was getting some peer opinion/experiences also. I did not want to find out something late in the development stage.
Thanks for the info. I will post the results of my test.

Thomas

modified 29-Aug-18 21:01pm.

CStatic problem

15-Oct-01 10:28

I want my CStatic behind all other buttons, edit controls etc.
It's a bitmap static and how to do that!??

// DeRGTT

Christian Graus15-Oct-01 10:30

Christian Graus

15-Oct-01 10:30

Don't use a static - draw the bitmap onto the background instead.

Christian

As I learn the innermost secrets of the around me, they reward me in many ways to keep quiet.

Men with pierced ears are better prepared for marriage. They've experienced pain and bought Jewellery.

15-Oct-01 10:40

Ok... how to do that then! Smile | :)

J Patel15-Oct-01 11:06

J Patel

15-Oct-01 11:06

Check out http://www.endurasoft.com/techtalk/dlgbkgnd.htm

There is another class on codeguru as well.

HTH

Jignesh

new and delete, why does this work?

Michael Dunn15-Oct-01 12:34

Michael Dunn

15-Oct-01 12:34

Your question is answered in the VC forum FAQ.

--Mike--
http://home.inreach.com/mdunn/
"The Earth is doomed." -- Rupert Giles
Heart | [heart]

your

with

and

Sam C15-Oct-01 10:22

15-Oct-01 10:22

Hi,

Going over some code in a multithreaded library I came across a snippet that bewilers me, and I was hoping one of you can make sense of it for me. It is part of a multi-threaded application. First there a global structure declared.

struct CustomStruct
{
  CWnd* pCwnd;
  int* pInt;
  long* plong;
}

These are the same declarations but I can't recall them. But they are all pointers to some value. Then in one member function part of a class there is this call.

...
CustomStruct* pCS=new CustomStruct;

pCS->pCwnd=AfxGetMainWnd();
pCS->Int=&IntVariable;
pCS->plong=&LongVariable;

CreateThread(...(Pass the above struct address as LPVOID)

And in the static function for the thread we have

CustomStruct* pCS=(CustomStruct*)wParam;
CWnd* pCwnd=pCS->pCwnd;
int* pInt=pCS->pInt;
long* plong=pCS->plong;

delete pCS;

How does the delete portion of the code work? I don't understand how we can delete the structure here and still have access to the new pointers we declared in the function? How can we delete the structure and still have the data stored in the pointer still be valid? Did we not get rid of that data with delete? I'm confused please explain.

Thanks in Advance.

Sam C
----
Systems Manager
Hospitality Marketing Associates

Tim Smith15-Oct-01 10:27

Tim Smith

15-Oct-01 10:27

As you noticed, the temporary structure just contains a window handle and pointers to other variables. Once these values are copied from the structure, it can be deleted.

The original variables that the pointers referenced still exist.

Tim Smith
Descartes Systems Sciences, Inc.

Sam C15-Oct-01 11:54

15-Oct-01 11:54

Thanks. I get it now, but what if we change the pointers to be straight variables. For example, remove the CWnd* and change the other to to long and int (instead of long* and int*) then by deleting the structure this time we remove those variables from memory? And the above example I gave will no longer be valid?

Thanks for helping out I didn't have pointer problems or memory allocation problems using VB Smile | :)

Sam C
----
Systems Manager
Hospitality Marketing Associates

Tomasz Sowinski15-Oct-01 10:28

Tomasz Sowinski

15-Oct-01 10:28

Think about CustomStruct as a disposable paper bag. Inside there are three things: a pointer to CWnd, a pointer to int, and a pointer to long. You take these things out of the bag, and get rid of the bag.

'delete' destroys only a memory block that holds three pointers. These three pointers remain perfectly valid.

Tomasz Sowinski -- http://www.shooltz.com

Sam C15-Oct-01 11:52

15-Oct-01 11:52

Thanks for some reason I was thinking it "destroyed" everything. So only the pointers are deleted but not the actual value stored in memory. So if these weren't pointers then we would have a "memory" leak problem? Say for instance we remove the CWnd, but keep int and long we call delete would those values be removed from memory?

Sam C
----
Systems Manager
Hospitality Marketing Associates

Mike Burston15-Oct-01 12:29

Mike Burston

15-Oct-01 12:29

You're almost there!

Yes, when 'delete' is called on the struct/class, the members are destroyed. If those members are pointers, then the pointer is destroyed, but not what is pointed to. If you have no other pointer to the 'pointed to' object, then you have a memory leak (remember - you can have multiple pointers pointing to the same memory address/object).

If you want the things that are 'pointed to' to be destroyed when you call 'delete', you write a destructor that does this. As a general rule (there are always exceptions, and the code you are looking at is one of those exceptions)
if a class/struct contains pointers, it should also have a destructor that 'cleans up' the pointed to objects. And a copy constructor and an assignment operator - but that's getting a little too complicated for now!

So far, so good (I hope).

If the members are just 'builtin types' like int, then when delete is called the int is destroyed. However, in your code you copied the int value from the struct just before calling delete. Therefore, the 'int' in the struct is removed from memory by the call to delete, but the copy you made still remains valid, becuase it is a different copy of the int value from the struct. Er... I think that's what I'm trying to say!

-----------------------
Reg : "Well, what Jesus blatantly fails to appreciate is that it's the meek who are the problem."

PJ Arends15-Oct-01 13:07

PJ Arends

15-Oct-01 13:07

I think the easy way to get your head around pointers is to think of them as addresses. the RAM (memory) is a street, and every house on that street has an address (a pointer). If you want to tell your friend to go to a certain house, you write the address on a piece of paper, and you give him the paper (you have just passed a pointer, in a customstruct(on paper)), then he goes out and meets another friend, who also wants the addresses that he writes in his notebook (gets a copy of the pointer). Now your friend decides he doesn't need the address any more so he throws away the paper (deletes the custom struct, but the memory(house) still exists). As long as the house exists the address is valid, but if the house burns down (your object is deleted from memory) the address will point to an empty lot (invalid memory).
I hope this helps, this analogy helped me understand pointers Smile | :)

---
Blessed are those who can laugh at themselves, for they shall never cease to be amused Laugh | :laugh:

Sam C15-Oct-01 13:46