Return-Path: william@bourbon.usc.edu Delivery-Date: Mon Sep 22 20:40:35 2008 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on merlot.usc.edu X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.3 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.14.1/8.14.1) with ESMTP id m8N3eZD7003123 for ; Mon, 22 Sep 2008 20:40:35 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.14.2/8.14.1) with ESMTP id m8N3h6bE029432 for ; Mon, 22 Sep 2008 20:43:06 -0700 Message-Id: <200809230343.m8N3h6bE029432@bourbon.usc.edu> To: cs551@merlot.usc.edu Subject: Re: 551 off-topic Date: Mon, 22 Sep 2008 20:43:06 -0700 From: Bill Cheng Someone wrote: > A lot of functions that I have seen in the book/man pages/online take an > argument as reference and put the return value there. > > Example: > > int function(type param1, type param2, type &returnParam) { > > ........//computation > ........//put return value in returnParam > ........//return errorCode > > } > > Is this a good way of programming? I usually return the value rather than > putting it in on of the arguments passed. Good question! What happens is that when you get involved in a large project or implementing a product that will be used by external end users, you may see more functions get specified this way. Many of these functions will simply return an error code. This is quite convenient if you have a product that's being used by non-technical people. When they see an error, all they have to do is to call customer service and say what error code is printed on the screen. The customer service people can look up the error code in the database and can even know which engineering to contact! I was involved in a project once where someone was put in charge of the error code database even before a single line of code was written! -- Bill Cheng // bill.cheng@usc.edu