I'm seriously tempted...

Ray Cassick

:-D

Ray Cassick

John Cardinal wrote:

their understanding of the effects that their changes could have

This actually brings up a question about available tools. Do you think that there are good tools available to help developers get this bigger picture? Do you think just having a simple call graph that shows the tree of affected functions impacted by changing one is enough? Personally I think that this along with a good Unit testing package/system in place (and a decent design to start with) should be enough to fend off all but the real killer corner cases here.

My Blog[^]
FFRF[^]

Rob Graham

Christian Graus wrote:

were shutting off the plane to reboot the computer

One heck of a power switch on that computer. To restart, turn off airplane...:wtf:

Tim Smith

Ray Cassick wrote:

When was the last time an aircraft guidance system needed to be rebooted mid flight?

More times than you really want to know.

Tim Smith I'm going to patent thought. I have yet to see any prior art.

Member 96

No a call graph isn't enough, you have to *know* what goes where and what is affected by what. As for unit testing I don't believe in it and we don't use it. I believe it's a crutch designed for companies to be able to place far less trust in their developers and free them up to hire very large teams of low talent programmers in an effort to cheaply get software out the door faster. In other words factory programming. In our company we practice what I feel is artisan programming not factory programming, but we pick projects where we can be artisans so my opinion is obviously biased. In all the examples I've seen it used in it is used pointlessly in the great majority of methods / functions and is just a drain on resources and time and gives developers a false sense of security. So much important time seems to be wasted developing the tests, seeing if they are applicable, running the tests etc against a great majority of code that is blindingly simple and if coded correctly and defensively in the first place would not require a test at all under any circumstances. I do believe in something alternative which is special code that runs in debug builds only and make liberal use of that to ensure sanity checks etc where it makes sense in my own code.

"I don't want more choice. I just want better things!" - Edina Monsoon

Pierre Leclercq

Yes that is a very good idea. I think some companies have already done that. The first to come in mind would be Google. They started a search engine company at a time when everyone was thinking it was a saturated market. They did it much better than everyone else... Still the problem at hand does not apply only to software, many companies do not care enough about quality or support.

M RI0

Ray Cassick wrote:

Personally I am getting sick of the mantra 'all software has bugs'. When was the last time an aircraft guidance system needed to be rebooted mid flight?

Very strong comment. I will remember that one! And ofcourse, It's just commercial talk. Maybe it's a hard criterium, but it is possible to deliver software without any bug. throw new NotImplementedException("No signature.");

Lost User

Man...where have you been Gatsby? Haven't seen you around here since your last article on missile tracking and moving targets.

Gary Wheeler

M@RI0 wrote:

it is possible to deliver software without any bug

No, it's not, except for trivial cases. The phrase "without bugs" implies a lot of things. For lack of a better definition, it means software that can be formally proven correct. Any application of meaningful size can't be proven correct. Similarly, even trivial applications that run under existing operating systems can't be proven correct, since you have to prove the environment correct as well. If you define "without bugs" as "software that isn't immediately lethal to the end user, or even better, doesn't get us sued in court", then sure. There's plenty of bug-free software out there.

Software Zen: delete this;

ghle

Rob Graham wrote:

One heck of a power switch on that computer. To restart, turn off airplane...

Either we were on the same United flight, or it happens more than occasionally. Seriously, all power to the plane was shut off. Totally quiet, no lights, no air, no engines. IIRC it was the guidance computers. After a couple of minutes, fire up the engines and we're good to go. I remember saying, a little too loudly "Must be running Windows.":omg: I thought it was funny. Half the passengers in front of me turned around. It was obvious from the stares of disbelief that no one else found it humorous. :-O

Gary

ghle

_Damian S_ wrote:

if it wasn't for those pesky users!

