Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Why not FILE instead of FILE*?

Reply
Thread Tools

Why not FILE instead of FILE*?

 
 
Joona I Palaste
Guest
Posts: n/a
 
      04-16-2004
Why is the standard C type for file handles FILE* instead of FILE?
AFAIK the type FILE is a pre-defined typedef for some other type anyway.
So why not make it instead a typedef for a *pointer* to that type? For
one thing, that would stop people trying to poke around at the insides
of a FILE. For another, it could allow for cases where the "real" type
behind FILE is not a pointer to anything.

--
/-- Joona Palaste ((E-Mail Removed)) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"It sure is cool having money and chicks."
- Beavis and Butt-head
 
Reply With Quote
 
 
 
 
Richard Delorme
Guest
Posts: n/a
 
      04-16-2004
Joona I Palaste a écrit :
> Why is the standard C type for file handles FILE* instead of FILE?
> AFAIK the type FILE is a pre-defined typedef for some other type anyway.
> So why not make it instead a typedef for a *pointer* to that type? For
> one thing, that would stop people trying to poke around at the insides
> of a FILE. For another, it could allow for cases where the "real" type
> behind FILE is not a pointer to anything.


If FILE is not a pointer for sure, there is a need to change other parts
of the standard, like fopen returning NULL on failure. I am afraid that
such a change breaks too much well-formed code.
Moreover, it is very easy to create your own typedef if FILE does not
fit your need, so a change in the standard is not required.

--
Richard

 
Reply With Quote
 
 
 
 
Severian
Guest
Posts: n/a
 
      04-16-2004
On 16 Apr 2004 06:12:04 GMT, Joona I Palaste <(E-Mail Removed)>
wrote:

>Why is the standard C type for file handles FILE* instead of FILE?
>AFAIK the type FILE is a pre-defined typedef for some other type anyway.
>So why not make it instead a typedef for a *pointer* to that type? For
>one thing, that would stop people trying to poke around at the insides
>of a FILE. For another, it could allow for cases where the "real" type
>behind FILE is not a pointer to anything.


FILE * is not a good representation of an opaque type, since
implementation-provided macros may depend on FILE members (i.e.,
getc).

If macro definitions could be hidden, FILE would not need to be so
pubic. (Oops, public.)

--
Sev
 
Reply With Quote
 
Irrwahn Grausewitz
Guest
Posts: n/a
 
      04-16-2004
Joona I Palaste <(E-Mail Removed)> wrote:
>Why is the standard C type for file handles FILE* instead of FILE?
>AFAIK the type FILE is a pre-defined typedef for some other type anyway.
>So why not make it instead a typedef for a *pointer* to that type? For
>one thing, that would stop people trying to poke around at the insides
>of a FILE. For another, it could allow for cases where the "real" type
>behind FILE is not a pointer to anything.


