Can I create C functions that are only visible to my class which is broken into multiple files?

Using a static function, I can limit the linkage of my function to the file at hand and that is perfe开发者_高级运维ct in many cases. But I have a class that is unwieldy as one file, but breaking it up is made more frustrating because there are functions that I would like to keep 'private' but are needed throughout.

One part of the answer must be counter-questions, such as:

• Why is your class so big that it must be split up?
• Are you sure your class is so big that it must be split up? (How big is 'big'?)
• Are you sure you have your class properly abstracted?
• Can you make the common functions into a new class that can be used by the main class you are working with? That will hide the functions behind a class interface barrier.

On the whole, if you can avoid it, do not split the class file up arbitrarily because of size constraints; keep together that which belongs together.

A Gruesome Possibility

Assuming that a split is necessary and an orthodox split (into various classes that work together) is not possible, the question becomes: how gruesome will you accept your code being? (It's already a bit gruesome since there's an awful lot of functionality in a single file; can you stand it becoming more gruesome?)

Assume your class is in 4 (or more) files.

1. class.h
2. class.c
3. class1.c
4. class2.c

The header, class.h, is orthodox - self-contained and idempotent. It is used by the outside world (meaning outside this collection of source code) to access the facilities provided by the class.

The files class1.c and class2.c contain implementations of the functions in the class. They could be given a separate, distinctive file suffix - there might be some advantages to doing so. The files are not designed to be compiled standalone; they are strictly a convenience that splits the source up because the class got too big.

The file class.c is what you compile. It contains:

1. #include "class.h"
2. Other definitions needed by the class internals.
3. #include "class1.c"
4. #include "class2.c"

Thus, although the source is split up, you actually compile a single file, class.c.

In your makefile or equivalent, you specify that class.o depends on the header and all three source files; if any of those changes, then you need to recompile the whole lot. One advantage of changing the suffix of the implementation files (class1.c and class2.c) is that they will not compile separately because the suffix is not recognized by the C (Objective-C) compiler. One downside of changing the suffix is that your syntax-aware editor won't be aware of the correct syntax highlighting for the separate files unless you tell it the file type. If you use an IDE, it may also be less than amused at this trickery.

If you work on a machine where the size of the source means it cannot all be compiled at once like this, then you are snookered. This technique does not help at all; you have to split the files up and compile them separately. In that case, really look hard at whether you can split the code cleanly into several classes which can be managed in an orthodox way.

By request, my comment on the OP as an answer:

There's no language support for this that I'm aware of... You could put all the support functions in a separate c file and only #import its header from the class implementation files? If they don't have to be C functions (for passing as callbacks to C APIs, for example) I'd reimplement them as methods on the class and declare the private interface in a separate header—each implementation file would then #import both the "public" and "private" header.

Prefix their names with output of a cryptographic RNG. Now you don't have to worry about unintentional name collisions. Problem solved. You can hide the renaming in preprocessor macros if you really like.