C is too old? opinions?

[Lasse Espeholt]

Hi...

I am relativ new to the impressive and powerfull C language, but i
thinks it is obsolete...

The idea with header/source files where methods can clash into
eachother i don't like... Look at C# which is much cleaner with
namespaces.

Why has C not namespaces and a "area idea" where some methods and
fields could be hidden from the outside?

Something like:

a_source_file.c:

namespace SomeName(.SomeName)
{
area Stack
{
private int[] myStack;

private void someMethod() {};

public void push(int i) {};
public int pop() {};
}
}

another_source_file.c:

using SomeName(.SomeName);

int main(int argc, char[] *argv)
{
Stack.push(10);
System.printf(Stack.pop());
}

I'm really annoyed ;) Is im the only own with that point of view?

If i was a really good programmer (which i'm not... yet! ;)) i would
developed a compiler and a much more simple (but still impressive and
powerfull) c...

Best and kindest regards
Lasse Espeholt

[Keith Thompson]

W Marsh <wa*********@gmail.comwrites:
[...]

Go on then - I would like to know how garbage collection affects
real-time systems. A good reason, showing thought and reason. In other
words, show us that you're not just full of shit.

Bear in mind that garbage collection shouldn't affect the behaviour of
a system, only its constraints.

My understanding is that typical garbage collection systems
occasionally through periods of intense activity to gather information
about memory that can be reclaimed. It's difficult or impossible to
predict when these periods will occur or how much CPU time they'll
take. The result can be a missed deadline, which is unacceptable in a
hard real-time system.

* Exactly how precise do you think a toaster timer needs to be?

I don't know, but if you can't guarantee a reasonable upper bound on
any unpredictable delays, you could end up with burned toast or worse.

Possibly garbage collection could be safely used in a toaster, but I
wouldn't use it in a real safety-critical system. (And how much
dynamic memory allocation does a toaster need to do?)

I'm not an expert on either garbage collection or real-time systems.
Feel free to correct me if I'm mistaken.

--
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.

[pete]

W Marsh wrote:

>
On Thu, 13 Jul 2006 11:53:06 -0700, "Dann Corbit" <dc*****@connx.com>
wrote:

I think you have a reading comprehension problem.

You were lumping Java and .NET together, suggesting that they were
inadequate in real-time systems for the same reason.

Go on then - I would like to know how garbage collection affects
real-time systems.

http://www.devx.com/tips/Tip/13491

Many programming languages are unsuitable for real time
programming due to their non-deterministic nature. For example,
languages that have a built-in garbage collector are very problematic
because the garbage collector might "wake up" at the wrong moment,
halting all other operations until it finishes. A real time software
application that controls the amount of fuel supplied to an airplane's
engine at lift off cannot be interrupted by a garbage collector, not
even momentarily.

Bear in mind that garbage collection shouldn't affect the behaviour of
a system, only its constraints.

* Exactly how precise do you think a toaster timer needs to be?

A toaster timer has nothing to do with real time programming.

Followup To: comp.programming

--
pete

[Dann Corbit]

"W Marsh" <wa*********@gmail.comwrote in message
news:d4********************************@4ax.com...

On Thu, 13 Jul 2006 11:53:06 -0700, "Dann Corbit" <dc*****@connx.com>
wrote:

>>"W Marsh" <wa*********@gmail.comwrote in message
news:oc********************************@4ax.com. ..

>>On Thu, 13 Jul 2006 11:45:02 -0700, "Dann Corbit" <dc*****@connx.com>
wrote:

Languages do not age the way that people think they do.
COBOL and BASIC are alive and well.
C will never go away.
For writing simple filter programs, it is a very good alterative.
Languages like C# and Java have to go garbage collection and hence are
unsuitable for real-time stuff.
Can you imagine .NET installed on a toaster IC to pop your toast up in
the
morning? I can't.
Java is used extensively on embedded devices. You're making yourself
look a bit silly, there.

How does your response relate to my post?

Is Java used for real-time systems (if so, they should fire the product
implementors for incompetence).

Does Java require .NET?

I think you have a reading comprehension problem.

You were lumping Java and .NET together, suggesting that they were
inadequate in real-time systems for the same reason.

I was lumping them together for real time systems. Your connection was
faulty and not implied in my message.

>I assumed you
must have been talking about embedded stuff as well because of your
vague reasoning and toaster example*. In other words, you seemed
confused. I made a logical leap as required.

