Time to ask?

[Keith Thompson]

The poster responsible will know...but thanks, I will in future (and in
present as you can see

The poster responsible may or may not know, as Richard just posted.
But in any case, you're posting to a newsgroup, not just to the author
of the article to which you're following up.

And thanks for providing context.

 

[Andrew Poelstra]

Sorry Andrew, is this because some newreaders cannot view previous
messages?

Yep. For example, my reader discards messages once I've read them and exited
the program. It would take far too much effort to grab past messages, and
in all likelihood my ISP has deleted any old messages from its server.

 

[mdh]

mdh said:

Your program periodically requires input. How are you supplying this input?

There is a standard input available during debugging. One of the poster
earlier mentioned that ungetch() is a named function in C. It turns out
that Xcode objected to the use of a "modified" version of ungetch(). On
changing the function name to my_ungetch() it no longer hangs during
debugging. Not sure why it does work when compiled normally(using
ungetch only), but in any case, that seems to be the explanation for
the hanging.

 

[Richard Heathfield]

mdh said:

There is a standard input available during debugging. One of the poster
earlier mentioned that ungetch() is a named function in C.

In fact it is not a standard C function.

It turns out
that Xcode objected to the use of a "modified" version of ungetch().

Compilers are not permitted, when invoked in conforming mode, to use the
name ungetch(). It is possible that you did not invoke the compiler in
conforming mode.

 

[mdh]

Compilers are not permitted, when invoked in conforming mode, to use
the

name ungetch(). It is possible that you did not invoke the compiler in
conforming mode.

Sorry, am not familiar with the notion of "conforming mode". Will look
it up, thanks.

 

[Keith Thompson]

Sorry, am not familiar with the notion of "conforming mode". Will look
it up, thanks.

(The quoting level was messed up; I think I've corrected it.)

Compilers commonly have options (command-line or otherwise) that make
them behave differently. A compiler will typically have a set of
options that cause it to behave as a conforming C compiler; other sets
of options may enable extensions that, while perhaps useful, can break
conforming code.

"ungetch" happens to be the name of a non-standard function provide by
the curses or ncurses library, but as far as the C standard is
concerned, it's just another identifier. A conforming C compiler must
allow you to define "ungetch" for yourself in any way you like, as
long as you don't have a #include for some non-standard header that
defines it. A compiler that gives you trouble because you've used
that identifier is not conforming. There *should* be a way to tell
the compiler to behave in a conforming manner; it may or may not be
the default.

On the other hand, avoiding such identifiers isn't a bad idea. If you
define your own ungetch() function, and later decide to have your
program use the curses library, you're going to have problems. But
nobody can reasonably be expected to keep track of all the identifiers
declared by every third-party library in existence, and the C standard
is defined in such a way that you don't have to.

<OT>
Something like C++'s namespaces would make this easier. Rather than
ungetch(), curses could define curses::ungetch(), and your own
my_library::ungetch() wouldn't conflict with it. You'd just have to
ensure that each namespace has a unique name, not each identifier in
every library. A common workaround in C is to use a common prefix as
part of each identifier, but that can get very ugly very quickly.
</OT>

 

[Tom Plunket]

Do me a favor please. Correct me when I'm wrong. Otherwise read for
enlightenment.

Heh, sweeter words have never been uttered.

The declaration and definition of a function named getch() in a
program is NOT an implementation of it. Really.

Actually, it is.

The implementation is the compiler suite for your...

Actually, the implementation of anything is not your compiler. Your
compiler takes the code implemented by you and by your compiler vendor
and (hopefully) makes a software program which can be executed on the
target platform.

So yeah, read and learn.

-tom!

 

[Tom Plunket]

Yes...I agree....I have had this situation before where it compiles and
runs fine, but when I step through it, it hangs...as here.

Maybe it's not hanging, but rather waiting for user input?
-tom!

 

[Mark McIntyre]

Actually, it is.

Actually, I agree. AN implementation of getch() was provided.

Actually, the implementation of anything is not your compiler.

In the context of ISO C it is. The key word is "the".

Your compiler takes the code implemented by you

Thats not the definition of "the implementation" that the C standard,
and by extension people round here, use.

The Implementation is the environment in which you convert your code
into some sort of excutable product. You, the programmer, may not mess
with it, nor wander into its namespace, etc.

So yeah, read and learn.

indeed.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Joe Wright]

Yes, I think you're wrong.

"getch" is just another identifier. There is nothing by that name in
the standard library, and it's in the user namespace. If I declare
and define a function called getch(), that's just as much an
implementation of getch() as a declaration and definition of foobar()
is an implementation of foobar() -- and I can make my getch() function
do whatever I like.

It happens that there are are functions named "getch" in other
libraries, the curses/ncurses library and MS Windows (and they're
incompatible with each other). Because of that, I would probably
avoid using that identifier in my own code -- but there's nothing in
the C standard that forbids it, or even discourages it. If an
implementation prevents me from declaring my own getch() when I
haven't #included any system-specific header that declares it, then
that implementation is non-conforming.

Why wrong? I didn't say you couldn't declare and define you own getch().
Of course you can and your getch() can do anything you like, maybe
generate a list of local churches. Anything.

I meant to say the function getch() that we know and love from conio.h,
ncurses and friends can't be successfully written in terms of getchar().
Further I meant to take issue with 'implementation'.

I do regret the tone of my post. The 'read for enlightenment' was a
little over the top. Sorry all.

 

[Keith Thompson]

Why wrong? I didn't say you couldn't declare and define you own
getch(). Of course you can and your getch() can do anything you like,
maybe generate a list of local churches. Anything.

I meant to say the function getch() that we know and love from
conio.h, ncurses and friends can't be successfully written in terms of
getchar(). Further I meant to take issue with 'implementation'.

I do regret the tone of my post. The 'read for enlightenment' was a
little over the top. Sorry all.

But as far as the C standard is concerned, there is absolutely nothing
special about either the getch() function declared in conio.h, or the
getch() function defined by ncurses (which, it's important to realize,
are two different functions).

You could just as easily argue that the declaration of getch() in
ncurses.h, and its implementation in whatever C source file implements
it, don't constitute an "implementation" of getch().

"getch" is just another identifier, and neither ncurses or conio has
any more claim on it than your or I do.

I understand that you didn't mean to make the claim that you appeared
to be making (though we can only judge your statements by what you
actually write) -- but now you seem to be making that claim anyway.

 

[Joe Wright]

I believe I did

No. We lowly programmers can declare and define what we like but we are
not the 'implementor' of our implementation. getch() is implemented or
not on your system. You (programmer) may ignore it, re-declare it and
re-define it. You cannot implement it.

I know this sounds awfully pedantic but words are things. I regret the
'read for enlightenment' bit is my other post.

 

[Keith Thompson]

No. We lowly programmers can declare and define what we like but we
are not the 'implementor' of our implementation. getch() is
implemented or not on your system. You (programmer) may ignore it,
re-declare it and re-define it. You cannot implement it.

I know this sounds awfully pedantic but words are things. I regret the
'read for enlightenment' bit is my other post.

I think the source of all this confusion is the word "implementation".

The standard defines the term "implementation" as follows (C99 3.12):

implementation

particular set of software, running in a particular translation
environment under particular control options, that performs
translation of programs for, and supports execution of functions
in, a particular execution environment

I see your point, but I would argue that this refers to an
implementation *of C*. If I write a function called "foobar", I have
an implementation of foobar, though it's not necessarily part of any
implementation of C.

 

[Joe Wright]

But as far as the C standard is concerned, there is absolutely nothing
special about either the getch() function declared in conio.h, or the
getch() function defined by ncurses (which, it's important to realize,
are two different functions).

You could just as easily argue that the declaration of getch() in
ncurses.h, and its implementation in whatever C source file implements
it, don't constitute an "implementation" of getch().

"getch" is just another identifier, and neither ncurses or conio has
any more claim on it than your or I do.

I understand that you didn't mean to make the claim that you appeared
to be making (though we can only judge your statements by what you
actually write) -- but now you seem to be making that claim anyway.

Making *what* claim anyway? I had really only two points, that getch(),
to the extent it might return something for each keypress and not echo
it, cannot be written in terms of getchar(). Do you disagree?

Second, when we programmers determine to add functionality to our
environments by declaring and defining new stuff in the form of
functions or whatever, our magic and wonderful additions do not
contribute to the implementation of C on our system.

My C implementation is by the FSF called GCC and further implemented for
DOS by DJ Delorie and called DJGPP. DJ is the implementor. Not you, not
me and not CBF. :=)

