Assembling a string

[JAKE]

I'm pretty new to ansi c and I'm stuck I'm trying to assemble a string
in a called function. I need to send it three different data types and
return the assembled string. I've been getting errors such as...

28 C:\Dev-Cpp\assemble.c conflicting types for 'assemble'
3 C:\Dev-Cpp\assemble.c previous declaration of 'assemble' was here
30 C:\Dev-Cpp\assemble.c syntax error before "a"

here's what I have so far....

#include <stdio.h>

void assemble(float, int, char, char[]);

int main()
{
float a;
int b;
char c, all[6];

printf("ENTER A FLOATING POINT NUMBER:\n");
scanf("%f", &a);

printf("/nENTER A INTERGER:\n");
scanf("%d", &b);

printf("/nENTER A CHARACTER:\n:");
scanf("%c", &c);

assemble(a, b, c, all);

puts(all);

return 0;
}

void assemble (float *a, int *b, char *c, char *all)
{

sprintf(all,"%f, %d, %c" a, b, c);

return;
}

Am I supposed to convert the data types before I pass them to the
function?
Appreciate any help.

[Richard G. Riley]

On 2006-02-23, JAKE <ja*****@yahoo.com> wrote:

I'm pretty new to ansi c and I'm stuck I'm trying to assemble a string
in a called function. I need to send it three different data types and
return the assembled string. I've been getting errors such as...

28 C:\Dev-Cpp\assemble.c conflicting types for 'assemble'
3 C:\Dev-Cpp\assemble.c previous declaration of 'assemble' was here
30 C:\Dev-Cpp\assemble.c syntax error before "a"

here's what I have so far....

#include <stdio.h>

void assemble(float, int, char, char[]);

int main()
{
float a;
int b;
char c, all[6];

printf("ENTER A FLOATING POINT NUMBER:\n");
scanf("%f", &a);

printf("/nENTER A INTERGER:\n");
scanf("%d", &b);

printf("/nENTER A CHARACTER:\n:");
scanf("%c", &c);

assemble(a, b, c, all);

puts(all);

return 0;
}

void assemble (float *a, int *b, char *c, char *all)
{

sprintf(all,"%f, %d, %c" a, b, c);

return;
}

Am I supposed to convert the data types before I pass them to the
function?
Appreciate any help.

You have declared assemble to expect POINTERS to the data. Whereas you
have passed the data by value.

Without giving the solution:

int a; // a is an integer
int * b; //b is apointer to an integer

b = &a; // assign the address of a to b;
*b=1; // put 1 into the address pointed to be b. In this case, now a
== 1

--
Remove evomer to reply

[tmp123]

JAKE wrote:

I'm pretty new to ansi c and I'm stuck I'm trying to assemble a string
in a called function. I need to send it three different data types and
return the assembled string. I've been getting errors such as...

28 C:\Dev-Cpp\assemble.c conflicting types for 'assemble'
3 C:\Dev-Cpp\assemble.c previous declaration of 'assemble' was here
30 C:\Dev-Cpp\assemble.c syntax error before "a"

here's what I have so far.... .... void assemble(float, int, char, char[]); .... void assemble (float *a, int *b, char *c, char *all)

....
The compiler complains that the two previous lines are not equal
declarations.

[pemo]

JAKE wrote:

I'm pretty new to ansi c and I'm stuck I'm trying to assemble a string
in a called function. I need to send it three different data types
and return the assembled string. I've been getting errors such as...

28 C:\Dev-Cpp\assemble.c conflicting types for 'assemble'
3 C:\Dev-Cpp\assemble.c previous declaration of 'assemble' was here
30 C:\Dev-Cpp\assemble.c syntax error before "a"

here's what I have so far....

#include <stdio.h>

void assemble(float, int, char, char[]);

int main()
{
float a;
int b;
char c, all[6];

printf("ENTER A FLOATING POINT NUMBER:\n");
scanf("%f", &a);

printf("/nENTER A INTERGER:\n");
scanf("%d", &b);

printf("/nENTER A CHARACTER:\n:");
scanf("%c", &c);

assemble(a, b, c, all);

puts(all);

return 0;
}