The toaster example has nothing to do with real time systems. Your leap was
not logical.

Go on then - I would like to know how garbage collection affects
real-time systems. A good reason, showing thought and reason. In other
words, show us that you're not just full of shit.

I'm full of crap and you're a genius. I can tell immediately, and there is
no sense trying to talk to you about it.

Bear in mind that garbage collection shouldn't affect the behaviour of
a system, only its constraints.

It affects how long delays can be. That is important for real time systems.

* Exactly how precise do you think a toaster timer needs to be?

I have no idea. And it has nothing whatsoever to do with real-time
programming.

Another example of where C is an excellent choice is with DSPs and other
things of that nature. That is why you will find so many C compilers for
that arena.

If you want to write a toaster controller using embedded Java, that would be
fine

[Dann Corbit]

"John Bode" <jo*******@my-deja.comwrote in message
news:11**********************@m73g2000cwd.googlegr oups.com...
[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.

[Ancient_Hacker]

Whew, "real-time" and "Java" in the same sentence.
A few gotchas:

(1) Your traditional garbage collector can really muck-up any attempts
at begin "real-time".
Real-time to a lot of folks means that the CPU can handle interrupts
and execute code at any time. Usually when you're in a
garbage-collecting phase, you're recursed down about 5 levels into some
complex object and can't just hand off to the main programas there's
lots of dangling pointers. If you can't hand off aninterrupt to code
in 5 microseconds, I'm not interested.

I'm not saying its impossible to write an interruptible garbage
collector, I just wouldnt like to haev to implement or probably, use
one.

(2) With Java you get an extreme amount of flexibility, dynamicness,
(is that a word), and security. Problem is, most real-time apps need
more "real-time" performance, and not so much of those other things.
You can't have everything. When the crunch comes, a real-time app
needs what Java can't provide, and can't be removed from the language,
and doesnt need about 60% of what's in Java.

[jjf]

Keith Thompson wrote:

>
... if you can't guarantee a reasonable upper bound on
any unpredictable delays, you could end up with burned toast or worse.

But ... but ... what could be worse?

[Dann Corbit]

"Ancient_Hacker" <gr**@comcast.netwrote in message
news:11**********************@h48g2000cwc.googlegr oups.com...

Whew, "real-time" and "Java" in the same sentence.
A few gotchas:

(1) Your traditional garbage collector can really muck-up any attempts
at begin "real-time".
Real-time to a lot of folks means that the CPU can handle interrupts
and execute code at any time. Usually when you're in a
garbage-collecting phase, you're recursed down about 5 levels into some
complex object and can't just hand off to the main programas there's
lots of dangling pointers. If you can't hand off aninterrupt to code
in 5 microseconds, I'm not interested.

I'm not saying its impossible to write an interruptible garbage
collector, I just wouldnt like to haev to implement or probably, use
one.

(2) With Java you get an extreme amount of flexibility, dynamicness,
(is that a word), and security. Problem is, most real-time apps need
more "real-time" performance, and not so much of those other things.
You can't have everything. When the crunch comes, a real-time app
needs what Java can't provide, and can't be removed from the language,
and doesnt need about 60% of what's in Java.

I'm not saying it is impossible to do it either, just that it's a really bad
idea.

Consider (for instance) the Tour de France [it's a bicycle race for the
non-bike-racing folks].

Recumbent bicycles with fairings are now allowed for the time trial events.
If they were, and the stages were flat, faired recumbent bikes would smoke
the traditional diamond frames. So it is just tradition that prevents their
usage (they would be an actually superior alternative).

Suppose (for instance) that someone suggested using scooters for time
trials. You could put fairings on the scooters. And you could stand on 12
foot stilts to get a really long throw on each kick. But it's still a
scooter.

In the same way, you could tweak and munge and twist Java to make it sort of
work in a real-time environment. But it is (without question) cramming the
square peg into the round hole.

If it's not time critical, and if nobody is going to die if it should delay,
then for embedded things Java should be fine. So make toast with it, if you
like. After all, what's better than toast and Java in the morning.

[goose]

jj*@bcs.org.uk wrote:

Keith Thompson wrote:

... if you can't guarantee a reasonable upper bound on
any unpredictable delays, you could end up with burned toast or worse.

But ... but ... what could be worse?

You drop it on the floor, it lands butter-side down :-)

goose,
search google for an ignoble award wrt toast

[Morris Dovey]

