|
I mostly disagree with the others.
1.
You need better identifier names. Then the short form is the right one:
if (printingToFile) printToFile();
2.
it does not make sense comparing with true explicitly, as can be proven ex absurdo:
If you think
if (a==true) ...
is any good, then the following is even better:
if ((a==true)==true) ...
3.
when the variable's type is NOT boolean and you need an explicit constant value, then one can argue putting the constant first is safer, as it causes an error when accidentally = is used instead of ==. However, a decent compiler will generate a warning when you accidentally write:
if (myInteger=1) ...
|
|
|
|
|
I don't agree with your point 2 proof (though it is clever).
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.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Agreed 100%.
Remember these ones:
BOOL bDoIt = ::ExternFunction();
if (bDoIt == TRUE)
where ExternFunction() according to documentation returns non-zero on success?
It's not a matter of style. It's a matter of stupidity.
|
|
|
|
|
Niklas Lindquist wrote: BOOL bDoIt = ::ExternFunction();
if (bDoIt == TRUE)
Niklas Lindquist wrote: It's a matter of stupidity.
May be I'm being a bit stupid but, what exactly is "stupid" in the code above?
if (bDoIt) would've looked nicer but if (bDoIt == TRUE) isn't bad either.
It's better to know some of the questions than all of the answers.
Pravin.
|
|
|
|
|
It's ultra-bad. Returning non-zero on success, might just as well mean returning 2, 3 or, God forbid, even 4. Comparing it to TRUE (i.e. 1) might not give the anticipated result. The only thing you can compare it to is FALSE, if (bDoIt != FALSE), would have been the correct usage. But that really doesn't help anyone, does it.
Good naming removes the need for such constructs. It's about readability.
Consider
if (signalIsOn) {}
if (signalIsOn == true) {}
The second construct is just plain silly, and actually reduces readability.
|
|
|
|
|
OK, now I get it. To be honest, I had never thought about this side effect. But, to me what seems to be the real problem here is the use of BOOL (which is essentially int)in place of bool. A bool bDoIt would have responded to any non-zero number by simply turning itself to true.
Does that mean we should avoid using BOOL in general?
It's better to know some of the questions than all of the answers.
Pravin.
|
|
|
|
|
PravinSingh wrote: the real problem here is the use of BOOL
I admit that this is slightly off topic, but still, I think it's worth mentioning.
Avoiding BOOL in general is a good thing. But in reality, you would probably use a mix if you are hacking Windows API. The language evolves, but sadly, a lot of features are not used using excuses such as 'we need to handle an old code base' or 'we need to support an ancient compiler'. They might be valid excuses, but you could be stuck at that forever. Whenever possible, embrace what the technology gives. Also, embrace boolean algebra and proper naming
|
|
|
|
|
This was adopted as a standard some time ago by many developers for these statements because there was actually a time when the compiler would not have complained about
if( isThisCool = true )
but most certainly would have complained about
if( isThisCool = a )
so it was a little bit of a defensive coding mechanism.
Nowadays, it really doesn't matter and I personally have gone to the
if( isThisCool )
syntax. It just reads nice that way.
|
|
|
|
|
Generally prefer the third form - if someone needs reminding that a logical expression resolves to true (non-zero in older languages) or false (0 in older languages) in an algol derived language then they need a refresher.
If you use decent names, know boolean algebra and wrap up complicated logical expressions in functions you can't go wrong. Or rather you probably won't go wrong, and if you did then direct comparison with true or false (either way around) isn't going to help you.
Cheers,
Ash
|
|
|
|
|
Hello everybody.
This is my problem:
I need to connect to https webpage which has a self-signed certificate.
Regular webbrowsers warn me when I open that page.
I want to connect to it and POST some data.
When I connect to the https webpage, I'm getting an error saying "The certificate authority is invalid or incorrect". Here's my code:
CInternetSession ises;
CFile* f=NULL;
f=(CFile*)ises.OpenURL(L"https://mysite.com/login.jsp");
...
Is there any way to accept that certificate or any other solution?
Thanks in advance.
|
|
|
|
|
Maybe this[^] can help.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
|
|
|
|
|
Code-o-mat, thanks for your reply.
I tried the code that should ignore the invalid certifacate as said in the link you gave.
But, it doesn't seem to work, the code's working, but my problem didn't get solved.
Please see the code:
CFile* f=NULL;
MyTry:
try{
f=(CFile*)ises.OpenURL(L"https://mysite.com/login.jsp");
}
catch(CInternetException* s){
if(s->m_dwError==ERROR_INTERNET_INVALID_CA){
DWORD dwFlags;
DWORD dwBufferLen=sizeof(dwFlags);
ises.QueryOption(INTERNET_OPTION_SECURITY_FLAGS,(LPVOID)&dwFlags,&dwBufferLen);
dwFlags|=SECURITY_FLAG_IGNORE_UNKNOWN_CA|SECURITY_FLAG_IGNORE_CERT_CN_INVALID;
ises.SetOption(INTERNET_OPTION_SECURITY_FLAGS,&dwFlags,sizeof(dwFlags));
goto MyTry;
}
}
...
Is there any other way to workaround this problem?
|
|
|
|
|
I can't think of anything else other than trying to do the download without OpenURL, using CInternetSession::GetHttpConnection[^], CHttpConnection::OpenRequest[^] and CHttpFile[^], maybe it makes a difference...
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
|
|
|
|
|
Hi,
How to remove maximize button from frame window in SDI application?
|
|
|
|
|
I've never found a clean way to remove the maximise button but you can effectively disable it by handling WM_SYSCOMMAND/SC_MAXIMIZE and returning 0 from the window procedure.
Cheers,
Ash
|
|
|
|
|
Better to rest the WS_MAXIMIZEBOX style bit with a SetWindowLong, so that the gui will paint the button consistently.
By simply throwing away the command, you end-up with an inconsistent GUI showing an enabled command that doesn't behave as expected.
2 bugs found.
> recompile ...
65534 bugs found.
|
|
|
|
|
Don't set (or remove ) the WS_MAXIMIZEBOX style. As Ash said, the maximize box will then be drawn disabled.
If you have none of WS_MAXIMIZEBOX and WS_MINIMIZEBOX styles, no size boxes are drawn at all.
cheers,
AR
When the wise (person) points at the moon the fool looks at the finger (Chinese proverb)
|
|
|
|
|
I have a very frustrating issue that has been driving me nuts for a couple of years now.
We have a 3rd party application that is pretty much a high load Sybase database to which we have no visibility. My internal customer requires me to provide them with real time statistics using a web app to show the results.
In order to retrieve this real time data, we have an sdk provided by the vendor, who unfortunately no longer exist so it is completely unsupported.
This sdk has one big problem, it has a memory leak that causes the thread to grow by between 2 and 4k on each iteration.
My solution is an MFC application which consumes the sdk. In order to manage the memory space of the application and keep it from eating up unlimited resources, I have a Windows Service wrapping the application and monitoring the memory usage. When the usage gets to big, it signals the application to exist and then restart.
My issue is that periodically there is a memory error occuring within the sdk which I can't handle in my application. There is no pattern to the timing of this error. It could be five minutes, or five days, and the invalid memory address also doesn't follow any visible patterns.
Has anyone else had a similar issue with a memory exception in a third party sdk? How did you deal with it? I have spent years writing real time software and my threading knowledge is very good, so I have eliminated the possibilities of bad or missing locks and pointers in my side of the application.
modified on Wednesday, October 13, 2010 2:27 PM
|
|
|
|
|
If the memory leak and the memory access error are inside a third-party library that comes without sources, you have no chance to fix it. According to what you have already done, the only one approach that I could imagine is to use Structured Exception Handling (C++)[^] to catch the memory access violation event: this will give you the chance to exit the application without showing a dialog that reports the crash, the next step is obviously to restart the application.
|
|
|
|
|
Thanks for the quick response. I'm doing some reading and I'll post back whether this is a solution or not.
|
|
|
|
|
PogoboyMtK wrote: we have an sdk provided by the vendor, who unfortunately no longer exist so it is completely unsupported.
After patching a solution, have a long hard discussion with the power that be in your company to find a replacement for that faulty SDK.
Watched code never compiles.
|
|
|
|
|
I agree 100%. My issue is that the sdk is tied 100% to the db which is 100% tied to the product which is 100% tied to the users which is simply not an option to upgrade.. I don't know whether to laugh or cry about that one.
|
|
|
|
|
This might sound disgusting but maybe you could try hooking the memory allocation API calls "under the hood", i mean things like GlobalAlloc or HeapAlloc and somehow keep track of the memory allocation/deallocations the third party does and when you get back the control (so execution comes back from the third pary call), investigate what memory allocations were left undeallocated and deallocate them yourself.
I already did such hooking magic a few times in my life so in case you are interested, i am willing to try and help doing this, it sounds like a challenge.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
|
|
|
|
|
I would love for the help, but due to confidentiality issues I can't take you up on it.
Thank you for the offer, though.
Anytime someone tells me some code will be "disgusting" or "really ugly", etc. I become very much intrigued by the challenge of making it pretty and manageable.
modified on Wednesday, October 13, 2010 2:52 PM
|
|
|
|
|
I didn't mean the code would be ugly, i meant the concept itself. Anyways, i can still try to give you the idea, maybe you can use it, maybe not, that is up to you to decide, so here's what i would do.
1. Try to determine where the memory leaks come from by trial and error (i mean, what 3rd party call, i supose you already know that, so you can skip this step)
2. Install hooks for the allocation/reallocation/deallocation methods listed here[^], see API hooking revealed[^] for hooking methods (since you are working within your own process -i supose- you don't need the DLL injection part). Depending on that SDK you might need to do the hooking for multiple modules (DLLs), again, this is up to you to determine. Since malloc/new come down to these memory management functions, this should suffice to "catch" all memory allocations.
3. In my hook functions, i would call the originals to perform the actual memory management, but i would add every allocated pointer to some array of my own, remove them when they are freed, replace them when reallocations are done. I would make this conditional based on some global flag (or such) so when it is unneeded (when no 3rd party code is executing) it doesn't take up resources uselessly.
4. Before the 3rd party call, i would turn the "allocation tracking" mentioned in point 3, let the 3rd party thing finish, turn off the tracking thing, and then analize the array i used for the pointers. If my assumptions are correct the array should contain pointers to the buffers which aren't freed up and then i could just free them up myself (be careful to use the correct methods for the deallocation, so if e.g. a pointer was allocated by HeapAlloc then use HeapFree, if VirtualAlloc then use VirtualFree).
What might go wrong is that if the 3rd party thing e.g. calls CRT's malloc, and that calls HeapAlloc, which in turn calls VirtualAlloc, and you hooked both HeapAlloc and VirtualAlloc, then you might "hit" the same pointer twice, another thing that can be -and i am afraid will be- a problem is that -as far as i know- CRT doesn't actually free up memory when you call free (or at least not always) but it somehow flags it internally for himself to be free and will reuse it later, sadly as far as i know you can't hook malloc/free.
This whole idea requires some experimenting i am afraid. In case you decide to try it, please do tell me how it went, i am curious. Good luck, if you should have any questions, feel free to hit me in the head with it.
[EDIT] If your third party SDK doesn't link statically to CRT (so uses the DLLs) then you might even hook malloc/free/realloc too. [/EDIT]
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
modified on Wednesday, October 13, 2010 4:47 PM
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
