Is this right?

[Profetas]

I have heard some thing from my lecture that I disagree. and I would like
to hear if I am wrong.

"A variable is an object"
"C hasn't changed in the past 30 years"
"C is an extended assembly language"
"Procedure generate unreadable code"


I know that C may be considered low level, but I am not sure about
extended assembly language. I don't even consider HLA an extended assembly
language.

But I may be wrong please give your opinion
Thanks Profetas

 

[Mike Wahler]

I have heard some thing from my lecture that I disagree. and I would like
to hear if I am wrong.

"A variable is an object"
True.

"C hasn't changed in the past 30 years"

False. C has been changed (via updates to the standard)
on at least three occasions during that time (1989, 1995, 1999).

"C is an extended assembly language"

IMO that's one fairly reasonable description. But imo
should be qualified with 'generalized' (i.e. 'assembly
language' is necessarily processor specific, whereas C
'generalizes' it). C is designed to be platform-independent.

"Procedure generate unreadable code"

I have no idea what this is supposed to mean. What
you are calling 'procedure' has a single name in C:
'function'.

One can write either 'readable' or 'unreadable' code
in any language. The former, of course does take experience
and practice. And 'readable' is a somewhat subjective term.

I know that C may be considered low level, but I am not sure about
extended assembly language.

I think the reason many call C 'assembly-like' is because
many of its constructs can often be directly translated to
assembly instructions (e.g the '++' and '=' operators).
"Higher" level concepts are typically expressed via functions,
not 'native' C statements. (Compared to e.g. BASIC, where e.g.
the "PRINT" command is part of the language itself).

I don't even consider HLA an extended assembly
language.

Why not?

-Mike

 

[Eric Sosman]

I have heard some thing from my lecture that I disagree. and I would like
to hear if I am wrong.

"A variable is an object"

Informally: Every variable is an object, but not every
object is a variable.

Formally: I don't know. The C Standard does not define
"variable," except possibly by reference to ISO/IEC 2382-1.
I do not have a copy of the latter, and am not interested
in purchasing one simply to answer your question.

"C hasn't changed in the past 30 years"

True; It's still 299792458 m/s in vacuo.

"C is an extended assembly language"

No. Yes. Maybe. Give rigorous definitions of "extended"
and "assembly language," and perhaps the question will become
meaningful. Until then, it's best to think of C as a collapsed
reassembly language.

"Procedure generate unreadable code"

Not only that, but lecturer generate unparseable sentence.

 

[Joona I Palaste]

True; It's still 299792458 m/s in vacuo.

No, that's c, not C.

--
/-- Joona Palaste ([email protected]) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"I said 'play as you've never played before', not 'play as IF you've never
played before'!"
- Andy Capp

 

[Malcolm]

I have heard some thing from my lecture that I disagree. and I
would like to hear if I am wrong.

"A variable is an object"

Depends what you mean by "object". In an object-oriented programming sense,
no, because a C variable cannot have type relationships with other objects.
However most people would accept the sentence "the object on the top of the
stack is a C double."

"C hasn't changed in the past 30 years"

Not true. You would have a hard time getting very old C code to compile, and
the language has gone through several versions. However no really major
changes ahve been made and C is much more stable than C++.

"C is an extended assembly language"

Sort of. C abstracts assembler by one step, which is both the power and the
deficiency of the langauge. Most C statements compile to only a few assembly
instructions.

"Procedure generate unreadable code"

I expect you mean "procedural programming (as opposed to object-oriented
programming) is unreadable". This isn't true, though it is easy to write bad
code in any language, including C. It easier to modify the behaviour of OO
code without rewriting it, which is the advantage of OO, not superior
readability.

 

[Eric Sosman]

No, that's c, not C.

I tried to write a wisecrack to explain away the
difference, something recalling old-time Unix man pages'
habit of capitalizing function names when they began
sentences:

Exit() terminates the program, ...

Nowadays they all seem to weasel out of the problem:

The exit() function terminates the program ...

