C is too old? opinions?

[Tak-Shing Chan]

Tak-Shing Chan said:

Tak-Shing Chan said:

On Wed, 12 Jul 2006, Richard Heathfield wrote:

Lasse Espeholt said:

<snip>

I'm looking for the simplicity of c# without objects

[It is very clear that Lasse is talking about objects in the
C# sense here.]

Not so. In comp.lang.c, the word "object" has a clearly-defined meaning.
If he isn't using the word in that sense, his usage is off-topic.

This is basically a summary of what *I* have said in my
previous post (which you have largely snipped and rewritten in
your own words without attributions to me).

No, it isn't. Learn to read for comprehension. Especially consider the
importance of the word 'if'. You can accuse me of plagiarism as much as you
want, but a /valid/ accusation requires evidence of plagiarism.

Your reply to Lasse implies that he isn't using the word in
the C sense. As the protasis is true, our statements are
logically equivalent. More on that below.

Yes. It requires one or more axioms (statements of belief, assumptions) and
premises (either axioms, observed facts, or results of previous
deductions), and a logical connection between them. In this case, the valid
deduction I drew is as follows:

Axiom: he did not use the word 'object' in an off-topic sense.
Premise: he used the word 'object'.
Deduction: he used the word 'object' in a topical sense.

You can contradict me as much as you want, but a valid contradiction
requires more than mere statements of disagreement.

This axiom contradicts with your reply to Lasse: ``Then C is
the wrong place to look. C has objects. So does C++, so it's no
good looking there, either'' (Heathfield, 2006-07-12).

Since when are C++ objects on-topic here? For your
information (although I believe that you are aware of this
already), C++ objects cannot be interpreted in the C sense
because for polymorphic objects ``the implementation generates
information associated with each such object that makes it
possible to determine that object's type during program
execution'' (ISO/IEC 14882:2003, 1.8; 10.3). Therefore the C
interpretation is ruled out.

Even if you exclude such polymorphic objects from the entire
discussion, the subset of C-reinterpretable objects in C++ are
*still* off-topic. Moreover, if you apply the strictest
topicality rules here, then C++ does not even exist, let alone
objects in C++.

If you agree that C++ objects are off-topic here, then you
must also agree that your reply to Lasse is off-topic. It would
be inconsistent to assume the topicality axiom in Lasse's post
while disobeying the very same axiom in your immediate reply to
that post. Therefore, my criticisms still hold.

Tak-Shing

 

[Tak-Shing Chan]

1. He used the word OBJECT.........................premise
2. He was off-topic................................premise
3. OBJECT was topically used ......................assumption
4. He used the word OBJECT in topical sense........& introduction, 1,
3
5. He used the word OBJECT in off-topic sense......& introduction, 1,
2
6. OBJECT was not topically used...................not elimination 3,
4, 5
7. OBJECT was not topically used...................discharge 3
8. OBJECT was not topically used...................proof

You proof is flawed. (1) and (2) does not imply (5).

Tak-Shing

 

[Richard Heathfield]

[mailed, not posted]

You said:

Your reply to Lasse implies that he isn't using the word in
the C sense.

No, it doesn't.

Tak-Shing, I'm delighted to see your return to comp.lang.c, and I know and
respect your knowledge and experience of the C language.

But I also know that you and I have very different and conflicting ways of
thinking about things. Also, we both have a tendency to follow minutiae to
the bitter end, and sometimes beyond.

If we are not careful, we will end up generating colossal amounts of heat
and almost no light.

Therefore, I have decided to strive to minimise the number and length of my
replies to your articles. This is not intended as a slur to you. It's just
an attempt to keep the group's noise levels down.

<snip>

 

[Tak-Shing Chan]

[mailed, not posted]

Your newsreader has a bug.

Tak-Shing

 

[Richard Heathfield]

Tak-Shing Chan said:

[mailed, not posted]

Your newsreader has a bug.

Oops. No, I do.

Sorry about that.

 

[goose]

You proof is flawed. (1) and (2) does not imply (5).

Well, since it was done right and proper,
perhaps you can point out where it went
wrong.

After all, /formal logic/ is to /formally prove/
something, not make a statement and then magically
"know" the correct answer


goose,
(hey, it *might* be wrong, but I'd rather know
which /step/ is wrong).

 

[Walter Roberson]

[If I could add just one feature to C it would be decent namespace
control. And if I could add just one feature to physics I think it
would be the spindizzy. Any bets on which is more likely?]

Modern stoeticists use Jorn Spindillies (R) -- recommended by
three out of five Apostles!

 

[Jack Klein]

Hi...

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

[snip drivel]

You have the official permission of comp.lang.c not to use the C
language if you don't like it.

If you want C++, or Java, or C# of Visual Basic, or any one of
hundreds of other languages that would be more to your liking, who's
stopping you?

 

[Andrew Poelstra]

use
#ifndef H_FILE
#define H_FILE

You don't want to find yourself renaming files
because you suddenly stepped on the implementations
(or the standards) toes

True, it'd be stupid to have a `file.h'. However, the implementation
would almost certainly use guards like `__FILE_H__' or the like, and
so there wouldn't be any problems solved by reorganizing the #define.

(Note: If you were talking about the leading underscore, it's so
common that the Standard'd be nuts to move it into implementation
namespace.)

 

[goose]

True, it'd be stupid to have a `file.h'. However, the implementation
would almost certainly use guards like `__FILE_H__' or the like, and
so there wouldn't be any problems solved by reorganizing the #define.

(Note: If you were talking about the leading underscore, it's so
common that the Standard'd be nuts to move it into implementation
namespace.)

nope; its easier to remember that H_* does not clash
with standard nor implementation than to remember
all the rules for #define

goose,

 

[Keith Thompson]

Andrew Poelstra wrote:



use
#ifndef H_FILE
#define H_FILE
...
#endif

You don't want to find yourself renaming files
because you suddenly stepped on the implementations
(or the standards) toes

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

 

[Ben Pfaff]

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.

 

[John Bode]

Hi...

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

C is a product of the early 1970s and it shows, but that doesn't
necessarily make it 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?

Again, C dates from a time where these concepts hadn't yet been
formalized. They could certainly be added to a future version of the
standard (C89 incorprated several useful concepts from C++), but
frankly, if they haven't been added by now, I wouldn't expect them to
be added in the future.

And, you can currently restrict visibility by using the static keyword.

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());
}

Language design isn't as easy as it looks. Something that looks simple
on paper may turn out to be difficult to code (as I'm discovering right
now with a design of mine; not quite as painless as I'd hoped it would
be).

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


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

A lot of people *say* that, damn few wind up ever doing it.

 

[Dann Corbit]

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.

 

[W Marsh]

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.

 

[Dann Corbit]

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.

 

[Tak-Shing Chan]

Well, since it was done right and proper,

Only in form but not in content.

perhaps you can point out where it went
wrong.

I already did. In the above, I said (1) and (2) does not
imply (5). In English, this means: ``he used the word OBJECT''
and ``he was off-topic'' does not imply that ``he used the word
OBJECT in off-topic sense''. To claim otherwise is to commit the
fallacy of division.

(hey, it *might* be wrong, but I'd rather know
which /step/ is wrong).

From step (5) onwards.

Tak-Shing

 

[W Marsh]

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?

 

[pete]

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

He's talking about a safe procedure for creating
header guard identifiers from .h file names.

EBOLA_H_ would not be a suitable header guard
for a file named ebola.h

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.
7.26.3 Errors <errno.h>
[#1] Macros that begin with E and a digit or E and an
uppercase letter (possibly followed by any combination of
digits, letters, and underscore) may be added to the
declarations in the <errno.h> header.

 

[John Bode]

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

There is a real time Java specification, and Sun has released a real
time version of Java (RTS). A high-level introduction is at
http://www.onjava.com/pub/a/onjava/2006/05/10/real-time-java-introduction.html?page=1.
Quote:

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