jj*@bcs.org.uk (in
11**********************@s13g2000cwa.googlegroups. com) said:

| Keith Thompson wrote:
||
|| ... if you can't guarantee a reasonable upper bound on
|| any unpredictable delays, you could end up with burned toast or
|| worse.
|
| But ... but ... what could be worse?

Setting fire to the kitchen. I'm not kidding - my ex managed to set
the kitchen curtains on fire, not just once, but _twice_ with a GE
Toast-R-Oven! Her explanation, both times, was that she'd been too
busy to pay attention...

Had to trade her in for a real-time model (no kitchen fires since.)

--
Morris Dovey
DeSoto Solar
DeSoto, Iowa USA
http://www.iedu.com/DeSoto

[Mark McIntyre]

On Thu, 13 Jul 2006 00:23:36 +0200, in comp.lang.c , Lasse Espeholt
wrote:

>
I like to have namespaces and using... ;)

"using" is an abomination.
C++ requires headers to just the same extent as C, so any comparison
there is meaningless.
You need to step over into Java to get what you want, and frankly the
syntax there is gruesome.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Flash Gordon]

Keith Thompson wrote:

W Marsh <wa*********@gmail.comwrites:
[...]

>Go on then - I would like to know how garbage collection affects
real-time systems. A good reason, showing thought and reason. In other
words, show us that you're not just full of shit.

Bear in mind that garbage collection shouldn't affect the behaviour of
a system, only its constraints.

My understanding is that typical garbage collection systems
occasionally through periods of intense activity to gather information
about memory that can be reclaimed. It's difficult or impossible to
predict when these periods will occur or how much CPU time they'll
take. The result can be a missed deadline, which is unacceptable in a
hard real-time system.

Sometimes you need a predictable time interval between an external event
(generally an interrupt) and some specified action. It might not matter
whether that time is 500ns, 600ns or what, just that it does not vary by
more than some specified limit. This can be an even harder time
constraint to meet that taking at most some specific time.

If the garbage collection is on a timer interrupt, for example, you
could always just disable the interrupt during the critical period.

>* Exactly how precise do you think a toaster timer needs to be?

I don't know, but if you can't guarantee a reasonable upper bound on
any unpredictable delays, you could end up with burned toast or worse.

Indeed.

Possibly garbage collection could be safely used in a toaster, but I
wouldn't use it in a real safety-critical system. (And how much
dynamic memory allocation does a toaster need to do?)

I'm not an expert on either garbage collection or real-time systems.
Feel free to correct me if I'm mistaken.

It is not just safety-critical systems where this can be an issue. You
can also have hard real-time constraints on video processing and motor
control. On one of the motor control systems with interesting control
loops and IR video systems in my time, amongst other things, and none of
them were safety critical. I've also worked on one safety critical
project, and the real-time aspects where nowhere near as tight.
--
Flash Gordon, living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidelines and intro:
http://clc-wiki.net/wiki/Intro_to_clc

[Default User]

Dann Corbit wrote:

