f



Is this right?

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

0
xuxu_18 (51)
5/27/2004 7:29:49 PM
comp.lang.c 30656 articles. 5 followers. spinoza1111 (3246) is leader. Post Follow

27 Replies
795 Views

Similar Articles

[PageSpeed] 52

"Profetas" <xuxu_18@yahoo.com> wrote in message
news:e3a3c840b05a99a337313fc11601ef23@localhost.talkaboutprogramming.com...
> 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


0
mkwahler (3821)
5/27/2004 7:43:20 PM
Profetas wrote:
> 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.

-- 
Eric.Sosman@sun.com

0
Eric.Sosman (4552)
5/27/2004 7:54:10 PM
Eric Sosman <Eric.Sosman@sun.com> scribbled the following:
> Profetas wrote:
>> 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"

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

No, that's c, not C.

-- 
/-- Joona Palaste (palaste@cc.helsinki.fi) ------------- 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
0
palaste (2323)
5/27/2004 8:02:43 PM
"Profetas" <xuxu_18@yahoo.com> wrote in message
> 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.



0
Malcolm
5/27/2004 8:15:29 PM
Joona I Palaste wrote:
> Eric Sosman <Eric.Sosman@sun.com> scribbled the following:
> 
>>Profetas wrote:
>>
>>>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"
> 
> 
>>     True; It's still 299792458 m/s in vacuo.
> 
> 
> 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!

-- 
Eric.Sosman@sun.com

0
Eric.Sosman (4552)
5/27/2004 8:25:43 PM
In 'comp.lang.c', "Profetas" <xuxu_18@yahoo.com> wrote:

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

-- 
-ed- get my email here: http://marreduspam.com/ad672570
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-reference: http://www.dinkumware.com/manuals/reader.aspx?lib=c99
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
0
emdelYOURBRA (457)
5/27/2004 8:43:45 PM
On Thu, 27 May 2004 15:29:49 -0400, "Profetas" <xuxu_18@yahoo.com> wrote:

>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

-- 
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix  
C++ users: download BD Software's free STL Error Message Decryptor at:
   www.bdsoft.com/tools/stlfilt.html
0
leor (637)
5/27/2004 8:55:18 PM
"Malcolm" <malcolm@55bank.freeserve.co.uk> wrote:
>
>"Profetas" <xuxu_18@yahoo.com> wrote in message
>> 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."

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
-- 
Irrwahn Grausewitz (irrwahn33@freenet.de) 
welcome to clc: http://www.ungerhu.com/jxh/clc.welcome.txt 
clc faq-list  : http://www.faqs.org/faqs/C-faq/faq/ 
clc OT guide  : http://benpfaff.org/writings/clc/off-topic.html
0
irrwahn33 (608)
5/27/2004 9:22:10 PM
Profetas wrote:
> 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
0
5/27/2004 9:35:17 PM
"Profetas" <xuxu_18@yahoo.com> wrote in message
news:e3a3c840b05a99a337313fc11601ef23@localhost.talkaboutprogramming.com...
> 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

-- 
Stephen Sprunk        "Stupid people surround themselves with smart
CCIE #3723           people.  Smart people surround themselves with
K5SSS         smart people who disagree with them."  --Aaron Sorkin

0
stephen (1366)
5/27/2004 9:45:28 PM
Profetas wrote:

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

0
5/27/2004 10:03:14 PM
Profetas <xuxu_18@yahoo.com> wrote:
> 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.

-- 
Viktor Lofgren, Umea, Sweden
  Mainly self-eductated UNIX programmer, running Slackware-current.
0
zwd (8)
5/28/2004 12:09:07 AM
"Viktor Lofgren" <zwd@eudial.nos--pam.mine.nu> wrote in message
news:Dqvtc.93617$dP1.300119@newsc.telia.net...
> Profetas <xuxu_18@yahoo.com> wrote:
> > 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.

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


0
mkwahler (3821)
5/28/2004 1:02:02 AM
Viktor Lofgren wrote:

> Profetas <xuxu_18@yahoo.com> wrote:
> 
>>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.

Wrong.
0
5/28/2004 1:23:01 AM
"Mike Wahler" <mkwahler@mkwahler.net> wrote:

