Re: <vent> Arrrgh </vent>
I don't know what kind of program/environment you are working in, but generally users don't care about performance if the program crashes. Also users don't care where the program crashes (e.g. 3rd party dlls), all they know is that your company's program has crashed. IMO, stability is worth much more than performance.
Re: <vent> Arrrgh </vent>
I agree completely. I think sometimes he is a little bit too focused on performance and code efficiency, instead of maintainability and stability - eg. he doesn't trust the STL so we have implemented all our own versions (pain pain pain to maintain).
[sigh].
sockman
Re: <vent> Arrrgh </vent>
Have you taken performance comparisons between your hand written code and STL?
STL is supposed to be within 5% of hand written code.
Even if you are seeing slight speed improvements over STL it is generally hard to justify a the hand written solution:
STL is used by 10's of thousands of folks (whereas your code is not)
STL is universal. Many folks already know STL, so newcomer training is reduced.
Very few people can write equivalent code as STL and get it right the first time.
Re: <vent> Arrrgh </vent>
No performance testing has been done. He just doesn't trust it. There is nothing I can say or do to make him change his mind. I stopped hitting my head against that particular wall a while ago now. Now I think I will stop hitting my head against the exception handling wall :)
Re: <vent> Arrrgh </vent>
Quote:
Originally Posted by sockman
No performance testing has been done. He just doesn't trust it.
But he does trust all of those other functions that are part of the standard library, like fopen(), right? If he does trust these functions, why?
It's mostly psychological if you ask me. He trusts "easy" things he thinks are simple to code himself, but anything that needs a few hours to code yourself, then he only trusts himself to do it. Of course, creating your own fopen() is not easy, but since he's seen it a lot, it's OK.
There is something called NIH (Not Invented Here) syndrome, and I guess he fits the profile.
Regards,
Paul McKenzie
Re: <vent> Arrrgh </vent>
Quote:
Originally Posted by Paul McKenzie
There is something called NIH (Not Invented Here) syndrome, and I guess he fits the profile.
Usually after working for a guy like that it leads to RFH syndrome.
(Really frustrated here)
Re: <vent> Arrrgh </vent>
Quote:
Originally Posted by Paul McKenzie
There is something called NIH (Not Invented Here) syndrome, and I guess he fits the profile.
Absolutely.
I think you have pretty much nailed it. As soon as anyone brings up STL or c++ exceptions and a whole raft of other banned things you can practically see the cone of silence come down over his head.
It took me a good year to convince him to let programmers use the debugger! He doesn't trust it. He finally gave in, but he still refuses to use it himself and gets annoyed when he sees programmers fire it up. After all, what can a debugger do that you can't do with hours and hours of combing through trace files?
sockman
Re: <vent> Arrrgh </vent>
Quote:
Originally Posted by sockman
Absolutely.
I think you have pretty much nailed it. As soon as anyone brings up STL or c++ exceptions and a whole raft of other banned things you can practically see the cone of silence come down over his head.
If he needed to get a C++ job in another company, I wonder if he realizes he would probably not get hired. But I still think it's psychological -- there are some programmers who have their ego broken if they are not coding their own linked lists, containers, string classes, exception mechanism's etc.
Quote:
It took me a good year to convince him to let programmers use the debugger! He doesn't trust it. He finally gave in, but he still refuses to use it himself and gets annoyed when he sees programmers fire it up.
Debuggers have been available since close to the beginning of "interactive" programming (programming with a terminal and a keyboard in front of you). It isn't something new invented by Microsoft, so I don't know what his problem would be with it.
I would fire up the debugger every chance I get, and make sure he sees it started. I just wouldn't care what he thought, and just get the problem solved. You do have customers, right? Do they care how you solve the problem?
Quote:
After all, what can a debugger do that you can't do with hours and hours of combing through trace files?
Trace files are first, once you see a problem, then debuggers are used to confirm the fault. If the trace file doesn't reveal anything in a timely manner, then the debugger takes precedence. That is the way I usually do things if I have a trace or log file of some type.
Regards,
Paul McKenzie
Re: <vent> Arrrgh </vent>
Even for people, like me, working in embedded system who has to worry about interrupts, timings etc, use a debugger. Not using a debugger is counter-productive especially the complexity of software has increased exponentially.
In today's fast pace world, not only our knowledge have to progress but also the tool we use. We will not remain competitive if we are still using stone age tool. In fact, lots of previous assumptions about software programming has been obsoleted because technology has improved. Anyway, I think your manager is most likely to save pennies but lose pounds (pardon me if it is not correct). :rolleyes:
Re: <vent> Arrrgh </vent>
Quote:
Originally Posted by sockman
I have just spent the last 2 weeks tracking down an esoteric bug with structured exception handling only to find out that the problem was my boss has deliberately switched off Buffer Security Checking in the visual studio project settings.
Turning off BSC does not cause bugs by itself. It's a mechanism for detecting buffer overruns on the stack (for local variables). If you turn it off and there's no buffer overrun, nothing bad happens. If there is a buffer overrun, BSC will shut the program down safely. If BSC is off during a buffer overrun, the program will exhibit erroneous behavior in some other way.
Quote:
Originally Posted by sockman
Now, everything I have read about this particular setting tells me that it is on by default and important for any code which does exception handling of any kind.
BSC and EH (= Exception Handling) are two unrelated features that can be enabled and disabled independently. There is a slight connection between them because of the way they're implemented. If they're both on then BSC will also protect the EH frame on the stack. EH frames are necessary for exception dispatching to work correctly. So if BSC is off, a buffer overrun happens and then an exception is raised, the exception dispatch will not work right. If BSC is on the program will shut down safely.
Quote:
Originally Posted by sockman
My boss is under the impression that this setting causes a drop in performance.
Indeed it does.
Quote:
Originally Posted by sockman
I am frustrated because I am writing a program which uses some third party dlls which sometimes crash, and I would love to be able to handle the crashes gracefully and allow my program to continue.
That doesn't sound right. Do the 3rd party dlls use SEH exceptions to "normally" report error conditions, or do they raise exceptions as a result of a bug? If it's the former, then you really should and have no choice but to handle the exceptions they raise. If it's bug then it's most certainly not right to just arbitrarily ignore the exceptions, because doing that may leave your program in an inconsistent state (with a memory corruption of some sort) and the longer it runs the worse it's likely to get.
Re: <vent> Arrrgh </vent>
Well, it could be that your boss don't want the programmers to sortof "hide" their programming errors by using SEH insteadof fixing them.
Regards,
Usman.
Re: <vent> Arrrgh </vent>
Quote:
Originally Posted by Arjay
Usually after working for a guy like that it leads to RFH syndrome.
(Really frustrated here)
...that in turn typically leads to WSIBSHIOGNRCJ fever.
You know, Why Should I Be Sitting Here Instead Of Getting a New Really Cool Job. Very dangerous infectious disease. ;)
Re: <vent> Arrrgh </vent>
Quote:
My boss is under the impression that this setting causes a drop in performance.
Which is why people often enable it in test builds and disable it in release. That's of course assuming it makes a significant difference. In realtime software quite probably yes, in desktop apps, possibly no. Not using it at all seems a bit daft though.
Re: <vent> Arrrgh </vent>
Quote:
EH frames are necessary for exception dispatching to work correctly. So if BSC is off, a buffer overrun happens and then an exception is raised, the exception dispatch will not work right. If BSC is on the program will shut down safely.
That's my point. And therefore they can't be disabled independently because turning BSC off affects how SEH works.
I have several 3rd party dlls which crash - no error return codes. Unfortunately I don't have any option but to use these dlls. I have already found the most stable way to call their exported functions but in some cases the dlls just flake out unexpectedly and I would like to handle these situations without my program exiting without warning because this looks *bad* to users.
Quote:
If it's bug then it's most certainly not right to just arbitrarily ignore the exceptions, because doing that may leave your program in an inconsistent state (with a memory corruption of some sort) and the longer it runs the worse it's likely to get.
Yes I agree with this. What I actually do is provide a nice error message, do some error logging and provide a restart button.
Quote:
Well, it could be that your boss don't want the programmers to sortof "hide" their programming errors by using SEH insteadof fixing them.
I just can't agree with this. Exception handling is a final resort. Sometimes you get an exceptional condition which you haven't banked on or simply can't predict or can't handle in any other way such as a crashing dll. If it's about not hiding errors, it is far easier to analyse a problematic program which implements good exception handling than one which just crashes and exits. And as a customer I know which one I would want.
