Yea mate... It's what we "Cut or teeth on" in the 'computing' field !
A new 'whipper-snapper' these days starts at Uni, learning 'C++' of what ever :-)
(And of course 'HTML5'/Javascript/CSS)...
But do they know about 'Machine-Code' !!!!!!! hahaha.....
Hardly forgotten -- there's a thing called WebAssembly now. You load a Uint8Array with various specific bytes, then execute it in a virtual machine (which, I don't know what instruction sets are available, or if it's specific to x86). What's old is now new again!
C and friends are rather useful shortcuts. There are so many things you encounter in assembler that are pure tedium, that you don't need to be wasting your time writing. Especially on RISC instruction sets. Far better to have the compiler do it for you. Learn the inner workings of C -- inspect the assembler output it generates! -- and treat the compiler as an assembler generator.
This is a valuable perspective in VHDL too, though there the instantiation is more direct: you're describing gates, latches, state machines and so on. The key is you're doing it far quicker than you could write a schematic, and you're doing it at scale, and optionally with parameterization, too!
Which is not to say, abuse the compiler to generate whatever assembly you think you want. Respect its semantics. Don't force it to do something special-case and fragile; talk nicely to it, work within its semantics to generate code that is both robust and efficient.
I was just telling someone about the inner workings of object-oriented programming (OOP) -- if you're having trouble working with the abstraction, then consider a concrete example.
I don't know if all OOP languages follow this design, internally. After all, it shouldn't matter, and doesn't -- that's the point of the abstraction, not needing to know! But at the very least, this is still one possible implementation of it, and where a concrete example is needed, it's perfectly fine!
Anyway: what is an "object"?
An object is a structure, a block of memory organized as a set of parameters, given special (object-specific) meaning. In C, a struct.
The special thing about an "object" is the struct contains function pointers, to functions that operate on the object.
So, an OOP implementation in C would add function pointers to the struct, which are initialized to whatever functions operate on that struct. (The initialization is called "construction".)
When you say "object.doStuff()", you're actually calling "object.doStuff(&object);" -- the object itself is passed in, implicitly, as a parameter to the function. In the function, the object appears as the variable: "this".
When every object of that type is constructed, the same functions are bound to it. So the functions are all the same, across objects. Same code, residing at the same address, but able to serve any object of that type, anywhere in memory.
This is very apparent once you study C++ -- there, the whole process is explicit, all exposed for you. Most of the time, you don't want to touch that, you want to stick with the default behavior and harness the simple, powerful syntax of OOP. But the option is there, for the expert programmer, to control all of these internals. It is likewise their responsibility to make sure references don't get screwed up in the process!
Tim
Home
Help
Search
Login
Register