But I decided the wisecrack was pretty lame, and
deleted it before sending the message -- not believing for
one moment, understand, that comp.lang.c would let the
discrepancy go unchallenged ;-)

Pedants 'R Us!

 

[Emmanuel Delahaye]

I have heard some thing from my lecture that I disagree. and I would like
to hear if I am wrong.

"A variable is an object"
True

"C hasn't changed in the past 30 years"
False

"C is an extended assembly language"

'Portable assembly' in some way, but, actually it's more an abstract language
(3d generation).

"Procedure generate unreadable code"

Bad programmers generate unreadable code. C has no procedures but functions.
Structures are good to organise the data and the code.

I know that C may be considered low level, but I am not sure about

Say 'medium-level'. Neither low, nor high. Well, it's highly debatable. It's
a question of point of view.

extended assembly language. I don't even consider HLA an extended assembly
language.

What the heck is HLA... (High Level Assembly ?)

http://webster.cs.ucr.edu/AsmTools/HLA/index.html

Good guess!

 

[Leor Zolman]

I have heard some thing from my lecture that I disagree. and I would like
to hear if I am wrong.

"C is an extended assembly language"

I like saying, "C is a low-level language with high-level control
structure". I seem to recall that the fellow I first heard this from is the
same one who suggested, back in 1978, that I should write a C compiler for
CP/M systems.
-leor

 

[Irrwahn Grausewitz]

Depends what you mean by "object". In an object-oriented programming sense,
no, because a C variable cannot have type relationships with other objects.
However most people would accept the sentence "the object on the top of the
stack is a C double."

Since we're talking about C, there's only one valid definition of
object:

ISO/IEC 9899:1999
3.14
object
region of data storage in the execution environment, the contents
of which can represent values

Given this definition it's obvious that every variable designates
("is") an object.

Regards

 

[Robert Harris]

I have heard some thing from my lecture that I disagree. and I would like
to hear if I am wrong.

"A variable is an object"
"C hasn't changed in the past 30 years"
"C is an extended assembly language"

Assembly language is different for each CPU with a different instruction
set; C is not (subject to compiler specifics like size of int's,
endian-ness, alignment, etc). In fact you can write a program in C that
is reasonably portable across all CPUs; that would be impossible in
assembler.

Robert

 

[Stephen Sprunk]

I have heard some thing from my lecture that I disagree. and I would like
to hear if I am wrong.

"C hasn't changed in the past 30 years"

There's at least 3 distinct flavors of C: K&R, C89/90, and C99. Given that
these flavors are not identical, C must have changed over that time period.

"C is an extended assembly language"

I've seen C referred to many times as "portable assembly language" because
it exposes so much of the machine's internals (if you stray from the
Standard), unlike most other high-level languages. However, this is not
accurate because assembly language instructions have a one-to-one
correspondence with machine language instructions, simply using mnemonics
instead of opcodes; C obviously doesn't qualify.

S

 

[E. Robert Tisdale]

I have heard some thing from my lecture that I disagree.
and I would like to hear if I am wrong.

"A variable is an object"

True.
But constants are objects as well.

"C hasn't changed in the past 30 years"
False.

"C is an extended assembly language"

False.
C is a general purpose, high level programming language.

"Procedure generate unreadable code"
False.

I know that C may be considered low level
but I am not sure about extended assembly language.
I don't even consider HLA an extended assembly language.

But I may be wrong. Please give your opinion.

 

[Viktor Lofgren]

I have heard some thing from my lecture that I disagree. and I would like
to hear if I am wrong.

"A variable is an object"

I'm going to be uncontroversial and say No.
Since C lacks the elemental theories of object orientation, it does
not have objects, so you can not think of variables as objects.

"C hasn't changed in the past 30 years"

The latest ANSI C (C99) was released 1999, 2004 - 1999 = 5, *bzz* wrong!

"C is an extended assembly language"

Can look on this in two angles:
#1 So is every other language running on a computer.
#2 Kinda works as a front-end for assembler in some ways, but it is a bit
too abstract for being an assembly language.

 