"John Bode" <jo*******@my-deja.comwrote in message
news:11**********************@m73g2000cwd.googlegr oups.com... [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.

We're looking at it very seriously for avionics systems. I wouldn't
hand-wave it away.


Brian

[Sjouke Burry]

W Marsh wrote:

On Thu, 13 Jul 2006 11:53:06 -0700, "Dann Corbit" <dc*****@connx.com>
wrote:

>>"W Marsh" <wa*********@gmail.comwrote in message
news:oc********************************@4ax.com. ..

>>>On Thu, 13 Jul 2006 11:45:02 -0700, "Dann Corbit" <dc*****@connx.com>
wrote:
Languages do not age the way that people think they do.
COBOL and BASIC are alive and well.
C will never go away.
For writing simple filter programs, it is a very good alterative.
Languages like C# and Java have to go garbage collection and hence are
unsuitable for real-time stuff.
Can you imagine .NET installed on a toaster IC to pop your toast up in the
morning? I can't.
Java is used extensively on embedded devices. You're making yourself
look a bit silly, there.

How does your response relate to my post?

Is Java used for real-time systems (if so, they should fire the product
implementors for incompetence).

Does Java require .NET?

I think you have a reading comprehension problem.

You were lumping Java and .NET together, suggesting that they were
inadequate in real-time systems for the same reason. I assumed you
must have been talking about embedded stuff as well because of your
vague reasoning and toaster example*. In other words, you seemed
confused. I made a logical leap as required.

Go on then - I would like to know how garbage collection affects
real-time systems. A good reason, showing thought and reason. In other
words, show us that you're not just full of shit.

Bear in mind that garbage collection shouldn't affect the behaviour of
a system, only its constraints.

* Exactly how precise do you think a toaster timer needs to be?

How precise does a feedback loop in control
need to be,when the loop goes round 1000
times per second? Even malloc/free can be
to much there.
With LISP as an example, calculating a fractal,
it stopped every 2 seconds,to do garbage collection
for 1 or two seconds.
Things just depend on how real time your
program is,and hoe short your time tick is.
If short enough,any housekeeping job can be to much,
in which case I am glad to have an old
C compiler,without those nice new features.

[WaterWalk]

Lasse wrote:

Hi...

I am relativ new to the impressive and powerfull C language, but i
thinks it is obsolete...

The idea with header/source files where methods can clash into
eachother i don't like... Look at C# which is much cleaner with
namespaces.

Why has C not namespaces and a "area idea" where some methods and
fields could be hidden from the outside?

Something like:

a_source_file.c:

namespace SomeName(.SomeName)
{
area Stack
{
private int[] myStack;

private void someMethod() {};

public void push(int i) {};
public int pop() {};
}
}

another_source_file.c:

using SomeName(.SomeName);

int main(int argc, char[] *argv)
{
Stack.push(10);
System.printf(Stack.pop());
}

I'm really annoyed ;) Is im the only own with that point of view?

If i was a really good programmer (which i'm not... yet! ;)) i would
developed a compiler and a much more simple (but still impressive and
powerfull) c...

Best and kindest regards
Lasse Espeholt

Sometime earlier, I've asked similar question about why not add
namespace to c. That thread may have something that interests you.

http://groups.google.com/group/comp....d539c84ac08458

[Dann Corbit]

"Default User" <de***********@yahoo.comwrote in message
news:4h***********@individual.net...

Dann Corbit wrote:

>"John Bode" <jo*******@my-deja.comwrote in message
news:11**********************@m73g2000cwd.googleg roups.com... [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.

We're looking at it very seriously for avionics systems. I wouldn't
hand-wave it away.

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.
I have done lots of .NET stuff, and I can tell you that it could never be
used for real-time stuff that I would trust, even if you manually call the
collector frequently. Both timing and memory size sometimes get flaky
(external routines may be out of your control, for instance). I have done a
little bit of Java (not the realtime flavor) and it behaved similarly, but I
am not nearly so expert there.

If such a thing should come to pass, I would hope and pray that (for
example) a collision avoidance system were not written in any GC language.
I would quit the job before I did that.

Of course, there may be some miracle that allows GC languages to both run GC
super-rapidly with no ballooning of memory usage.

If you really do choose such a system, I hope that you test the ever-loving
spots off of it and buy a huge insurance policy from SUN in the event that
it piles an airplane into a mountainside.

Brian

[Old Wolf]

Dann Corbit wrote:

"W Marsh"wrote:

> "Dann Corbit" wrote:

>>>Can you imagine .NET installed on a toaster IC to pop your toast up in the
morning? I can't.

Java is used extensively on embedded devices. You're making yourself
look a bit silly, there.

How does your response relate to my post?

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.

[Richard Heathfield]

Dann Corbit said:

<snip>

>
If you really do choose such a system, I hope that you test the
ever-loving spots off of it and buy a huge insurance policy from SUN in
the event that it piles an airplane into a mountainside.

By then, it's too late to buy insurance.

--
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)

[jaysome]

On Thu, 13 Jul 2006 10:30:54 -0700, Ben Pfaff <bl*@cs.stanford.edu>
wrote:

>Keith Thompson <ks***@mib.orgwrites:

>>Andrew Poelstra wrote:
What exactly is wrong with typing this?:

#ifndef FILE_H_
#define FILE_H_

Neither FILE_H_ nor H_FILE is in the implementation's namespace.
There's no problem with trailing underscores, only leading ones.

Unfortunately, the FILE_H approach breaks down for files whose
names begin with "e". H_FILE is a better way from that
viewpoint.

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.

Most if not all implementations define macros in <errno.husing a
convention that begins with an "E" followed by all uppercase
characters. The probability of a user-defined include guard macro
named something like the regular expression "E[0-9A-Z]*_H" or better
yet "E[0-9A-Z]+_H_INCLUDED_" is zero for all practical purposes.

Nevertheless, I learned something from your post as I was not aware of
the reserved "E.*" macro names. The pedantic side of me says that I
should have coded my DevStudio macro (i.e., macro in the sense of a
DevStudio script) to have used "H_FILE_INCLUDED_" instead of
"FILE_H_INCLUDED_" for the automatically inserted include guard.

Best regards
--
jay

[pete]

jaysome wrote:

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.
--
pete

[Harald van Dijk]

pete wrote:

jaysome wrote:

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), and E[0-9A-Z]* are only reserved as
macro names in <errno.h>.

[jaysome]

On Fri, 14 Jul 2006 07:50:03 GMT, pete <pf*****@mindspring.comwrote:

>jaysome wrote:

>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
--
jay

[pete]

jaysome wrote:

>
On Fri, 14 Jul 2006 07:50:03 GMT, pete <pf*****@mindspring.comwrote:

jaysome wrote:

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.

--
pete

[pete]

=?utf-8?B?SGFyYWxkIHZhbiBExLNr?= wrote:

>
pete wrote:

jaysome wrote:

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>.

--
pete

[goose]

jaysome wrote:

On Fri, 14 Jul 2006 07:50:03 GMT, pete <pf*****@mindspring.comwrote:

jaysome wrote:

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

[Al Balmer]

On Thu, 13 Jul 2006 18:49:31 -0700, "Dann Corbit" <dc*****@connx.com>
wrote:

>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.

--
Al Balmer
Sun City, AZ

[Al Balmer]

On 13 Jul 2006 19:06:13 -0700, "Old Wolf" <ol*****@inspire.net.nz>
wrote:

>Dann Corbit wrote:

>"W Marsh"wrote:

>> "Dann Corbit" wrote:
Can you imagine .NET installed on a toaster IC to pop your toast up in the
morning? I can't.

Java is used extensively on embedded devices. You're making yourself
look a bit silly, there.

How does your response relate to my post?

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.

--
Al Balmer
Sun City, AZ

[Default User]

Dann Corbit wrote:

"Default User" <de***********@yahoo.comwrote in message
news:4h***********@individual.net...

We're looking at it very seriously for avionics systems. I wouldn't
hand-wave it away.

I guess it is time to fly Airbus.

It's nice that you think our R&D wing is a bunch of morons.


Brian

[Kevin Handy]

Old Wolf wrote:

>
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.

----== 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 =----

[John Bode]

Dann Corbit wrote:

"John Bode" <jo*******@my-deja.comwrote in message
news:11**********************@m73g2000cwd.googlegr oups.com...
[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."

[Jack Klein]

On Thu, 13 Jul 2006 11:01:16 +1200, Ian Collins <ia******@hotmail.com>
wrote in comp.lang.c:

Richard Heathfield wrote:

Ian Collins said:

>Lasse Espeholt wrote:

<snip>

>>with includes you shall write "ifndef __FILE_H__" otherwise you could
end up in trouble.
I don't, my boilerplate generator does.

I hope not. I hope it puts a # at the beginning, and I hope it omits those
leading underscores. If not, it's broken.

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

[Jack Klein]

On Wed, 12 Jul 2006 22:46:05 GMT, Andrew Poelstra
<ap*******@nowhereat.allwrote in comp.lang.c:

On 2006-07-12, Lasse Espeholt <Lassewrote:

On 2006-07-13 00:29:04 +0200, Ian Collins <ia******@hotmail.comsaid:

Lasse Espeholt wrote:
On 2006-07-13 00:19:03 +0200, Ian Collins <ia******@hotmail.comsaid:

I like to have namespaces and using... ;)

So what's the difference in typing a few includes or the equivalent
using directives?

with includes you risk that the files have functions there have the same name.

with includes you shall write "ifndef __FILE_H__" otherwise you could
end up in trouble.

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 letterreserved 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

[Eric Sosman]

Jack Klein wrote:

[...]
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.)

