Standard Defines
pemo
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
> 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.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
pemo
"Richard Heathfield" <inv...@invalid.invalid> wrote in message
news:dmmna5$rqk$1...@nwrdmz02.dmz.ncs.ea.ibs-infra.bt.com...
> 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.
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
>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.
--
a signature
Michael Mair
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
--
E-Mail: Mine is an /at/ gmx /dot/ de address.
Keith Thompson
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 "__".
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
pemo
"Michael Mair" <Michae...@invalid.invalid> wrote in message
news:3v9cajF...@individual.net...
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
"Keith Thompson" <ks...@mib.org> wrote in message
news:lnu0dsh...@nuthaus.mib.org...
> Michael Mair <Michae...@invalid.invalid> writes:
>> pemo wrote:
>>> "Richard Heathfield" <inv...@invalid.invalid> wrote in message
>>> news:dmmna5$rqk$1...@nwrdmz02.dmz.ncs.ea.ibs-infra.bt.com...
>>>
>>>>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.
>>> 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.
>
> 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
> Michael Mair <Michae...@invalid.invalid> writes:
>
>>pemo wrote:
>>
>>>"Richard Heathfield" <inv...@invalid.invalid> wrote in message
>>>news:dmmna5$rqk$1...@nwrdmz02.dmz.ncs.ea.ibs-infra.bt.com...
>>>
>>>
>>>>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.
>>>
>>>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.
>
> 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.
Mark McIntyre
<Michae...@invalid.invalid> wrote:
>
>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.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Flash Gordon
> "Michael Mair" <Michae...@invalid.invalid> wrote in message
> news:3v9cajF...@individual.net...
<snip>
>> 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??
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.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.
lawrenc...@ugs.com
>
> 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
lawrenc...@ugs.com
>
> 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
> On Thu, 01 Dec 2005 23:38:01 +0100, in comp.lang.c , Michael Mair
> <Michae...@invalid.invalid> wrote:
>
>>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.
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...
Michael Mair
> Michael Mair <Michae...@invalid.invalid> wrote:
>
>>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.
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...
pemo
"Flash Gordon" <sp...@flash-gordon.me.uk> wrote in message
news:l0d463x...@news.flash-gordon.me.uk...
> pemo wrote:
>> "Michael Mair" <Michae...@invalid.invalid> wrote in message
>> news:3v9cajF...@individual.net...
>
> <snip>
>
>>> 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??
>
> 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).