Standard Defines

[pemo]

Are there standard macros that a (c99) compliant compiler should support?

I note that in the c99 std that __FILE__ __LINE__ __func__ are
mentioned, but others (that seem to be built in to every compiler I
currently use) like __DATE__ __TIME___ don't appear. Presumably,
__TIME__ etc are just simply 'popular' rather than required?

 

[Richard Heathfield]

pemo said:

Are there standard macros that a (c99) compliant compiler should support?

I note that in the c99 std that __FILE__ __LINE__ __func__ are
mentioned, but others (that seem to be built in to every compiler I
currently use) like __DATE__ __TIME___ don't appear.

Look harder. They are both there.

 

[pemo]

pemo said:


Look harder. They are both there.

So they are!

Interesting - when given __, acrobat reader, finds 7.2.2 (__FILE__ etc),
but nothing else - however, give it DATE, and it finds 6.10.8 - containing
__DATE__ etc! Weird

 

[those who know me have no need of my name]

in comp.lang.c i read:

Are there standard macros that a (c99) compliant compiler should support?

yes. the standard enumerates them.

I note that in the c99 std that __FILE__ __LINE__ __func__ are
mentioned,

__func__ isn't a macro.

but others (that seem to be built in to every compiler I
currently use) like __DATE__ __TIME___ don't appear. Presumably,
__TIME__ etc are just simply 'popular' rather than required?

they are in the list -- see 6.10.8 for the basic list you are after.

 

[Michael Mair]

So they are!

Interesting - when given __, acrobat reader, finds 7.2.2 (__FILE__ etc),
but nothing else - however, give it DATE, and it finds 6.10.8 - containing
__DATE__ etc! Weird

Yep; in most cases, a plain text file is better for searching.
I keep the relevant last public draft around in this form just
for this reason. After finding something there, I still can
look into the standard to verify the information from the draft.

Cheers
Michael

 

[Keith Thompson]

Yep; in most cases, a plain text file is better for searching.
I keep the relevant last public draft around in this form just
for this reason. After finding something there, I still can
look into the standard to verify the information from the draft.

Note that the standard, even in its PDF version, still has an
old-fashioned section at the end called an "index", where you'll find
a number of identifiers starting with "__".

 

[pemo]

Yep; in most cases, a plain text file is better for searching.
I keep the relevant last public draft around in this form just
for this reason. After finding something there, I still can
look into the standard to verify the information from the draft.

Hmmm - must check to see if Acrobat files can be saved as 'test' - the
search facility in Acrobat can only get better - can't it??

 

[pemo]

Note that the standard, even in its PDF version, still has an
old-fashioned section at the end called an "index", where you'll find
a number of identifiers starting with "__".

Yup, you're right Keith - sometimes I think (realise!) that despite all my
years/education - well - I'm basically pretty dumb ... or, yet another way
to look at that ... I should at least try everything in the book *before* I
ask such stuff. MEMO TO SELF!

 

[Michael Mair]

Note that the standard, even in its PDF version, still has an
old-fashioned section at the end called an "index", where you'll find
a number of identifiers starting with "__".

*g* Yep, should have mentioned this curious device.

However, even though the standard's index is rather complete,
it is still a technical book and suffers in part from the
useless index syndrome: You often have to know the answer and part
of the wording used in the answer to find the answer when using
index and table of contents. (The only technical book with an
index that could -- with one level of indirection, of course --
up to now answer all my questions is the second edition of the
LaTeX Companion; this is in part because I did not use it much
but in part because the team of authors had a pro making the index.)

If the author or the team writing the book does not aim at an
excellent index from the beginning, then the index often is the
part which suffers when time and money grow short...
Whenever I write some technical text where I am not bound to use
a well-known text "processing" tool out of Redmond, the index
indeed is part of the writing process. This way, I have only to
weed out the unnecessary parts; in addition, I ask friends to
"ask" the text questions and try to answer them in a couple of
minutes using the index.

Cheers
Michael

 

[Flash Gordon]

Hmmm - must check to see if Acrobat files can be saved as 'test' - the
search facility in Acrobat can only get better - can't it??

If not, then in windows you can create a "printer" attached to port
"file:" of type "Generic / Text Only" which will probably be good
enough. In *nix there are other methods to generate a text file from a PDF.

 

[Mark McIntyre]

Yep; in most cases, a plain text file is better for searching.

You guys must have badly broken PDF readers

I find the pdf just fine to search, takes about 2 seconds to search
the whole thing, and no problems finding all the things we've talked
about here.

 

[lawrence.jones]

Interesting - when given __, acrobat reader, finds 7.2.2 (__FILE__ etc),
but nothing else - however, give it DATE, and it finds 6.10.8 - containing
__DATE__ etc! Weird

That may be because there's actually a very thin space between the two
underscores (otherwise they tend to blend together, making it hard to
tell that they're two separate characters). I don't know why it would
find some and not the others, though.

-Larry Jones

You don't get to be Mom if you can't fix everything just right. -- Calvin

 

[lawrence.jones]

However, even though the standard's index is rather complete,
it is still a technical book and suffers in part from the
useless index syndrome: You often have to know the answer and part
of the wording used in the answer to find the answer when using
index and table of contents.

Hopefully it's better than the complete useless indexes that are
automatically generated and thus contain every mention of a term without
any clue as to which are actually interesting and which are not. I'm
always open to suggestions for improvements either directly or via
comp.std.c.

-Larry Jones

Some people just don't have inquisitive minds. -- Calvin

 

[Michael Mair]

You guys must have badly broken PDF readers

I find the pdf just fine to search, takes about 2 seconds to search
the whole thing, and no problems finding all the things we've talked
about here.

Well, there are things, especially in code examples, that
I cannot find via AR or xpdf. This may be a problem of the
pdf file itself. Having had enough fun with "intelligent"
pdf generation, I use the much more "grep"able text files...

Cheers
Michael

 

[Michael Mair]

Hopefully it's better than the complete useless indexes that are
automatically generated and thus contain every mention of a term without
any clue as to which are actually interesting and which are not.

Definitely!
Also better than the standard publisher-provided index.

I'm
always open to suggestions for improvements either directly or via
comp.std.c.

As it is a standard document, it is fine as it is.
I have no suggestions; however, sometimes I wish for a
meta-index giving someone who does not breathe the
terminology daily the right keywords to look for.

However, it never occurred to me to just ask for a
certain index entry. I will keep a list now...

Cheers
Michael

 

[pemo]

If not, then in windows you can create a "printer" attached to port
"file:" of type "Generic / Text Only" which will probably be good enough.
In *nix there are other methods to generate a text file from a PDF.

Found File | Save as Text ... in Acrobat - worked ok. Also tried the file:
generic printer thing, but when I 'printed' to that, the output was
unreadable (like as though one had opened a binary file).