--
Eric Sosman
es*****@ieee-dot-org.invalid

[Ian Collins]

Jack Klein wrote:

On Thu, 13 Jul 2006 11:01:16 +1200, Ian Collins <ia******@hotmail.com>
wrote in comp.lang.c:

Why reply to something I wrote over 15 months ago?

--
Ian Collins.

[Ian Collins]

Jack Klein wrote:

On Thu, 13 Jul 2006 11:01:16 +1200, Ian Collins <ia******@hotmail.com>
wrote in comp.lang.c:

>>>

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.

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.

--
Ian Collins.

[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, e0. 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" <ja*******@spamcop.netwrote in message
news:26********************************@4ax.com...

On Thu, 13 Jul 2006 11:01:16 +1200, Ian Collins <ia******@hotmail.com>
wrote in comp.lang.c:

>Richard Heathfield wrote:

Ian Collins said:
Lasse Espeholt wrote:

<snip>

with includes you shall write "ifndef __FILE_H__" otherwise you could
end up in trouble.
I don't, my boilerplate generator does.
I hope not. I hope it puts a # at the beginning, and I hope it omits
those
leading underscores. If not, it's broken.

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

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

mpj

[Roberto Waltman]

Eric Sosman wrote:

>... Also, ... 'marzipan' ... will become keywords.

I hope not. That would break all the C code I ever wrote.
--
Roberto Waltman

[ Please reply to the group,
return address is invalid ]

[pete]

Jack Klein wrote:

>
On Wed, 12 Jul 2006 22:46:05 GMT, Andrew Poelstra
<ap*******@nowhereat.allwrote in comp.lang.c:

On 2006-07-12, Lasse Espeholt <Lassewrote:

On 2006-07-13 00:29:04 +0200,
Ian Collins <ia******@hotmail.comsaid:
>Lasse Espeholt wrote:
>>On 2006-07-13 00:19:03 +0200,
>>Ian Collins <ia******@hotmail.comsaid:
>>>
>>I like to have namespaces and using... ;)
>>>
>So what's the difference in typing
>a few includes or the equivalent using directives?
>
with includes you risk that the files
have functions there have the same name.
>
with includes you shall write
"ifndef __FILE_H__" otherwise you could end up in trouble.
>

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 letterreserved 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.