I can't imagine with what of this you can find fault. But I'll wait.

 

[Joe Wright]

I think the source of all this confusion is the word "implementation".

The standard defines the term "implementation" as follows (C99 3.12):

implementation

particular set of software, running in a particular translation
environment under particular control options, that performs
translation of programs for, and supports execution of functions
in, a particular execution environment

I see your point, but I would argue that this refers to an
implementation *of C*. If I write a function called "foobar", I have
an implementation of foobar, though it's not necessarily part of any
implementation of C.

Precisely my desired point. Thank you.

 

[Keith Thompson]

Making *what* claim anyway? I had really only two points, that
getch(), to the extent it might return something for each keypress and
not echo it, cannot be written in terms of getchar(). Do you disagree?

Not at all.

Second, when we programmers determine to add functionality to our
environments by declaring and defining new stuff in the form of
functions or whatever, our magic and wonderful additions do not
contribute to the implementation of C on our system.

Not to the implementation *of C*.

My C implementation is by the FSF called GCC and further implemented
for DOS by DJ Delorie and called DJGPP. DJ is the implementor. Not
you, not me and not CBF. :=)

I can't imagine with what of this you can find fault. But I'll wait.

I had two points.

1. There's nothing special about the identifier "getch". The question
of whether your own declaration and definition of a function by that
name has nothing to do with the fact that somebody else happens to
have a function by the same name. (And again, the conio getch() and
the curses getch() are two different functions that merely happen to
have the same name and behave similarly in some ways.)

