tags:

views:

349

answers:

14

Hello,

I wanted to have a look at the implementation of different C/C++ functions (like strcpy, stcmp, strstr). This will help me in knowing good coding practices in c/c++. Could you let me know where can I find it?

Thanks.

+10  A: 

You could check out a copy of glibc, which will have the source code for all C functions in the C standard library. That should be a good starting place.

mipadi
Although this is the first answer that comes to mind, it may not be the best place to learn about "good coding practices" that have general applicability. This is because the glibc functions have a legitmate reason to be heavily micro-optimised - even platform-specific optimisations - simply because they are standard library functions. That's not normally a good practice for general programming.
caf
+2  A: 

standard c library

Tim Hoolihan
+3  A: 

Many C standard library functions have source code listings & discussions in The C Programming Language by Kernighan & Ritchie. The discussions are a helpful way of learning more about the specifics of the C language & how functions in the standard library work under the hood.

Pete
Nick
NoMoreZealots
This is a better suggestion than looking at real libraries. These were written with the goal of teaching C, rather than the goal of having the most efficient C library.
caf
+1  A: 

Here you go

The implementation will vary somewhat from OS to OS, but the GNU/Linux implementation is probably going to be the easiest one to find out there.

Eric Petroelje
+3  A: 

Look at an implementation of the libc standard C library. To see how a real, popular C library is implemented, try looking at the glibc code. You can access the code using git:

git clone git://sourceware.org/git/glibc.git

As for C++, you can find the glibc++ standard library on one of these mirrors:

http://gcc.gnu.org/mirrors.html

You can also check out uLibc, which will probably be simpler than the GNU library:

http://git.uclibc.org/uClibc/tree/

To give you a flavour, here's the strncpy implementation from uLibc:

Wchar *Wstrcpy(Wchar * __restrict s1, const Wchar * __restrict s2)
{
    register Wchar *s = s1;

#ifdef __BCC__
    do {
        *s = *s2++;
    } while (*s++ != 0);
#else
    while ( (*s++ = *s2++) != 0 );
#endif

    return s1;
}

Here is strcmp and strstr

IRBMe
A great example of why real C library implementations aren't a good guide to generally-applicable good programming practices - having those two slightly-refactored versions of the same loop for different C compilers would almost never be justified in most of the programming you'll do.
caf
+2  A: 

"The Standarc C Library" is a specification. You want the sources for an implementation of the specification. Your C compiler may or not provide such sources - one that does is GCC.

anon
+1  A: 

You could also have a look at the OpenBSD source tree. Specifically, you want the string subdirectory of libc.

Michael van der Westhuizen
A: 

Here's the general strXXX C functions in NetBSD : http://cvsweb.netbsd.org/bsdweb.cgi/src/common/lib/libc/string/

Here's the NetBSD strXXX implementation for i386 processors http://cvsweb.netbsd.org/bsdweb.cgi/src/common/lib/libc/arch/i386/string/

nos
A: 

If you use Visual Studio Professional or Team, you should be able to find the source here:

C:\Program Files\Microsoft Visual Studio 9.0\VC\crt\src

Otávio Décio
+3  A: 

Most compilers provide source code for the library - however that source code is usually rather more complex and convoluted than you might expect.

A good resource for this is P.J. Plauger's book, "The Standard C Library", whch can be had pretty cheaply if you go for a used one. The code presented is not always straight-forward, but Plauger explains it quite well (and gives the reasons why it can't always be straight-forward and still follow the standard).

Michael Burr
A: 

For your purposes, this book may be helpful: Mastering Algorithms with C

Frank V
+2  A: 

About 10 years ago, I read The Standard C Library by Plauger. Thoroughly recommend it.

Sinan Ünür
+7  A: 

It's worth pointing out that the source code for the C standard library does not necessarily highlight good coding practices. As the standard library, it has a special status where, for example, it can rely on a lot of unspecified or non-portable behavior simply because they know the exact compiler with which it is used.

And of course, this only tells you about C coding practices.

That has nothing to do with C++ coding practices, which are very different. Don't treat them as one language. There is no such thing as C/C++. C is a language with its own coding practices and common idioms, and C++ is a separate, independent language which also has its own practices and idioms.

Good C code is rarely good C++ code. strcpy and other C library functions are certainly not good C++ code.

jalf
This was my first thought when I saw the question. It is arguable that the best C libaries ARE processor specific. A general C lib written in just C and minimal amounts of processor/architecture specific functionality is going to have crappy performance compared to a targeted libary for the particular system. This even more of a concern on handheld platforms where the general excuses for inefficient code don't apply. (i.e. It's not going to be ran on a 3+GHz octo-core processor with infinite memory.)
NoMoreZealots
Sorry if that sounded preachy, but I get annoyed everytime I boot my PC and it takes longer than a system I had 20 years ago. People take the "little efficiencies" argument to a level of insanity on modern systems. The whole "netbook" and handheld market makes me giddy when I hear people whine about "it's not powerful enough" for there applications. Now you actually have to THINK, ain't that a bitch!
NoMoreZealots
I completely agree, but coming from the other direction. I write scientific applications made to run on clusters with 1000+ cores. At this scale, those little inefficiencies really add up. In 18 months when we get a new system with twice the problem, our problems have at least doubled in size. The hardware is never going to catch up to what we want to do.
KeithB
I agree that you should never write inefficient code, speaking of the actual algorithmic constructs themselves. What I don't agree with is people who are always bashing managed code for being slow. I personally think that writing clean, small, organized, and mostly 'portable' code is more important in most cases than efficiency. The hardware will get faster in the future and good code will be reused; crappy, messy, non-portable code will just become obsolete, and we'll have to reinvent that wheel *again*.
LoveMeSomeCode
I don't think anyone even mentioned managed code. In most cases, there is also no contradiction between clean/portable and efficient code. And people thinking that *only* the algorithmic efficiency matters are just missing the point.
jalf
the algorithmic efficiency, on different levels, is the whole of efficiency. I'm speaking in generic terms where the algorithm is your whole plan of how to do something. And I only brought up managed code because someone always does in an efficiency debate, and I'm very pro-managed-code. Yeah, I know C can be faster than C#, but straight assembler can be faster than C, so why don't we do that all day? Oh that's right, because hardware is cheaper than software people.
LoveMeSomeCode
Is it? Tell that to KeithB who's working with huge cluster computers. Anyway, perhaps you should write a blog post about it. But since you really insist on the comparison, I should probably mention that there's no technical reason why C should be slower than ASM. Given a sufficiently good compiler, and well-written C code, it won't be. But managed code *always* has a cost, if nothing else then in startup time. Anyway, managed code is hardly the issue here. Nor is performance, come to think of it. Don't you people have blogs or something to post your pet peeves on? ;)
jalf
Actually managed code is a interesting example of why library MUST be efficient. If the managed code was running on non-optimized (down to the metal) libraries, it would run like horse crap. Nicklus Wirth had quote that went something like, the rate at which programs are becoming inefficient is greater than the rate computers are increasing in speed.
NoMoreZealots
A: 

In general, I find the BSD libc much easier to read than the GNU one. There are less "gcc-isms", the core is much clearer in intent, etc... For example, the BSD code for malloc is quite readable compared to glibc

David Cournapeau