Hence, long live COBOL and command-line interfaces!!! :-D Contrary to popular beliefs, it IS possible to write bug-free software. It is difficult, but not impossible. With increased (or reduced) complexity comes bugs. bool WasteTimeAndSuckCycles() { bool bWillNeverHappen = TRUE; int i = 0; while (bWillNeverHappen) { // Warm up the CPU // Wait for CPU Power-off i++; } return (bWillNeverHappen); }

Gary

ghle

Gary Wheeler wrote:

M@RI0 wrote: it is possible to deliver software without any bug No, it's not, except for trivial cases.

Sorry, Wheeler, you've been listening to Billy G. too much. It is possible to write bug-free software. The software must do everything it is supposed to do, and nothing it is not supposed to do (the more difficult proof), including allowing for unanticipated situations. As a developer, it is not my responsibility to validate the O.S. or the complier/linker/assembler, however, the application must operate correctly under the O.S. that I qualify it for. Example, if an O.S. (bug) stops sending the application mouse clicks, that is not a problem with the application (that would appear to hang). If the compiler is wrong, again it is not a problem with the application. (Writing in machine code can alleviate compiler problems.) The difficulty is that formally proving software is correct is typically more time-consuming than the application/system development time. We attempt to reduce bugs by applying whatever testing we can, however, there comes diminishing returns. How much testing is done also, in the business world, depends on the "lethalness" of the software. If an application/system can kill/maim people or destroy equipment unintentionally, testing is generally more thorough than if the downside is our spell-checker misses some spellings. Also, having the software do self-checking takes CPU cycles and can make a system less responsive. Multi-processor CPUs can allow software to be more reliable at run-time with no degradation in performance. One thread tests the gozeins and gozeouts while another thread runs the logic. The logic thread returns expected results only if the checking thread finds no problems. Has ANYONE ever found a bug that after-the-fact given the resources was impossible under any means to find? No! We have an aha moment. Once found, we can add additional testing to find that bug in the future (or not). The problem is that we need to *think* about these situations at development time and incorporate them into the application.

Gary

Big Daddy Farang

ghle wrote:

Hence, long live COBOL and command-line interfaces!!!

I agree 50 per cent. Command-line interfaces rock. COBOL not so much. ;) Actually we could replace COBOL with a myriad of other languages and have that same "discussion." For example, "VB" or "C" or ".NET" or "Java." So let's leave at, "To each his own." By the way, you have a compiler warning. It should be: bool bWillNeverHappen = true; Best regards, BDF

ghle

To each his own - agreed. Another thread discussed the desire to kill COBOL, just another reason why we can't.

Big Daddy Farang wrote:

By the way, you have a compiler warning. It should be: bool bWillNeverHappen = true;

Note: I do NOT have a compiler warning, you do. It compiled and executed just fine.:wtf: From afx.h // Standard constants #undef FALSE #undef TRUE #undef NULL #define FALSE 0 #define TRUE 1 #define NULL 0

Gary

Big Daddy Farang

Hi Gary, I sit corrected. It is indeed I who has the compiler warning. I know that with VC++ 6 that would compile without warning. Your original code would be bool bWillNeverHappen = 1; after preprocessing. C++ allows assigning an int to a bool and doesn't complain. However, either of these would be more correct: BOOL bWillNeverHappen = TRUE; // BOOL is #typedef int bool bWillNeverHappen = true; Why have nits if you can't pick them? :laugh: BDF

Dan Neely

Big Daddy Farang wrote:

Why have nits if you can't pick them?

because lice are icky. :rolleyes:

-- You have to explain to them [VB coders] what you mean by "typed". their first response is likely to be something like, "Of course my code is typed. Do you think i magically project it onto the screen with the power of my mind?" --- John Simmons / outlaw programmer

ghle

Big Daddy Farang wrote:

Why have nits if you can't pick them?

Ah, and eat them! Some food for thought... X| But seriously, true is defined as NOT ZERO and false is defined as ZERO, no? so bool nits = TRUE; and bool nits = 1; are correct and valid anyhow? It's been a while since I've used the CPM Borland C compiler... But this brings up a burning question regarding my EVC++ environment. MS generated code uses BOOL instead of bool. This takes a larger data storage area (32 bits to store a 1 or zero) which is not efficient. Is the trade off on storage space made up for in execution speed and or data alignment. I.e., is it faster to load registers with 32 bits rather than 8 bits (1 bit?). I know it is faster to load on an even boundary, but what if you are only loading one byte, not 4? Is there a penalty for padding the field with zeros or in loading 4 bytes instead of one? Anyone?:confused:

Gary

Big Daddy Farang

ghle wrote:

true is defined as NOT ZERO and false is defined as ZERO, no?

Sort of, I guess you can think of them in those terms surely. From MSDN's C++ Language Reference: bool This keyword is a built-in type. A variable of this type can have values true and false. Conditional expressions have the type bool and so have values of type bool. For example, i!=0 now has true or false depending on the value of i. true This keyword is one of the two values for a variable of type bool or a conditional expression (a conditional expression is now a true boolean expression). false The keyword is one of the two values for a variable of type bool or a conditional expression (a conditional expression is now a true Boolean expression). So they don't come right out and say that but.... The C# Language Reference explains further: In C++, a value of type bool can be converted to a value of type int; in other words, false is equivalent to zero and true is equivalent to nonzero values. In C#, there is no conversion between the bool type and other types. For example, the following if statement is invalid in C#, while it is legal in C++:

int x = 123;
if (x) // Invalid in C#
{
printf("The value of x is nonzero.");
}

ghle wrote:

MS generated code uses BOOL instead of bool.

I think this partly due to backwards compatibility with C language which does not have bool but uses BOOL. As for the questions in your last paragraph, I don't have to answer that. #define (don't have to) (can't)

ghle wrote:

Anyone?

Bueller? BDF

ghle

Big Daddy Farang wrote:

C language which does not have bool but uses BOOL

Backwards nit, I think. Oh oh, found this... No Boolean type[^] "NOTE: There is NO Boolean type in C -- you should use char, int or (better) unsigned char."

Gary