using an FPGA to emulate a vintage computer
in [FPGA]
|
From: Michael Wojcik on 9 Mar 2010 13:42 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. -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State University
From: Michael Wojcik on 9 Mar 2010 13:19 Muzaffer Kal wrote: > On Fri, 5 Mar 2010 09:07:31 -0800 (PST), Quadibloc <jsavard(a)ecn.ab.ca> > wrote: >> On Feb 26, 4:56 am, Ahem A Rivet's Shot <ste...(a)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. > Of course not, given that there is dereference operator anywhwere. On > 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
From: Michael Wojcik on 9 Mar 2010 13:22 Ahem A Rivet's Shot wrote: > > 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 ... > + the value of y just as x = y[3] will and x = 3[y] will, > 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
From: Michael Wojcik on 9 Mar 2010 13:42 Greg Menke wrote: > Peter Flass <Peter_Flass(a)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. > 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. > 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
From: Michael Wojcik on 9 Mar 2010 13:32
Quadibloc wrote: > > 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 |