A CT&P excursion - beat it up!

[Bob Nelson]

After completing KNK2, my interest in C was reignited, prompting a
re-reading of Traister's dubious book on pointers. Then I dusted off
the fine ``C Traps and Pitfalls'' by Andy Koenig. Nowadays I primarily
work in PHP, Perl and C++. Consequently my C skills have atrophied.

So inspired by CT&P's ``calendar'' example on page 30, I decided to
brush up on some elementary C (although Koenig describes it as walking
``out on the ice'') with the little toy exercise below.

For posting, here I yanked all the comments for brevity. There's a
(too?) liberal use of typedef, pointers for the sake of pointers and
some blatantly obvious asserts. It compiles cleanly with Sun C 5.8
2005/10/13 on a SPARC and lint shows only functions returning values
that are ignored. The output meets expectations for a non-leap year.

So look this over being brutal and merciless with your critique as I
try to rebuild my flabby C muscles:

#include <assert.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

enum { MONTHS = 12, DAYS = 31 };
enum { JAN, FEB, MAR, APR, MAY, JUN, JUL, AUG, SEP, OCT, NOV, DEC };
static const char *const months[] = { "JAN", "FEB", "MAR", "APR",
"MAY", "JUN", "JUL", "AUG",
"SEP", "OCT", "NOV", "DEC", };

int main(void)
{
typedef int month_type[DAYS];
typedef month_type *month_ptr_type;
typedef int *day_ptr_type;

int calendar[MONTHS][DAYS];
month_ptr_type month_ptr;
size_t num_months;
size_t num_days_per_month;

memset(calendar, 0, sizeof calendar);
assert(calendar[DEC][DAYS - 1] == 0);

month_ptr = calendar;
assert(sizeof *month_ptr == DAYS * sizeof(int));

num_months = sizeof calendar / sizeof *calendar;
assert(num_months == MONTHS);

num_days_per_month = sizeof *calendar / sizeof **calendar;
assert(num_days_per_month == DAYS);

for(; month_ptr < calendar + num_months; ++month_ptr) {
day_ptr_type day_ptr = *month_ptr;
int month_num = (month_ptr - calendar + num_months) - num_months;
int days_in_month;
int day_num;

switch(month_num) {
case FEB:
days_in_month = 28;
break;
case APR:
case JUN:
case SEP:
case NOV:
days_in_month = 30;
break;
default:
days_in_month = 31;
break;
}

for(day_num = 1; day_num <= days_in_month; ++day_num, ++day_ptr)
*day_ptr = day_num;
}

for(month_ptr = calendar; month_ptr < calendar + num_months; ++month_ptr) {
int month_num = (month_ptr - calendar + num_months) - num_months;
int total_days_in_month = -1;
day_ptr_type day_ptr;

for(day_ptr = *month_ptr + num_days_per_month - 1;
day_ptr *month_ptr; --day_ptr) {
if(*day_ptr) {
total_days_in_month = *day_ptr;
break;
}
}

printf("month %d (%s) has %d days\n",
month_num + 1, months[month_num], total_days_in_month);
}

return EXIT_SUCCESS;
}

[Ron Ford]

On Sat, 07 Jun 2008 02:08:07 -0500, Bob Nelson wrote:

[code elided]
0 warnings, 0 errors.

On my machine the output doesn't last long enough to read. Add a getchar()
call somewhere:

>
printf("month %d (%s) has %d days\n",
month_num + 1, months[month_num], total_days_in_month);

getchar();

}

return EXIT_SUCCESS;
}

I had to write a perpetual calender for my scientific programming class in
fortran in college. Output was un-fun.
--
The chief value of money lies in the fact that one lives in a world in
which it is overestimated.
H. L. Mencken

[Richard Heathfield]

Ron Ford said:

On Sat, 07 Jun 2008 02:08:07 -0500, Bob Nelson wrote:

[code elided]
0 warnings, 0 errors.

On my machine the output doesn't last long enough to read. Add a
getchar() call somewhere:

Why should he do that? Learn how to drive a command shell.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Keith Thompson]

Ron Ford <ro*@nowhere.netwrites:

On Sat, 07 Jun 2008 02:08:07 -0500, Bob Nelson wrote:
[code elided]
0 warnings, 0 errors.

On my machine the output doesn't last long enough to read. Add a getchar()
call somewhere:

>>
printf("month %d (%s) has %d days\n",
month_num + 1, months[month_num], total_days_in_month);

