Is this right?

[Dan Pop]

True.
But constants are objects as well.

Go back under your rock, Trollsdale. You can't take the address of a
constant and you can't assign anything to it.

FYI, const qualified objects are not constants:

6.4.4 Constants

Syntax

1 constant:
integer-constant
floating-constant
enumeration-constant
character-constant

Dan

 

[j]

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.

Objects in C do not differ from objects in C++.
C++ people often confuse ``object'' and ``instance of a class''.
Classes are a kind of namespace at best but while an instance
of a class constitutes as an object, it does not mean that all
objects are an instance of a class.

 

[Michael Wojcik]

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

(I'll skip the others, since a number of people have already discussed
them.)

"C is an extended assembly language"

This is a matter of opinion, if not religion, but I'll weigh in on
the "no" side. The defining characteristic of an assembly language
is its direct (1-to-1, or very close) mapping to the central
processor's external machine language. (I say "external" because
many processors microdecode the "public" machine language into an
internal stream of simpler instructions.) Each statement in an
assembly language program is an (external) CPU operation, or very
nearly.

This is definitely not true of C. It may be true of some C programs
written for some C implementations, but it is not true of the
language as a whole. Yes, some C statements can be compiled into a
single assembly language statement in many implementations; this is
true for many high-level languages (COBOL has "ADD 1 TO ELEM-ITEM").
I'm not aware of any processor that has a single assembly-language
equivalent of, say,

char *NewPtr = realloc(StrList[Idx], Len1 + Len 2 + 1);

Second, aside from hypothetical exotic processors, assembly language
programs are notable for their lack of control structures: they are
formed of instruction sequences and explicit changes to the flow of
control (branches, whether they're simple, conditional, or more
complex, as with subroutine calls in some processor families). (Of
course this is a consequence of the first characteristic.) To say
that C or any language is "assembly plus control constructs" is to
say that C is "not assembly" - the lack of control constructions is
one of the most essential characteristics of (most) assembly
languages.

And, of course, standard C is abstracted from the real machine; C's
alleged "close to the metal" nature is inherently implementation-
dependent. That doesn't mean it isn't a feature of the language in
a practical sense (for most implementations), but it isn't one in
the strict sense of the language as defined by the standard.

--
Michael Wojcik (e-mail address removed)

Americans have five disadvantages which you should take into account
before giving us too hard a time:
- We're landlocked
- We're monolingual
- We have poor math and geography skills -- Lucas MacBride

 

[Neil Kurzman]

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

I though BASIC was used to write unreadable code.

 

[Neil Kurzman]

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

(I'll skip the others, since a number of people have already discussed
them.)

"C is an extended assembly language"

This is a matter of opinion, if not religion, but I'll weigh in on
the "no" side. The defining characteristic of an assembly language
is its direct (1-to-1, or very close) mapping to the central
processor's external machine language. (I say "external" because
many processors microdecode the "public" machine language into an
internal stream of simpler instructions.) Each statement in an
assembly language program is an (external) CPU operation, or very
nearly.

This is definitely not true of C. It may be true of some C programs
written for some C implementations, but it is not true of the
language as a whole. Yes, some C statements can be compiled into a
single assembly language statement in many implementations; this is
true for many high-level languages (COBOL has "ADD 1 TO ELEM-ITEM").
I'm not aware of any processor that has a single assembly-language
equivalent of, say,

char *NewPtr = realloc(StrList[Idx], Len1 + Len 2 + 1);

Second, aside from hypothetical exotic processors, assembly language
programs are notable for their lack of control structures: they are
formed of instruction sequences and explicit changes to the flow of
control (branches, whether they're simple, conditional, or more
complex, as with subroutine calls in some processor families). (Of
course this is a consequence of the first characteristic.) To say
that C or any language is "assembly plus control constructs" is to
say that C is "not assembly" - the lack of control constructions is
one of the most essential characteristics of (most) assembly
languages.

And, of course, standard C is abstracted from the real machine; C's
alleged "close to the metal" nature is inherently implementation-
dependent. That doesn't mean it isn't a feature of the language in
a practical sense (for most implementations), but it isn't one in
the strict sense of the language as defined by the standard.

--
Michael Wojcik (e-mail address removed)

Americans have five disadvantages which you should take into account
before giving us too hard a time:
- We're landlocked
- We're monolingual
- We have poor math and geography skills -- Lucas MacBride

My Prof made 3 groups

Low Level
Medium Level
High Level

C was in the medium group

 

[August Derleth]

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"

Define object. This is meaningless without that definition.

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

Demonstrably false. C changed throughout the 1970s and 1980s as
pre-standard compilers were implemented with different feature sets, in
1989 when the first standard was released, again in 1990 with a normative
addendum to the 1989 standard, and yet again in 1999 with a completely new
standard.

So, C hasn't changed in five years.

"C is an extended assembly language"

False. Well, false for most values of the word. C allows you to inspect
the binary representation of objects (there's that word) and it forces you
to do your own memory management, but it also allows you to write
nontrivial programs that are completely portable.

By your professor's definition Java and C++ are extended assembly
languages.

"Procedure generate unreadable code"

"Professor generate unreadable junk"

This is one of the stupidest things I've heard yet. What, does your prof
want you to eschew 50 years of programming best practice by not creating
subroutines or functions?

You either misheard him, or you should reconsider paying for his class.

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.

Heh. HLA /is/ an extended assembly language by definition, if we're both
talking about the same thing (High-Level Assembler). But C is
substantially different from HLA in both form and function: HLA is little
more than a set of macros, while C is a full-fledged language. HLA aims to
hide the worst of a specific machine's oddities, while C's job is to make
writing portable but efficient programs as easy as possible.

But I may be wrong please give your opinion

You are right, in that you correctly flagged the bullshit.

I wonder if your professor has a Usenet account... ;-)

 

[August Derleth]

My Prof made 3 groups

Low Level
Medium Level
High Level

C was in the medium group

This is acceptable to many people, me included. But mid-level to me merely
means that you must do your own memory management.

 

[Martin Dickopp]

Define object. This is meaningless without that definition.

"Region of data storage in the execution environment, the contents of
which can represent values." (3.14#1)

In the context of this newsgroup, I think it is okay to assume that the
definitions of terms in the C standard apply. An object is therefore
clearly defined, however I wonder what a variable is...

Martin