Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Ahead of "main"?

Reply
Thread Tools

Ahead of "main"?

 
 
Barry Schwarz
Guest
Posts: n/a
 
      04-30-2007
On Sun, 29 Apr 2007 23:48:23 +0100, Flash Gordon
<(E-Mail Removed)> wrote:

>Stephen Sprunk wrote, On 29/04/07 22:35:
>> "mdh" <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed) ps.com...
>>> Hi all,
>>> Going quite methodically through K& R ( as some of you can attest
>>> to!), I have never seen a big diffference in declaring a function
>>> within "main" or "ahead" of it. Now, (p119, K&R II), the discussion
>>> states that "functions "whatever" " should be declared ahead of
>>> main.
>>> Is there a good reason for this?

>>
>> In Standard C, functions cannot be declared "within" main(); these are
>> called nested functions and are implemented as an extension by some
>> compilers, but in general you should never use them.

>
>Wrong. They can be *declared* within main or any other function, they
>just cannot be *defined* in a function. A declaration says something
>exists, a definition says what it is, the difference is important in C.
>
> > Therefore, the
>> debate is about whether to declare functions before or after main().
>>
>> As a rule, you should declare all functions before you call them; I
>> won't go into the reasons why, as Eric did a good job of that. One
>> style is to define all other functions before main(), which also
>> declares them. The other is to declare all of your functions in a group
>> near the beginning of the source, and then you can define them in any
>> order you want. The latter style is effectively required when you move
>> to multi-file projects, and the standard practice is to put all of your
>> function declarations in header (.h) files so that each source file can
>> simply #include the appropriate header files and then use whatever
>> functions are needed.

>
>Actually, you should not put *all* your function definitions in header
>files, since generally there are some which should be local to a given
>source file and declared static in that source file. I.e. you should
>always limit visibility to the smallest unit that makes sense, since
>then you don't have to look as far to see all of the usage.


You should not put any function definitions in a header file. I would
go a step further and say no object definitions either. Only
declarations. The only definitions in a header file should be typedef
(oops, even though it is called a type definition in the standard, it
is specifically described as a declaration) and macro definitions.


Remove del for email
 
Reply With Quote
 
 
 
 
Richard Tobin
Guest
Posts: n/a
 
      04-30-2007
In article <(E-Mail Removed)>,
Barry Schwarz <(E-Mail Removed)> wrote:

>You should not put any function definitions in a header file.


Except inline function definitions.

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
 
Reply With Quote
 
 
 
 
Flash Gordon
Guest
Posts: n/a
 
      04-30-2007
Barry Schwarz wrote, On 30/04/07 12:00:
> On Sun, 29 Apr 2007 23:48:23 +0100, Flash Gordon
> <(E-Mail Removed)> wrote:
>
>> Stephen Sprunk wrote, On 29/04/07 22:35:


<snip>

>>> As a rule, you should declare all functions before you call them; I
>>> won't go into the reasons why, as Eric did a good job of that. One
>>> style is to define all other functions before main(), which also
>>> declares them. The other is to declare all of your functions in a group
>>> near the beginning of the source, and then you can define them in any
>>> order you want. The latter style is effectively required when you move
>>> to multi-file projects, and the standard practice is to put all of your
>>> function declarations in header (.h) files so that each source file can
>>> simply #include the appropriate header files and then use whatever
>>> functions are needed.

>> Actually, you should not put *all* your function definitions in header
>> files, since generally there are some which should be local to a given
>> source file and declared static in that source file. I.e. you should
>> always limit visibility to the smallest unit that makes sense, since
>> then you don't have to look as far to see all of the usage.

>
> You should not put any function definitions in a header file. I would
> go a step further and say no object definitions either. Only
> declarations. The only definitions in a header file should be typedef
> (oops, even though it is called a type definition in the standard, it
> is specifically described as a declaration) and macro definitions.


It was a trypo. I meant you should not put all your function
declarations in your headers.
--
Flash Gordon
 
Reply With Quote
 
=?utf-8?B?SGFyYWxkIHZhbiBExLNr?=
Guest
Posts: n/a
 
      04-30-2007
Barry Schwarz wrote:
> You should not put any function definitions in a header file. I would
> go a step further and say no object definitions either. Only
> declarations. The only definitions in a header file should be typedef
> (oops, even though it is called a type definition in the standard, it
> is specifically described as a declaration)