void assemble (float *a, int *b, char *c, char *all)
{

sprintf(all,"%f, %d, %c" a, b, c);

return;
}

Am I supposed to convert the data types before I pass them to the
function?
Appreciate any help.

Change

void assemble(float, int, char, char[]);

To

void assemble(float *, int *, char *, char[]);

or

void assemble(float *, int *, char *, char *);
Change

assemble(a, b, c, all);

To

assemble(&a, &b, &c, all);

Or

assemble(&a, &b, &c, &all[0]);

--
==============
*Not a pedant*
==============

[Keith Thompson]

"JAKE" <ja*****@yahoo.com> writes:
[snip]

here's what I have so far....

#include <stdio.h>

void assemble(float, int, char, char[]);

int main()
{
float a;
int b;
char c, all[6];

printf("ENTER A FLOATING POINT NUMBER:\n");
scanf("%f", &a);

printf("/nENTER A INTERGER:\n");
scanf("%d", &b);

printf("/nENTER A CHARACTER:\n:");
scanf("%c", &c);

assemble(a, b, c, all);

puts(all);

return 0;
}

void assemble (float *a, int *b, char *c, char *all)
{

sprintf(all,"%f, %d, %c" a, b, c);

return;
}

That doesn't even compile. The declaration and definition of
assemble() are inconsistent, and you have a syntax error on the
sprintf() call. Also, I assume you mean "\n" rather than "/n".

Post your actual code (cut-and-paste, don't re-type). Otherwise we
have no way of guessing which errors are in your code and which ones
you introduced when you posted an approximation of it.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Vladimir S. Oka]

JAKE wrote:

<snip>

void assemble (float *a, int *b, char *c, char *all)
{

sprintf(all,"%f, %d, %c" a, b, c);
Apart from what others have pointed out, you're missing a comma here.
That's why you get the third error.

sprintf(all,"%f, %d, %c", a, b, c);
^

return;
}

Also, alloting only 6 bytes to `all` is sure to give you a buffer
overflow above. One way around it is to declare `all` with whatever
size you think you need, but ensure that `sprintf` can't give you a
larger string (also taking care about the terminating \0). E.g.:

char all[26];

sprintf(all, "%10f, %10d, %1c", a, b, c); /* single blanks */

--
BR, Vladimir

[Keith Thompson]

Keith Thompson <ks***@mib.org> writes:

"JAKE" <ja*****@yahoo.com> writes:
[snip]

here's what I have so far....

[snip]
That doesn't even compile. The declaration and definition of
assemble() are inconsistent, and you have a syntax error on the
sprintf() call. Also, I assume you mean "\n" rather than "/n".

Post your actual code (cut-and-paste, don't re-type). Otherwise we
have no way of guessing which errors are in your code and which ones
you introduced when you posted an approximation of it.

Sorry, I didn't read the original message closely enough. I see that
you *did* post your actual code, and you were asking about the
compilation errors.

I think others have answered your questions.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Rod Pemberton]

"Vladimir S. Oka" <no****@btopenworld.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...

JAKE wrote:

<snip>

void assemble (float *a, int *b, char *c, char *all)
{

sprintf(all,"%f, %d, %c" a, b, c);

Apart from what others have pointed out, you're missing a comma here.
That's why you get the third error.

sprintf(all,"%f, %d, %c", a, b, c);
^

return;
}

Also, alloting only 6 bytes to `all` is sure to give you a buffer
overflow above. One way around it is to declare `all` with whatever
size you think you need, but ensure that `sprintf` can't give you a
larger string (also taking care about the terminating \0). E.g.:

char all[26];

sprintf(all, "%10f, %10d, %1c", a, b, c); /* single blanks */

Vladimir,

Are you using a fixed with font? FYI, the caret above is place under the %
of the %d in my newsreader...

RP

[Vladimir S. Oka]

Rod Pemberton wrote:

"Vladimir S. Oka" <no****@btopenworld.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...

JAKE wrote:

<snip>