[Mike Wahler]

I'm going to be uncontroversial and say No.

I think you meant controversial.

Since C lacks the elemental theories of object orientation, it does
not have objects, so you can not think of variables as objects.

Context, context.

=====================================================================
ISO/IEC 9899:1999 (E)

[....]

3. Terms, definitions, and symbols

1 For the purposes of this International Standard, the following
definitions apply. Other terms are defined where they appear in
italic type or on the left side of a syntax rule. Terms explicitly
defined in this International Standard are not to be presumed to
refer implicitly to similar terms defined elsewhere.

[....]

3.14
1 object
region of data storage in the execution environment, the contents
of which can represent values

2 NOTE When referenced, an object may be interpreted as having a
particular type; see 6.3.2.1.
=====================================================================

C does indeed have objects, but not the sort you're
thinking of. Also note that object oriented programming
can indeed be (and is) done with C.

-Mike

 

[E. Robert Tisdale]

I'm going to be uncontroversial and say No.
Since C lacks the elemental theories of object orientation,
it does not have objects
so you can not think of variables as objects.

Wrong.

 

[Richard Bos]

I think the reason many call C 'assembly-like' is because
many of its constructs can often be directly translated to
assembly instructions (e.g the '++' and '=' operators).

That does not make C any more "assembly-like" than, say, Pascal or Perl.
Arguably, the C for statement is _less_ assembly-like than Pascal's;
after all, Pascal's for is a direct DJNZ, while C's is a very
generalised looping construct.

Richard

 

[Martin Dickopp]

I'm going to be uncontroversial and say No.
Since C lacks the elemental theories of object orientation, it does
not have objects, so you can not think of variables as objects.

You'd better read the C standard more carefully.

The term "object" is mentioned more than 600 times and defined in
section 3. The term "variable" as a noun (i.e. not in the sense of
"variable length array" or "variable arguments"), OTOH, is not defined
in section 3 and is metioned in normative text only once or twice.

So while C clearly has objects, it could be considered controversial
whether it has variables.

Martin

 

[Harti Brandt]

On Thu, 27 May 2004, Profetas wrote:

P>"C is an extended assembly language"

I tend to say the same. By looking at a C statement you can usually easily
tell to what kind of machine code that compiles (the complexity of
what the machine will do is proportional to the complexity of the C
program, for some fuzzy definition of 'proportional'). Compare this with
C++. By looking at:

foo_t
add(foo_t a, foo_t b)
{
return (a + b);
}

This may compile to any amount of code including calls to functions you
even don't want to know of. Operator overloading, virtual functions and
exceptions make C and C++ different in this regard.

In C you would know that this compiles just to an ADD instruction for
a primitive data type and some function entry/exit code.

harti

 

[Dan Pop]

False. C has been changed (via updates to the standard)
on at least three occasions during that time (1989, 1995, 1999).

And before 1989, it kept changing as Ritchie added new features.
Appendix A of K&R1 is really a snapshot of Ritchie's "C Reference Manual"
as it was shortly before Unix V7 was released (the Unix V7 C has a few
more features, some of them hinted in K&R1).

IMO that's one fairly reasonable description. But imo
should be qualified with 'generalized' (i.e. 'assembly
language' is necessarily processor specific, whereas C
'generalizes' it). C is designed to be platform-independent.

I disagree: C's execution control statements and C's expressions are
*far* above the typical assembly language capabilities. C is a high
level language (even if lower level than most other HLLs) while assembly
languages aren't.

Some vendors introduced (without much success) the concept of high level
assembly. According to that concept, one could probably say that C is a
generalised high level assembly language, but I'm afraid that such a
statement would be more confusing than clarifying...

Dan

 

[Dan Pop]

True; It's still 299792458 m/s in vacuo.

Nope, that's lower case 'c' and the "in vacuo" is redundant, as the 'c'
in question is a physical constant defined as the speed of light in
vacuum.

Dan