Click here to Skip to main content
Rate this: bad
good
Please Sign up or sign in to vote.
See more: C++ C
Hi,
Could you please help me with your valuable suggestions on designing an application in C with the best practices.
 
Like every user-defined function should return either a true of false value indicating if it has failed or not.
Handling null pointers.
 

I was also told that returning a value from a function is expensive. So better to avoid it.
 
Is this true ?
 
Please help.
Posted 11-Oct-12 19:22pm
Edited 11-Oct-12 19:24pm
v2
Rate this: bad
good
Please Sign up or sign in to vote.

Solution 3

There are hundreds of things that various programmers think everyone should do, but not all are equally useful for a given class of projects and teams, and some are surely debatable. I've found the Table of Contents printed on http://www.gotw.ca/publications/c++cs.htm[^] to be a useful basis for discussion. Whether or not you buy the book for the full explanations and rationales is your decision, but if you're inexperienced it might be a great help to understand programming techniques in-depth.
 
As to your questions:
1. Returning success or failure is a rather crude method of error propagation. In C++, the preferred method is throwing exceptions, in C it's returning an error code (i. e. an integral value indicating the cause of the problem, rather than just true or false). The former is not possible in C, but the latter can be used in C++ too, instead of using exceptions. Just make sure not to mix these two methods in any project.
 
2. In C++, the solution is to never use simple pointers, but "smart pointers" that keep track of whether the object they're pointing to is still being used or not. A smart pointer simply cannot be 0. (*ok, this is an over-simplification - see below!)
In C, you should always make sure that a pointer is not 0 before you use it, but unfortunately that doesn't prevent other parts of your program to mess with it and invalidate the data: checking for 0 is important, but not by itself sufficient to prevent run-time errors.
*P.S.: unlike C-pointers, smart pointers will know when the data they point to gets invalidated. So, while you still may need to check if they're valid, you can avoid run-time errors.
 
3. Returning a value copies the variable holding the return value inside the function to a new object of the same type. If creating a new object of this type and copying it's data is expensive, then returning by value is expensive; if not, then it isn't. If you are facing this problem, it may be better to let the calling function create the object containing the results, and pass a reference (or a pointer) to this object to the function.
  Permalink  
v2
Rate this: bad
good
Please Sign up or sign in to vote.

Solution 2

What you are looking for is a C style guide and you can find many of them with Google. A good C-style guide contains easily some 100 recommendation or rules. Hence it would be too long of an answer to just repeat even the most common ones here.
 
User defined functions limited to returning true of false: This is no good general rule in my opinion. There are many functions that should just return a numerical value, like sin, cos, etc. But for functions that perform quite an amount of work and that return several output values via parameters it is no bad idea to return a bool value as success indicator.
 
Returning a value is not generally expensive in C. Returning large amounts of data by-value (as opposed to by-reference or via a pointer) is however expensive in terms of execution time, because this requires the data to be copied to and from the stack. And this is true for many other programming languages as well.
 
For a good overview of best-practices books about C. Just to name a few:
 
- Code Complete, McConnell
- Effective C++, Scott Meyers (geared towards C++, but many things apply to C as well)
  Permalink  
Rate this: bad
good
Please Sign up or sign in to vote.

Solution 1

Hi Zerr0cool,
 
Regarding the best practices that you may help you designing your application, I can't give you an exhaustive list, but you may begin with :
 
- Before you jump to write into your IDE, you may take a reflexion time looking for what can be devided into one or more modular fucntions (for decreasing the complexity of maintaining you code)
 
- Try to seperate classes to 1 cpp file + 1 header file for each class (you may except simple/small classes to this latter)
 
- Try to use understandable (variable names and litterals to make easy for you or other to read)
 
- Sometime you may write comments, try to write them in the header files. And if it is related to function write it just after the implementation first line :
int SumOfTwo(int a, int b)
{
   // This function return the sum of two litterals a and b which are integers
   return(a+b);
}
 
- try to use contarcts: preconditions/postconditions check and try ... catch bloks as much as you can. This may help you when you got an unexpected behaviour of your application at run-time.
 

Quote:
I was also told that returning a value from a function is expensive. So better to avoid it.

Returning built-in types (like integer) or tiny objects are easy for the C++ compiler to optimize. They should be equally fast with both kind of functions ( returning references or values). But for complex user defined variables such as instance of classes the function returning a value is expension rather than the one useing references.
 
You may find a better explanation in this site C++: Return Value versus Output Parameter[^].
 
Hope I helped, sorry for my english Big Grin | :-D
  Permalink  

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

  Print Answers RSS
0 Nirav Prabtani 268
1 OriginalGriff 217
2 Mika Wendelius 185
3 CPallini 170
4 _Amy 170
0 Nirav Prabtani 284
1 OriginalGriff 217
2 Mika Wendelius 185
3 _Amy 170
4 CPallini 170


Advertise | Privacy | Mobile
Web03 | 2.8.140721.1 | Last Updated 12 Oct 2012
Copyright © CodeProject, 1999-2014
All Rights Reserved. Terms of Service
Layout: fixed | fluid

CodeProject, 503-250 Ferrand Drive Toronto Ontario, M3C 3G8 Canada +1 416-849-8900 x 100