The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
There's your problem right there. A method like that should be broken up into several (hundred) smaller methods...
Anything that is unrelated to elephants is irrelephant Anonymous - The problem with quotes on the internet is that you can never tell if they're genuine Winston Churchill, 1944 - Never argue with a fool. Onlookers may not be able to tell the difference. Mark Twain
This is the joy of embedded code -> realtime does not (always) allow to use the debugger, since the debugger actually stops the program, so your embedded systems also stops, which ruins the dynamics. So we are often down to the equivalent of TRACEing, so that we do not interrupt the realtime events and interrupts.
Friday afternoon not many people in the orfice today 'Working From Home' which I can't as I am using hardware that is too big. Silly thing is we have a 'smart' lighting system, you flick the switch, it take a gander at the light level, the lights then switch on & if it does not pick up some sort of movement every ten minutes turns the lights off. A pain if like me you are working on something where you have too be still!
We have a lab with lighting like that, but the lighting is anything but smart. This lab contains a printing press with lots of motion, flashing lights, and so on. You'd think it would keep the lights on. Nope. If you're in the lab, you have to remember to move every few minutes or the lights shut off.
The only time I use "stub" is to describe a dummy function that is generally used for simplifying development. So if you are writing a client and that client calls a service which does many things, or takes time, or needs annoying conditions to be true, you can write a stub that has the same method signature but simply returns a hard-coded result. That lets you continue testing the client without needing a working service.
I stub methods all the time, usually because I fully intend to implement them. My stubbed methods usually throw a NotImplemented exception. If I end up with any of these stubbed methods after the code is finished, I simply delete them (they're easy to find with a simple Find in Files search.
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
In the last month and a hlaf I saw extensive usage of stubs in the following scenarios:
* Interfaces towards modules which are called by those modules but not yet implemented by us;
* The actual code of IPC Interfaces (Legato/dBus...) when the implementation is to be done but clients (or servers) are developed concurrently;
* Most of the autogenerated code by AutoSAR tools contains stubs to be implemented by the actual ECU software developers.
GCS d--(d+) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
Last Visit: 27-Jan-20 0:21 Last Update: 27-Jan-20 0:21