Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.

Dismiss

Looking for a specific C group

3 views

Skip to first unread message

Quantum Flux

unread,

Apr 11, 1995, 3:00:00 AM4/11/95

I realize this is not the place for a programming question I have (about
designing a function to implement some aspects of boolean algebra), but I
know someone here can point me in the right direction. All programming is
done on a DOS machine in C. Which extension of the comp.* newsgroups
would be ideal for programming boolean algebra in such an environment?

Adam
______________________________________________________________________________
Quantum Flux Syracuse University
afo...@mailbox.syr.edu Computer Engineering Major
C H R O M I U M D I S T O R T I O N [http://web.syr.edu/~afoxman]

From: Chris Torek <to...@elf.bsdi.com>
Newsgroups: comp.lang.c.moderated
Subject: Re: Coding guidelines (was: Please, exchange experience on this list...)
References: <3kv6uc$8...@solutions.solon.com> <3llk5l$a...@solutions.solon.com> <3lrfbc$2...@solutions.solon.com> <3m179f$d...@solutions.solon.com>
Reply-To: to...@bsdi.com
Organization: Berkeley Software Design, Inc.

In article <3llk5l$a...@solutions.solon.com> Ronald F. Guilmette
<r...@rahul.net> asks for examples of where using pointers might be
slower than using indices.

In article <3lrfbc$2...@solutions.solon.com> >Michael Quinlan
<mi...@PrimeNet.Com> suggests (currently) unusual environments such
as 16-bit-int 32-bit-pointer schemes.

In article <3m179f$d...@solutions.solon.com> Ronald F. Guilmette
<r...@rahul.net> answers:
>I love to argue againt people who inisit on using apples-to-oranges com-
>parisons. It's so easy to see the holes in such arguments.
>
>Let's talk about small and/or medium model (i.e. 16 bit ints _and_ 16 bit
>pointers) shall we?

