Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Re: Splitting a source code file

Reply
Thread Tools

Re: Splitting a source code file

 
 
Stefan Ram
Guest
Posts: n/a
 
      06-04-2010
Ben Pfaff <(E-Mail Removed)> writes:
>A recursive function's definition must contain the function's own
>name.


If it is /directly/ and /statically/ recursive.

A function might be recursive /indirectly/, that is, f might
call g which in turn calls f.

A function might be recursive /dynamically/, that is, f gets a
function pointer p, which is called by f, then - at runtime -
it might happen that a p pointing to f is passed to f.

 
Reply With Quote
 
 
 
 
Stefan Ram
Guest
Posts: n/a
 
      06-04-2010
http://www.velocityreviews.com/forums/(E-Mail Removed)-berlin.de (Stefan Ram) writes:
>Ben Pfaff <(E-Mail Removed)> writes:
>>A recursive function's definition must contain the function's own
>>name.

>If it is /directly/ and /statically/ recursive.


Or, one might have:

extern int( * const alpha )( void );
int main( void ){ alpha(); }
int( * const alpha )( void ) = main;

 
Reply With Quote
 
 
 
 
ImpalerCore
Guest
Posts: n/a
 
      06-05-2010
On Jun 4, 7:21*pm, (E-Mail Removed) (Richard Harter) wrote:
> On Thu, 03 Jun 2010 17:32:31 +0100, Ben Bacarisse
>
>
>
> <(E-Mail Removed)> wrote:
> >(E-Mail Removed) (Richard Harter) writes:

>
> >> On Wed, 02 Jun 2010 22:00:01 -0700, Ben Pfaff
> >> <(E-Mail Removed)> wrote:

>
> >>>(E-Mail Removed) (Richard Harter) writes:

>
> >>>> I would put the matter the other way around. *Why should I make
> >>>> any assumptions about the naming policies of other libraries?

>
> >>>If you don't, then you can only use at most one library, because
> >>>you have to assume that every library conflicts with every other
> >>>library.

>
> >> Cute, Ben, but a bit of a false dichotomy. *I grant that at a
> >> minimum we need at least one unique name for a library. *One
> >> unique name is all we need, if we so choose. *If you want to call
> >> that a naming policy, so be it. *

>
> >I think the other Ben has more of a point than you grant. *Is there, in
> >a real system, much practical difference between a library with one or
> >two globally polluting names and one with 50 or 60? *You have to make
> >some sort of assumptions in order to pick one or two names that are
> >likely to be acceptable, but these choices can almost always be extended
> >to allow for more names.

>
> There are different topics being discussed in this thread. *The
> original posting was about moving private functions (made private
> by being declared static) into a separate file and allowing them
> to be accessed within more than one file. *In efffect, Ben's
> original proposal was to not make them static, but rather to use
> a naming convention to mark them as private and declare them in a
> private include file.
>
> Now this will almost certainly work but there is no guarantee.
> Sometimes two different pieces of code will step on each other's
> toes. *As a practical matter this usually happens because a
> problem in version control.
>
> I don't like this kind of naming policy. It's a hack and it's
> crufty. *The argument for it is that "This is what we've always
> been done. *This is known as the "If it was good enough for the
> Neanderthals it's good enough for us" argument.
>
> More immediately and perhaps more important to me is that making
> things private by concealed naming conventions produces Bastard
> Hungarian names. *Thus in the reference file there is a private
> function named connect. *Now that's a very bad name for a private
> function that is visible. *Suggested replacements are connect__
> and dfe_pvt_connect. *Using connect__ breaks if more than one
> person is using that naming convention. *dfe_pvt_connect is what
> I call Bastard Hungarian. *Some people love Bastard Hungarian. *I
> don't. *Too often the end result is a lot of typing and screen
> space for code that doesn't do very much. *That's my prejudice.
> YMMV.


Well, C++ implements namespaces, but even then there isn't any
constraint that prevents independent developers from choosing to use
the same namespace. All the namespace keyword provides is a
convenient syntax for implementing the same functionality as appending
a 'dfe_pvt' or other such name mangling. Yet, namespaces in C++ are
often touted as the solution to this problem, which means in many
people's minds, it's good enough for practical purposes.

For example, what is 'std::' but an arbitrary prefix used to try to
distinguish the standard library functions from other peoples class
and function naming that could produce a naming conflict.
Unfortunately, I think you're arguing against the status quo, so
unless you can provide a scheme that's justifiably better, your issue
with replacing the prefix as the name mangling method is likely not
going to resonate.

> Another problem with private functions concealed by naming
> conventions is that they provide an open back door for
> programmers using shortcuts or perhaps just not appreciating the
> naming convention.
>
>
>
> >I ask out of ignorance. *I've always just picked a naming policy and
> >kept my fingers crossed. *Maybe you have experience of situations where
> >picking one or two "safe" names is easy but extending that to a policy
> >that is "safe enough" is not.

