on 5/29/06 5:26 PM, Theodore H. Smith at [EMAIL PROTECTED] wrote:

> Hi list,
> 
> I've decided that some functions in my ElfData plugin's .cpp files,
> should not be available from other .cpp files. This doesn't affect
> the plugin's compiled form in any way, it's just an internal
> housekeeping matter.
> 
> Previously, I was using the convention of prefixing all functions
> that should only be used by the .cpp file that implements it, with
> local_ , and making it static of course. This has an advantage that I
> don't need to prepend my plugin or class name, because the function
> can only be used by the file that calls it.

This is more of the C model.  The modern way is to put the functions in an
anonymous namespace and not make them static.

> For example, normally I might have a function ED_FS_InternalUtility.
> Now I can use local_InternalUtility.
> 
> But I was thinking actually I didn't like the look of the local_
> prefix. It just looks dumb to me.
> 
> Maybe I could do the same convention by appending _? So I'll get
> "InternalUtility_" as the function name. Already it does look better
> to me.

I don't see that adding a suffix or prefix adds anything.  Both conventions
are usually about avoiding name collisions more than communicating
information to the code reader.  Since you're a one-man shop the key thing
is does your naming scheme make sense to you?  In a multi-person shop using
a full word prefix communicates more later on when someone else is
maintaining the code.  Really documented consistency is all that matters.

> Is there any harm that could come by appending this _ ? I remember
> that linkers sometimes reserve _ as a special character, although I
> understand that it's only reserved for the first letter of a function
> name, not the last.

Not that I know of but you should check the C++ standard.

Chris


_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Reply via email to