Assembling a string

[CBFalconer]

I do not know about "more common", but it does indeed eliminate the
need for most prototypes. It is also the kind of system-building
that is often referred-to as "bottom-up": you write the bottom-level
supporting functions first, and read and comprehend them. Then
you use those to assemble medium-level constructs; you use those
to assemble the complete program.

Ever since we stopped using line numbers in the editors this style
is totally independant of top-down vs bottom-up programming. Just
write the main function, with stubs above. Then elucidate the
stubs as convenient.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

 

[Richard Bos]

Final point to the OP in this regard: it seems to be pretty common
that newcomers to C use function prototypes and put their functions
in the order: main, function1, function2 ...

It's more common practice to put the functions in reverse order
(with main at the bottom if it's present, small helpers at the
top).

Says you. I want main() on top; I prefer to read it that way. main() is
the most important function. I want to read it first. When I then need
to know what a function called in main() does, I read on.
I find this the more logical way to read code. If I first encounter a
small function which, say, fimbricates a mingus, I may have no idea what
a mingus is used for, and why it's being fimbricates. If I first read
the high-level code which declares and uses menzies, I may not yet know
the details of fimbrication, but at least I'll have an overview; and if
I then want more detail, I'll read on and find the function which does
that job with a good idea of what it operates on, and why.

Mainly for this reason; you eliminate the need for the
separate prototype.

Pah. I refuse to hamper my style, and make my code more awkward (for me)
to read, just because of a broken compiler or editor.

If you do need a separate prototype (for a
header, because of interdependent functions or because you'll
need to interleave unrelated functions otherwise), then cut and
paste it.

This, though, is true. And a small effort.

Richard

 

[Vladimir S. Oka]

Ian Malone <[email protected]> wrote:

<snip a long discussion about relative altitude
of main vis other functions>

OTH, /I/ haven't seen a `main()` in almost five years now (c.l.c not
withstanding). When I did see it, it was out of pure curiosity (someone
claimed it really did exist, and I set out to see for myself).

More seriously, I believe that for any project large enough to expand
beyond a single file this point is moot, anyway, and I don't think
there are many these days that don't.

 

[Vladimir S. Oka]

Ian Malone <[email protected]> wrote:

<snip a long discussion about relative altitude
of main vis other functions>

OTH, /I/ haven't seen a `main()` in almost five years now (c.l.c not
withstanding). When I did see it, it was out of pure curiosity (someone
claimed it really did exist, and I set out to see for myself).

More seriously, I believe that for any project large enough to expand
beyond a single file this point is moot, anyway, and I don't think
there are many these days that don't.

 

[Richard Bos]

<snip a long discussion about relative altitude
of main vis other functions>

OTH, /I/ haven't seen a `main()` in almost five years now (c.l.c not
withstanding). When I did see it, it was out of pure curiosity (someone
claimed it really did exist, and I set out to see for myself).

That's what you get when you program on large-scale half-ISO
free-standing implementations, AKA MS Windows compilers .

More seriously, I believe that for any project large enough to expand
beyond a single file this point is moot, anyway, and I don't think
there are many these days that don't.

No, my point is the same for any file which contains one or more main[1]
functions which depend on others. In almost all cases, IMO, the most
high-level function(s) should be at the top of the file, and helper
functions should be underneath. Ideally, helper functions for a single
main function should be underneath it, and helper functions for all
high-level functions should be underneath them all.

Richard

[1] Not necessarily main()...

 

[Richard G. Riley]

<snip a long discussion about relative altitude
of main vis other functions>

OTH, /I/ haven't seen a `main()` in almost five years now (c.l.c not
withstanding). When I did see it, it was out of pure curiosity (someone
claimed it really did exist, and I set out to see for myself).

That's what you get when you program on large-scale half-ISO
free-standing implementations, AKA MS Windows compilers .

More seriously, I believe that for any project large enough to expand
beyond a single file this point is moot, anyway, and I don't think
there are many these days that don't.