>
> The OP was about sharing private functions. *People seemed to
> have assumed it was about using a minimal number of names for
> access to the public library functions. *That is quite a
> different matter.
>
>
>
> >[Aside: The only way I can see to use one name is to have an array --
> >either external or pointed to by a function return. *Then you'd need to
> >number the API calls rather than name them and (unless all the functions
> >happen to have the same type) cast many of the function pointers to the
> >right type at the point of use. *This would be such a mess that in
> >practise I think you need to have two names: a structure tag and either
> >a function or an extern reference to an instance of it.]

>
> Actually there are several ways that one can have a single name.
> One is as you suggest, using an array. *AFAICT, that's really
> ugly. *Another way is the one Jacob advocates, a global struct
> that has function pointers for the various entry points. *A third
> way is to use C99 and access fields of a struct returned by a
> function. *The problem I see with either choice 2 or 3 is that
> the function/struct name now has to be longer. *For example, in
>
> dfe_create_child(/* blah, blah, blah */)
>
> the name dfe_create_child is unlikely to be duplicated. *OTOH
>
> dfe.create_child(/* blah, blah, blah */)
>
> the name dfe is much more likely to be duplicated.
>
> There may be a clever, sensible way to do it in C, but I haven't
> seen it yet.


I don't particularly like having to just pick a prefix for my library,
and I agree that in general it's a problem area, but I don't know any
other solution that appeals to me enough to justify adding that kind
of complexity. The problem is always the same, its how you want to
package the name mangling that differs.

Best regards,
John D.
 
Reply With Quote
 
Nick
Guest
Posts: n/a
 
      06-07-2010
(E-Mail Removed)-berlin.de (Stefan Ram) writes:

> Ben Pfaff <(E-Mail Removed)> writes:
>>A recursive function's definition must contain the function's own
>>name.

>
> If it is /directly/ and /statically/ recursive.
>
> A function might be recursive /indirectly/, that is, f might
> call g which in turn calls f.


Even so, to compute the hashed name for f you need to know the hashed
name for g, and vice versa.
--
Online waterways route planner | http://canalplan.eu
Plan trips, see photos, check facilities | http://canalplan.org.uk
 
Reply With Quote
 
Richard Bos
Guest
Posts: n/a
 
      06-09-2010
Ben Pfaff <(E-Mail Removed)> wrote:

> Keith Thompson <(E-Mail Removed)> writes:
> > http://www.velocityreviews.com/forums/(E-Mail Removed) (Ben Pfaff) writes:
> >> (E-Mail Removed) (Alan Curry) writes:
> >>> Give each function a name containing the SHA1 of its definition.
> >>
> >> This is difficult if the function is recursive.

> >
> > How so?

>
> A recursive function's definition must contain the function's own
> name. Inserting the function's name into its definition changes
> the definition, which changes the function's name, which changes
> its definition, ...


Like hosts, functions can have THREE DIFFERENT NAMES. One static, one
extern, and one only known to the machine code.

Richard
 
Reply With Quote
 
Ben Pfaff
Guest
Posts: n/a
 
      06-09-2010
(E-Mail Removed) (Richard Bos) writes:

> Like hosts, functions can have THREE DIFFERENT NAMES. One static, one
> extern, and one only known to the machine code.


I don't understand how a function can have different static and
extern names.
--
"I'm not here to convince idiots not to be stupid.
They won't listen anyway."
--Dann Corbit
 
Reply With Quote
 
robertwessel2@yahoo.com
Guest
Posts: n/a
 
      06-09-2010
On Jun 9, 10:01*am, (E-Mail Removed) (Ben Pfaff) wrote:
> (E-Mail Removed) (Richard Bos) writes:
> > Like hosts, functions can have THREE DIFFERENT NAMES. One static, one
> > extern, and one only known to the machine code.

>
> I don't understand how a function can have different static and
> extern names.



I think he means that external names need not have as many significant
characters as internal names, and need not respect case. I think
that's been fully removed in C99, but in C89, internal identifiers
were required to respect 31 characters and case, whereas external
names could use as few as six characters and ignore case. The goal
being to support existing (and lame) linkers. Thus the internal name
could be MyIdentifier, and the external name MYIDEN.
 
Reply With Quote
 
Richard Bos
Guest
Posts: n/a
 
      06-09-2010
(E-Mail Removed) (Ben Pfaff) wrote:

> (E-Mail Removed) (Richard Bos) writes:
>
> > Like hosts, functions can have THREE DIFFERENT NAMES. One static, one
> > extern, and one only known to the machine code.

>
> I don't understand how a function can have different static and
> extern names.


The extern name can be a function _pointer_. There's no effective
difference.

Not that I'm _advocating_ this, mind you. If it were up to me, I'd just
choose a prefix and stick with it. But if you insist on using SHA1s for
external function names, you can.

Richard
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: Splitting a source code file Gene C Programming 5 06-19-2010 04:10 PM
Splitting source code Luke Worth Ruby 7 07-13-2005 11:21 AM
Re: Splitting up the definitions of a class into different files (splitting public from private)? John Dibling C++ 0 07-19-2003 04:41 PM
Re: Splitting up the definitions of a class into different files (splitting public from private)? Mark C++ 0 07-19-2003 04:24 PM
Re: Splitting up the definitions of a class into different files (splitting public from private)? John Ericson C++ 0 07-19-2003 04:03 PM



Advertisments