elektroda.net NewsGroups Forum Index - FPGA - using an FPGA to emulate a vintage computer
Goto page Previous 1, 2, 3 ... 14, 15, 16
Michael Wojcik
Guest
Guest
Tue Mar 09, 2010 7:15 pm
Brian Boutel wrote:
Quote:
Michael Wojcik wrote:
If we relax the definition to allow named as well as anonymous
functions, then someone could argue that get-accessors for properties
are thunks, and those are quite common in modern languages.
In functional languages with lazy evaluation (e.g. Haskell) arguments
are passed unevaluated, so an actual argument that is an expression
needs to be parcelled up as a piece of code and an environment in which
is is to be evaluated (i.e the bindings of the free variables in the
code). This amounts to a thunk.
If we relax the definition to allow named as well as anonymous
functions, then someone could argue that get-accessors for properties
are thunks, and those are quite common in modern languages.
In functional languages with lazy evaluation (e.g. Haskell) arguments
are passed unevaluated, so an actual argument that is an expression
needs to be parcelled up as a piece of code and an environment in which
is is to be evaluated (i.e the bindings of the free variables in the
code). This amounts to a thunk.
Good point. I have a passing familiarity with lazy evaluation, but
even with functional programming most of my experience is with
eager-evaluating languages like OCaml, so I didn't think of this example.
--
Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University
Michael Wojcik
Guest
Guest
Tue Mar 09, 2010 7:19 pm
Muzaffer Kal wrote:
Quote:
On Fri, 5 Mar 2010 09:07:31 -0800 (PST), Quadibloc <jsavard_at_ecn.ab.ca
wrote:
On Feb 26, 4:56 am, Ahem A Rivet's Shot <ste...@eircom.net> wrote:
No, he's saying that C doesn't really implement an array type, the
var[offset] syntax is just syntactic sugar for *(var + offset) which is why
things like 3[x] work the same as x[3] in C.
Um, no.
x = y + 3 ;
in a C program will _not_ store in x the value of y plus the contents
of memory location 3.
wrote:
On Feb 26, 4:56 am, Ahem A Rivet's Shot <ste...@eircom.net> wrote:
No, he's saying that C doesn't really implement an array type, the
var[offset] syntax is just syntactic sugar for *(var + offset) which is why
things like 3[x] work the same as x[3] in C.
Um, no.
x = y + 3 ;
in a C program will _not_ store in x the value of y plus the contents
of memory location 3.
No one claimed it would. But in C, 3[x] == x[3], provided x is a
pointer type pointing to an array with at least four elements, just as
Steve claimed.
Quote:
Of course not, given that there is dereference operator anywhwere. On
the other hand
x = y + *((int*)3);
would do what you want.
the other hand
x = y + *((int*)3);
would do what you want.
No, it wouldn't, since casting an integer to a pointer type causes
undefined behavior. It might work (for some value of "work") in some
implementations, but it's not valid C.
--
Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University
Michael Wojcik
Guest
Guest
Tue Mar 09, 2010 7:22 pm
Ahem A Rivet's Shot wrote:
Quote:
No but x = *(y + 3) will store in x the contents of the memory
location at 3
.... times the size in bytes[1] of the base type of y, which must be an
object pointer type ...
Quote:
+ the value of y just as x = y[3] will and x = 3[y] will,
which is what I stated.
which is what I stated.
[1] "bytes" as defined by the C Standard, ie the size of a char
object, which may or may not be an octet.
--
Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University
Michael Wojcik
Guest
Guest
Tue Mar 09, 2010 7:32 pm
Quadibloc wrote:
Quote:
Yes: the array name always refers to the pointer,
No, not "always", as has been pointed out more than once in this thread.
There are specific contexts where an identifier of array type decays
to a pointer to its first element. There are others where it does not,
such as when it is the operand of the sizeof operator.
This is all spelled out quite clearly in the C standard, and in
various other references, some of which were cited upthread.
--
Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University
Michael Wojcik
Guest
Guest
Tue Mar 09, 2010 7:40 pm
Peter Flass wrote:
Quote:
Michael Wojcik wrote:
Peter Flass wrote:
Hey! C's finally caught up to PL/I. Only took them 50 years, and then
of course all the features are just tacked-on in true C fashion, instead
of thought-through.
Well, that's rather insulting to the members of WG14, who spent a
decade designing those features. Fortunately, they published the
Rationale showing that, in fact, they were thought through.[1] And a
great deal of documentation describing the process is available in the
archives.[2]
If you'd care to show why you think otherwise, perhaps there would be
some grounds for debate.
"The flexible array must be last"?
Peter Flass wrote:
Hey! C's finally caught up to PL/I. Only took them 50 years, and then
of course all the features are just tacked-on in true C fashion, instead
of thought-through.
Well, that's rather insulting to the members of WG14, who spent a
decade designing those features. Fortunately, they published the
Rationale showing that, in fact, they were thought through.[1] And a
great deal of documentation describing the process is available in the
archives.[2]
If you'd care to show why you think otherwise, perhaps there would be
some grounds for debate.
"The flexible array must be last"?
Doing otherwise would break existing code. WG14's remit is to maintain
upward compatibility.
Quote:
"sizeof applied to the structure ignores the array but counts any
padding before it"?
padding before it"?
I have no idea what you're quoting there. That phrase doesn't seem to
be present in my copy of the standard.
Quote:
C is a collection of ad-hoc ideas. WG14 may have put a great deal of
thought into how to extend it without breaking the existing mosh, but
that's my point, it's still a mosh.
thought into how to extend it without breaking the existing mosh, but
that's my point, it's still a mosh.
If that was your point, then I have to say it was rather ill-expressed.
--
Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University
Michael Wojcik
Guest
Guest
Tue Mar 09, 2010 7:42 pm
Greg Menke wrote:
Quote:
Peter Flass <Peter_Flass_at_Yahoo.com> writes:
C is a collection of ad-hoc ideas. WG14 may have put a great deal of
thought into how to extend it without breaking the existing mosh, but
that's my point, it's still a mosh.
iostream formatting operators, because we really need more operator
overloading and no enhancements are too bizarre in service of making
everything, (for particular values of everything), specialized?
C is a collection of ad-hoc ideas. WG14 may have put a great deal of
thought into how to extend it without breaking the existing mosh, but
that's my point, it's still a mosh.
iostream formatting operators, because we really need more operator
overloading and no enhancements are too bizarre in service of making
everything, (for particular values of everything), specialized?
How fortunate, then, that C does not have them.
Quote:
Oh but wait, you can compile, install and dig your way through Boost so
as to avoid the fun & games of vanilla iostream.
as to avoid the fun & games of vanilla iostream.
Not in C, you can't.
Quote:
Thank goodness printf and friends are still around.
Indeed, since a great number of C programs use them, and the committee
is explicitly charged with maintaining upward compatibility from the
first standard.
--
Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University
Michael Wojcik
Guest
Guest
Tue Mar 09, 2010 7:42 pm
Greg Menke wrote:
Quote:
C++ does make for a nice "type-safe linking" C compiler.
Except that it's not a C implementation, and so is not a C compiler at
all.
C and C++ are different languages.
--
Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University
Greg Menke
Guest
Guest
Tue Mar 09, 2010 9:10 pm
Michael Wojcik <mwojcik_at_newsguy.com> writes:
Quote:
Greg Menke wrote:
C++ does make for a nice "type-safe linking" C compiler.
Except that it's not a C implementation, and so is not a C compiler at
all.
C and C++ are different languages.
C++ does make for a nice "type-safe linking" C compiler.
Except that it's not a C implementation, and so is not a C compiler at
all.
C and C++ are different languages.
Perhaps so, yet it is possible to compile C programs with a C++ and
observe some benefits relating to better compile-time and link-time type
checking. One can then disassemble the object modules created by C vs
C++ compilers and observe the distinct similarity of with respect to the
runtime structure.
Which is why it "makes for a nice C compiler", not "is a better C
compiler".
Gregm
Greg Menke
Guest
Guest
Tue Mar 09, 2010 9:18 pm
Michael Wojcik <mwojcik_at_newsguy.com> writes:
Quote:
Greg Menke wrote:
Peter Flass <Peter_Flass_at_Yahoo.com> writes:
C is a collection of ad-hoc ideas. WG14 may have put a great deal of
thought into how to extend it without breaking the existing mosh, but
that's my point, it's still a mosh.
iostream formatting operators, because we really need more operator
overloading and no enhancements are too bizarre in service of making
everything, (for particular values of everything), specialized?
How fortunate, then, that C does not have them.
Peter Flass <Peter_Flass_at_Yahoo.com> writes:
C is a collection of ad-hoc ideas. WG14 may have put a great deal of
thought into how to extend it without breaking the existing mosh, but
that's my point, it's still a mosh.
iostream formatting operators, because we really need more operator
overloading and no enhancements are too bizarre in service of making
everything, (for particular values of everything), specialized?
How fortunate, then, that C does not have them.
You are quoting out of context.
The original topic to which I followed up via the above quote was
related to the sometimes "undesigned" appearance of C++. The particular
quote above suggests C was already a collection of ad-hoc ideas, so that
C++ is not a substantial departure from existing practice.
Quote:
Oh but wait, you can compile, install and dig your way through Boost so
as to avoid the fun & games of vanilla iostream.
Not in C, you can't.
as to avoid the fun & games of vanilla iostream.
Not in C, you can't.
See above.
Quote:
Thank goodness printf and friends are still around.
Indeed, since a great number of C programs use them, and the committee
is explicitly charged with maintaining upward compatibility from the
first standard.
See above.
Gregm
Gene Wirchenko
Guest
Guest
Tue Mar 09, 2010 9:59 pm
On Sat, 06 Mar 2010 18:55:56 -0600, Charles Richmond
<frizzle_at_tx.rr.com> wrote:
[snip]
Quote:
I think there is *not* a single C programmer who has *not* had his
hand slapped by making the mistake of using "=" when he meant
"==". Thus the avalanche of replies...
hand slapped by making the mistake of using "=" when he meant
"==". Thus the avalanche of replies...
And because of this stupidity in language design being taken as
acceptable, now, there is, in some related languages, the problem of
using == when you needed ===.
Sincerely,
Gene Wirchenko
Andy Botterill
Guest
Guest
Tue Mar 09, 2010 10:18 pm
Could you please move this discussion about C and related programming
languages out of comp.arch.fpga. This thread has deviated considerably
from the original posters request which was mostly on topic. Andy
Peter Flass
Guest
Guest
Tue Mar 09, 2010 10:56 pm
Michael Wojcik wrote:
Quote:
Peter Flass wrote:
Michael Wojcik wrote:
Peter Flass wrote:
Hey! C's finally caught up to PL/I. Only took them 50 years, and then
of course all the features are just tacked-on in true C fashion, instead
of thought-through.
Well, that's rather insulting to the members of WG14, who spent a
decade designing those features. Fortunately, they published the
Rationale showing that, in fact, they were thought through.[1] And a
great deal of documentation describing the process is available in the
archives.[2]
If you'd care to show why you think otherwise, perhaps there would be
some grounds for debate.
"The flexible array must be last"?
Doing otherwise would break existing code. WG14's remit is to maintain
upward compatibility.
Michael Wojcik wrote:
Peter Flass wrote:
Hey! C's finally caught up to PL/I. Only took them 50 years, and then
of course all the features are just tacked-on in true C fashion, instead
of thought-through.
Well, that's rather insulting to the members of WG14, who spent a
decade designing those features. Fortunately, they published the
Rationale showing that, in fact, they were thought through.[1] And a
great deal of documentation describing the process is available in the
archives.[2]
If you'd care to show why you think otherwise, perhaps there would be
some grounds for debate.
"The flexible array must be last"?
Doing otherwise would break existing code. WG14's remit is to maintain
upward compatibility.
Yes, as I said, they probably did the best they could with what they had
to work with.
Quote:
"sizeof applied to the structure ignores the array but counts any
padding before it"?
I have no idea what you're quoting there. That phrase doesn't seem to
be present in my copy of the standard.
Same reference as above, a bit farther down. [whatever the link I was
sent was, it got clipped somewhere]
Quote:
C is a collection of ad-hoc ideas. WG14 may have put a great deal of
thought into how to extend it without breaking the existing mosh, but
that's my point, it's still a mosh.
If that was your point, then I have to say it was rather ill-expressed.
Most of my points are ill-expressed. I do the best I can with what I've
got to work with, too.
Michael Wojcik
Guest
Guest
Tue Mar 09, 2010 11:59 pm
[Followups restricted to a.f.c.]
Greg Menke wrote:
Quote:
Michael Wojcik <mwojcik_at_newsguy.com> writes:
Greg Menke wrote:
C++ does make for a nice "type-safe linking" C compiler.
Except that it's not a C implementation, and so is not a C compiler at
all.
C and C++ are different languages.
Perhaps so, yet it is possible to compile C programs with a C++
Greg Menke wrote:
C++ does make for a nice "type-safe linking" C compiler.
Except that it's not a C implementation, and so is not a C compiler at
all.
C and C++ are different languages.
Perhaps so, yet it is possible to compile C programs with a C++
Only some C programs. And then you are not compiling C programs with a
C++ implementation; you are compiling C++ programs that happen to be
written in the common subset of C and C++.
Quote:
and
observe some benefits relating to better compile-time and link-time type
checking.
observe some benefits relating to better compile-time and link-time type
checking.
There's nothing to prevent a conforming C implementation from making
similar checks, and some do. And any decent implementation, combined
with a modicum of discipline, makes this type checking unnecessary,
because the implementation's normal diagnostics will catch everything
C++-style name mangling would.
For better quality assurance, use real tools like Splint.
Quote:
One can then disassemble the object modules created by C vs
C++ compilers and observe the distinct similarity of with respect to the
runtime structure.
C++ compilers and observe the distinct similarity of with respect to the
runtime structure.
Irrelevant. Many language implementations produce similar output.
Quote:
Which is why it "makes for a nice C compiler", not "is a better C
compiler".
compiler".
I'm well familiar with this argument - I've heard it since circa 1990,
if memory serves. I'm not convinced. Write C for C implementations,
and C++ for C++ implementations.
Michael Wojcik
Guest
Guest
Tue Mar 09, 2010 11:59 pm
[Followups restricted to a.f.c.]
Greg Menke wrote:
Quote:
Michael Wojcik <mwojcik_at_newsguy.com> writes:
Greg Menke wrote:
Peter Flass <Peter_Flass_at_Yahoo.com> writes:
C is a collection of ad-hoc ideas. WG14 may have put a great deal of
thought into how to extend it without breaking the existing mosh, but
that's my point, it's still a mosh.
iostream formatting operators, because we really need more operator
overloading and no enhancements are too bizarre in service of making
everything, (for particular values of everything), specialized?
How fortunate, then, that C does not have them.
You are quoting out of context.
Greg Menke wrote:
Peter Flass <Peter_Flass_at_Yahoo.com> writes:
C is a collection of ad-hoc ideas. WG14 may have put a great deal of
thought into how to extend it without breaking the existing mosh, but
that's my point, it's still a mosh.
iostream formatting operators, because we really need more operator
overloading and no enhancements are too bizarre in service of making
everything, (for particular values of everything), specialized?
How fortunate, then, that C does not have them.
You are quoting out of context.
Nonsense. I quoted all of your message up to that point, and the
relevant part of Peter's.
Quote:
The original topic to which I followed up via the above quote was
related to the sometimes "undesigned" appearance of C++.
related to the sometimes "undesigned" appearance of C++.
Peter did not mention C++. My message, to which he was responding, did
not mention C++. I don't see a single reference to C++ in any of the
ancestor messages, until your own.
Quote:
The particular
quote above suggests C was already a collection of ad-hoc ideas, so that
C++ is not a substantial departure from existing practice.
quote above suggests C was already a collection of ad-hoc ideas, so that
C++ is not a substantial departure from existing practice.
An odd thing to "suggest" in a conversation about C. Perhaps you
should have noted that you had decided to switch to a different topic.
Eric Chomko
Guest
Guest
Wed Mar 10, 2010 9:30 pm
On Mar 9, 1:42 pm, Michael Wojcik <mwoj...@newsguy.com> wrote:
Quote:
Greg Menke wrote:
C++ does make for a nice "type-safe linking" C compiler.
Except that it's not a C implementation, and so is not a C compiler at
all.
C and C++ are different languages.
C++ does make for a nice "type-safe linking" C compiler.
Except that it's not a C implementation, and so is not a C compiler at
all.
C and C++ are different languages.
There is a subset/superset relationship between the two. Not unlike
the 8080 and Z-80, except IMO, the Z-80 is better than the 8080 and C
is better than C++.
elektroda.net NewsGroups Forum Index - FPGA - using an FPGA to emulate a vintage computer