All definitions are also declarations (macro definitions don't count
as "definitions"). A type definition is both a declaration and a
definition. A definition of an enumeration constant is also a
definition that can be appropriate for header files.

> and macro definitions.


 
Reply With Quote
 
David Thompson
Guest
Posts: n/a
 
      05-21-2007
On Mon, 30 Apr 2007 06:00:41 GMT, Chris Dollin
<(E-Mail Removed)> wrote:

> Malcolm McLean wrote:
>
> > Some early versions of C had local functions, declared within the function
> > that called them. The idea never caught on, and it is now not possible to
> > declare functions within main.

>
> I'm not sure /exactly/ what you're saying; but if I read you
> properly, what you're saying is false.
>
> To the best of my knowledge, no "early" versions of C had local
> functions, that is, functions /defined/ inside other functions.
> (I don't count BCPL as an early version of C.)
>

And IIRC that vitiated the potential benefit by prohibiting access to
outerscope (nonglobal) variables, punting on the closure issue.

> Again to the best of my knowledge, /all/ versions of C allow you
> to /declare/ -- not define -- (external) functions inside functions.
>

Right.

> > Old C also had no prototypes.

>
> Yes (where "Old" means "pre-Standard", for a useful value of "had").
>

I'm having trouble thinking of plausible nonuseful values of 'had'.
<OT> Does it depend on what 'is' is? <GG!> </>

> > So if you put functions in reverse order of
> > hierarchy, the compiler could do additional checking of arguments.

>
> Whatever the order you used, the compiler "could" do such checking.
> In practice it didn't: one used "lint".
>
> > Nowadays we should prototype all functions,

>
> Not true if by "prototype" you mean "declare with a prototype"
> rather than "define using typed-argument syntax".
>

I'm not sure if your second alternative was meant to be "define using
prototype syntax" or "define using K&R1 syntax" or even both. But:
it is certainly not REQUIRED to use prototypes, even in C99, except
for variable arguments or arithmetic parameters narrower than int or
double. It is however always or almost so a good idea, and thus I
would agree with 'should'.

> > so it doesn't matter where
> > main() is placed, though obviously it should be either the first or the
> > last function for readbility.

>
> I'm not sure about that last: it's not /obvious/, even if it's
> true.


Depends on who's looking. <G>

- formerly david.thompson1 || achar(64) || worldnet.att.net
 
Reply With Quote
 
Chris Dollin
Guest
Posts: n/a
 
      05-21-2007
David Thompson wrote:

> On Mon, 30 Apr 2007 06:00:41 GMT, Chris Dollin
> <(E-Mail Removed)> wrote:
>
>> Malcolm McLean wrote:
>>
>> > Some early versions of C had local functions, declared within the function
>> > that called them. The idea never caught on, and it is now not possible to
>> > declare functions within main.

>>
>> I'm not sure /exactly/ what you're saying; but if I read you
>> properly, what you're saying is false.
>>
>> To the best of my knowledge, no "early" versions of C had local
>> functions, that is, functions /defined/ inside other functions.
>> (I don't count BCPL as an early version of C.)
>>

> And IIRC that vitiated the potential benefit by prohibiting access to
> outerscope (nonglobal) variables, punting on the closure issue.


While I'm all in favour of full lexical scoping, I don't think that's
compatible with the design of BCPL, and, for the same reasons, with
that of C.

One might be able to manage the downward case with a big dose of
"if the function escapes, The Behaviour Is Undefined". But even
then there's a Cost which people might not be prepared to pay
(since now the function [pointer] has to carry some kind of
scope reference around with it.)

--
"People are part of the design. It's dangerous to forget that." /Star Cops/

Hewlett-Packard Limited Cain Road, Bracknell, registered no:
registered office: Berks RG12 1HN 690597 England

 
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
DropDown Type ahead Peter ASP .Net 1 02-24-2006 09:56 AM
The Road Ahead - a look back on bit-tech.net Silverstrand Front Page News 0 02-09-2006 02:56 AM
Format for changing type-ahead error sound? F*R*A*N*K_pa_nu_cc_i Firefox 1 12-09-2005 02:20 AM
Key ahead/keyboard buffer Rob T ASP .Net 1 08-01-2005 04:05 PM
Can we inherit a class and it's aspx ahead ad ASP .Net 3 05-12-2005 12:59 PM



Advertisments