|
Yeah, I was always told that STL was so efficient and logical. Bull pucky.
------- signature starts
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
Please review the Legal Disclaimer in my bio.
------- signature ends
|
|
|
|
|
I have a love/hate relationship with STL too. So many great jewels in a sea of ****.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
Do anyone know a technical discussion article as to detrmining the number of items at which a map becomes more expensive than a hash_map. Say, if there is a map of 10 items, I would assume that hash_map would fare worse than a map; and the reverse would be true if the number of items were a 100,000. But, is there a way to determine this based on an understanding of how these containers work internally?
Thomas
modified 29-Aug-18 21:01pm.
|
|
|
|
|
Herb Sutter wrote an article talking about the difference between hash_map and map.
http://www.cuj.com/experts/2005/hyslop.htm[^]
However, the standard hash_map can be very brain dead. I have found that if I am that worried about performance, my own hash table does better (2-3 times faster than STLPort's (yes in release mode for all of you who think STL can do no wrong)). But in each case I had special needs. In the first case, my hash_map was VERY dynamic. STL's brain dead hash_map loves to rehash at the drop of a hat and thus was wasting a lot of time. I actually got better performance by fixing my hash size at 17 (a prime since I was hashing addresses) and using my own hash class.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
Hey, you might consider posting your hash_map to CP (STL section is currently so meager).
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Actually, it isn't a template. It is straight plain C/C++. All I really did was fix the hash width and then store the hash information in the actual objects being hashed. Thus you get rid of any extra allocated memory devoted just to the hash map.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
Can anyone tell me how to permanently disable the STL compile warnings that I get each time I compile my code in debug.
The specific warning is C4786.
I am using Visual C++ 6.0 with SP5 and I am using the MS provided version of STL. Will moving to STLPort fix this?
|
|
|
|
|
What has always worked for me was to #pragma-down the warning level, and disable that specific warning.
This is what I use in a current project:
<br />
#pragma warning( push, 1 )<br />
#pragma warning( disable:4786 )<br />
#include <vector><br />
#include <iterator><br />
#include <string><br />
#include <map><br />
#include <stack><br />
#include <vector><br />
#include <xtree><br />
#pragma warning( pop )<br />
Peace!
-=- James (Sonork:100.21837)
"There is nothing worse than being oblivious to the fact that you do not know what you are doing."
[Get Check Favorites 1.5 Now!]
|
|
|
|
|
Thanks for the quick reply. I will try it out ASAP.
|
|
|
|
|
James R. Twine wrote:
#pragma warning( push, 1 )
what does this do?
modified 29-Aug-18 21:01pm.
|
|
|
|
|
> > #pragma warning( push, 1 )
>
> what does this do?
That pushes the current warning level/state onto an internal stack and changes the warning level to 1. The corresponding pop restores (pops) the previous warning level back.
Note that when you pop, any warnings that were specifically disabled/modified after push will return to their previous state.
Peace!
-=- James (Sonork:100.21837)
"There is nothing worse than being oblivious to the fact that you do not know what you are doing."
[Get Check Favorites 1.5 Now!]
|
|
|
|
|
I am somewhat new to proxy stubs. I have been playing around with building a proxy stub. So, I used VC6's to create ATL COM exe.
I have added a method to the interface and everything compiles and links and all that.
Now, I am trying to use CoCreateInstanceEx to instantiate this interface in my client application with the CLSID of my interface and using the CLSCTX_SERVER parameter. Everything compiles and links on the client as well, but when it gets to the CreateInstance part, I get an HR that indicates the Interface is not supported.
I am not sure if this is an open-ended question or not, but is there an easy fix to this? Have I missed a step or something?
thanks
|
|
|
|
|
IIRC, a proxy/stub is required when crossing apartments or remoting (DCOM). Have you built the ATL COM object with merged proxy/stub code?
Peace!
-=- James (Sonork:100.21837)
"There is nothing worse than being oblivious to the fact that you do not know what you are doing."
[Get Check Favorites 1.5 Now!]
|
|
|
|
|
I'm working on a new shell extension (I've written them before, just not this kind...) implementing IShellExtInit and IContextMenu. IShellExtInit::Initialize works correctly - but is called a random number of times (seems to depend on how long it takes me to step throuh the code) for a single action in Explorer. After about 1 to 3 times, the debugger breaks to this colling block of code:
<br />
template <class T, const IID* piid = &__uuidof(T), const GUID* plibid = &CAtlModule::m_libid, WORD wMajor = 1,<br />
WORD wMinor = 0, class tihclass = CComTypeInfoHolder><br />
class ATL_NO_VTABLE IDispatchImpl : public T<br />
{<br />
public:<br />
typedef tihclass _tihclass;<br />
STDMETHOD(GetTypeInfoCount)(UINT* pctinfo)<br />
{<br />
*pctinfo = 1; <br />
return S_OK;<br />
}<br />
The interface and typelib GUID for the template are mine (and other COM automation servers in the library work). What could be causing this problem?
I've tried approaching it from many different angles, but have yet to figure out 1) why IShellExtInit::Initialize is getting called multiple times before IContextMenu is even QI'd, and 2) why it'd break here (I'm sure it's related to #1).
TIA
"Well, I wouldn't say I've been missing it, Bob." - Peter Gibbons
|
|
|
|
|
Shell extensions aren't automation servers, they don't need to implement IDispatch. It's odd that the shell is QI'ing for IDispatch in the first place, actually. My first suggestion is to remove IDispatch from the extension coclass.
--Mike--
"I'd rather you just give me a fish today, because even if you teach me how to fish, I won't do it. I'm lazy." -- Nish
Just released - 1ClickPicGrabber - Grab & organize pictures from your favorite web pages, with 1 click!
My really out-of-date homepage
Sonork-100.19012 Acid_Helm
|
|
|
|
|
Right, I realize that they're not automation servers (I mean that automation servers exists in my library) but every example - including yours - leaves the default ATL stuff there (which extents IDispatchImpl). ATL put it there in the first place and it's never caused problems with the many other shell extensions I've written (what can I say, I'm never content). I agree that it's not needed, though.
I'll try removing that, however, and see what happens. Thanks for the tip.
"Well, I wouldn't say I've been missing it, Bob." - Peter Gibbons
|
|
|
|
|
Even after removing everything related to IDispatch, the problem persists: IShellExtInit::Initialize is called many times, with different addresses for the parameters, until the runtime finally throws an exception, such as the ol' access violation for reading memory at NULL.
The IShellExtInit::Initialize implementation is exactly as yours is.
"Well, I wouldn't say I've been missing it, Bob." - Peter Gibbons
|
|
|
|
|
i made an ATL/Com project and it works just fine in debug mode but when im trying to build Win32 Release MinDependency, i get this error:
LIBCMT.lib(crt0.obj) : error LNK2001: unresolved external symbol _main
ReleaseMinDependency/Tokenizer.dll : fatal error LNK1120: 1 unresolved externals
Error executing link.exe.
any suggestion?
|
|
|
|
|
MSDN Q291952 should solve this;
You could try the MinSize version to verify it builds first.
Steve S
[This signature space available for rent]
|
|
|
|
|
|
This is answered in the VC forum FAQ.
--Mike--
"I'd rather you just give me a fish today, because even if you teach me how to fish, I won't do it. I'm lazy." -- Nish
Just released - 1ClickPicGrabber - Grab & organize pictures from your favorite web pages, with 1 click!
My really out-of-date homepage
Sonork-100.19012 Acid_Helm
|
|
|
|
|
thanks a lot, that solved the problem.
|
|
|
|
|
I'm trying to get a file name. Sound easy enough.
CString strFileName;<br />
static TCHAR szFilter[] = "Comma Delimited (*.csv)\0*.csv\0All Files(*.*)\0*.*\0\0";<br />
<br />
GetDlgItemText(IDC_EDIT_LOOKUP, strFileName);<br />
<br />
CFileDialog dlg(TRUE, NULL, strFileName, OFN_HIDEREADONLY | OFN_OVERWRITEPROMPT | OFN_FILEMUSTEXIST , szFilter, NULL);<br />
<br />
if(dlg.DoModal() == IDOK)<br />
{<br />
TCHAR szFileName[MAX_PATH + 64];<br />
dlg.GetFilePath(szFileName, MAX_PATH + 64);<br />
<br />
SetDlgItemText(IDC_EDIT_LOOKUP, szFileName);<br />
}
The problem is when I call GetFilePath, I get an ATLASSERT, because the window handle is 0. I thought this should be straight forward. Everything else is populated okay, but clicking OK seems to kill the window handle before I get the file name. Or should I be calling a different function.
|
|
|
|
|
Try this in place of dlg.GetFilePath:
lstrcpy(szFileName, dlg.m_szFileName);
|
|
|
|
|
Ed Gadziemski wrote:
Try this in place of dlg.GetFilePath:
lstrcpy(szFileName, dlg.m_szFileName);
I did not bother trying that as its a protected member. But it works. 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