--
pete

[Keith Thompson]

pete <pf*****@mindspring.comwrites:
[...]

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").

--
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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[pete]

Keith Thompson wrote:

>
pete <pf*****@mindspring.comwrites:
[...]

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").

It's easier for me to show than to describe.
It's like this:
/* BEGIN e_sort.h */

#ifndef H_E_SORT_H
#define H_E_SORT_H
/*
** Stuff
*/
#endif

/* END e_sort.h */
http://www.mindspring.com/~pfilandr/C/e_driver/e_sort.h

--
pete

[Charlie Gordon]

"Keith Thompson" <ks***@mib.orga écrit dans le message de news:
ln************@nuthaus.mib.org...

pete <pf*****@mindspring.comwrites:
[...]

>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").

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.

--
Chqrlie.

[jacob navia]

Charlie Gordon wrote:

"Keith Thompson" <ks***@mib.orga écrit dans le message de news:
ln************@nuthaus.mib.org...

>pete <pf*****@mindspring.comwrites:
[...]

>>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").

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.

Why not

#pragma once

Chqrlie?

[Joachim Schmitz]

"jacob navia" <ja***@jacob.remcomp.frschrieb im Newsbeitrag
news:46**********************@news.orange.fr...

Charlie Gordon wrote:

>"Keith Thompson" <ks***@mib.orga écrit dans le message de news:
ln************@nuthaus.mib.org...

>>pete <pf*****@mindspring.comwrites:
[...]
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").

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.

Why not

#pragma once

Because it's not supported on every compiler, unfortunatly.
It's a common extension, but not in the Standard.

Bye, Jojo

[Joachim Schmitz]

"pete" <pf*****@mindspring.comschrieb im Newsbeitrag
news:46***********@mindspring.com...

Jack Klein wrote:

>>
On Wed, 12 Jul 2006 22:46:05 GMT, Andrew Poelstra
<ap*******@nowhereat.allwrote in comp.lang.c:

On 2006-07-12, Lasse Espeholt <Lassewrote:
On 2006-07-13 00:29:04 +0200,
Ian Collins <ia******@hotmail.comsaid:
Lasse Espeholt wrote:
On 2006-07-13 00:19:03 +0200,
Ian Collins <ia******@hotmail.comsaid:

I like to have namespaces and using... ;)

So what's the difference in typing
a few includes or the equivalent using directives?

with includes you risk that the files
have functions there have the same name.

with includes you shall write
"ifndef __FILE_H__" otherwise you could end up in trouble.
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 letterreserved 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.

