|
Thank sfor your help CPallini, really appreciate it.
Regards,
The only programmers that are better than C programmers are those who code in 1's and 0's.....
Programm3r My Blog: ^_^
|
|
|
|
|
you're welcome.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
Now tell me an MFCxx.dll is a COM dll or a standard DLL?
Press: 1500 to 2,200 messages in just 6 days? How's that possible sir?
Dr.Brad :Well,I just replied to everything Graus did and then argued with Negus for a bit.
|
|
|
|
|
VuNic wrote: Now tell me an MFCxx.dll is a COM dll or a standard DLL?
none. you have to provide it with your application binary, or place it in the path...
|
|
|
|
|
That's what a standard win32 dll dear.
Press: 1500 to 2,200 messages in just 6 days? How's that possible sir?
Dr.Brad :Well,I just replied to everything Graus did and then argued with Negus for a bit.
|
|
|
|
|
VuNic wrote:
That's what a standard win32 dll dear.
he he he
|
|
|
|
|
Hello comunity,
i try to save a struct variables to a map!
Simple struct with some CStrings as member!
Which one(Map) to use for that: CMapStringToOb, CMapStringToPtr, CMapWordToPtr?
regards
break;
|
|
|
|
|
in the context of MFC, I would use CMapStringToPtr or CMapWordToPtr depending on the key.
but I strongly suggest you start using STL and std::map.
|
|
|
|
|
Maximilien wrote: I strongly suggest you start using STL and std::map
I second that.
MFC also has a template version called CMap which works similar to std::map . Haven't tried it though since I prefer the STL version.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote "High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
I thought CMap used a hash table and thus was similar to the non-standard hash_map as opposed to std::map.
std::map does not (as far as I know) provide constant average lookup times where CMap does. This would, in my opinion, indicate that std::map is not a good substitute (as far as performance is concerned) for CMap.
This is the main reason I still use CMap, at least until the new "standard" version of hash_map finally gets fully approved.
Maybe I'm missing something so correct me if that's incorrect
|
|
|
|
|
Regarding the performance issue you're probably right, but I cannot verify this since, like I said, I haven't used CMap very much. Whether this performance boost is necessary or not would depend on how the map is used and how frequently elements have to be looked up.
I prefer the STL version due to portability reasons, CMap only exists in MFC library.
If I e.g. develop software in C++ aimed for an embedded system I wouldn't find CMap in that environment. So if I know how to use the STL library I can write more portable code.
If the std::map implementation becomes a performance issue I will first re-evaluate my design and if I find the design to be allright I probably will write my own mapping container using a hash table or similar.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote "High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Roger Stoltz wrote: So if I know how to use the STL library I can write more portable code
Fair enough. I would agree that the portability issue is a big one. I hesitated to use hash_map only because of all the warnings about each library implementing slightly different variations of it and the fact that the "standard" extension for it will likely be of a different name. I'd hate to learn a specific library only to have to change once again when the standard was ratified.
I'm stuck in a windows only OS environment so the MFC's portability issues have been non-existent but I keep forgetting that's not the case for everyone.
Anyway, I'm constantly struggling to understand it all and I posted the comment out of fear that I may have missed something between std::map, hash_map, and CMap. My main concern was the comparison between std::map and CMap since, as far as I know, std::map does not use a hashing table and thus the similarities are not enough to consider one a direct replacement for the other. CMap and hash_map appear, at first glance, to be closer.
One of these years this stuff may all finally make some sense to me.
|
|
|
|
|
Depends on what you are associating with the struct... If you are mapping a string to the struct, you can use CMapStringToPtr or CMapStringToOb , depending on how your struct is/was designed.
Note that using the STL version of the map class would likely be a better idea, but while I like the STL's string class, doing a wholesale replacement of CString may or may not be possible depending on your codebase.
Peace!
-=- James Please rate this message - let me know if I helped or not!<HR> If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong! Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road! See DeleteFXPFiles
|
|
|
|
|
Hi all,
I have a question regarding running VC6 programs on Vista. My program is having problem (certain API won't work) with the MSVCRT.DLL provided by Vista in System32 folder. I have tried the side-by-side way to place my own (older version of MSVCRT.DLL) under my application directory and provide a manifest file for that. It works under Windows XP.
However, when i move the files to Vista, Vista still used the System32/MSVCRT.DLL and ignored my manifest, and thus ignore the older MSVCRT.DLL. I wonder if someone has experienced the same. I have heard that Vista always use the MSVCRT.DLL from System32 for security reason.
Does someone know how to override it? If not, then I may have to recompile my old programs for Vista.
Thanks for helping.
Benny Levin
|
|
|
|
|
If that really is a security feature, then one of two things is up:
The functionality you are trying to use is not being used correctly or is undocumented, and just used to work before things were fixed/changed -or-
There is a bug in the MSVCRT.DLL provided in Vista.
All things being equal - I would presume the former, no offense intended, otherwise Vista would not be backward compatible and that is a rather stupid thing to do.
Peace!
-=- James Please rate this message - let me know if I helped or not!<HR> If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong! Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road! See DeleteFXPFiles
|
|
|
|
|
Hello,
When I use the insert function in vector from STL the pointer becomes invalid from the point where it was inserted.
So how do I use the next elements from the vector
Prithaa
|
|
|
|
|
please show how you're doing thing ?
|
|
|
|
|
Hello,
class CRICH
{
};
vector<CRICH*>m_table;
CRICH *CRICHobj = new CRICH;
m_table.insert(&m_table[2],1,CRICHobj);
Now the pointers after 2 become invalid if I already have vector of about 10 elements of CRICH*
Prithaa
|
|
|
|
|
can't you just us std::vector<>::push_back() ?
|
|
|
|
|
Hello,
But how does a insert work.I want to insert elements in betweeen a vector.
How reorganize invalid pointers
Prithaa
|
|
|
|
|
class CRICH {};
vector<CRICH*> m_table;
CRICH *CRICHobj = new CRICH;
m_table.push_back(CRICHobj);
the danger with with a vector of pointer (rather than a pointer of objects, is that you have to be very careful with memory leaks.
when removing an element from the vector, you should always think to delete it.
for instance, when cleaning the vector:
vector<CRICH*>::iterator it;
for (it = m_table.begin(); it != m_table.end(); it++) {
delete(*it);
}
m_table.clear();
the best is still to declare a vector<CRICH> m_table (by object), and then, only add objects like this :
CRICH CRICHobj = CRICH();
m_table.push_back(CRICHobj);
then, no need to care about deletes, and you can just do a m_table.clear()
|
|
|
|
|
Hello,
Thanks for the details of vector of pointers.
But then what should I do about the insert in a vector.
How can I access the all the elements of the vector once I insert
Prithaa
|
|
|
|
|
prithaa wrote: But then what should I do about the insert in a vector
i shown you the code !!!
prithaa wrote: How can I access the all the elements of the vector once I insert
hum, you should learn about iterators...
|
|
|
|
|
Hello,
Thanks for your support and replies
I'll check up iterators.
Thanks
Prithaa
|
|
|
|
|
prithaa wrote: Now the pointers after 2 become invalid if I already have vector of about 10 elements of CRICH*
what do you mean by that ? do you keep external pointers ( outside of the vector ? ) to those objects ?
inserting in the middle of a vector will invalidate the iterators, but should not invalidate the pointers.
for example, p4 is still a valid pointer to the element.
std::vector<patate*> myVectorPatate;
patate* p = new patate( 1 );
myVectorPatate.push_back( p );
p = new patate( 2 );
myVectorPatate.push_back( p );
p = new patate( 3 );
myVectorPatate.push_back( p );
patate* p4 = new patate( 4 );
myVectorPatate.push_back( p4 );
p = new patate( 5 );
myVectorPatate.push_back( p );
p = new patate( 6 );
myVectorPatate.push_back( p );
p = new patate( 7 );
myVectorPatate.push_back( p );
for ( unsigned int i = 0; i < myVectorPatate.size(); i++ )
{
patate* p = myVectorPatate[i];
std::cout << p->m_i << std::endl;
}
p = new patate( 33 );
myVectorPatate.insert( myVectorPatate.begin() + 2, p );
for ( unsigned int i = 0; i < myVector.size(); i++ )
{
patate* p = myVectorPatate[i];
std::cout << p->m_i << std::endl;
}
|
|
|
|