C is too old? opinions?

J

jaysome

jaysome said:
It does not necessarily break down. Just because you use an include
guard macro name that begins with "E", it only breaks down if the
implementation has defined a macro with the same name in <errno.h>,
and that file is included in the same translation unit that includes
your header file.

That's the opposite of what the C standard says:

N869
7.26 Future library directions
[#1] The following names are grouped under individual
headers for convenience. All external names described below
are reserved no matter what headers are included by the
program.

You are correct. Even ANSI/ISO 9899-1990 Section 7.13 has the same
wording.

However, the crux of my point still applies.

Best regards
 
P

pete

jaysome said:
jaysome said:
It does not necessarily break down. Just because you use an include
guard macro name that begins with "E", it only breaks down if the
implementation has defined a macro with the same name in <errno.h>,
and that file is included in the same translation unit that includes
your header file.

That's the opposite of what the C standard says:

N869
7.26 Future library directions
[#1] The following names are grouped under individual
headers for convenience. All external names described below
are reserved no matter what headers are included by the
program.

You are correct. Even ANSI/ISO 9899-1990 Section 7.13 has the same
wording.

However, the crux of my point still applies.

It's simpler to start header guards with an H_
than it is to consider which standard headers
are being included in a C file,
or will be included at some future date.
 
P

pete

=?utf-8?B?SGFyYWxkIHZhbiBExLNr?= said:
jaysome said:
It does not necessarily break down. Just because you use an include
guard macro name that begins with "E", it only breaks down if the
implementation has defined a macro with the same name in <errno.h>,
and that file is included in the same translation unit that includes
your header file.

That's the opposite of what the C standard says:

N869
7.26 Future library directions
[#1] The following names are grouped under individual
headers for convenience. All external names described below
are reserved no matter what headers are included by the
program.

An external name is an identifier that has external linkage.
Macros are internal names (n1124 6.4.2.1),
OK

and E[0-9A-Z]* are only reserved as
macro names in <errno.h>.
 
G

goose

jaysome said:
jaysome said:
It does not necessarily break down. Just because you use an include
guard macro name that begins with "E", it only breaks down if the
implementation has defined a macro with the same name in <errno.h>,
and that file is included in the same translation unit that includes
your header file.

That's the opposite of what the C standard says:

N869
7.26 Future library directions
[#1] The following names are grouped under individual
headers for convenience. All external names described below
are reserved no matter what headers are included by the
program.

You are correct. Even ANSI/ISO 9899-1990 Section 7.13 has the same
wording.

However, the crux of my point still applies.

What crux? ETYPES_H is still reserved whether or not
the implementation defines it not.

goose,
etypes.h not that uncommon
 
A

Al Balmer

I guess it is time to fly Airbus.
If GC happens, then things have to pause.
If GC does not happen, then memory grows uncontrollably.

Rather too simplistic a viewpoint.

If anyone is really interested in this, I suggest starting a thread in
comp.arch.embedded, where it would not only be topical, but a number
of knowledgeable people might be persuaded to participate.
 
A

Al Balmer

A toaster IC is an embedded device.

You are saying you cannot imagine .NET on a particular embedded device.

But W Marsh pointed out that Java (which is pretty much the same thing)
does run on embedded devices. In fact I am soon to be embarking
on a project to port a C application to a Java embedded device,
should be a whole barrel o' fun.

.NET started off as Java, but Sun would not let Microsoft add their own
extensions, so Microsoft forked it and renamed to .NET . They are
both garbage-collected languages that compile to a virtual machine
target.

Huh? That's not really what .NET is. Microsoft did try to hijack Java,
and lost the ensuing lawsuit, but I think what it led to was C#, which
could be considered a component of .NET.

It's interesting (but still off-topic) that Java (originally called
Oak) was originally conceived as an embedded system platform.
 
K

Kevin Handy

Old said:
A toaster IC is an embedded device.

Embeded != real-time
You are saying you cannot imagine .NET on a particular embedded device.

Real-time is about handling events in a specific time-frame,
not about running on a limited set of hardware. They are
two seperate issues. You can have real-time operations
running on a mainframe, but that doesn't make the mainframe
an embeded device.
But W Marsh pointed out that Java (which is pretty much the same thing)
does run on embedded devices. In fact I am soon to be embarking
on a project to port a C application to a Java embedded device,
should be a whole barrel o' fun.

But has nothing to do with real-time. embeded != real-time.
.NET started off as Java, but Sun would not let Microsoft add their own
extensions, so Microsoft forked it and renamed to .NET . They are
both garbage-collected languages that compile to a virtual machine
target.

Can you guarantee that all events will be handled within a very
limited time frame? If the garbage-collection could cause it
to fail the time constraints, then it is NOT real-time.

Consider, a program controlling the engines on the space shuttle:
Engine shutoff in 5..4..3..2.. **Garbage Collection Starting**
.... (10 seconds go by) ... **Garbage collection ended** ...
1.. engines shut down... Would you care to be flying on this
shuttle flight?

Or a simplier example: You must generate a square wave on one
thread while munging strings in another. The string munging
thread doesn't know when the square wave thread will kick in.
Could garbage-collecter kicking in ever cause a distorted
square wave? If so, it is NOT real-time.
 
J

John Bode

Dann said:
[snip]
"Real-time Java offers a much more reliable and predictable scheduling
mechanism, memory handling methods, different memory models, a more
predictable threading and synchronization model, asynchronous event
handling, and high-resolution time handling. It makes predictable
execution the first priority in all trade-off decisions, sometimes at
the expense of typical general-purpose computing performance measures.
This is what real-time means."

I predict a titanic flop. The fundamental design of Java makes garbage
collection a necessity. I just hope they don't try to steer rockets with
it.

If you delay garbage collection, yo'll run out of RAM. Who's screaming for
real-time Java anyway? They're morons.

Again, from the Java RTS Web site:

"The RTSJ introduces the concept of two new threads: real-time threads
and no-heap real-time threads (a thread which cannot be interrupted by
garbage collection). These threads offer more precise scheduling than
with standard Java threads. They have 28 levels of priority and unlike
standard Java, their priority is strictly enforced."
 
J

Jack Klein

I'm sure you get my point, but for completeness, it emits

#ifndef _module_filename_h_

Equally bad. That defines an identifier with a leading underscore at
file scope, where all identifiers beginning with an underscore,
followed by anything or nothing, are reserved, per 7.3.
#define _module_filename_h_

#endif

Where module is lower case.

What is it with people and leading and trailing underscores?

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html
 
J

Jack Klein

Well, you may very well end up in trouble typing that. Invading the
implementation's namespace is a no-no. (Using _ followed by another
_ or an UPPERCASE letter is the implementation's namespace).

What exactly is wrong with typing this?:

#ifndef FILE_H_
#define FILE_H_

...

#endif

The problem with this is that you might have a file named something
like enter_data.h, and generate an identifier ENTER_DATA_H_, which
runs afoul of the pattern E<upper case letter> reserved for future
expansion of <errno.h>.

Better to swap around like this:

H_FILE

....because there are no reserved identifiers beginning with "H_" or
"h_". And no need for a trailing underscore at all.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html
 
E

Eric Sosman

Jack said:
[...]
Better to swap around like this:

H_FILE

...because there are no reserved identifiers beginning with "H_" or
"h_". And no need for a trailing underscore at all.

Perhaps that should be "there are AS YET no reserved
identifiers ..." ;-)

I have it on reliable authority (the entrails of a goat)
that C0x will reserve all identifiers containing underscores
at any positions. Also, `length' and `sum' and 'marzipan'
will become keywords.

Almost forgot to mention: The strdup() function will at
last enter the Standard library. It will take a string as its
lone argument, and return a newly-allocated string containing
just one occurrence of each unique character in the original.
Hence the name, an abbreviation for "strip duplicates."

(That goat made an awful fuss while I was trying to examine
its entrails, and kicked me several times in the unmentionables.
Maybe it wasn't a goat at all, but a gnu? Either way, I'm sore
as all-get-out; time to try a soothing poultice of chopped
penguin liver.)
 
I

Ian Collins

Jack said:
Equally bad. That defines an identifier with a leading underscore at
file scope, where all identifiers beginning with an underscore,
followed by anything or nothing, are reserved, per 7.3.
7.3 is Complex arithmetic.

7.1.3 states that All identifiers that begin with an underscore are
always reserved for use as identifiers with file scope in both the
ordinary and tag name spaces.

All identifiers beginning with a double underscore or an underscore and
a capital letter are reserved for any use.
 
W

Wade Ward

3

--
-- --
-- I'm using a bst to kill bugs today. 32 kills so far. That is an
authentic task.

During sorting, the most important technique is pre-selection, the
neceassayrry method for sorters who last more than 2 weeks at ups. Sara was
the best before I walked into the building. King Rooster.

n s ? foot / hand

e w ? hand \ foot

No survivors for n, e> 0. La cooka rach tja.
--
-- --
--
Wade Ward

"In any given barnyard, there can be only one rooster."
Wade Ward
"I put my pants on like any other 6: between four and a dozen failures."
{~._.~} The Naked Picture Poster from Down Under
`( Y )`
Jack Klein said:
Equally bad. That defines an identifier with a leading underscore at
file scope, where all identifiers beginning with an underscore,
followed by anything or nothing, are reserved, per 7.3.


What is it with people and leading and trailing underscores?

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

I apologize to you, jack; i've only got 21 hrs. to live and i got a ppp.

mpj
 
P

pete

Jack said:
The problem with this is that you might have a file named something
like enter_data.h, and generate an identifier ENTER_DATA_H_, which
runs afoul of the pattern E<upper case letter> reserved for future
expansion of <errno.h>.

Better to swap around like this:

H_FILE

...because there are no reserved identifiers beginning with "H_" or
"h_". And no need for a trailing underscore at all.

I like the trailing underscore, because I think that the
header guards should have a unique format that is not
likely to be accidentally written in a non header guard macro.

When I had a file named sort.h, I tried a header guard H_SORT,
but there was a problem because the program also had macros like
B_SORT
I_SORT
S_SORT
Q_SORT
and of course: H_SORT

I kept my H_SORT macro for heapsort,
and changed some other things instead.

At this current time, I'm using H_filename_H.
 
K

Keith Thompson

pete said:
I like the trailing underscore, because I think that the
header guards should have a unique format that is not
likely to be accidentally written in a non header guard macro.

When I had a file named sort.h, I tried a header guard H_SORT,
but there was a problem because the program also had macros like
B_SORT
I_SORT
S_SORT
Q_SORT
and of course: H_SORT

I kept my H_SORT macro for heapsort,
and changed some other things instead.

At this current time, I'm using H_filename_H.

Presumably the "filename" portion consists only of letters, digits,
and underscores (i.e., you strip the trailing ".h").
 
C

Charlie Gordon

Keith Thompson said:
Presumably the "filename" portion consists only of letters, digits,
and underscores (i.e., you strip the trailing ".h").

I use PROJECTNAME_PATHNAME

with PROJECTNAME is the name of the project in uppercase.
and PATHNAME is the name of the header file including the relative path in
the project hierarchy, uppercased with all non alphanumeric characters
replaced with underscores.

lib/compress/huffman.h in project zipklone would be protected by

#ifdef ZIPCLONE_LIB_COMPRESS_HUFFMAN_H
#define ZIPCLONE_LIB_COMPRESS_HUFFMAN_H
....
#endif

The scheme leaves little room for collisions and can be automated too.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
474,434
Messages
2,571,691
Members
48,796
Latest member
Greg L.

Latest Threads

Top