cusor position in display output
Kevin Pulford
a DOS environment. It is actually being written as a Win32 console
application. I have figured out or found reference to everything but the
screen output.
I want to display several lines of text form my program to the current
display. I have used printf(), and cout << but they just dump to the
current cursor location.
How can I display the text strings to the display at, for example 12 rows
down and 10 colums out into the screen?
I have ben searching on cursor position, but I keep coming up with windows
objects, and references to cursor (pointer icons).
Any help would be greatly appreciated.
Thanks
Kevin
Jack Klein
<kpul...@earthlink.net> wrote in comp.lang.c:
> I am trying to write a very simple program in Visual C++ IDE, but to run in
> a DOS environment. It is actually being written as a Win32 console
> application. I have figured out or found reference to everything but the
> screen output.
Actually you are doomed before you start. Your Visual C++ will indeed
produce Win32 console applications, but they will not run at all in
MS-DOS. Your compiler does not produce executables that run in an
MS-DOS environment. Period. No matter how much you want it to.
> I want to display several lines of text form my program to the current
> display. I have used printf(), and cout << but they just dump to the
> current cursor location.
Neither C nor (off-topic in this group) C++ display anything, nor do
they have any sort of cursor location. All input and output in both
languages is abstracted to streams. Neither language requires or
supports a video display.
> How can I display the text strings to the display at, for example 12 rows
> down and 10 colums out into the screen?
>
> I have ben searching on cursor position, but I keep coming up with windows
> objects, and references to cursor (pointer icons).
>
> Any help would be greatly appreciated.
>
> Thanks
>
> Kevin
It is always a good idea to see if a newsgroup has a FAQ, and read if
before posting. This newsgroup does, and there is a link to it in my
signature.
You particularly want to read this question:
19.4 How can I clear the screen, or print things in inverse video, or
move the cursor? at http://www.eskimo.com/~scs/C-faq/q19.4.html.
Further questions about Win32 specific non-standard extensions to
support such things belong in a Windows programming newsgroup, most
likely one in the news:microsoft.public.vc.* family. They can also
explain the difference between a Win32 console application and an
MS-DOS application, because there is no correspondence between the
two.
But if you really want to make MS-DOS programs, you are going to need
a different compiler to do so with.
--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq
Richard Heathfield
Inadvertently, you have stumbled across a couple of issues that you
probably didn't know existed and that you probably wished didn't exist.
The first issue is this: C is a portable language, and one way that it
achieves this is simply /not/ to provide support for non-portable
aspects of computing, of which hardware is the most obvious example.
Some computer systems don't even supply a screen, and those that /do/
supply screens have wildly differing ways of dealing with them.
Consequently, C leaves screen issues to individual implementations -
those that choose to do so can provide support for screens, and those
that choose not to don't have to. So right away we have the problem that
the answer to your question is /very/ system-dependent.
The second issue is that you say you're targetting DOS (and I assume you
mean MS-DOS), but you're using Visual C++. Now, up until version 1.52 or
so, Visual C++ did indeed facilitate the building of DOS programs. Since
then, however, it has not done so. What it /does/ support is something
it calls "console applications". I suspect this is what you really mean,
but I can't be sure.
If you are using Visual C++ 1.52 or prior, there's a function called
something like _settextcursorposition() which you can use to do what you
want, and the Help system should help you track it down. Or you could
use ANSI.SYS drivers, if you know your target system will have ANSI.SYS
loaded (which it may not). Or you could use a BIOS call:
#include <dos.h> /* warning - non-standard header! */
void SetCursorPosition(int x, int y, int page)
{
union REGS inregs, outregs; /* warning - non-standard union! */
inregs.h.ah = 2;
inregs.h.bh = page; /* probably you want 0 - most people do */
inregs.h.dh = y; /* 0 for top row */
inregs.h.dl = x; /* 0 for left column */
int86(0x10, &inregs, &outregs); /* warning - non-standard function!
*/
}
Since this is off-topic in comp.lang.c, ask for further help in
comp.os.msdos.programmer.
If you are using Visual C++ 2.0 or later, you have more of a problem.
For a start, you're now in a 32-bit universe, and your options are more
limited. You might still get away with ANSI.SYS drivers, if your target
system will co-operate. But you might have to use the Windows API. Under
Windows, the concept of a "console application" is supported by a number
of "console functions". Here is the console function for updating the
cursor position:
BOOL SetConsoleCursorPosition(
HANDLE hConsoleOutput, /* handle of console screen buffer */
COORD dwCursorPosition /* new cursor position coordinates */
);
As you can see, this approach takes you away from the standard stream
model of C (as, of course, do the DOS solutions, more or less), and
launches you into a world of handles and unfamiliar structures and odd
typedefs - a new model of console I/O that you have to take on board
more or less as a whole. (Search your API help for
SetConsoleCursorPosition and then spend a few minutes browsing around
the more useful-looking See Also... links, and you'll see what I mean.)
Again, this is highly off-topic in comp.lang.c so, if you need further
help in this regard, ask for it in comp.os.ms-windows.programmer.win32 -
where, I am sure, they will be delighted to educate you further.
Another possibility you might want to explore is a "portable" (-ish)
full-screen console library, such as curses, which is apparently
available for at least some of the Windows platforms. If you want more
help with curses programming, ask for it in comp.unix.programmer (which
may, in fact, re-direct you to a more suitable newsgroup - I don't know
whether there is a specific curses newsgroup, but it wouldn't surprise
me). Don't be put off by the "unix" bit - curses started on Unix (I
believe), and that's all there is to it. The advice ought to be
portable, I guess.
Whichever solution you settle for, be aware that your chosen approach
takes you away from portable C programming. Consequently, you might want
to keep this part of your program heavily modularised, to ease future
porting efforts.
Good luck with your project.
--
Richard Heathfield : bin...@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Richard Heathfield
>
> On Sun, 23 Jun 2002 17:17:52 GMT, "Kevin Pulford"
> <kpul...@earthlink.net> wrote in comp.lang.c:
>
> > I am trying to write a very simple program in Visual C++ IDE, but to run in
> > a DOS environment. It is actually being written as a Win32 console
> > application. I have figured out or found reference to everything but the
> > screen output.
>
> Actually you are doomed before you start. Your Visual C++ will indeed
> produce Win32 console applications, but they will not run at all in
> MS-DOS. Your compiler does not produce executables that run in an
> MS-DOS environment. Period. No matter how much you want it to.
In my own reply to him, I failed to notice that he said "it is actually
being written as a Win32 console application". This implies (as you
appear to have divined correctly, whereas I missed it completely) that
he is using a version of Visual C++ later than version 1.52. He should
therefore ignore the part of my reply which dealt with MS-DOS.
<snip>
Ioannis Vranos
news:3D16330A...@eton.powernet.co.uk...
> Jack Klein wrote:
> >
> > On Sun, 23 Jun 2002 17:17:52 GMT, "Kevin Pulford"
> > <kpul...@earthlink.net> wrote in comp.lang.c:
> >
> > > I am trying to write a very simple program in Visual C++ IDE,
but to run in
> > > a DOS environment. It is actually being written as a Win32
console
> > > application. I have figured out or found reference to everything
but the
> > > screen output.
> >
> > Actually you are doomed before you start. Your Visual C++ will
indeed
> > produce Win32 console applications, but they will not run at all
in
> > MS-DOS. Your compiler does not produce executables that run in an
> > MS-DOS environment. Period. No matter how much you want it to.
>
> In my own reply to him, I failed to notice that he said "it is
actually
> being written as a Win32 console application". This implies (as you
> appear to have divined correctly, whereas I missed it completely)
that
> he is using a version of Visual C++ later than version 1.52. He
should
> therefore ignore the part of my reply which dealt with MS-DOS.
:)) Who uses VC++ 1.52 nowadays anyway. When this product was
released?
--
Ioannis
* Ioannis Vranos
* Programming pages: http://www.noicys.cjb.net
* Alternative URL: http://run.to/noicys
Jack Klein
<noi...@spammers.get.lost.hotmail.com> wrote in comp.lang.c:
Actually there are quite a few people who use VC++ 1.52 these days,
for a variety of reasons. I'll restrict myself to the C usage only
for this group, of course.
It is actually an extremely good and highly optimizing C89 conforming
compiler for creating true MS-DOS programs. Despite the slavish
fascination of the masses with the latest and greatest, there is still
some use in some places for true MS-DOS programs.
Another place where this compiler is still used quite a bit is in
embedded systems using such Intel microprocessors/microcontrollers as
the 80188, 80186, and 80386EX, all of which are still in production
now.
You desk top computer chauvinists need to face the facts and look at
the numbers: of the approximately 10,000,000,000 (ten BILLION in US
terminology) CPUs sold every year these days, approximately 1% go into
the workstations, servers, lap tops, and palm size computers you think
computing is all about.
Ioannis Vranos
news:bmdchuork0u5p2b0l...@4ax.com...
>
> > :)) Who uses VC++ 1.52 nowadays anyway. When this product was
> > released?
>
> Actually there are quite a few people who use VC++ 1.52 these days,
> for a variety of reasons. I'll restrict myself to the C usage only
> for this group, of course.
>
> It is actually an extremely good and highly optimizing C89
conforming
> compiler for creating true MS-DOS programs. Despite the slavish
> fascination of the masses with the latest and greatest, there is
still
> some use in some places for true MS-DOS programs.
DJGPP, etc is better i guess.
> Another place where this compiler is still used quite a bit is in
> embedded systems using such Intel microprocessors/microcontrollers
as
> the 80188, 80186, and 80386EX, all of which are still in production
> now.
>
> You desk top computer chauvinists
:))
> need to face the facts and look at
> the numbers: of the approximately 10,000,000,000 (ten BILLION in US
> terminology) CPUs sold every year these days, approximately 1% go
into
> the workstations, servers, lap tops, and palm size computers you
think
> computing is all about.
I do not care so much about the actual numbers, but i do know that the
future is a constellation of devices working in the background. So i
do not underestimate embedded systems.
VC++ 1.52 just sounds too old i guess.
Ioannis Vranos
> > released?
>
> Actually there are quite a few people who use VC++ 1.52 these days,
> for a variety of reasons. I'll restrict myself to the C usage only
> for this group, of course.
Since it seems you like MS, i think this book is for you:
http://www.amazon.com/exec/obidos/ASIN/0312192258/deloriesoftware/104-
1595860-7799930
:)
Richard Heathfield
>
<snip>
>
> :)) Who uses VC++ 1.52 nowadays anyway.
I do. Is that all right with you?
> When this product was released?
Mid-1990s.
Mark McIntyre
>:)) Who uses VC++ 1.52 nowadays anyway. When this product was
>released?
I still have it installed on my box. Occasionally i use it for
debugging some old DOS programs I have for data transfer.,
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
Kevin Pulford
by posting a C++ question. It was really meant to be a C question, since I
am not trying to use any objects. I just happens that my compiler is a C /
C++ version 6.0 Microsoft compiler.
I will re direct my question .
Thanks
"Jack Klein" <jack...@spamcop.net> wrote in message
news:il7chughr20s388ec...@4ax.com...
Jack Klein
<noi...@spammers.get.lost.hotmail.com> wrote in comp.lang.c:
> "Jack Klein" <jack...@spamcop.net> wrote in message
> news:bmdchuork0u5p2b0l...@4ax.com...
> >
> > > :)) Who uses VC++ 1.52 nowadays anyway. When this product was
> > > released?
> >
> > Actually there are quite a few people who use VC++ 1.52 these days,
> > for a variety of reasons. I'll restrict myself to the C usage only
> > for this group, of course.
> >
> > It is actually an extremely good and highly optimizing C89
> conforming
> > compiler for creating true MS-DOS programs. Despite the slavish
> > fascination of the masses with the latest and greatest, there is
> still
> > some use in some places for true MS-DOS programs.
>
>
> DJGPP, etc is better i guess.
Not for anything before a 386. Totally useless on 8088, 8086, and
80286 (all obsolete), or the 80188 and 80186 which are very much alive
and well.
Richard Heathfield
>
> Thank you all for the replies. I am sorry if I have offended anyone here,
I don't think you offended anyone, did you?
> by posting a C++ question.
Um, it wasn't a C++ question. :-) It was a Win32 question, as it turned
out.
> It was really meant to be a C question, since I
> am not trying to use any objects.
You'll find that tricky in C. C, too, has objects; they are not as
flashy as C++ objects, but they serve us well in their own quiet way.
Here's an example:
int i_am_an_object = 6;
In C, an object is a named region of storage.
> I just happens that my compiler is a C /
> C++ version 6.0 Microsoft compiler.
Yes, it is well-understood here by sensible people that the mere mention
of a compiler named "<vendor> C++" should /not/ have people immediately
reaching for their Off-Topic buttons.
>
> I will re direct my question .
That's probably wise. I suggest comp.os.ms-windows.programmer.win32 as
being your next stop. They might send you onward from there - I don't
know.
<snip>
Dave Vandervies
Richard Heathfield <bin...@eton.powernet.co.uk> wrote:
>You'll find that tricky in C. C, too, has objects; they are not as
>flashy as C++ objects, but they serve us well in their own quiet way.
>Here's an example:
>
>int i_am_an_object = 6;
>
>In C, an object is a named region of storage.
Does it have to have a name? For example, I thought that if malloc
returned a non-null pointer that pointer pointed at an anonymous object:
--------
int *i_point_at_an_anonymous_object =
malloc(sizeof *i_point_at_an_anonymous_object);
--------
*i_point_at_an_anonymous_object doesn't have a name, but I thought
(assuming malloc didn't fail) it was an object.
n869 seems to agree with me:
--------
3.15
[#1] object
region of data storage in the execution environment, the
contents of which can represent values
--------
No mention of names here.
dave
--
Dave Vandervies dj3v...@calum.csclub.uwaterloo.ca
Hey, I make mistakes too. Why, I remember once back in 1978 ...
--Chris Torek in comp.lang.c
E. Gibbons
Dave Vandervies <dj3v...@calum.csclub.uwaterloo.ca> wrote:
>In article <3D16A63C...@eton.powernet.co.uk>,
>Richard Heathfield <bin...@eton.powernet.co.uk> wrote:
>
>>You'll find that tricky in C. C, too, has objects; they are not as
>>flashy as C++ objects, but they serve us well in their own quiet way.
>>Here's an example:
>>
>>int i_am_an_object = 6;
>>
>>In C, an object is a named region of storage.
>
>Does it have to have a name? For example, I thought that if malloc
>returned a non-null pointer that pointer pointed at an anonymous object:
>--------
>int *i_point_at_an_anonymous_object =
> malloc(sizeof *i_point_at_an_anonymous_object);
>--------
>*i_point_at_an_anonymous_object doesn't have a name, but I thought
>(assuming malloc didn't fail) it was an object.
True; even here:
char *cp = "anonymous array";
cp points at an anonymous object, AFAIK.
One might also argue that static objects returned by-reference from
functions become anonymous after return, since the object name ceases to
be in-scope. Mind you, *I'm* not arguing that, just observing that one
could!
>n869 seems to agree with me:
>--------
> 3.15
> [#1] object
> region of data storage in the execution environment, the
> contents of which can represent values
>--------
>No mention of names here.
--
Richard Heathfield
>
> In article <3D16A63C...@eton.powernet.co.uk>,
> Richard Heathfield <bin...@eton.powernet.co.uk> wrote:
>
> >You'll find that tricky in C. C, too, has objects; they are not as
> >flashy as C++ objects, but they serve us well in their own quiet way.
> >Here's an example:
> >
> >int i_am_an_object = 6;
> >
> >In C, an object is a named region of storage.
>
> Does it have to have a name?
No. Perhaps I should have said that a named region of storage is an
object. :-)
I was, of course, quoting K&R2.
pete
>
> In article <af84bu$e6b$1...@tabloid.uwaterloo.ca>,
> Dave Vandervies <dj3v...@calum.csclub.uwaterloo.ca> wrote:
> >In article <3D16A63C...@eton.powernet.co.uk>,
> >Richard Heathfield <bin...@eton.powernet.co.uk> wrote:
> >
> >>You'll find that tricky in C. C, too, has objects; they are not as
> >>flashy as C++ objects, but they serve us well in their own quiet way.
> >>Here's an example:
> >>
> >>int i_am_an_object = 6;
> >>
> >>In C, an object is a named region of storage.
> >
> >Does it have to have a name?
No.
> >For example, I thought that if malloc
> >returned a non-null pointer that pointer pointed at an anonymous
> > object:
Yes. That's the exception.
> >--------
> >int *i_point_at_an_anonymous_object =
> > malloc(sizeof *i_point_at_an_anonymous_object);
> >--------
> >*i_point_at_an_anonymous_object doesn't have a name, but I thought
> >(assuming malloc didn't fail) it was an object.
The pointer itself is an object that
has the name of the pointer as an identifier.
The pointer points to the other object, which was
allocated by malloc and which has no name.
There is no identifier, which when used as an operand
to & and sizeof, will yield the address and size respectively,
of the allocated object, except by coincidence.
>
> True; even here:
>
> char *cp = "anonymous array";
>
> cp points at an anonymous object, AFAIK.
"anonymous array" is the array name.
&"anonymous array" is the address of the array.
sizeof"anonymous array" will give you the object's size.
That's the way that array names (object names) act with & and sizeof.
--
pete
pete
>
> Dave Vandervies wrote:
> >
> > In article <3D16A63C...@eton.powernet.co.uk>,
> > Richard Heathfield <bin...@eton.powernet.co.uk> wrote:
> >
> > >You'll find that tricky in C. C, too, has objects; they are not as
> > >flashy as C++ objects, but they serve us well in their own quiet way.
> > >Here's an example:
> > >
> > >int i_am_an_object = 6;
> > >
> > >In C, an object is a named region of storage.
> >
> > Does it have to have a name?
>
> No. Perhaps I should have said that a named region of storage is an
> object. :-)
>
> I was, of course, quoting K&R2.
>
> <snip>
"Object" is defined differently in K&R1, K&R2, C89, C99,
and they never got it right.
By the time you get to C99, you really have to rely
on the "everybody knows" rule, to know that an integer constant
is not an lvalue.
--
pete
Dan Pop
>E. Gibbons wrote:
>>
>> In article <af84bu$e6b$1...@tabloid.uwaterloo.ca>,
>> Dave Vandervies <dj3v...@calum.csclub.uwaterloo.ca> wrote:
>> >In article <3D16A63C...@eton.powernet.co.uk>,
>> >Richard Heathfield <bin...@eton.powernet.co.uk> wrote:
>> >
>> >>You'll find that tricky in C. C, too, has objects; they are not as
>> >>flashy as C++ objects, but they serve us well in their own quiet way.
>> >>Here's an example:
>> >>
>> >>int i_am_an_object = 6;
>> >>
>> >>In C, an object is a named region of storage.
>> >
>> >Does it have to have a name?
>
>No.
>
>> >For example, I thought that if malloc
>> >returned a non-null pointer that pointer pointed at an anonymous
>> > object:
>
>Yes. That's the exception.
One of the exceptions. String literals are another. Each byte composing
an object is an unnamed object on its own.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan...@ifh.de
pete
>
> In <3D184D...@mindspring.com> pete <pfi...@mindspring.com> writes:
>
> >E. Gibbons wrote:
> >>
> >> In article <af84bu$e6b$1...@tabloid.uwaterloo.ca>,
> >> Dave Vandervies <dj3v...@calum.csclub.uwaterloo.ca> wrote:
> >> >In article <3D16A63C...@eton.powernet.co.uk>,
> >> >Richard Heathfield <bin...@eton.powernet.co.uk> wrote:
> >> >
> >> >>You'll find that tricky in C. C, too, has objects; they are not as
> >> >>flashy as C++ objects, but they serve us well in their own quiet way.
> >> >>Here's an example:
> >> >>
> >> >>int i_am_an_object = 6;
> >> >>
> >> >>In C, an object is a named region of storage.
> >> >
> >> >Does it have to have a name?
> >
> >No.
> >
> >> >For example, I thought that if malloc
> >> >returned a non-null pointer that pointer pointed at an anonymous
> >> > object:
> >
> >Yes. That's the exception.
>
> One of the exceptions. String literals are another.
Then, I think I was wrong about this:
> > char *cp = "anonymous array";
> >
> > cp points at an anonymous object, AFAIK.
>
> "anonymous array" is the array name.
> &"anonymous array" is the address of the array.
> sizeof"anonymous array" will give you the object's size.
> That's the way that array names (object names) act with & and sizeof.
My point being that
the string literal was not an anonymous object.
But, considering that identical string constants
need not be stored at the same address, then
that makes it more obvous to me that there isn't a one to one
correspondence between the identifier and the object.
So then, the string literal *is* an anonymous object.
> Each byte composing
> an object is an unnamed object on its own.
Thank you.
--
pete
Richard Heathfield
The way I think of it is "something your program is allowed to write
to", but of course that's not quite right either (since const objects
are still objects).
pete
>
> pete wrote:
> >
> > Richard Heathfield wrote:
> > >
> > > Dave Vandervies wrote:
> > > >
> > > > In article <3D16A63C...@eton.powernet.co.uk>,
> > > > Richard Heathfield <bin...@eton.powernet.co.uk> wrote:
> > > >
> > > > >You'll find that tricky in C. C, too, has objects; they are not as
> > > > >flashy as C++ objects, but they serve us well in their own quiet way.
> > > > >Here's an example:
> > > > >
> > > > >int i_am_an_object = 6;
> > > > >
> > > > >In C, an object is a named region of storage.
> > > >
> > > > Does it have to have a name?
> > >
> > > No. Perhaps I should have said that a named region of storage is an
> > > object. :-)
> > >
> > > I was, of course, quoting K&R2.
> > >
> > > <snip>
> >
> > "Object" is defined differently in K&R1, K&R2, C89, C99,
> > and they never got it right.
> > By the time you get to C99, you really have to rely
> > on the "everybody knows" rule, to know that an integer constant
> > is not an lvalue.
>
> The way I think of it is "something your program is allowed to write
> to", but of course that's not quite right either (since const objects
> are still objects).
You can also write to a file, which is not an object.
--
pete
Dan Pop
>pete wrote:
>>
>> "Object" is defined differently in K&R1, K&R2, C89, C99,
>> and they never got it right.
>> By the time you get to C99, you really have to rely
>> on the "everybody knows" rule, to know that an integer constant
>> is not an lvalue.
>
>The way I think of it is "something your program is allowed to write
>to", but of course that's not quite right either (since const objects
>are still objects).
And so are string literals, a weird category of objects, which,
despite NOT being const objects, can't be modified.
What's wrong with the C99 definition? Which is identical to the C89
definition, BTW.
[#1] object
region of data storage in the execution environment, the
contents of which can represent values
Dan
E. Gibbons
>E. Gibbons wrote:
>>
>> True; even here:
>>
>> char *cp = "anonymous array";
>>
>> cp points at an anonymous object, AFAIK.
>
>"anonymous array" is the array name.
>&"anonymous array" is the address of the array.
>sizeof"anonymous array" will give you the object's size.
>That's the way that array names (object names) act with & and sizeof.
I think you are wrong (BICBW). When the sequence "anonymous array"
appears in the source code, the compiler *might* be smart enough to
notice that it matches a previously-occurring string literal, and might
re-use the same array (at the same address) -- or, it might not; i.e.,
every occurrence of "anonymous array" might refer to a separately
allocated array. Thus, I don't see how the initializer can be viewed
as a "name" for anything; rather, as someone more famous than me would
say, it is a THING IN ITSELF. :)
IOW, if I am correct in what I believe, then there is no guarantee
whether the following program prints "same" or "different":
#include <stdio.h>
int main(void)
{
char * a = "anonymous array";
char * b = "anonymous array";
if(a == b) {
puts("same");
} else {
puts("different");
}
return 0;
}
--Ben
(BTW, if "anonymous array" is the name of an object, then what is
"mous array" if it occurs in the same program?)
--
Joona I Palaste
> Thus, I don't see how the initializer can be viewed
> as a "name" for anything; rather, as someone more famous than me would
> say, it is a THING IN ITSELF. :)
Just don't start getting delusions of furniturity.
--
/-- Joona Palaste (pal...@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"No, Maggie, not Aztec, Olmec! Ol-mec!"
- Lisa Simpson
Mark McIntyre
wrote:
>Richard Heathfield wrote:
>>
>> The way I think of it is "something your program is allowed to write
>> to", but of course that's not quite right either (since const objects
>> are still objects).
>
>You can also write to a file, which is not an object.
What (in the context of C) is a "file" ? Surely you mean you can write
to a stream (which is an object)?
Ben Pfaff
> What (in the context of C) is a "file" ?
You may find C99 7.19.3, titled "Files", of interest in answering
this question.
--
"Some people *are* arrogant, and others read the FAQ."
--Chris Dollin
Dan Pop
>On Tue, 25 Jun 2002 09:38:49 -0400, pete <pfi...@mindspring.com>
>wrote:
>
>>Richard Heathfield wrote:
>>>
>>> The way I think of it is "something your program is allowed to write
>>> to", but of course that's not quite right either (since const objects
>>> are still objects).
>>
>>You can also write to a file, which is not an object.
>
>What (in the context of C) is a "file" ?
7.19.3 may provide some enlightenment.
>Surely you mean you can write
>to a stream (which is an object)?
Nope, he didn't. A stream is an interface that allows you to write to
files and to read back what you have written.
pete
You are correct, as usual.
In C89 and C99, it was the definition of "lvalue"
rather than the definition of "object" which confused me.
The K&R books, defined those terms together,
which is where I got it into my head that lvalues and objects
were inextricably linked concepts.
--
pete
Mark McIntyre
>Mark McIntyre <markmc...@spamcop.net> writes:
>
>> What (in the context of C) is a "file" ?
>
>You may find C99 7.19.3, titled "Files", of interest in answering
>this question.
Thats a good point, although its worth noting that a large part of
7.19.3 concerns streams.
Note also that you don't write to files, you write to streams which
are linked to them by implementation-specific magic. Thus the point
about writing to objects remains valid.
pete
>
> On 25 Jun 2002 15:01:55 -0700, Ben Pfaff <b...@cs.stanford.edu> wrote:
>
> >Mark McIntyre <markmc...@spamcop.net> writes:
> >
> >> What (in the context of C) is a "file" ?
> >
> >You may find C99 7.19.3, titled "Files", of interest in answering
> >this question.
>
> Thats a good point, although its worth noting that a large part of
> 7.19.3 concerns streams.
>
> Note also that you don't write to files,
file_pointer = fopen(file_name, "w");
means to open a file for writing.
> you write to streams which
> are linked to them by implementation-specific magic. Thus the point
> about writing to objects remains valid.
Are you saying that streams are objects ?
They're not.
--
pete
Dan Pop
>Note also that you don't write to files, you write to streams which
>are linked to them by implementation-specific magic. Thus the point
>about writing to objects remains valid.
You're confusing the mechanism used for writing (a stream) with the
destination of the writing (a file).