void assemble (float *a, int *b, char *c, char *all)
{

sprintf(all,"%f, %d, %c" a, b, c);
Apart from what others have pointed out, you're missing a comma here.
That's why you get the third error.

sprintf(all,"%f, %d, %c", a, b, c);
^

return;
}

Also, alloting only 6 bytes to `all` is sure to give you a buffer
overflow above. One way around it is to declare `all` with whatever
size you think you need, but ensure that `sprintf` can't give you a
larger string (also taking care about the terminating \0). E.g.:

char all[26];

sprintf(all, "%10f, %10d, %1c", a, b, c); /* single blanks */

Vladimir,

Are you using a fixed with font? FYI, the caret above is place under the %
of the %d in my newsreader...

I'm forced to use blinkin' Google from the office. I tried my best with
Preview, but obviously failed. I now realise it'd have been better if I
just spelled it out: "missing comma after closing double quote". :-(

--
BR, Vladimir

RP

[Vladimir S. Oka]

Vladimir S. Oka wrote:

Rod Pemberton wrote:

"Vladimir S. Oka" <no****@btopenworld.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...

JAKE wrote:

<snip>

> void assemble (float *a, int *b, char *c, char *all)
> {
>
> sprintf(all,"%f, %d, %c" a, b, c);

Apart from what others have pointed out, you're missing a comma here.
That's why you get the third error.

sprintf(all,"%f, %d, %c", a, b, c);
^

>
> return;
> }

Also, alloting only 6 bytes to `all` is sure to give you a buffer
overflow above. One way around it is to declare `all` with whatever
size you think you need, but ensure that `sprintf` can't give you a
larger string (also taking care about the terminating \0). E.g.:

char all[26];

sprintf(all, "%10f, %10d, %1c", a, b, c); /* single blanks */

Vladimir,

Are you using a fixed with font? FYI, the caret above is place under the %
of the %d in my newsreader...

I'm forced to use blinkin' Google from the office. I tried my best with
Preview, but obviously failed. I now realise it'd have been better if I
just spelled it out: "missing comma after closing double quote". :-(

However, it looks OK viewed through Googgles (I'm using fixed-width
view, which seems to be utilising Courier New typeface). Could it be
/your/ font? ;-)

--
BR, Vladimir

[Richard Bos]

"Rod Pemberton" <do*********@sorry.bitbucket.cmm> wrote:

"Vladimir S. Oka" <no****@btopenworld.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...

sprintf(all,"%f, %d, %c", a, b, c);
^

Vladimir,

Are you using a fixed with font? FYI, the caret above is place under the %
of the %d in my newsreader...

Then I suspect it's your newsreader that has the problem; it's under the
comma in mine, which I've set to use Courier.

Richard

[Kenneth Brody]

JAKE wrote:

I'm pretty new to ansi c and I'm stuck I'm trying to assemble a string
in a called function. I need to send it three different data types and
return the assembled string. I've been getting errors such as...

28 C:\Dev-Cpp\assemble.c conflicting types for 'assemble'
3 C:\Dev-Cpp\assemble.c previous declaration of 'assemble' was here
30 C:\Dev-Cpp\assemble.c syntax error before "a"

here's what I have so far....

#include <stdio.h>

You prototype the function one way:
void assemble(float, int, char, char[]); [...]

Then you define it another way:
void assemble (float *a, int *b, char *c, char *all) [...] Appreciate any help.

Pick one way, and stick with it. Either you want float/int/char, or you
want pointers to float/int/char.

Note that the call in main() to this function, and the body of the function,
both imply that you want the values, not the pointers.

Also, note that you define all as a 6-character array, and then sprintf()
into it much more than 6 characters.

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

[Martin Ambuhl]

JAKE wrote:

I'm pretty new to ansi c and I'm stuck I'm trying to assemble a string
in a called function. I need to send it three different data types and
return the assembled string. I've been getting errors such as...

28 C:\Dev-Cpp\assemble.c conflicting types for 'assemble'
3 C:\Dev-Cpp\assemble.c previous declaration of 'assemble' was here
30 C:\Dev-Cpp\assemble.c syntax error before "a"

here's what I have so far....
[Prototype] void assemble(float, int, char, char[]);
[from function definition]
void assemble (float *a, int *b, char *c, char *all)
It is obvious that 'float' is not the same as 'float *', 'int' is not
the same as 'int *', and 'char' is not the same as 'char *'.
Am I supposed to convert the data types before I pass them to the
function?

No, but
a) the function prototype must match the function definition
b) a function expecting addresses of its parameters should be supplied
with addresses of its parameters, not with their values/

