As you probably know, C++ has no standard graphics library. Most games use DirectX or OpenGL.
But how do those libraries actually work? In other words, how can the third-party libraries draw graphics if there's no mechanism for it in C++? Are they just written in another language?
Specifically DirectX and OpenGL work by calling the operating system and/or the video hardware driver. The driver, in turn, does the actual drawing by interacting with the graphical device. The exact details of interaction vary from one video card to another.
Back in the DOS days, C++ programmers could work with the hardware directly. This was accomplished in two ways. First, by writing to/reading from a special memory block ("framebuffer" AKA "video memory") where the pixels or text were stored. It was a span of memory at a known address, so to work with it you had to cast an integer constant to a pointer and work with that pointer. Purely C++ mechanism. The other way of interaction was reading from/writing to I/O ports. Now, this is a mechanism that was not directly supported by C, unless you count inline assembly. There were library functions that would wrap these two operations (literally, wrappers around two CPU commands - INP and OUTP), but most programmers would use a one-line inline assembly snippet instead.
These days, most compilers that I know of have intrinsics for port operations. Those compile to INP/OUTP without a function call. And support for inline assembly is no longer a given.
Even now, video hardware interaction boils down to these two pathways - framebuffer and I/O ports. But we application-level programmers don't get to see those anymore. This is driver stuff.
One modern caveat has to do with protected mode; in protected mode, the C pointers are not the same as underlying physical addresses. Simply typecasting 0xA0000 to a pointer won't get you to a framebuffer, even in kernel mode. However, kernel-level code (i. e. a driver) can request that the memory manager give it a pointer that corresponds to a specific physical address.
One other pathway of programs interacting with hardware is catching and processing hardware interrupts. It's not usually used for graphics (to the best of my knowledge), but it's also handled by the operating system, with the raw interrupt handler being in the kernel and the driver doing the follow-up processing.