2. In my opinion, it's perfectly reasonable to say that a declaration
and definition of a function constitute an "implementation" of that
function, using the term "implementation" in its ordinary English
sense. This is not meant to imply that it's part of the C
"implementation" (and neither is conio or curses). It's true that the
C standard provides a definition of the term "implementation" (I
didn't realize that when this discussion started), so we should be
careful about how we use the term. IMHO, referring to the
implementation of a function doesn't conflict with the standard's use
of term, which refers to an implementation of the C language, but
YMMV.

(conio and curses could be considered to be part of the implementation
in the sense that they're extensions -- but then who's to say that my
own "foobar" function isn't an extension as well? An implementation
is commonly provided by more than one vendor or other source.)

 

[Richard Heathfield]

Joe Wright said:

No. We lowly programmers can declare and define what we like but we are
not the 'implementor' of our implementation. getch() is implemented or
not on your system. You (programmer) may ignore it, re-declare it and
re-define it. You cannot implement it.

Sure I can. Here we go:

double getch(const char *s)
{
double ch = 0.0;
size_t len = strlen(s);
size_t n = len;
while(n--)
{
ch += *s++;
}
if(len)
{
ch /= len;
}
return ch;
}

Voila! Un implementation du getch. Merci et bon nuit.

I know this sounds awfully pedantic but words are things.

According to one on-line dictionary, the word (in its verb sense) means "to
provide instruments or means of expression for". And a function definition
is pretty much a means of expression. I don't see what your objection is.
What do /you/ think "to implement" means?

I regret the 'read for enlightenment' bit is my other post.

Mmm. Quite so.

 

[av]

(The quoting level was messed up; I think I've corrected it.)

Compilers commonly have options (command-line or otherwise) that make
them behave differently. A compiler will typically have a set of
options that cause it to behave as a conforming C compiler; other sets
of options may enable extensions that, while perhaps useful, can break
conforming code.

"ungetch" happens to be the name of a non-standard function provide by
the curses or ncurses library, but as far as the C standard is
concerned, it's just another identifier. A conforming C compiler must
allow you to define "ungetch" for yourself in any way you like, as
long as you don't have a #include for some non-standard header that
defines it. A compiler that gives you trouble because you've used
that identifier is not conforming. There *should* be a way to tell
the compiler to behave in a conforming manner; it may or may not be
the default.

On the other hand, avoiding such identifiers isn't a bad idea. If you
define your own ungetch() function, and later decide to have your
program use the curses library, you're going to have problems.

why? the compiler/linker should find there is a call to a name that
has 2 different address and so don't link and not have the executable
so i have to change the names

But
nobody can reasonably be expected to keep track of all the identifiers
declared by every third-party library in existence, and the C standard
is defined in such a way that you don't have to.

<OT>
Something like C++'s namespaces would make this easier. Rather than
ungetch(), curses could define curses::ungetch(), and your own
my_library::ungetch() wouldn't conflict with it. You'd just have to
ensure that each namespace has a unique name, not each identifier in
every library. A common workaround in C is to use a common prefix as
part of each identifier, but that can get very ugly very quickly.

this is good in the objects by classes too
X c;
c.name(); c.d="f"; etc

 

[Keith Thompson]

why? the compiler/linker should find there is a call to a name that
has 2 different address and so don't link and not have the executable
so i have to change the names

I'd say that qualifies as having problems.

 

[Flash Gordon]

I'd say that qualifies as having problems.

It's also not guaranteed to happen. On various implementations,
depending on the precisely how you build your program, it could link
without warning or error and then call one or the other function
depending on the order things were specified and even depending on your
environment settings when you run the program. This is one of the ways
in which debugging malloc packages are written and used. I would say
that is potentially having major problems.

Also, if you included a non-standard header that provided an
implementation of ungetch as a macro (something that sounds sensible to
me) in one of your files that was intended to use your ungetch, it would
expand the macro instead of calling your ungetch which could lead to all
sorts of interesting problems.