You asked for examples; he gave you an example. You appeared to
claim that pointers were always faster than indices. A single
counterexample refutes this claim as easily as ten (where is Mark
Brader's signature quote when I need it? :-) ). Still, another
example... consider a loop of the general form:

for i in [0..N) do a[i] = b[i] op c[i] rof;

In C we might write this as either:

for (i = 0; i < N; i++)
a[i] = b[i] OP c[i];

or:

for (pa = a, pb = b, pc = c; pa < &a[N]; pa++, pb++, pc++)
*pa = *pb OP *pc;

On some machines, if these are compiled more or less literally,
the second form is typically slower than the first. These machines
are those that have an indexed addressing mode, and the reason the
first form is faster is that it uses 5 instructions in the loop
(load, load, op, store, inc), while the second uses 8 (load, load,
op, store, inc, inc, inc). The load and store instructions overlap
the address computation (an add, possibly with a shift, depending
on the machine; if the shift is not available, the loop can run i
from 0 to 4N, assuming the array element size is 4) with their
other work.

These machines are not especially rare. For instance, anyone who
has ever used a sparc box has used one such.
--
In-Real-Life: Chris Torek, Berkeley Software Design Inc
Berkeley, CA Domain: to...@bsdi.com +1 510 549 1145

Newsgroups: comp.lang.c,comp.lang.c.moderated
From: dan...@afsmail.cern.ch (Dan Pop)
Subject: Re: newbie's slow file i/o
Organization: CERN European Lab for Particle Physics
References: <3m181e$d...@solutions.solon.com> <3m7hla$4...@solutions.solon.com>

In <3m7hla$4...@solutions.solon.com> trin...@news.ed.ray.com (Scott Tringali) writes:

>ga...@oak.circa.ufl.edu wrote:
>: /*
>: ** Hi y'all, A Question from Newbieville
>: ** ... the following proggie seems _real slow_. Is it because I
>: ** added "printf("Processing file...);" down yonder _OR_ is it
>: ** because I have several flags && therefore several ints to check
>: ** each time a new character is read???
>
>Neither. The offending statement is this:
>
>: while((c=getc(rfp))!=EOF) {
>
>Do a block read (in your case, fread) with a buffer of 8K, and then do
>your processing on the buffer.

Why? stdio will do the block read anyway. Hint: stdio has its own
internal buffering. And getc() is a macro defined in <stdio.h> in most
implementations, so it doesn't even have the overhead of a function call
(unless the programmer explicitly bypasses the macro and uses the function
from the standard library).

> Want some numbers?
>
>Bufsize Clock Time #loops
>--------------------------------
>1 423.4 1468802
>2 215.2 734401
>4 107.2 367201
>8 54.0 183601
>. . .
>8192 0.3 180
>
>You get the point. [Data from Stevens, Advanced Programming in the
>Unix Environment, p. 57]

He gets the wrong point, unless he has Stevens' book and can read that
page himself and see that this table applies to something completely
different than the subject of our discussion: calling read() (a Unix
_system call_) with different sizes of the user supplied buffer.

When using stdio functions, whether getc() or fread(), read() is called
by stdio, usually with the same buffer size. So, whether the user reads
the file with getc() or with fread(), the same number of read() calls
are issued by stdio. Which means that the above quoted table is
completely irrelevant to our discussion. Showing it to a newbie,
without adequate comments, in order to support a bogus claim/advice,
is extremely unethical.

Reading the file with fread() instead getc() will be somewhat faster
(less stdio overhead), but not 1400+ times faster, as suggested by the
table. And if the processing has to be done on a character by character
basis, the getc() approach is the most natural one, even if marginally
slower.

Dan
--
Dan Pop
CERN, CN Division
Email: dan...@afsmail.cern.ch
Mail: CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland

From: psh...@MIT.EDU
Reply-To: news-answe...@MIT.EDU (the *.answers moderation team)
Subject: Re: LEARN C/C++ TODAY (A list of resources/tutorials)

> Newsgroups: comp.lang.c.moderated
> Subject: LEARN C/C++ TODAY (A list of resources/tutorials)
> Date: 2 Apr 1995 03:00:58 -0500
> Message-ID: <3llljq$a...@solutions.solon.com>
>
> [Note to Moderators -- If you don't feel this is appropriate in c.l.c.m,
> please forward it to /dev/null. Thanks]

If the moderator comp.lang.c.moderated agrees to your periodically
reposting the article to that newsgroup, please let us know so that we
can update our records to reflect this. The easiest thing to do is to
ask him for permission for you to go ahead to cross-post to c.l.c.m
with the following Approved line, rather than having to submit it to
him each time and having him repost it for you twice a month.

Ping Huang, member of the *.answers moderation team
(news-answe...@MIT.EDU)

From: wkau...@us.oracle.com (William Kaufman)
Newsgroups: comp.lang.c,comp.lang.c.moderated
Subject: Re: newbie's slow file i/o
Organization: Oracle Corporation, Redwood Shores CA
References: <3m181e$d...@solutions.solon.com> <3m6g7l$8...@solutions.solon.com>

In article <3m6g7l$8...@solutions.solon.com>,
h...@eel.ufl.edu (Henry C. Schoepp) writes:
] You're doing things one character at a time. This is slow and disk intensive.
] Think about allocating a large buffer, possibly the size of the file and using a
] fread() I/O to get a large block.

And, in article <3m6ge8$8...@solutions.solon.com>,
trin...@news.ed.ray.com (Scott Tringali) says the same:
] Do a block read (in your case, fread) with a buffer of 8K, and then do
] your processing on the buffer.

But the standard C libraries should be doing block I/O and handing
back single characters, shouldn't it? Buffering (e.g., through
setvbuf()) shouldn't win you much, especially if the file is smaller
than BUFSIZ (or if BUFSIZ is at least 8K).

I'd think that all you gain by this is some function call overhead,
calling fread() once versus N calls to fgetc(). (And maybe not even
that: fgetc() could be implemented inline--say, via a macro--where
fread() almost never can, practically speaking.)

Scott, you quoted (with statistics) Stevens, but I don't have access
to that book. Was he talking about fopen()/fread(), or was he talking
about open()/read()? (The latter definitely suffer from lack of
buffering,...)

In article <3m6ga6$8...@solutions.solon.com>,
ba...@aplcomm.jhuapl.edu (Mike Bandy) writes,
] You're assured to get this done faster by using the system()
] command to execute operating system commands directly.

Wouldn't calling remove() and rename() be faster? At least, you
avoid two calls to system() (which, on Unix, involves fork() and exec(),
plus two invocations of the shell).

But, yes, using either rename() or the OS's rename utility should be
faster than copying it by hand, since the OS probably doesn't do any
copying, esp. if the two files are in the same directory.

-- Bill K.

Bill Kaufman | "I mean ... it's not even been a two-and-two-make-
wkau...@us.oracle.com | five sort of day, it's more like a two-and-two-
| make ... *fish* ..." -- "Cages", Dave McKean

From: rog...@galaxy.galstar.com (Roger Clegg)
Newsgroups: comp.lang.c.moderated
Subject: Re: Pointers versus indices: Clarity sought
Organization: GALSTAR - Tulsa's Public Access Internet
References: <3lll70$a...@solutions.solon.com>

Mike Dowling (mi...@moocow.math.nat.tu-bs.de) wrote:
: Now I am very confused. Perhaps somebody here can explain a few things.
: On a i486 DX2 80 MHz PC running Linux and gcc -O6 the pointer version
: causes a 1% improvement in efficiency.

: No surprise there. Now, here it comes!

: On an HP 735 100MHz RISC workstation with c89 -O, the pointer version runs 25%
: SLOWER than the index version.

: This was reduced to about 15% slower with the following loop.

: for ( (p = a[j], q = a[i]); q < &a[i][i]; q++)
: tmp += *p++**q;

: On the same HP using gcc -O6 (same as -O2 on the HP) the program runs about 1%
: slower with the pointer version (and about 25% slower than the c89 version).
I think the key here is NEVER trust a compiler when you have time
critical code to write. I have written many real time drivers and
since I switched to 'c' instead of assembly a few years back, I have
noticed that compiler technology leaves a lot to be desired. For
instance, simply changing your index from increasing to decreasing
caused the optimizer to generate MUCH better code. I could find no
particular reason for this. The processor could do a decrement-branch
faster, but the compiler wasn't smart enough to use that. No, the
difference was in the number of unecessary register-memory transfers
the compiler generated. I wouldn't have ever noticed this if a college
who had had a problem with the compiler hadn't accidently discovered it
during several desparate attempts to fix some code he was working on
without inserting assembly.
FYI,
rogerc

From: abac...@singnet.com.sg
Newsgroups: comp.lang.c.moderated
Subject: Re: Reading data files in MS Binary format
Organization: Singapore Telecom Internet Service

Can someone help me out of this data-format fix? I have data files with
floating point numbers stored in MS Binary format (if that's the right
reference). Using Microsoft's compilers, I have been able to read data using
the fmsbintoieee() function from the maths.h library. Is there a way of
reading the same files using Turbo C/C++. My initial checks in the Turbo C++
Bible indicates the function is not available in the maths.h library. Am I
stuck to Microsoft's compilers as far as reading these data files are
concerned?
T. C., Ng
abac...@singnet.com.sg

From: hans.s...@e-technik.tu-chemnitz.de (Hans Steffani)
Subject: MSG-ID 3m185r$d...@solutions.solon.com

Hi,
I found the the menitioned article in clcm. It is a collection
of many articles from the last days? Why did it pass you
moderation.

It is no problem for me, but I think you oversaw this article
and I think you should get a hint.

Hans Friedrich Steffani
--
Hans Friedrich Steffani
Institut fuer Elektrische Maschinen und Antriebe
TU Chemnitz-Zwickau
e-mail: hans.s...@e-technik.tu-chemnitz.de

From: e...@larry.gsfc.nasa.gov (Edward Hartnett)
Newsgroups: comp.lang.c,comp.lang.c.moderated
Subject: Re: newbie's slow file i/o
Organization: NASA Goddard Space Flight Center -- Greenbelt, Maryland USA
References: <3m181e$d...@solutions.solon.com> <3m6ga6$8...@solutions.solon.com>

>>>>> "J" == Jari Kokko <jko...@lk-hp-20.hut.fi> writes:

J> Mike Bandy:
>> sprintf( str, "rm -f %s", argv[i] );
>> system( str );
>> sprintf( str, "mv write_temp %s", argv[i] );
>> system( str );

J> Yikes! Are you nuts? Can you spell "zsh -c"? Executing system level with
J> system() is crazy if all you want to do is overwrite a file. Why not just
J> remove() and rename(). Both are standard functions.

J> Jari, who thinks he might be missing a joke somewhere...

On a slightly related topic, I would be very interested in seeing some
examples of C or C++ programs that do things otherwise usually done in
the shell.

I have a perl 5 program, for example, that does some fairly complex
shelly sort of things. It opens an ftp connection, grabs a bunch of
files, runs various programs on the files, and then renames them.

I've also got tons of C and some C++ code, and I'm wondering if it
would not be more productive to switch from perl 5 to C++ for this
task (much as I lover perl 5, a *fantastic* language). Problem is,
since I've always done this kind of task with shell scripts (first
csh, then bourne) and perl, I've never written any C code for the
purpose.

From: Eric Brunson <bru...@sun1.scri.fsu.edu>
Subject: Re: Var arg defines?

Thanks, Mr. Moderator.

>
> This is in the comp.lang.c FAQ. You can get the FAQ from rtfm.ai.mit.edu
>
> -s
>

--------------------
Eric Brunson
bru...@scri.fsu.edu

From: h...@eel.ufl.edu (Henry C. Schoepp)
Newsgroups: comp.lang.c,comp.lang.c.moderated
Subject: Re: newbie's slow file i/o
Organization: Electrical Engineering, University of Florida
References: <3m181e$d...@solutions.solon.com> <3m6g7l$8...@solutions.solon.com> <3m7int$4...@solutions.solon.com>

>It was my understanding that the functions which use the (FILE *) type read
>large buffers into memory from disk (hence, the large area allocated to
>the FILE pointer). Is this incorrect?

The above is a true statement. The definition of large in the second line is
implementation specific. Sometimes large means 512 bytes, sometimes it may mean
512 megabytes. Generally these buffers are some convenient small number, like
the size of a cluster on a system. Furthermore, it requires that each of the
characters be fetched from that buffer, and all the other internal stuff dealing
with it. By using the fread() function to read a larger block of data at once,
you reduce the number of seeks on the disk (assuming the file does not have 100%
fragmentation!) which is the longest delay in any such access.

Disk seeks are generally in the range of about 10 to 30 ms, depending upon the
age of the hardware. This maybe further reduced by additional software cahces.
However it is not uncommon to have transfer rates around 1 M/s.

Hank

From: gs...@io.org (George Swan)
Newsgroups: comp.lang.c,comp.lang.c.moderated
Subject: Re: newbie's slow file i/o
Organization: Internex Online (Data: 363-3783/Telnet: io.org)
References: <3m181e$d...@solutions.solon.com> <3m6g1m$8...@solutions.solon.com>

In article <3m6g1m$8...@solutions.solon.com>,
Ronald F. Guilmette <r...@rahul.net> wrote:
>In article <3m181e$d...@solutions.solon.com>, <ga...@oak.circa.ufl.edu> wrote:

>>** Hi y'all, A Question from Newbieville
>
>OK... here's a mild flame:
>
>Don't post 100+ lines of code and ask us where the bottleneck is. You're
>a big boy, and you should be able to profile it yourself. If you haven't
>got a profiler and/or a code coverage tool, get one. (I think there are
>some free ones floating around the net.)

Actually, shouldn't Gary really be using expand or col?
That is, existing tools that do the task he had in mind, without
requiring him to do any programming.

From: h...@eel.ufl.edu (Henry C. Schoepp)
Newsgroups: comp.lang.c.moderated
Subject: DO NOT POST
Organization: Electrical Engineering, University of Florida

To the moderator:
I would just like to thank you for the time you put into this group. I've found
this group to be sufficiently superior to comp.lang.c to unsubscribe to it. This
is a great group.

Hank

From: gs...@io.org (George Swan)
Newsgroups: comp.lang.c.moderated
Subject: Re: Coding guidelines
Organization: Internex Online (Data: 363-3783/Telnet: io.org)
References: <3kv6uc$8...@solutions.solon.com> <3l6gu0$n...@solutions.solon.com> <3lfbj1$l...@solutions.solon.com> <3llkti$a...@solutions.solon.com>

The story so far: There has been a long thread discussing
at what level of granularity you should break our programs
into functions. Numerous writers have recommended including
code that does a particular part of an operation, but is
only called once, right in what ever function uses it.

Some of them have IMO set up a "strawman" in their description
of the bad habits we learned in CS100. The examples of the
style they criticize are so weak.

In article <3llkti$a...@solutions.solon.com>,
Michael Shields <shi...@tembel.org> wrote:
>In article <3lfbj1$l...@solutions.solon.com>,
>Thad Smith <Thad...@acm.org> wrote:

>> The reuse test is a good indication that a piece of code should be a
>> separate function, but there are other reasons, too. I try to
>> maintain a consistent level of abstraction across my design.

>Sorry if I didn't explain it too clearly, but I agree. However, I do
>make some effort to break bad habits taught in CS class. One of these
>is the idea that a function like this:

>void
>initialize()
>{
> create_a_socket();
> change_uid_and_gid();
> set_signal_handlers();
>}

So what happens if "create_a_socket( )" fails? If some portion
of the program needs that socket, then shouldn't the whole program
fail now?

Wouldn't something like this be a fairer example:

int initialize( void )
{
if (create_a_socket( ) != OK)
fprintf( stderr, "Can't create a socket!\n" );
else if (change_uid_and_gid( ) != OK)
fprintf( stderr, "Can't change uid and gid!\n" );
else if (set_signal_handlers( ) != OK)
fprintf( stderr, "Can't set signal handlers!\n" );
else
return OK;
return ~ OK;
}
int main( void )
{
if (initialize( ) != OK)
fprintf( stderr, "%s: Can't do initial setup!\n", argv [0] );
else if (user_input_loop( ) != OK)
fprintf( stderr, "%s: unrecoverable user input!\n", argv [0] );
[snip...]
}

From: kre...@flinux.tu-graz.ac.at (Herbert Kremser)
Newsgroups: comp.lang.c.moderated
Subject: Re: Coding guidelines (was: Please, exchange experience on this list...)
Organization: Technical University of Graz, Austria
References: <3kv6uc$8...@solutions.solon.com> <3lbvrk$d...@solutions.solon.com> <3llk5l$a...@solutions.solon.com> <3lrf5u$2...@solutions.solon.com> <3m177k$d...@solutions.solon.com>

Ronald F. Guilmette (r...@rahul.net) wrote:
: In article <3lrf5u$2...@solutions.solon.com>,
: David Kastrup <d...@kaa.informatik.rwth-aachen.de> wrote:
: >"Ronald F. Guilmette" <r...@rahul.net> writes:
: >>My mottoe is ``Write for clarity and do not _assume_ optimization.''
: >
: >>>Especially with regard to array references. In fact, comparing pointers
: >>>for end of array conditions can be slower than letting the optimizer
: >>>stop on an integer index reaching a limit.
: >
: >>Really?? Care to provide a compelling example?
: >
: >Ever indexed "huge" arrays under one of those pesky DOS compilers? There
: >an address is 32bits, an int is 16 bit. Comparing an index of an array
: >containing, say, 10000 doubles will be faster than comparing the address.

: I make it a point to avoid working in environments which don't provide
: a simple programming model (i.e. 32 bit pointers and 32 bit ints) when-
: ever possible. (Note that I _do_ work on x86 machines... but only 386
: and above, and... whenever possible... only under real live 32-bit
: operating systems.)

Ok stick with your 32 bit pointers and 32 bit ints.
I'm having fun with 64 bit pointers and 32 bit ints (or 64 bit long ints
if needed) meanwhile. :)

Whenever possible you shouldn't relate on the size of a variable.
Clean code should run on 64 bit machines too.
Ok.

Herbert
--
[on public request 12 lines of signature deleted] *snip* ;)

From: dre...@umich.edu (Daniel Reish)
Newsgroups: comp.lang.c.moderated
Subject: Re: `register' (was: Re: Coding guidelines...)
Organization: University of Michigan
References: <3kv6uc$8...@solutions.solon.com> <3m17gj$d...@solutions.solon.com> <3m6g3k$8...@solutions.solon.com> <3m7ih2$4...@solutions.solon.com>

[Quoted sections of Mr. Guilmette's (IMO correct) article from long ago
deleted.]

In article <3m7ih2$4...@solutions.solon.com>,
Herman Rubin <hru...@stat.purdue.edu> wrote:
>In article <3m6g3k$8...@solutions.solon.com>,
>Daniel Reish <dre...@umich.edu> wrote:
>>In article <3m17gj$d...@solutions.solon.com>,
>>Herman Rubin <hru...@stat.purdue.edu> wrote:

>>>There have been machines on which a register variable could have an address,
>>>and on which register array exist. It is possible to do some of this in
>>>machine code even if this is not the case; one can unroll a loop using
>>>register direct addressing. There is no good reason for this not to
>>>become more widespread.

>>Perhaps not, but what does this have to do with a discussion of
>>programming in ANSI C?

>The C language normally allows uses of the machine in other ways internal
>to it;

This is blatantly false. It would be correct if you had said 'most
compilers have non-ANSI extensions which allow ...'.

> few implementations do not have this capability. Many implementations
>have it badly.

>>>Should not the C (or any other) language allow unlimited use of
>>>machine instructions by the programmer? Most implementations have
>>>this property. Many instructions can be easily added by programmers,
>>>but are not in the language. This will always be the case.

>>No, because we're talking about ANSI C. (Aren't we?) If you want
>>assembly language, you know where to find it.

>One of the features of C is the ability to insert assembler instructions.
[deletia]

Again, this is not a feature of C. This is a common extension, and I
will agree that it can be useful, but it is not part of the C language.

>Now suppose that I have a "portable" program,

Why do you put the word _portable_ in quotes? Do you not believe in
such a thing as a portable program?

> but as someone knowing
>what instructions are available in hardware, I can tell the user that
>there is no way that the compiler can do a good job on this particular
>block of code,

The art of C compilers being in the state that it is in, I find this
difficult to believe. However, if it is the case, there are languages
other than C which you may use. One of them is assembly. None of
them belong in a discussion in this newsgroup.

> or possibly that it cannot without certain hardware
>instructions. Some of this might require keeping it in a register
>for a large number of asm instructions, which the so-called optimizing
>compiler cannot understand. Since we do not have a "frequency" directive
>in C, we cannot tell this to the compiler.

"So-called optimizing compiler"? Of course, I would have to be nuts to
claim that any C compiler in existence today can consistently produce
code as small and fast as that created by a skilled programmer, an
assembler, and a vast amount of time and money. But modern compilers
may be a good deal closer than you think.

[deletia]

>>>The C language allows the declaration register. The compiler should be
>>>required to follow the programmers instructions. It should be possible

>>Yes, and BY DEFINITION, the 'register' declaration means that the
>>variable cannot be referenced, and that no one will try to do so.
>>This can be used by the compiler as an indication that the variable in
>>question might be put in a machine register, but it does NOT mean that
>>the variable must be put in a register. It is an instruction, and, to
>>be ANSI-compliant, the compiler must obey it, but your understanding
>>of the instruction's meaning is inaccurate.

>>>for the compiler to discuss things with the programmer, and make suggestions.
>>>But the programmer should be the boss.

>>>>Get used to it.

>>>And what if, as is the case on some machines, there is necessary loss in
>>>moving between registers and memory? We should not "get used to it."
>>>Both hardware and software are to serve people, not the other way around.

>>Then the optimizer will place some of those variables in registers. If
>>you want, you can indicate which ones can be placed in registers, and,
>>depending on the compiler, it might give those some priority in
>>determining which variables should be registers. So what's the problem?

>The current so-called optimizing compilers will usually do a better job
>than the programmer who does not, or cannot, consider efficiency.

There's that "so-called" again. Seen any good compilers lately?

> One
>can liken the situation to a programmer for an automobile autopilot which
>can optimize over the routes the compiler writer considered, but will not
>allow picking an alternate route because of traffic, nor even allow the
>car to be backed into the driveway so the garage can be washed.

I'm not sure I understand this metaphor, but I think it amounts to an
argument for using an assembler in certain situations. I would not
disagree with this opinion, though I personally believe that the
difference between C and assembler has been overstated.

I don't see how this metaphor can be used as an argument for changing
the ANSI C standard in a way that would only break existing programs
and reduce the portability of ANSI C code. In any event, it does not
reflect the way things actually _are_.

--
D.R.

From: usan...@king.mcs.drexel.edu (Shawn Anderson)
Newsgroups: comp.lang.c.moderated
Subject: [Help] Huge Text File I/O
Organization: Drexel University, Dept. of Math. and Comp. Sci.

I am haveing a bit of a problem. I have a text file that is around 1 to 2
megs in size. The structure is just like a raw mail file filled with
internet mail. What I want to be able to do is read it in a access each
individual email. However due to the size, I cannot read the entire thing
in. What I have been trying to due is build an array that stores the file
offset of the beginning of each email, and then just seek to the correct
place, however this is not working. I get the correct offsets, but when I
seek to that offset later, the file pointer does not point to the same
place as when I read in the file. Then when I try to read from the specified
location my program crashes. Anybody have any ideas. Thanx...

Shawn Anderson

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
- Horngren's Observation: = For every complex problem, there =
= Among economists, the real - is a solution that is simple, -
- world is often a special case. = neat, and completely wrong. =
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
- InterNet : usan...@mcs.drexel.edu =
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Newsgroups: comp.lang.c.moderated
From: j...@and.nl (Jos Horsmeier)
Subject: Re: Which operators can CPP use?
Organization: AND Software B.V., Rotterdam
References: <3m6fvp$8...@solutions.solon.com>

In article <3m6fvp$8...@solutions.solon.com> sch...@asgard.lpl.arizona.edu writes:

The C preprocessor knows next to nothing about the C language syntax.
All it can handle are the `Lego blocks' of the language -- the so
called preprocessor-tokens (short: pp-tokens). The C preprocessor
is no more, and no less, than a batch, line oriented editor, i.e.
it can replace, insert or delete streams of pp-tokens from its
input. There's one notable exception though: part of the C preprocessor
syntax reads:

#if constant-expression
#elif constant-expression

This constant expression is just another sequence of pp-tokens and
it can include macro names and all the other Lego blocks the pre-
precessor knows about. This sequence of pp-tokens is treated just
as the rest of the input, i.e. macro replacement is performed on it.

If the tokend `defined' ends up in this list of pp-tokens in the
form:

defined identifier

define ( identifier )

the sequence is replaced with a single `0' or `1' if the `identifier'
is (not) defined as a macro name. That's all there is to it. All
other identifiers in the pp-token stream (making up the constant
expression) are replaced by a single `0'. A footnote in the Standard
is very simple about it:

ISO 6.8.1 Conditional inclusion (footnote 83)

`Because the controlling constqant expression is evaluated during
translation phase 4, all identifiers either are or are not macro
names -- there simply are no keywords, enumeration constants, etc.

The following expamples are all valid constant expression (to the
C preprocessor that is) and they all yield a zero value:

sizeof *p
while + for
sin*x + cos*x

On the other hand, constant expressions handled by the C preprocessor
can be as complex as any other expression, as long as they obey to
what that footnote (see above) said about them:

#if !(defined(MSDOS) ^ defined(unix))
#error Help!, this machine is schizophrenic or alien!
#endif

#if defined(WIN95) && defined(MSDOS)
#error Hey Bill, you didn't tell us that ...
#endif

#if (INT_MAX >> 16) == 0
#error This machine is too tight for me ...
#endif

#define ten 10+
#define bottles 16
#define of <<
#define beer 1
#if ten (bottles of beer) != 42
#error darn ...
#endif

In all other contexts, constant expressions are not evaluated by
the C preprocessor, i.e. they're simply passed to the next phases
of the compiler. It's the only place where they can be evaluated.
Your example:

#define JMAX 100

int a[JMAX+5];

is processed by the C preprocessor into tokens like this:

`int' `a' `[' '100' `+' `5' `]' `;'

and the next phases will handle the constant expression `100+5' ...
Note that some of the restrictions do not apply anymore in those
next phases -- the `sizeof' operator does what you expect it to
do, casts can be performed on operands, identifiers can be used
in simple contexts, etc. etc.

does this clarify things a bit?

kind regards,

Jos aka j...@and.nl

0 new messages