No, my point is the same for any file which contains one or more main[1]
functions which depend on others. In almost all cases, IMO, the most
high-level function(s) should be at the top of the file, and helper
functions should be underneath. Ideally, helper functions for a single
main function should be underneath it, and helper functions for all
high-level functions should be underneath them all.

Richard

[1] Not necessarily main()...

In general I would agree : it is nothing but common sense to have the
highest level at the the top for hardcopy reading. Having said that I
would use a debugger/tags/IDE to browse code, so the physical location
is not as important as it once was. It is almost certain that I
wouldnt have any functions in the same file as main anyway - project
IDEs and makefiles make keeping things in monolithic files redundant -
and reduces that new print out size when function X got fixed TO be
honest, I prefer helper functions at the top of anything that uses
them : seems to be a more logical progression but it could be more me
thinking in terms of old one pass compilers/assemblers and just being
a stick in the mud.

But when I print out those files, guess which function is at the
beginning of the folder? Yup. main() or its equivalent.

 

[Vladimir S. Oka]

That's what you get when you program on large-scale half-ISO
free-standing implementations, AKA MS Windows compilers .

It's mobile phone, actually (and not WinCE one, more like home grown).
I was mildly surprised to see a `main()` actually, as it's not really
required. ;-)

More seriously, I believe that for any project large enough to expand
beyond a single file this point is moot, anyway, and I don't think
there are many these days that don't.

No, my point is the same for any file which contains one or more main[1]
functions which depend on others. In almost all cases, IMO, the most
high-level function(s) should be at the top of the file, and helper
functions should be underneath. Ideally, helper functions for a single
main function should be underneath it, and helper functions for all
high-level functions should be underneath them all.

I agree with this. I also like to see a "main" first, only to be later
broken down into smaller tasks. I seemed to have clutched onto the
`main()` bit...

 

[Vladimir S. Oka]

That's what you get when you program on large-scale half-ISO
free-standing implementations, AKA MS Windows compilers .

It's mobile phone, actually (and not WinCE one, more like home grown).
I was mildly surprised to see a `main()` actually, as it's not really
required. ;-)

More seriously, I believe that for any project large enough to expand
beyond a single file this point is moot, anyway, and I don't think
there are many these days that don't.

No, my point is the same for any file which contains one or more main[1]
functions which depend on others. In almost all cases, IMO, the most
high-level function(s) should be at the top of the file, and helper
functions should be underneath. Ideally, helper functions for a single
main function should be underneath it, and helper functions for all
high-level functions should be underneath them all.

I agree with this. I also like to see a "main" first, only to be later
broken down into smaller tasks. I seemed to have clutched onto the
`main()` bit...

 

[Richard Bos]

You are, BTW, double-posting. This may be Google playing silly-buggers
again.

Richard

 

[Vladimir S. Oka]

You are, BTW, double-posting. This may be Google playing silly-buggers
again.

Indeed it is (was, I'm back to KNode and happy as a puppy).

Generally, Mon to Fri UK office hours I'm posting using Google as my
company's IS "security" policy does not allow NNTP. It's /very/
annoying frankly... :-(

 

[Ben Pfaff]

I tend to use what has sometimes been described as "outside-in"
programming, where I attack all the problems I understand from both
the bottom and top ends, and leave the problems I do not quite
understand to be handled by the solutions to the ones that I do.

Really? In my experience, my software turns out better if I
first attack the problems that I don't already understand.
Sometimes I will build some kind of prototype of just those
parts, to allow me to experiment with different possibilities.
Afterward, I can write the routine parts of the program.

 

[Chris Torek]

Really? In my experience, my software turns out better if I
first attack the problems that I don't already understand.
Sometimes I will build some kind of prototype of just those
parts, to allow me to experiment with different possibilities.

I like the experimentation approach; but I often find it hard
to write useful experiments without also writing all the support
code (file I/O, parsing, whatever). So the support code is then
done, and:

Afterward, I can write the routine parts of the program.

.... all that remains is to replace the failed experiments with
the working ones, and maybe tweak the "routine parts".