On a platform that I frequently work with, quite a few API calls have
trailing underscores and are spelled in all-caps.

Bye, Jojo

[Ben Pfaff]

jacob navia <ja***@jacob.remcomp.frwrites:

Why not

#pragma once

Because it doesn't work on every compiler?
--
Ben Pfaff
http://benpfaff.org

[Tor Rustad]

jacob navia wrote:

Charlie Gordon wrote:

[...]

>#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.

Why not

#pragma once

Chapter and verse please.

--
Tor <torust [at] online [dot] no>

[Richard]

Tor Rustad <to********@hotmail.comwrites:

jacob navia wrote:

>Charlie Gordon wrote:

[...]

>>#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.

Why not

#pragma once

Chapter and verse please.

The book of common sense when using well known compilers, page 1.

It is an answer to problems people might have in C. And good advice
too. If your C *must* be 100% standard compatible amongst ALL compilers
then clearly not. But for a LOT of people using many compilers very
useful to know.

Good advice Jacob.

[jacob navia]

Richard wrote:

Tor Rustad <to********@hotmail.comwrites:

>jacob navia wrote:

>>Charlie Gordon wrote:

[...]

>>>#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.

Why not

#pragma once

Chapter and verse please.

The book of common sense when using well known compilers, page 1.

It is an answer to problems people might have in C. And good advice
too. If your C *must* be 100% standard compatible amongst ALL compilers
then clearly not. But for a LOT of people using many compilers very
useful to know.

Good advice Jacob.

It is supported by
1) MSVC (windows)
2) Intel compiler
2) Comeau C/C++ (Unix and windows)
3) Digital Mars C/C++ (Unix+Windows I think)
4) gcc (versions later than 3.4) (Unix)
5) lcc-win32 (Windows)
6) Delorie C/C++ (MSDOS)
7) MIPS PRO C/C++ (SGI)
8) Code Warrior (MacIntosh version)
9) Digital C++ (Unix)
10) MPW C compiler (Macintosh)
11) The Watcom compiler

[Richard Heathfield]

Tor Rustad said:

jacob navia wrote:

>Charlie Gordon wrote:

[...]

>>#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.

Why not

#pragma once

Chapter and verse please.

Alas, chapter and verse will not be forthcoming, because the C Standard
doesn't mention '#pragma once' specifically. It does, however, have this
to say about pragmas in general:

1 A preprocessing directive of the form
# pragma pp-tokensopt new-line
where the preprocessing token STDC does not immediately follow pragma in
the directive (prior to any macro replacement)146) causes the
implementation to behave in an implementation-defined manner. The behavior
might cause translation to fail or cause the translator or the resulting
program to behave in a non-conforming manner. Any such pragma that is not
recognized by the implementation is ignored.

So the advice here is to use a pragma that might be ignored or might do
something arbitrary and unexpected - and incredibly bad advice it is.
Anyone capable of implementing a C compiler *must* be well aware of this.
Draw your own conclusions.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Richard]

Keith Thompson <ks***@mib.orgwrites:

>
If you want to suggest '#pragma once', that's ok with me, but *please*
don't do so without mentioning that it's non-standard. It's a nice
feature, and I wouldn't mind having it in the standard (though
defining it precisely might be difficult), but there is a cost to
using it.

This is a sensible reply.

There is a chance that the OP was interested in how best to achieve
something. "Best" does not, in his case, necessarily mean using the
standard. Nothing wrong with sharing a little bit of experience with the
usual caveats.

[Flash Gordon]

jacob navia wrote, On 26/09/07 18:58:

Richard wrote:

>Tor Rustad <to********@hotmail.comwrites:

>>jacob navia wrote:
Charlie Gordon wrote:
[...]

#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.
>
Why not

#pragma once
Chapter and verse please.

The book of common sense when using well known compilers, page 1.

It is an answer to problems people might have in C. And good advice
too. If your C *must* be 100% standard compatible amongst ALL compilers
then clearly not. But for a LOT of people using many compilers very
useful to know.

Good advice Jacob.

It is supported by
1) MSVC (windows)

<snip>

11) The Watcom compiler

Alternatively, you could use the normal method that is supported by,
hold on whilst I count...


Sorry, I lost count whilst counting all of the conforming compilers.

So on the one hand we have a method supported by at least 11 compilers
and used by some people. On the other hand we have the method most
people use that is supported by ALL conforming compilers and probably
most non-conforming compilers as well.
--
Flash Gordon