getchar();

> }

return EXIT_SUCCESS;
}

Don't bother. Just run the program in a way that doesn't cause the
window to close when the program terminates. Not all systems are
Windows; on a non-Windows system, a program that gratuitously waits
for input before terminating would be quite annoying.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Ron Ford]

On Sat, 07 Jun 2008 08:42:01 +0000, Richard Heathfield wrote:

Ron Ford said:

>On Sat, 07 Jun 2008 02:08:07 -0500, Bob Nelson wrote:

[code elided]
0 warnings, 0 errors.

On my machine the output doesn't last long enough to read. Add a
getchar() call somewhere:

Why should he do that? Learn how to drive a command shell.

I use Dev-Cpp for quick and dirty C stuff and simply could not find a
means, from within the IDE, to pause a program before windows eats it up.
I ended up putting in a dos-shortcut where the executable lives, and that
works, but it misses the whole point of staying within an IDE during
development and testing.:-(

--
I confess I enjoy democracy immensely. It is incomparably idiotic, and
hence incomparably amusing.
H. L. Mencken

[Flash Gordon]

Bob Nelson wrote, On 07/06/08 08:08:

<snip>

So look this over being brutal and merciless with your critique as I
try to rebuild my flabby C muscles:

#include <assert.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

enum { MONTHS = 12, DAYS = 31 };
enum { JAN, FEB, MAR, APR, MAY, JUN, JUL, AUG, SEP, OCT, NOV, DEC };
static const char *const months[] = { "JAN", "FEB", "MAR", "APR",
"MAY", "JUN", "JUL", "AUG",
"SEP", "OCT", "NOV", "DEC", };

int main(void)
{
typedef int month_type[DAYS];
typedef month_type *month_ptr_type;
typedef int *day_ptr_type;

int calendar[MONTHS][DAYS];

Rather than the memset further down initialise calendar here
int calendar[MONTHS][DAYS] = {0};

month_ptr_type month_ptr;
size_t num_months;
size_t num_days_per_month;

memset(calendar, 0, sizeof calendar);
assert(calendar[DEC][DAYS - 1] == 0);

As you say, a someone pointless assert. As are the others below.

month_ptr = calendar;
assert(sizeof *month_ptr == DAYS * sizeof(int));

num_months = sizeof calendar / sizeof *calendar;
assert(num_months == MONTHS);

num_days_per_month = sizeof *calendar / sizeof **calendar;
assert(num_days_per_month == DAYS);

for(; month_ptr < calendar + num_months; ++month_ptr) {

Rather than assigning monthptr several lines up I would assign it in the
for statement.
for (month_ptr = calendar;
month_ptr < calendar + num_months;
++month_ptr) {

Well, actually I would not use a pointer at all but instead in index use
it as an array.

day_ptr_type day_ptr = *month_ptr;
int month_num = (month_ptr - calendar + num_months) - num_months;

<snip>

This looks horrible complex for a simple problem. Having num_months
appear twice is somewhat suggestive of a poor job.

I've not reviewed the rest.
--
Flash Gordon

[Richard Heathfield]

Ron Ford said:

<snip>

I use Dev-Cpp for quick and dirty C stuff and simply could not find a
means, from within the IDE, to pause a program before windows eats it up.

If you're running a console-style program, it makes sense to run it from a
console.

I ended up putting in a dos-shortcut where the executable lives, and that
works, but it misses the whole point of staying within an IDE during
development and testing.:-(

The whole point being... what, exactly?

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Ben Bacarisse]

Bob Nelson <bn*****@nelsonbe.comwrites:

After completing KNK2, my interest in C was reignited, prompting a
re-reading of Traister's dubious book on pointers. Then I dusted off
the fine ``C Traps and Pitfalls'' by Andy Koenig. Nowadays I primarily
work in PHP, Perl and C++. Consequently my C skills have atrophied.

So inspired by CT&P's ``calendar'' example on page 30, I decided to
brush up on some elementary C (although Koenig describes it as walking
``out on the ice'') with the little toy exercise below.

I don't know what KNK2 nor CT&P are, but I don't think that matters...

<snip>

So look this over being brutal and merciless with your critique as I
try to rebuild my flabby C muscles:

#include <assert.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

enum { MONTHS = 12, DAYS = 31 };
enum { JAN, FEB, MAR, APR, MAY, JUN, JUL, AUG, SEP, OCT, NOV, DEC };
static const char *const months[] = { "JAN", "FEB", "MAR", "APR",
"MAY", "JUN", "JUL", "AUG",
"SEP", "OCT", "NOV", "DEC", };

int main(void)
{
typedef int month_type[DAYS];

Some people object to typedefs (external declarations) inside
functions. I don't, but you may find people who do.

Array types are odd and although you use them correctly, some people
will consider it obfuscation to have them at all.

typedef month_type *month_ptr_type;

Pointers to array types are even rarer. I don't think it makes
anything clearer in this program.

typedef int *day_ptr_type;

And finally, there is a school of thought that says the pointerlyness
of type (that it is a pointer) should not be hidden inside a typedef
unless you are making an opaque handle type. You are not, and I think
you've obscured things a little with all these typedefs. Note how you
feel you want to name the type with _ptr_ so you don't get lost. Much
better to let the * in the declaration do that for you.

For example, if you do need to have the pointed-to type named, try
this:

typedef int day_type;

and simply declare your variables:

day_type *dp;

but even that is overkill here, I feel.

int calendar[MONTHS][DAYS];

Having done all of the above, why not

month_type calendar[MONTHS];

If you've gone the effort of having an array type, why not use it?

month_ptr_type month_ptr;
size_t num_months;
size_t num_days_per_month;

memset(calendar, 0, sizeof calendar);
assert(calendar[DEC][DAYS - 1] == 0);

month_ptr = calendar;
assert(sizeof *month_ptr == DAYS * sizeof(int));

num_months = sizeof calendar / sizeof *calendar;
assert(num_months == MONTHS);

num_days_per_month = sizeof *calendar / sizeof **calendar;
assert(num_days_per_month == DAYS);

for(; month_ptr < calendar + num_months; ++month_ptr) {
day_ptr_type day_ptr = *month_ptr;
int month_num = (month_ptr - calendar + num_months) - num_months;

Why not: 'int month_num = month_ptr - calendar;'?

int days_in_month;
int day_num;

switch(month_num) {
case FEB:
days_in_month = 28;
break;
case APR:
case JUN:
case SEP:
case NOV:
days_in_month = 30;
break;
default:
days_in_month = 31;
break;
}

I'd do this with an array rather than a switch.

for(day_num = 1; day_num <= days_in_month; ++day_num, ++day_ptr)
*day_ptr = day_num;

Slightly more idiomatic might be:

for(day_num = 0; day_num < days_in_month; ++day_num)
*day_ptr++ = day_num + 1;

}

for(month_ptr = calendar; month_ptr < calendar + num_months; ++month_ptr) {
int month_num = (month_ptr - calendar + num_months) - num_months;

see above.

int total_days_in_month = -1;
day_ptr_type day_ptr;

for(day_ptr = *month_ptr + num_days_per_month - 1;
day_ptr *month_ptr; --day_ptr) {
if(*day_ptr) {
total_days_in_month = *day_ptr;
break;
}
}

printf("month %d (%s) has %d days\n",
month_num + 1, months[month_num], total_days_in_month);
}

return EXIT_SUCCESS;
}

Overall I am a little baffled. What is all the array setting for? Is
this part of a larger program that will do more? If I wanted the
output that you get, I'd just write:

#include <stdio.h>
#include <stdlib.h>

enum { MONTHS = 12, DAYS = 31 };
enum { JAN, FEB, MAR, APR, MAY, JUN, JUL, AUG, SEP, OCT, NOV, DEC };

static const char *const months[] = {
"JAN", "FEB", "MAR", "APR", "MAY", "JUN",
"JUL", "AUG", "SEP", "OCT", "NOV", "DEC"
};

static const int month_len[] = {
31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31
};

int main(void)
{
int month_num;
for (month_num = 0; month_num < MONTHS; month_num++)
printf("month %d (%s) has %d days\n",
month_num + 1, months[month_num], month_len[month_num]);
return EXIT_SUCCESS;
}

but I am sure that misses the point of your code.

--
Ben.

[Bartc]

"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:Qd******************************@bt.com...

Ron Ford said:

<snip>

>I use Dev-Cpp for quick and dirty C stuff and simply could not find a
means, from within the IDE, to pause a program before windows eats it up.

If you're running a console-style program, it makes sense to run it from a
console.

Yes, once it's finished. At that point you don't want the pause anymore.

>

>I ended up putting in a dos-shortcut where the executable lives, and that
works, but it misses the whole point of staying within an IDE during
development and testing.:-(

The whole point being... what, exactly?

The point being that it's supposed to be Integrated.

-- bartc

[Richard Heathfield]

Bartc said:

>
"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:Qd******************************@bt.com...

>Ron Ford said:

<snip>

>>

>>I ended up putting in a dos-shortcut where the executable lives, and
that works, but it misses the whole point of staying within an IDE
during development and testing.:-(

The whole point being... what, exactly?

The point being that it's supposed to be Integrated.

I guess we all have different ways of working. My way involves a lot of
xterm sessions. They all appear on the same screen, so I guess you could
call them integrated. No getchar call required, though.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[gw7rib]

On 7 Jun, 08:08, Bob Nelson <[e-mail]:

So look this over being brutal and merciless with your critique as I
try to rebuild my flabby C muscles:

I haven't read the whole thing, but this line caught my eye:

enum { JAN, FEB, MAR, APR, MAY, JUN, JUL, AUG, SEP, OCT, NOV, DEC };

This will make JAN equal to zero, FEB one, etc. To my mind this is a
problem in the making. Someone somewhere will decide not to use your
enums and will plug in a month number directly - for example, 4 for
April. Which your program will instead take as being May. So the
program will give strange results, and the other person won't know
why.

Hope that is of some help.
Paul.

[Flash Gordon]

gw****@aol.com wrote, On 07/06/08 17:42:

On 7 Jun, 08:08, Bob Nelson <[e-mail]:

>So look this over being brutal and merciless with your critique as I
try to rebuild my flabby C muscles:

I haven't read the whole thing, but this line caught my eye:

>enum { JAN, FEB, MAR, APR, MAY, JUN, JUL, AUG, SEP, OCT, NOV, DEC };

This will make JAN equal to zero, FEB one, etc. To my mind this is a
problem in the making. Someone somewhere will decide not to use your
enums and will plug in a month number directly - for example, 4 for
April. Which your program will instead take as being May. So the
program will give strange results, and the other person won't know
why.

A C programmer of any real experience who assumes that something is
numbered from 1 is a fool because in C numbering is commonly done from 0.
--
Flash Gordon

[Bartc]

"Flash Gordon" <sp**@flash-gordon.me.ukwrote in message
news:b0************@news.flash-gordon.me.uk...

gw****@aol.com wrote, On 07/06/08 17:42:

>On 7 Jun, 08:08, Bob Nelson <[e-mail]:

>>So look this over being brutal and merciless with your critique as I
try to rebuild my flabby C muscles:

I haven't read the whole thing, but this line caught my eye:

>>enum { JAN, FEB, MAR, APR, MAY, JUN, JUL, AUG, SEP, OCT, NOV, DEC };

This will make JAN equal to zero, FEB one, etc. To my mind this is a
problem in the making. Someone somewhere will decide not to use your
enums and will plug in a month number directly - for example, 4 for
April. Which your program will instead take as being May. So the
program will give strange results, and the other person won't know
why.

A C programmer of any real experience who assumes that something is
numbered from 1 is a fool because in C numbering is commonly done from 0.

If certain sequences already have a natural or well-known numbering, like
the months of the year, then it makes sense to use that same ordering.

See K&R2, p111, where they've done just that.

--
Bartc

[soscpd]

Hello Ron, List

Try that:

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char *argv[])
{

system("PAUSE");
return 0;
}

Regards
Rafael

[Richard Tobin]

In article <ec**********************************@k30g2000hse. googlegroups.com>,
<gw****@aol.comwrote:

>enum { JAN, FEB, MAR, APR, MAY, JUN, JUL, AUG, SEP, OCT, NOV, DEC };

>This will make JAN equal to zero, FEB one, etc. To my mind this is a
problem in the making. Someone somewhere will decide not to use your
enums and will plug in a month number directly - for example, 4 for
April.

They're going to be awfully disappointed with the standard struct tm
then, because its tm_mon has 0 for January.

-- Richard

--
In the selection of the two characters immediately succeeding the numeral 9,
consideration shall be given to their replacement by the graphics 10 and 11 to
facilitate the adoption of the code in the sterling monetary area. (X3.4-1963)

[Flash Gordon]

Bartc wrote, On 07/06/08 20:25:

"Flash Gordon" <sp**@flash-gordon.me.ukwrote in message
news:b0************@news.flash-gordon.me.uk...

>gw****@aol.com wrote, On 07/06/08 17:42:

>>On 7 Jun, 08:08, Bob Nelson <[e-mail]:
So look this over being brutal and merciless with your critique as I
try to rebuild my flabby C muscles:
I haven't read the whole thing, but this line caught my eye:

enum { JAN, FEB, MAR, APR, MAY, JUN, JUL, AUG, SEP, OCT, NOV, DEC };
This will make JAN equal to zero, FEB one, etc. To my mind this is a
problem in the making. Someone somewhere will decide not to use your
enums and will plug in a month number directly - for example, 4 for
April. Which your program will instead take as being May. So the
program will give strange results, and the other person won't know
why.

A C programmer of any real experience who assumes that something is
numbered from 1 is a fool because in C numbering is commonly done from 0.

If certain sequences already have a natural or well-known numbering, like
the months of the year, then it makes sense to use that same ordering.

It is foolish to assume it. For example, the tm_mon field in struct tm
has the months numbered 0 to 11 according to the C standard.

See K&R2, p111, where they've done just that.

I did not say it was foolish to number months from 1, I said it is
foolish to assume they are numbered from 1.
--
Flash Gordon

[Bob Nelson]

Ben Bacarisse wrote:

Bob Nelson <bn*****@nelsonbe.comwrites:

>After completing KNK2, my interest in C was reignited, prompting a
re-reading of Traister's dubious book on pointers. Then I dusted off
the fine ``C Traps and Pitfalls'' by Andy Koenig. Nowadays I primarily
work in PHP, Perl and C++. Consequently my C skills have atrophied.

So inspired by CT&P's ``calendar'' example on page 30, I decided to
brush up on some elementary C (although Koenig describes it as walking
``out on the ice'') with the little toy exercise below.

I don't know what KNK2 nor CT&P are, but I don't think that matters...

Actually the ``CT&P'' reference should be self-evident from the above since
the book ``C Traps and Pitfalls'' is mentioned in the preceding paragraph.
As for ``KNK2'', the author K.N. King (``C Programming: A Modern
Approach'') maybe hasn't yet gotten to the point of being as readily
recognized as ``K&R2'', ``C&V'', ``UB'', ``dmr'' and other abbreviations
accepted here in c.l.c. Note that ``u'' was NOT included in that list. :-)

For the sake of brevity, I'll elide the most of the C gymnastics I posted
and thank you for the thoughtful review, particularly the following point:

>int main(void)
{
typedef int month_type[DAYS];

Some people object to typedefs (external declarations) inside
functions. I don't, but you may find people who do.

Array types are odd and although you use them correctly, some people
will consider it obfuscation to have them at all.

> typedef month_type *month_ptr_type;

Pointers to array types are even rarer. I don't think it makes
anything clearer in this program.

In 20/20 hindsight, the excessive use of typedefs was muddleheaded on my
part. They only serve to hide the pointer variables and don't contribute to
clarity. Without mentioning the name of the other language popular down the
hall, some of its standard template library is arguably obfuscated by
liberal use of typedefs.

Overall I am a little baffled. What is all the array setting for? Is
this part of a larger program that will do more?

The sole purpose was a somewhat self-indulgent re-exploration of pointers
based upon re-reading Andy Koenig's ``C Traps and Pitfalls''. (See page 30
of the book for the basis of what I posted). It was an exercise for the
sake of exercise and dusting off some cobwebs in what Koenig describes as a
``dark corner'' of the language. Unlike a decade ago when I was using C
everyday, the bulk of my work is now in Perl, C++, PHP, Java and other
languages where pointers either don't exist, are discouraged or hidden
behind layers of abstraction, the code I posted was merely a tour de force
of using pointers everywhere I could in the context of a trivial toy.

What it lacked in elegant simplicity, it more than made up for in its
overbearing circuitousness.

[Bob Nelson]

Ron Ford wrote:

On Sat, 07 Jun 2008 02:08:07 -0500, Bob Nelson wrote:

[code elided]
0 warnings, 0 errors.

On my machine the output doesn't last long enough to read. Add a
getchar() call somewhere:

>>
printf("month %d (%s) has %d days\n",
month_num + 1, months[month_num],
total_days_in_month);

getchar();
[...]

Although I appreciate you looking at the code I posted, Ron, I'll join some
of the others in disagreeing with your addition of ``getchar()''. If the
output were redirected to a file, the program would appear to hang as it
waits for user input.

There's a C compiler under Windows that requires a keypress when it displays
its options, page by page. My personal preference is that a program should
just emit all of its output at once and not require user interaction. It's
somewhat invasive of a non-interactive program to add ``getchar()''. In
Pittsburgh, PA, the term would that would be ``nebby''. Perhaps they teach
that Western Pennsylvania jargon to the CS students at Carnegie-Mellon. I'm
not sure that ``nebby'' will ever become as widespread as ``nasal daemon''
here in the culture of c.l.c. but I think a good rule of thumb is to avoid
``nebbines'' (and that's also applicable to ``Are you sure?'' prompting,
IMHO).

[Richard Heathfield]

soscpd said:

>
Hello Ron, List

Try that:

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char *argv[])
{

system("PAUSE");
return 0;
}

Thank you, soscpd. I tried your advice, but I seem to be having some
difficulty with it. When I ran your program, I got the output:

sh: PAUSE: command not found

and the program didn't wait for me to press any keys.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[soscpd]

Hello Little Richard, List

You welcome! :)

On Jun 8, 1:24*am, Richard Heathfield <[e-mail]:

Hello Ron, List

sh: PAUSE: command not found
and the program didn't wait for me to press any keys.

Let's elaborate a little bit more. You know what the code pretend to
do, but the code doesn't work in your environment and you don't know
why. Is that correct? What is your environment exactly? Don't you have
this problem solved, as say some previous post here? I remember of
something like:

I guess we all have different ways of working. My way involves a lot of
xterm sessions. They all appear on the same screen, so I guess you could
call them integrated. No getchar call required, though.

Hey... that is not bad. But I am not usual to graphics on my posix
based SO's. If I need something with graphics, there is always
framebuffer on my box. Stable enough to my needs. No xterm / getchar /
system("read -p \"$*\""); call required, though.

But if you think this "way of work" is a bit better then yours, and
you like to use it, I will be glad to help you (think as much as
anyone here in this group.). Just open a new thread with your
question, or mail me directly and we can figure a way to accoplish
that "upgrade".

Regards
Rafael

[pete]

soscpd wrote:

Hello Little Richard, List

You welcome! :)

On Jun 8, 1:24 am, Richard Heathfield <[e-mail]:

>>Hello Ron, List

sh: PAUSE: command not found
and the program didn't wait for me to press any keys.

Let's elaborate a little bit more. You know what the code pretend to
do, but the code doesn't work in your environment and you don't know
why. Is that correct?

No. He's being sarcastic.
He is ridiculing the notion of writing programs in such a way
so as to suit other programmers
who don't know how to keep a window open.
It's a ridiculous notion.

--
pete

[soscpd]

Hello Pete, List

On Jun 8, 9:39 am, pete <[e-mail]:

No. He's being sarcastic.

No! Really?

Com'on Pete. You can do better then that.

Regards
Rafael

[Jack Klein]

On Sat, 7 Jun 2008 04:23:44 -0500, Ron Ford <ro*@nowhere.netwrote in
comp.lang.c:

On Sat, 07 Jun 2008 08:42:01 +0000, Richard Heathfield wrote:

Ron Ford said:

On Sat, 07 Jun 2008 02:08:07 -0500, Bob Nelson wrote:

[code elided]
0 warnings, 0 errors.

On my machine the output doesn't last long enough to read. Add a
getchar() call somewhere:

Why should he do that? Learn how to drive a command shell.

I use Dev-Cpp for quick and dirty C stuff and simply could not find a
means, from within the IDE, to pause a program before windows eats it up.
I ended up putting in a dos-shortcut where the executable lives, and that
works, but it misses the whole point of staying within an IDE during
development and testing.:-(

Having an IDE whose behavior is not what you want misses the whole
point of using an IDE.

Suggesting that someone artificially modify their code for your
convenience in using in IDE that has, in your opinion, deficient
behavior, is rather selfish, don't you think?

There are other completely free IDEs that provide the behavior you
prefer, including Microsoft's Visual Studio 2008 Express.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

[Keith Thompson]

soscpd <so****@gmail.comwrites:

Hello Pete, List

On Jun 8, 9:39 am, pete <[e-mail]:

>No. He's being sarcastic.

No! Really?

Com'on Pete. You can do better then that.

Sarcasm is difficult to convey in a text-only medium like this one.

The fact that Richard was being sarcastic was obvious to anyone who's
been reading this newsgroup for any length of time, and therefore
knows that Richard knows perfectly well why system("PAUSE") doesn't
work on his system.

You, on the other hand, don't (yet?) have enough of a track record
here for us to assume that you really know what you were pretending
not to know. We've seen plenty of posters here who are genuinely as
naive as you were pretending to be.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[soscpd]

Hello List

What about we knock it off? I was just trying to tip some guy with a
blink console issue.

By the way, I totally agree with Jack Klein.

Regards
Rafael

[Ron Ford]

On Sat, 07 Jun 2008 12:08:02 +0000, Richard Heathfield wrote:

Bartc said:

>>
"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:Qd******************************@bt.com...

>>Ron Ford said:

<snip>

>>>
I ended up putting in a dos-shortcut where the executable lives, and
that works, but it misses the whole point of staying within an IDE
during development and testing.:-(

The whole point being... what, exactly?

The point being that it's supposed to be Integrated.

I guess we all have different ways of working. My way involves a lot of
xterm sessions. They all appear on the same screen, so I guess you could
call them integrated. No getchar call required, though.

I like to use an IDE for toy programs and snippets off the net, in
particular because they have a visual debugger. The IDe's I use for other
syntaxes don't have this issue. If it's a larger project or has fancy
linking needs, I find the gnu compiler collection to be the best way to go.
Putting a dos shortcut where your source files are is a huge time-saver.
Also an explorer shortcut on the desktop to where your source files live is
a keystroke saver.

I just unpacked two sun discs, so my indenture to windows may come to an
end. They have C99 right out of the box. If I stick with windows, at
least on one partition, I'll download VS 8 Express.

Heck, I thought I was giving reasonable advice to avoid something more
system specific like system "pause."
--
The penalty for laughing in a courtroom is six months in jail; if it were
not for this penalty, the jury would never hear the evidence.
H. L. Mencken

[Richard Heathfield]

Ron Ford said:

<snip>

Heck, I thought I was giving reasonable advice to avoid something more
system specific like system "pause."

I agree that getchar is an improvement over system("pause"), but omitting
the getchar completely is an even bigger improvement. The trick is to
educate the programmer about ensuring that the execution environment is
appropriate to the program being executed. For a GUI program, that's a GUI
environment. For a console-style program, a console is more appropriate.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Nick Keighley]

On 8 Jun, 03:53, Bob Nelson <[e-mail]:

<snip>

[...] My personal preference is that a program should
just emit all of its output at once and not require user interaction. It's
somewhat invasive of a non-interactive program to add ``getchar()''. In
Pittsburgh, PA, the term would that would be ``nebby''. Perhaps they teach
that Western Pennsylvania jargon to the CS students at Carnegie-Mellon. I'm
not sure that ``nebby'' will ever become as widespread as ``nasal daemon''
here in the culture of c.l.c. but I think a good rule of thumb is to avoid
``nebbines'' (and that's also applicable to ``Are you sure?'' prompting,

"nebby": of or pertaining to the stiff bit on the front of a
gentleman's cap?

--
Nick Keighley

[Bob Nelson]

Nick Keighley wrote:

On 8 Jun, 03:53, Bob Nelson <[e-mail]:

<snip>

>[...] My personal preference is that a program should
just emit all of its output at once and not require user interaction.
It's somewhat invasive of a non-interactive program to add ``getchar()''.
In Pittsburgh, PA, the term would that would be ``nebby''. Perhaps they
teach that Western Pennsylvania jargon to the CS students at
Carnegie-Mellon. I'm not sure that ``nebby'' will ever become as
widespread as ``nasal daemon'' here in the culture of c.l.c. but I think
a good rule of thumb is to avoid ``nebbines'' (and that's also applicable
to ``Are you sure?'' prompting,

"nebby": of or pertaining to the stiff bit on the front of a
gentleman's cap?

From http://pittsburghese.com/glossary.ep...ype=adjectives
Nebby: Nosy or curious. Dat nebby lady asks too many questions.

[lawrence.jones]

Nick Keighley <ni******************@hotmail.comwrote:

>
"nebby": of or pertaining to the stiff bit on the front of a
gentleman's cap?

No, the older meaning: of or pertaining to the nose; i.e., nosy,
sticking ones nose into other people's business or other places it
doesn't belong. A nebby person is also known pleonastically as a
nebnose or nebbynose.

-- Larry Jones

The living dead don't NEED to solve word problems. -- Calvin