Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I think most people would agree that pointers are a major source of bugs in C programs (if not the greatest source of bugs). Other languages drop pointers entirely for this reason. When working in C, then, would it be best to avoid using pointers whenever practical? For example, I recently wrote a function like this:

void split(char *record, char *delim, int numfields, int fieldmax, char result[numfields][fieldmax]);

While not as versatile as a dynamically allocated variable, in that it requires the programmer to know the number of fields in advance and anything over fieldmax is truncated (which is sometimes acceptable), it eliminates the need for memory management, and the potential for memory corruption. I think this is a pretty good trade, but I was wondering what the opinions of other programmers on this were.

share|improve this question
18  
"...most people would agree that pointers are a major source of bugs in C programs..." Pointers are no more or less inherently dangerous than guns, motorcycles or sharp objects. The greatest source of bugs in C programs is sloppy work on the part of the developer. –  Blrfl Nov 2 '11 at 14:40
1  
Perhaps I'm missing something, but that code you posted won't compile. –  Pubby Nov 2 '11 at 14:40
2  
@Blrfl > The first step toward being a great programmer is adminiting how faillible everybody is. pointer is a great tool, very powerfull, but also error prone. If you use them, you WILL make mistake sometime and mess up memory, sloppy work or not. –  deadalnix Nov 2 '11 at 14:43
2  
@deadalnix: Yep, and I've done it, too. All I'm saying is that if you're going to use a sharp tool, learn how to use it properly and don't blame the tool if you accidentally use it to cut off your leg. Someone who wants a language that protects them from their own mistakes should probably not be using C. Pascal, Ada and maybe Java would be much better choices. –  Blrfl Nov 2 '11 at 14:54
4  
Pointers don't bug programs, programmers bug programs. –  Kevin Nov 2 '11 at 15:43
show 5 more comments

6 Answers

up vote 17 down vote accepted

Other languages don't "drop pointers entirely," they just restrict what you can do with them, give them a syntax that looks like non-pointer variables, handle some operations on them behind the scenes, and call them something else, like a reference or object. If you ever have to make a distinction between assigning a copy of something or not, you are dealing with pointers.

With the exception of programming paradigms that pass everything by copy, with obvious performance implications, the use of pointers is unavoidable in all but the simplest of programs. By all means, use stack variables where it makes sense, but if you try to avoid pointers too much, you will introduce a whole different breed of potential bugs.

share|improve this answer
    
Yeah, I wasn't trying to say "never use pointers" - even the code sample I posted had pointers in it. It was about the choice between static and dynamic allocation, and if all the problems pointers can introduce should make us prefer static. But at the risk of answering my own question, I guess the choice is driven more by business requirements than anything else - if you can get away with using a static variable, why not do it? –  treadmarks Nov 2 '11 at 16:51
add comment

Those char* should really be const, unless you actually meant a pointer to one single character, which I find to be quite unlikely. Apart from that, pointers are the reason C is so fast- they're extremely efficient. What else are you going to do, copy everything around everywhere? The ability to alias any variable at any time is risky, but it's also very powerful.

If you don't like bugs, and you still like performance, then upgrade to C++. It's vastly less buggy when written with adherence to it's most basic principles and can be faster than C, and is certainly no slower in the general case.

share|improve this answer
    
const doesn't make the distinction between intending to use the pointer as a string or single character at a time, only whether you intend to modify the underlying data. They still should be declared as const, but that's only because they're not intended to be modified (or so I infer from the declaration), and so one can safely pass a string literal. –  Kevin Nov 2 '11 at 14:59
add comment

In my oppinion, it doesn't make any sense to use C and want to avoid pointers. If you do so, then you'd better use another language.

Pointers are unavoidable in C. This is what make C so powerfull and also what make C a pain in the ass sometime. C is meant to be used with pointers.

Arrays are pointers, functions are pointers, memory allocation work through pointers, and so on. Take advantage of that or change language.

share|improve this answer
1  
Arrays and functions aren't pointers. –  Pubby Nov 2 '11 at 14:38
5  
@Pubby8: Arrays and pointers are closely related. –  FrustratedWithFormsDesigner Nov 2 '11 at 14:49
3  
@Pubby8 technically you're correct, but the answerer's point is that to use the full expressive powers of arrays/functions you should know how using these constructs with pointers multiplies their power significantly. Not knowing pointers boxes you in significantly wrt arrays/functions. –  Doug T. Nov 2 '11 at 14:49
5  
@Pubby8 Arrays most certainly are pointers, and c doesn't even say anything about going from an array to a pointer unless you explicitly activate certain compiler warnings. A 'function' is just a place in memory that the compiler treats as having instructions instead of data. That's why declaring a function pointer is allowed, you're just accessing the same instructions at the same point in memory using a different name. –  Kevin Nov 2 '11 at 14:53
3  
@Kevin Arrays implicitly cast to pointers, that doesn't mean they are. Why does sizeof(array) return the number of indices of an array and not the size of a pointer? And yes, a function is in memory and can have a pointer to it, but that does not mean its a pointer. That's like saying int is equivalent to int * because they both involve memory. –  Pubby Nov 2 '11 at 15:03
show 4 more comments

Good luck using the standard runtime or any third-party libraries. If you mean you want to avoid pointer manipulation then you might have a chance, but I don't think you'll gain any real benefit. It's the nature of the beast; if you want protection from pointer errors, then you'd be better off using a different language.

share|improve this answer
add comment

The power of C comes from the fact that underline data storage is transparent to use. It is not really about pointers, it is more about working directly on hardware while still being a general purpose code.

While this may be of no virtue in many cases, in that case, we don't need to drop pointers from C, we need to drop C from development.

In my opinion, in your earlier version, you are NOT avoiding pointers. I can always supply an already corrupt (or free()ed) pointer as *record and everything will be doomed!

The core issue, though, is not really pointers! I have seen so many people don't get it right in the beginning, but even after having reasonable number of project experience, some get it, some fear it. I cann't say authoritatively, but those who have some basic exposure (introduction) to microprocessor architecture and/or OS basics, don't quite face that much trouble. It is the essence of how the machines work and C translates it in a very transparent way on higher level. If you ever fear pointers in C, try work on this background knowledge and lot of practice; things should work smooth. I don't quite believe that one should ever fear C or its' pointers. If you have the fear, there is always a way to get over it and then start enjoying pointers in C.

share|improve this answer
add comment

In principle you're right that only using pointers when necessary will result in fewer bugs. However, in C, almost all of the time, pointers ARE necessary.

For instance, I may be wrong, but I don't think your code sample works: I don't think the function can receive a dynamic array as an argument, so it will have to use "numfields" and "fieldmax" to calculate where to write the data -- which will scribble over random memory if the wrong sizes are passed.

And most of the time, deciding the return size in advance will be difficult. If you want to avoid pointer bugs, use C++, and use pointers only when you need to.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.