[Ian Malone]

Kenneth Brody wrote:

JAKE wrote:

I'm pretty new to ansi c and I'm stuck I'm trying to assemble a string
in a called function. I need to send it three different data types and
return the assembled string. I've been getting errors such as...

here's what I have so far....

You prototype the function one way:

void assemble(float, int, char, char[]);

[...]

Then you define it another way:

void assemble (float *a, int *b, char *c, char *all)

[...]

Appreciate any help.

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). Mainly for this reason; you eliminate the need for the
separate prototype. 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.

--
imalone

[pete]

Ian Malone wrote:

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). Mainly for this reason; you eliminate the need for the
separate prototype.
Saving Keystrokes!?
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.

I think it's better to write and use prototypes by default,
and completely dispense with any need to
even consider the order the definitions.

--
pete

[Default User]

Richard Bos wrote:

"Rod Pemberton" <do*********@sorry.bitbucket.cmm> wrote:

"Vladimir S. Oka" <no****@btopenworld.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...

sprintf(all,"%f, %d, %c", a, b, c);
^

Vladimir,

Are you using a fixed with font? FYI, the caret above is place
under the % of the %d in my newsreader...

Then I suspect it's your newsreader that has the problem; it's under
the comma in mine, which I've set to use Courier.

Moi aussi. "Courier New" to be specific. Looked fine.

Brian

[Micah Cowan]

"Vladimir S. Oka" <no****@btopenworld.com> writes:

JAKE wrote:

<snip>

void assemble (float *a, int *b, char *c, char *all)
{

sprintf(all,"%f, %d, %c" a, b, c);

Apart from what others have pointed out, you're missing a comma here.
That's why you get the third error.

sprintf(all,"%f, %d, %c", a, b, c);
^

return;
}

Also, alloting only 6 bytes to `all` is sure to give you a buffer
overflow above. One way around it is to declare `all` with whatever
size you think you need, but ensure that `sprintf` can't give you a
larger string (also taking care about the terminating \0). E.g.:

char all[26];

sprintf(all, "%10f, %10d, %1c", a, b, c); /* single blanks */

I'm sorry to say that the above format string does not do what you
think it does. For most of the conversion specifiers, there is no way
to specify a /maximum/ number of characters to use for the field: what
you have done is to specify the /minimum/ number of characters to
appera in the field.

There's really no substitute for using snprintf() in cases like
these. You've got to pass in the size of the buffer along with a
pointer into the buffer itself.

-Micah

[CBFalconer]

pete wrote:

Ian Malone wrote:

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). Mainly for this reason; you eliminate the need for the
separate prototype.

Saving Keystrokes!?

No. Avoiding errors. Any time you have to maintain two copies to
be identical, it is easy to foul up. It also has the advantage
that you know immediately which way to look for the function
source. The only times you need a prototype is for external access
and for mutual recursion.

--
"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/>

[Chris Torek]

In article <43**************@cam.ac.uk> Ian Malone <ib***@cam.ac.uk> wrote:

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). Mainly for this reason; you eliminate the need for the
separate prototype.

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.

There are adherents of the "top-down" style, in which you define the
overall problem first, and begin by breaking it down into major
components. Then you write those major components, assuming that
any complicated parts they need to perform are also already written,
and simply calling those (not yet written) functions. Then you
work on those, breaking them down as needed.

I use neither approach. :-)

(Aside: I once saw the "top-down programming" approach illustrated
as a quite funny bit of artwork. There was a river [or other
physical obstacle] over which a bridge was being built ... from
the top down. The partially-complete bridge was magically floating
above the river.)