IMHO Making FILE a typedef alias for pointer-to-realfiletype would've
caused even more confusion among programmers, and on itself wouldn't
have kept anybody from manipulating the internals of the underlying
type (lookup the struct declaration in stdio.h as before, and use .
instead of ->, that's all).

Actually, the IMNSHO most reasonable solution would've been to keep
the typedef as is, but hide the internals of the underlying type by
moving its declaration from the header to the library source (make
it an opaque type), e.g. something like:


/************* stdio.h *************/
typedef
struct _iobuf
FILE;

FILE *fopen(const char *, const char *);
/* .... */
/***********************************/


/************* stdio.c *************/
#include <stdio.h>

struct _iobuf
{
int _file;
int _flag;
/* etc. */
};

FILE *fopen(const char *filename, const char *mode)
{
/* yaddayaddayadda */;
}
/* .... */
/***********************************/


This approach however has the drawback that getc and putc could
not have been easily implemented as simple macros, but given the
potential dangers that arise from such macro implementations,
it's highly debatable if this would've been a big loss (IMO not).

Regards
--
Irrwahn Grausewitz ((E-Mail Removed))
welcome to clc: http://www.ungerhu.com/jxh/clc.welcome.txt
clc faq-list : http://www.faqs.org/faqs/C-faq/faq/
clc OT guide : http://benpfaff.org/writings/clc/off-topic.html
 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      04-16-2004
Irrwahn Grausewitz wrote:
>

.... snip ...
>
> This approach however has the drawback that getc and putc could
> not have been easily implemented as simple macros, but given the
> potential dangers that arise from such macro implementations,
> it's highly debatable if this would've been a big loss (IMO not).


IMO yes. Consider:

while ('\n' != (c = getc(stdin))) continue;

If getc is a function this involves a function call, and all its
overhead, for each loop execution. If getc is a macro this is
likely to become (pseudo assembly):

<initialization>
..1: inc R1
eq R1,R2
jf .2
call load; (resets R1, R2, buffer, may be inline)
..2: eq (R1), '\n'
jf .1

and executes roughly 4 instructions per iteration. This allows
buffering input to have a major effect on execution speed. The
registers are all pointing to some offsets within *stdin. If the
eq/jf pairs are single instructions, we have 3 per iteration. If
we can embed auto-increment, we may have 2 instructions per
iteration, with one memory access, which in turn is probably
cached.

Not bad for a simple minded optimizer. There is a reason C is
known as structured assembly.

--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?


 
Reply With Quote
 
Irrwahn Grausewitz
Guest
Posts: n/a
 
      04-16-2004
Irrwahn Grausewitz <(E-Mail Removed)> wrote:
>[...], and use . instead of ->, that's all).


Dreaded, no, just the other way round!
--
Irrwahn Grausewitz ((E-Mail Removed))
welcome to clc: http://www.ungerhu.com/jxh/clc.welcome.txt
clc faq-list : http://www.faqs.org/faqs/C-faq/faq/
clc OT guide : http://benpfaff.org/writings/clc/off-topic.html
 
Reply With Quote
 
Irrwahn Grausewitz
Guest
Posts: n/a
 
      04-16-2004
CBFalconer <(E-Mail Removed)> wrote:
>Irrwahn Grausewitz wrote:
>>

>... snip ...
>>
>> This approach however has the drawback that getc and putc could
>> not have been easily implemented as simple macros, but given the
>> potential dangers that arise from such macro implementations,
>> it's highly debatable if this would've been a big loss (IMO not).

>
>IMO yes. Consider:
>
> while ('\n' != (c = getc(stdin))) continue;

<snip>
>and executes roughly 4 instructions per iteration. This allows
>buffering input to have a major effect on execution speed.

<snip>
>Not bad for a simple minded optimizer. There is a reason C is
>known as structured assembly.


IMHO there's good reason to deviate from this POV in the age of
optimizing compilers and 'intelligent' caches. I'd rather have
my programs waste some cycles than use potentially dangerous
macros; furthermore, if I feel the need to produce top-notch
micro-optimized assembly code, well, then I won't rely on a C
compiler for this task in the first place. Other's mileages may
(and will) of course vary.

Regards
--
Irrwahn Grausewitz ((E-Mail Removed))
welcome to clc: http://www.ungerhu.com/jxh/clc.welcome.txt
clc faq-list : http://www.faqs.org/faqs/C-faq/faq/
clc OT guide : http://benpfaff.org/writings/clc/off-topic.html
 
Reply With Quote
 
Dan Pop
Guest
Posts: n/a
 
      04-16-2004
In <(E-Mail Removed)> Irrwahn Grausewitz <(E-Mail Removed)> writes:

>CBFalconer <(E-Mail Removed)> wrote:
>>Irrwahn Grausewitz wrote:
>>>

>>... snip ...
>>>
>>> This approach however has the drawback that getc and putc could
>>> not have been easily implemented as simple macros, but given the
>>> potential dangers that arise from such macro implementations,
>>> it's highly debatable if this would've been a big loss (IMO not).

>>
>>IMO yes. Consider:
>>
>> while ('\n' != (c = getc(stdin))) continue;

><snip>
>>and executes roughly 4 instructions per iteration. This allows
>>buffering input to have a major effect on execution speed.

><snip>
>>Not bad for a simple minded optimizer. There is a reason C is
>>known as structured assembly.

>
>IMHO there's good reason to deviate from this POV in the age of
>optimizing compilers and 'intelligent' caches. I'd rather have
>my programs waste some cycles than use potentially dangerous
>macros;


What is potentially dangerous in macros like getc and putc? They've
been implemented as macros since the invention of <stdio.h> and I haven't
heard anyone complaining about them...

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: http://www.velocityreviews.com/forums/(E-Mail Removed)
 
Reply With Quote
 
Irrwahn Grausewitz
Guest
Posts: n/a
 
      04-16-2004
(E-Mail Removed) (Dan Pop) wrote:
>Irrwahn Grausewitz <(E-Mail Removed)> writes:
>>CBFalconer <(E-Mail Removed)> wrote:

<snip>
>>>Not bad for a simple minded optimizer. There is a reason C is
>>>known as structured assembly.

>>
>>IMHO there's good reason to deviate from this POV in the age of
>>optimizing compilers and 'intelligent' caches. I'd rather have
>>my programs waste some cycles than use potentially dangerous
>>macros;

>
>What is potentially dangerous in macros like getc and putc? They've
>been implemented as macros since the invention of <stdio.h> and I haven't
>heard anyone complaining about them...


I consider all function-like macros to be potentially dangerous,
even if I wrote them myself. By avoiding them [1], I don't have
to think about possible side effects and can concentrate on more
important things. You may call me lazy.

[1] As with all general rules, I occasionally break it.

Regards
--
Irrwahn Grausewitz ((E-Mail Removed))
welcome to clc: http://www.ungerhu.com/jxh/clc.welcome.txt
clc faq-list : http://www.faqs.org/faqs/C-faq/faq/
clc OT guide : http://benpfaff.org/writings/clc/off-topic.html
 
Reply With Quote
 
pete
Guest
Posts: n/a
 
      04-17-2004
Joona I Palaste wrote:
>
> Why is the standard C type for file handles FILE* instead of FILE?
> AFAIK the type FILE is a pre-defined typedef for some other type anyway.
> So why not make it instead a typedef for a *pointer* to that type? For
> one thing, that would stop people trying to poke around at the insides
> of a FILE. For another, it could allow for cases where the "real" type
> behind FILE is not a pointer to anything.


Because the address of the FILE type object may be significant.
A copy of a FILE type object, might not work the same as the original.

--
pete
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Why not 'foo = not f' instead of 'foo = (not f or 1) and 0'? Kristian Domke Python 11 01-23-2008 07:27 PM
Why :: ? Why not : ? Why not . ? <- less clutter ?!? Skybuck Flying C++ 16 08-25-2007 09:48 PM
why why why why why Mr. SweatyFinger ASP .Net 4 12-21-2006 01:15 PM
findcontrol("PlaceHolderPrice") why why why why why why why why why why why Mr. SweatyFinger ASP .Net 2 12-02-2006 03:46 PM
why why why does function not work Horace Nunley ASP .Net 1 09-27-2006 09:52 PM



Advertisments