> "Profetas" <xuxu_18@yahoo.com> wrote in message
> news:e3a3c840b05a99a337313fc11601ef23@localhost.talkaboutprogramming.com...
> > 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).

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
0
rlb (4118)
5/28/2004 7:34:16 AM
Viktor Lofgren <zwd@eudial.nos--pam.mine.nu> writes:

> Profetas <xuxu_18@yahoo.com> wrote:
>> 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.

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


-- 
   ,--.    Martin Dickopp, Dresden, Germany                 ,= ,-_-. =.
  / ,- )   http://www.zero-based.org/                      ((_/)o o(\_))
  \ `-'                                                     `-'(. .)`-'
   `-.     Debian, a variant of the GNU operating system.       \_/
0
5/28/2004 7:43:48 AM
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
0
brandt1 (33)
5/28/2004 7:52:45 AM
In <sxrtc.13704$be.12049@newsread2.news.pas.earthlink.net> "Mike Wahler" <mkwahler@mkwahler.net> writes:

>"Profetas" <xuxu_18@yahoo.com> wrote in message
>news:e3a3c840b05a99a337313fc11601ef23@localhost.talkaboutprogramming.com...
>> 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).

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

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

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
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de
0
Dan.Pop (3615)
5/28/2004 11:38:50 AM
In <40B64762.2070503@sun.com> Eric Sosman <Eric.Sosman@sun.com> writes:

>Profetas wrote:
>
>> "C hasn't changed in the past 30 years"
>
>     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
-- 
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de
0
Dan.Pop (3615)
5/28/2004 11:43:13 AM
In <c95oiu$al4$1@nntp1.jpl.nasa.gov> "E. Robert Tisdale" <E.Robert.Tisdale@jpl.nasa.gov> writes:

>Profetas wrote:
>
>> 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.

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
-- 
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de
0
Dan.Pop (3615)
5/28/2004 11:54:03 AM
"Viktor Lofgren" <zwd@eudial.nos--pam.mine.nu> wrote in message
news:Dqvtc.93617$dP1.300119@newsc.telia.net...
> Profetas <xuxu_18@yahoo.com> wrote:
> > 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.
>

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.


> > "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.
>
> --
> Viktor Lofgren, Umea, Sweden
>   Mainly self-eductated UNIX programmer, running Slackware-current


--
j


0
5/28/2004 2:05:08 PM
In article <e3a3c840b05a99a337313fc11601ef23@localhost.talkaboutprogramming.com>, "Profetas" <xuxu_18@yahoo.com> writes:
> 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                  michael.wojcik@microfocus.com

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
0
mwojcik (1879)
5/28/2004 5:07:06 PM

Malcolm wrote:

> "Profetas" <xuxu_18@yahoo.com> wrote in message
> > 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.

I though BASIC was used to write unreadable code.


0
nsk (250)
5/29/2004 3:46:21 AM

Michael Wojcik wrote:

> In article <e3a3c840b05a99a337313fc11601ef23@localhost.talkaboutprogramming.com>, "Profetas" <xuxu_18@yahoo.com> writes:
> > 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                  michael.wojcik@microfocus.com
>
> 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


0
nsk (250)
5/29/2004 3:50:11 AM
On Thu, 27 May 2004 15:29:49 -0400, Profetas wrote:

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

> Thanks Profetas

-- 
yvoregnevna gjragl-guerr gjb-gubhfnaq guerr ng lnubb qbg pbz
To email me, rot13 and convert spelled-out numbers to numeric form.
"Makes hackers smile" makes hackers smile.

0
see84 (117)
5/30/2004 12:49:14 AM
On Sat, 29 May 2004 03:50:11 +0000, Neil Kurzman wrote:

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

-- 
yvoregnevna gjragl-guerr gjb-gubhfnaq guerr ng lnubb qbg pbz
To email me, rot13 and convert spelled-out numbers to numeric form.
"Makes hackers smile" makes hackers smile.

0
see84 (117)
5/30/2004 12:54:13 AM
August Derleth <see@sig.now> writes:

> On Thu, 27 May 2004 15:29:49 -0400, Profetas wrote:
>
>> 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.

"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


-- 
   ,--.    Martin Dickopp, Dresden, Germany                 ,= ,-_-. =.
  / ,- )   http://www.zero-based.org/                      ((_/)o o(\_))
  \ `-'                                                     `-'(. .)`-'
   `-.     Debian, a variant of the GNU operating system.       \_/
0
5/30/2004 8:50:38 AM
Reply: