Q:

Make function declarations based on function definitions

I've written a .cpp file with a number of functions in it, and now need to declare them in the header file.  It occurred to me that I could grep the file for the class name, and get the declarations that way, and it would've worked well enough, too, had the complete function declaration before the definition -- return code, name, and parameters (but not function body) -- been on one line.
It seems to me that this is something that would be generally useful, and must've been solved a number of times.  I am happy to edit the output and not worried about edge cases; anything that gives me results that are right 95% of the time would be great.
So, if, for example, my .cpp file had:
i2cstatus_t NXTI2CDevice::writeRegisters(
    uint8_t  start_register,    // start of the register range
    uint8_t  bytes_to_write,    // number of bytes to write
    uint8_t* buffer = 0)        // optional user-supplied buffer
{
...
}

and a number of other similar functions, getting this back:
i2cstatus_t NXTI2CDevice::writeRegisters(
        uint8_t  start_register,    // start of the register range
        uint8_t  bytes_to_write,    // number of bytes to write
        uint8_t* buffer = 0)

for inclusion in the header file, after a little editing, would be fine.
Getting this back:
i2cstatus_t writeRegisters(
        uint8_t  start_register,    
        uint8_t  bytes_to_write,    
        uint8_t* buffer);

or this:
i2cstatus_t writeRegisters(uint8_t  start_register, uint8_t  bytes_to_write, uint8_t* buffer);

would be even better.

A:

I think you got it backwards. The declaration is the crucial piece here. The implementation is the details. You are trying to save yourself a bit of typing at the expense of not carefully designing and crafting the interface, which is very important in any language, but in C++ it's the thing.
Start from the header files. Then, if you like, generate stub implementation bodies and maybe test case wrappers, then start filling in the functions. Build, test, fix, expand, leather, repeat.
Edit:
A rant that doesn't fit into a comment:
My question then would be - if it's not "public interface", why do you need it in a header? My strong opinion is that everything a header file contains is the interface, no matter how small and what internal/external subsystem is exposing it to what other part. It doesn't seem significant for one guy project. But sooner or later a second pair of eyes (probably even your own, three or six months down the road) will have to go through that interface again and figure out why it was made public, what the author was thinking, what the purpose is, etc. etc.
Trivial? Yes! But I can't tell you how many times I cursed the original author (including myself) of some code I had to read and understand (again), and this trivial rule of thumb would have saved me so much hair :)
Edit 2:
... how do I declare a private member function without declare it with the rest of the class, in the header?
This is known failure of C++ itself. See, for example, Sutter's (Mostly) Private article. There are several ways of dealing with this at the design level:

In C++ not everything has to be a class, free functions are great. Declare and use a function pointer, implement bunch of matching functions in the .cpp file, put pointers into a table or an STL container.
Forward declare a class, so it's opaque to the user, amend the interface to operate on reference or a pointer.
Use a pimpl idiom (also here)

A:

I compiled exuberant ctags version 5.8.  This command gets me what I want:
/usr/local/bin/ctags -x --c-kinds=f $SOURCE |
awk -v OFS=" " '$1=$1' |
cut -d " " -f 5- |
sed -e 's/[A-Za-z]*:://g' |
sed -e 's/)$/);/'

where you substitute the filename you are interested in in place of $SOURCE.  
Note that the ctags command by itself gives a reasonable output, and you can throw in a -u flag if you want the output in the order it appears in the file, instead of in alphabetical order.

