ints chars and doubles(primitive types)
Hi guys,
although at this stage I don't really consider myself much of a beginner anymore,but I feel like putting this in the beginner section and hope it will get some traction.
So to begin with this isn't a tutorial more like a thread where more experienced and knowledgeable programmers than myself would like to share their insight.
Ok so obviously at the very basics we have primitive types such as int,long,double,float,char. ofcourse there are more features to a language such as loops,branching,bit manipulation,input,output(even these kind of fall into my question,input output that is) also ofcourse we have pointers too.
we have many libraries in C++ and C which are compatible with C++ such as SFML,SDL,OPENGL,the QT framework,Windows api,Linux api and much much more
so these libraries contain many classes,but if you think about it the C++ language only has a certain amount of primitives mentioned earlier,so are most of these classes in these frameworks built using just the primitives of the language? I would imagine framework/engines such as SFML,QT and SDL are written using the windows and Linux API's but lets go lower level are those API's (windows and linux) written in the primitives of the language( I know there is some assembly involved)?
and for other libraries is this also the case?
also do libraries emphatically have to be based on other API's?
because it's quite clear if you were given no libraries or API's to use lets say just the primitives of the language there is no way I could imagine of creating things such as a window.
it's always something that interested me as programming sometimes can be quite abstract.
although at this stage I don't really consider myself much of a beginner anymore,but I feel like putting this in the beginner section and hope it will get some traction.
So to begin with this isn't a tutorial more like a thread where more experienced and knowledgeable programmers than myself would like to share their insight.
Ok so obviously at the very basics we have primitive types such as int,long,double,float,char. ofcourse there are more features to a language such as loops,branching,bit manipulation,input,output(even these kind of fall into my question,input output that is) also ofcourse we have pointers too.
we have many libraries in C++ and C which are compatible with C++ such as SFML,SDL,OPENGL,the QT framework,Windows api,Linux api and much much more
so these libraries contain many classes,but if you think about it the C++ language only has a certain amount of primitives mentioned earlier,so are most of these classes in these frameworks built using just the primitives of the language? I would imagine framework/engines such as SFML,QT and SDL are written using the windows and Linux API's but lets go lower level are those API's (windows and linux) written in the primitives of the language( I know there is some assembly involved)?
and for other libraries is this also the case?
also do libraries emphatically have to be based on other API's?
because it's quite clear if you were given no libraries or API's to use lets say just the primitives of the language there is no way I could imagine of creating things such as a window.
it's always something that interested me as programming sometimes can be quite abstract.
Last edited on
In some coarse sense the hardware manufacturers provide an API that is implemented (mostly) in silicon.
If a programmer causes the right data to go to the right spot, the electronics "notices" and takes action accordingly. We can make the machine do stuff (light up a particular pixel on a screen, e.g.) because that is literally what the electronics is built to do. Memory, after all, is basically just electronically-controllable switches: if the correct light-switch is on, a pixel lights up.
All the operating system does is abstract away the details of specific hardware for the users. The OS knows which light switch(es) the programmer's asking about and provides a predictable and mostly-transparent way to turn them on and off.
That information is written down in the hardware manufacturer's documentation. We just don't talk about it very much because as applications programmers the OS and the libraries we use do a fine job of hiding it from us.
Cutting out plenty of steps in the middle, it's sort of like this:
Your program tells the hardware what to do through the kernel.
The hardware tells your program what happened through the kernel.
If you can get one pixel to turn on, you can presumably turn on more than one. Once you can do that, how much work is it until we can start thinking about a GUI? (Lots, but it's no longer inconceivable!)
https://abstrusegoose.com/307
If a programmer causes the right data to go to the right spot, the electronics "notices" and takes action accordingly. We can make the machine do stuff (light up a particular pixel on a screen, e.g.) because that is literally what the electronics is built to do. Memory, after all, is basically just electronically-controllable switches: if the correct light-switch is on, a pixel lights up.
All the operating system does is abstract away the details of specific hardware for the users. The OS knows which light switch(es) the programmer's asking about and provides a predictable and mostly-transparent way to turn them on and off.
That information is written down in the hardware manufacturer's documentation. We just don't talk about it very much because as applications programmers the OS and the libraries we use do a fine job of hiding it from us.
Cutting out plenty of steps in the middle, it's sort of like this:
Your program tells the hardware what to do through the kernel.
The hardware tells your program what happened through the kernel.
If you can get one pixel to turn on, you can presumably turn on more than one. Once you can do that, how much work is it until we can start thinking about a GUI? (Lots, but it's no longer inconceivable!)
https://abstrusegoose.com/307
Last edited on
Keep in mind that the C programming language is 46 years old (1972). C++ is ... 33 years old? (1985?). Various libraries have been built on top of them ever since. Also, C benefits from decades of other languages, operating systems, editors etc. etc. going back to the mid 1950's for mainstream computers and 10-20 years earlier than that for other electronic computing machines.
Although windows has been around for a long time, it struggled until WinNT, which became mainstream in Windows 2000 if I recall correctly. So there are windows libraries and APIs built before and after those.
So what you're dealing with now is the result of several decades of innovation, invention, and development.
Although windows has been around for a long time, it struggled until WinNT, which became mainstream in Windows 2000 if I recall correctly. So there are windows libraries and APIs built before and after those.
So what you're dealing with now is the result of several decades of innovation, invention, and development.
looking at it backwards, everything we do ends up as primitive types. Your high level classes with inheritance and all the trimmings and such get run through the compiler and linker until towards the end of the process it generates machine language (not quite one to one with assembly, but close enough that we can get an assembly program from there with a compiler flag to review what it did). So everything you did ended up as primitive types (various sizes of integers and doubles) and a handful of mostly simple commands (the cpu can loop, compare primitive types, jump, index memory (array style or pointer style), do some logic and math, etc).
So everything you did, you could have written in assembly. C++ and such languages are just a way to express your ideas with smaller amounts of typed code and less tedious detail stuff (no one wants to go to memory location 199763, get the byte there, move it to a register, move another value to a register, compare the two and jump the code or not based off the result, then change the register and write the result back to the memory location) just to say if(x == y) x = othervalue;
C++ is for humans, in other words, to make telling the computer what we want it to do easier.
What level various tools are written at depend on the tool and what is needed and when it was written. There is not as much handwritten assembly anymore; programmers write a few lines of it here and there for a couple of reasons (can't do it cleanly any other way, like endian reversal which is built into the chip but takes a bunch of unnecessary operations to mimic in code) or for speed (humans can often write assembly that beats c++ code, but not as true as it used to be with smarter compilers and not as necessary with modern cpu speeds). Mostly, humans prefer shorter and easier to read and write, so we use high level languages as much as we can.
So everything you did, you could have written in assembly. C++ and such languages are just a way to express your ideas with smaller amounts of typed code and less tedious detail stuff (no one wants to go to memory location 199763, get the byte there, move it to a register, move another value to a register, compare the two and jump the code or not based off the result, then change the register and write the result back to the memory location) just to say if(x == y) x = othervalue;
C++ is for humans, in other words, to make telling the computer what we want it to do easier.
What level various tools are written at depend on the tool and what is needed and when it was written. There is not as much handwritten assembly anymore; programmers write a few lines of it here and there for a couple of reasons (can't do it cleanly any other way, like endian reversal which is built into the chip but takes a bunch of unnecessary operations to mimic in code) or for speed (humans can often write assembly that beats c++ code, but not as true as it used to be with smarter compilers and not as necessary with modern cpu speeds). Mostly, humans prefer shorter and easier to read and write, so we use high level languages as much as we can.
Thanks guys
@Jonnin true but for example I find it hard to imagine how a GUI such as windows,labels buttons could be written in just C++'s primitive types with no system calls,
I would imagine the GPU and CPU is involved and the OS is responsible for creating these windows,buttons,labels etc(just turning on and off different pixels on the screen or varying their color) so creating a window would be mainly done through the windows API on a windows system,of course I'm guessing you could write a window yourself from scratch if you had access to that graphics card perhaps through a device driver?
I just can't see how you could get a window to appear on the screen with just the primitive types.
thanks
@Jonnin true but for example I find it hard to imagine how a GUI such as windows,labels buttons could be written in just C++'s primitive types with no system calls,
I would imagine the GPU and CPU is involved and the OS is responsible for creating these windows,buttons,labels etc(just turning on and off different pixels on the screen or varying their color) so creating a window would be mainly done through the windows API on a windows system,of course I'm guessing you could write a window yourself from scratch if you had access to that graphics card perhaps through a device driver?
I just can't see how you could get a window to appear on the screen with just the primitive types.
thanks
system calls are needed, yes. Calling operating system routines is still going to resolve to primitives though; it just sets internals in the OS that you can't directly access, they are still just bytes for the most part. There are also hardware interrupt type routines (literally routines in the hardware, or in the bios, etc) that you must interface to, but those also are at some level bytes and such. Everything follows the same rules down in the CPU.
The windows api is obviously a bunch of classes and high level tools when you use it in C++. (It looks a little different in basic, etc). That was never in question, but when it actually executes, its ints and doubles and chars down in the cpu same as anything else.
you can directly command the graphics card to draw. Its just hardware. I would not do this, you can actually damage things if you don't know your way around, but its doable and was actually THE way games were done in dos etc.
at some level, there is very likely a hardware service that says "take this pointer that I just gave you. It is an RGB array. Draw it on the screen" which probably looks like mov ax, pointer, call interrupt 17 or something like that.
The OS may prevent this (it has rules), the hardware interface may be very complex, and I have no idea how to do it on anything newer than a 386 and I don't remember how to do it there too well either, lol. But none of that is the point, the point is that down deep, its all bytes and pointers and simple things that are put together very quickly to work their magic. Modern GPU are a bit weird, they have a lot of cpus in parallel and it takes some study to talk to them.
that is all it would be. Just load an image into a buffer and tell the hardware to display it is how you draw a window on the screen. The interactions of the windows and all is done in the software, but the actual display is just a dump. The buffer likely lives in the memory of the graphics card, but its still just a chunk of ram that you write to, with some rules to get to it.
Which is not to over-simplify the process. There is a LOT of stuff going on to draw modern GUIs. I have clearly skipped a lot of OS code and jumped straight to how it ends up on the screen.... think about displaying a web page with all the fonts and images and videos and sounds and its hair raising for sure :)
The windows api is obviously a bunch of classes and high level tools when you use it in C++. (It looks a little different in basic, etc). That was never in question, but when it actually executes, its ints and doubles and chars down in the cpu same as anything else.
you can directly command the graphics card to draw. Its just hardware. I would not do this, you can actually damage things if you don't know your way around, but its doable and was actually THE way games were done in dos etc.
at some level, there is very likely a hardware service that says "take this pointer that I just gave you. It is an RGB array. Draw it on the screen" which probably looks like mov ax, pointer, call interrupt 17 or something like that.
The OS may prevent this (it has rules), the hardware interface may be very complex, and I have no idea how to do it on anything newer than a 386 and I don't remember how to do it there too well either, lol. But none of that is the point, the point is that down deep, its all bytes and pointers and simple things that are put together very quickly to work their magic. Modern GPU are a bit weird, they have a lot of cpus in parallel and it takes some study to talk to them.
that is all it would be. Just load an image into a buffer and tell the hardware to display it is how you draw a window on the screen. The interactions of the windows and all is done in the software, but the actual display is just a dump. The buffer likely lives in the memory of the graphics card, but its still just a chunk of ram that you write to, with some rules to get to it.
Which is not to over-simplify the process. There is a LOT of stuff going on to draw modern GUIs. I have clearly skipped a lot of OS code and jumped straight to how it ends up on the screen.... think about displaying a web page with all the fonts and images and videos and sounds and its hair raising for sure :)
Last edited on
| you can directly command the graphics card to draw. Its just hardware. I would not do this, you can actually damage things if you don't know your way around, but its doable and was actually THE way games were done in dos etc. |
that's interesting :o but I'm guessing there is safe guards put in place by the OS to prevent you from accessing that device driver right?
If there is I'm guessing you would have to implement your own OS(mammoth task) that way you can access any of the hardware without the restraints(if there is any) and this probably would be pretty hard without the individual hardware pieces manuals.
closed account (SECMoG1T)
if one day you will get into embedded sys programming then everything might get clear to you, some embedded systems do use operating systems but not all, for those that don't you actually have to do everything from scratch, the microprocessor and supporting devices manuals will tells you what commands are available for such devices, that all you get.. everything else you create using those commands, including device drivers, kernels if required, firmware and even some User interfaces and anything else you need, although sometimes you get templates already coded they might be bloatware for your sys requirement, you need to reduce the memory footprint as much as possible so you will always find yourself going back to the drawing board.
you might find yourself creating a whole system from the ground up in pure assembly language, or you get lucky and use c/c++.
you might find yourself creating a whole system from the ground up in pure assembly language, or you get lucky and use c/c++.
Last edited on
that is correct, if you write your own OS or hack on an opensource one you could directly interface to hardware. Its a poor design on a full computer, necessary on micros as said above. The last embedded system I did ran windows. It was relatively small and weak, but it was a full on system, as are tablets (the computer part is insanely small, the screen takes up all the space and power). Imagine tablets/phones with no screen. Long battery life, pretty impressive computing power... you can still do dsp/gate array/etc stuff, and its necessary for low cost solutions, but IMHO it won't be long before the capability even on dollar a pop chips is close to a full system.
Last edited on
Topic archived. No new replies allowed.