The problem with top-down programming is that you *assume* that
some function f() will take care of some (complete) sub-problem.
You build a whole lot of code based on that assumption ... then,
later, you go to write f() and discover that it is an absolutely
terrible way to solve the problem, that it depends on a solution
that was going to be computed later in function h(), which you
earlier assumed would not need to be done until f() and g() had
both completed.

The problem with bottom-up programming is that you *assume* that
some function f() is going to be useful later. By the time you
get around to writing the code that needs f(), you discover that
f() does too little and too much, just as with the top-down
method.

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.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Vladimir S. Oka]

Micah Cowan wrote:

"Vladimir S. Oka" <no****@btopenworld.com> writes:

char all[26];

sprintf(all, "%10f, %10d, %1c", a, b, c); /* single blanks */
I'm sorry to say that the above format string does not do what you
think it does. For most of the conversion specifiers, there is no way
to specify a /maximum/ number of characters to use for the field: what
you have done is to specify the /minimum/ number of characters to
appera in the field.

Ah, yes. I stand corrected. I blame my upbringing^H^H^H^H^H^H^H^H^H^H
past five years in which *printf() was banned, even for debug output
and logging (deeply embedded, hard real time system). Only a simple,
home brewed, print_str(char *) is available. ;-)
There's really no substitute for using snprintf() in cases like
these. You've got to pass in the size of the buffer along with a
pointer into the buffer itself.

You're quite right again. It has crossed my mind, but I decided against
it, as OP may not have access to a fully conforming C99 implementation
(they tend to use antique Borland compilers in some beginner C courses,
it seems, at least judging by some recent posts here).

--
BR, Vladimir

Sushido, n:
The way of the tuna.

[CBFalconer]

Chris Torek wrote:

Ian Malone <ib***@cam.ac.uk> wrote:

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). Mainly for this reason; you eliminate the need for the
separate prototype.

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]

Ian Malone <ib***@cam.ac.uk> wrote:

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]

Richard Bos wrote:

Ian Malone <ib***@cam.ac.uk> 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.

--
BR, Vladimir

[Vladimir S. Oka]

Richard Bos wrote:

Ian Malone <ib***@cam.ac.uk> 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.

--
BR, Vladimir

[Richard Bos]

"Vladimir S. Oka" <no****@btopenworld.com> wrote:

Richard Bos wrote:

Ian Malone <ib***@cam.ac.uk> 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).

That's what you get when you program on large-scale half-ISO
free-standing implementations, AKA MS Windows compilers :-P.
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]

On 2006-02-24, Richard Bos <rl*@hoekstra-uitgeverij.nl> wrote:

"Vladimir S. Oka" <no****@btopenworld.com> wrote:

Richard Bos wrote:

> Ian Malone <ib***@cam.ac.uk> 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).

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

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.



--
Remove evomer to reply

[Vladimir S. Oka]

Richard Bos wrote:

"Vladimir S. Oka" <no****@btopenworld.com> wrote:

Richard Bos wrote:

Ian Malone <ib***@cam.ac.uk> 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).

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

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...

--
BR, Vladimir

[Vladimir S. Oka]

Richard Bos wrote:

"Vladimir S. Oka" <no****@btopenworld.com> wrote:

Richard Bos wrote:

Ian Malone <ib***@cam.ac.uk> 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).

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

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...

--
BR, Vladimir

[Richard Bos]

"Vladimir S. Oka" <no****@btopenworld.com> wrote:

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

Richard

[Vladimir S. Oka]

Richard Bos wrote:

"Vladimir S. Oka" <no****@btopenworld.com> wrote:

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... :-(

--
BR, Vladimir

You will gain money by speculation or lottery.

[Ben Pfaff]

Chris Torek <no****@torek.net> writes:

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.
--
"It would be a much better example of undefined behavior
if the behavior were undefined."
--Michael Rubenstein

[Chris Torek]

>Chris Torek <no****@torek.net> writes:

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.

In article <87************@benpfaff.org>,
Ben Pfaff <bl*@cs.stanford.edu> wrote: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".
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.