4 ms·

I think people disregard or forget the new programmer. Some of them are coming to C++. The question starts with how do I draw to the screen. The answer, wel

I think people disregard or forget the new programmer. Some of them are coming to C++. The question starts with how do I draw to the screen. The answer, well you download <pick a library>, compile it, add it to the include/linker paths, and then it should work. But, one thing is, if it isn't in the standard it does not exist. A simple set_pixel/get_pixel onto a surface(real or just a buffer) is pretty powerful. it allows expressing data in much better terms than cout/printf for many domains. I remember the joy or displaying my first sine wave. I think the current proposal was too heavy and I think that a minimal subset where one can draw pixels, lines... onto a surface is all that is needed for now. This gives a standard way of expressing that idea that allows further abstractions in the future. But for now, I want an easy way to visualize something.

mattnewport 8y ago
Better to focus on improving the situation with cross platform package managers and build systems for C++ IMO to simplify the process for beginners getting access to those third party libraries in their projects than trying to integrate graphics into the standard. There is some progress being made on package managers for C++ but things are still pretty fragmented and not very beginner friendly.
- hasahmed 8y ago
  Agreed times a million. I'm still blown away by how there is not a common npm-like C/C++ package manager. I know there are a few that are trying to make it happen, but still... Its really the widespread adoption that makes these things valuable.
- flohofwoe 8y ago
  Agreed. The beginner solution to get something renderable should be: > cpm install cairo And then in the source file: import cairo; (I think package manager, build system and modules need to go hand in hand)
  - beached_whale 8y ago
    vcpkg is almost there
- beached_whale 8y ago
  I don't think it is an either or. But being in the standard really aids in discovery and provides an interface to allow it to work just as well for everyone. Ad for package maanagers, first you have to get everyone to agree on an approach. So the first question is binary, source, or either. Then figure out if it is distributed(e.g. specify the host in the dependency) or centralized. For me I would something that is mixed binary/source and distributed. I do not want to be required pull binaries from a central host or require a central DB of locations. It would be good to have, just not mandatory. Then, like you said, the build system. I am not sure that this needs to be any one system. If you look at CMake external projects it is close to being really good with allowing most source control systems/url's. What it lacks is the ability to use versioning(such as git commit/release and per user/per system caching) It also does a git check on each build. But specifying dependencies like Carthage, used for Xcode, would a nice starting point
flohofwoe 8y ago
And why should the standard be encumbered with a toy API that's only useful for beginners (it's not like the rest of the standard library is exactly beginner friendly). And it's a bottomless pit, what use is drawing alone if you can't interact with the program? If you draw something, you need a window to draw into. You need a portable application entry because the standard main() is useless (think of Android, iOS and HTML5 via wasm). You need some sort of window-management. You need at least mouse and keyboard handling (and also consider devices which only have touch input). Want to render a hiscore? Now you need text rendering too. A button to start the game? Do we add a complete UI system like Qt? And that's just for getting beginners to write a little interactive toy program, all of this will be fairly useless for 'real' applications. Sorry to be blunt, but the whole idea was rubbish to begin with.
pandaman 8y ago
> But, one thing is, if it isn't in the standard it does not exist. I am not sure it's true. There are plenty of graphics libraries, including ones with their own standards (like OpenGL), which not only exist but are quite popular and have tons of code written against them.

mattnewport 8y ago

Better to focus on improving the situation with cross platform package managers and build systems for C++ IMO to simplify the process for beginners getting access to those third party libraries in their projects than trying to integrate graphics into the standard. There is some progress being made on package managers for C++ but things are still pretty fragmented and not very beginner friendly.

hasahmed 8y ago
Agreed times a million. I'm still blown away by how there is not a common npm-like C/C++ package manager. I know there are a few that are trying to make it happen, but still... Its really the widespread adoption that makes these things valuable.
flohofwoe 8y ago
Agreed. The beginner solution to get something renderable should be: > cpm install cairo And then in the source file: import cairo; (I think package manager, build system and modules need to go hand in hand)
- beached_whale 8y ago
  vcpkg is almost there
beached_whale 8y ago
I don't think it is an either or. But being in the standard really aids in discovery and provides an interface to allow it to work just as well for everyone. Ad for package maanagers, first you have to get everyone to agree on an approach. So the first question is binary, source, or either. Then figure out if it is distributed(e.g. specify the host in the dependency) or centralized. For me I would something that is mixed binary/source and distributed. I do not want to be required pull binaries from a central host or require a central DB of locations. It would be good to have, just not mandatory. Then, like you said, the build system. I am not sure that this needs to be any one system. If you look at CMake external projects it is close to being really good with allowing most source control systems/url's. What it lacks is the ability to use versioning(such as git commit/release and per user/per system caching) It also does a git check on each build. But specifying dependencies like Carthage, used for Xcode, would a nice starting point

flohofwoe 8y ago

And why should the standard be encumbered with a toy API that's only useful for beginners (it's not like the rest of the standard library is exactly beginner friendly). And it's a bottomless pit, what use is drawing alone if you can't interact with the program? If you draw something, you need a window to draw into. You need a portable application entry because the standard main() is useless (think of Android, iOS and HTML5 via wasm). You need some sort of window-management. You need at least mouse and keyboard handling (and also consider devices which only have touch input). Want to render a hiscore? Now you need text rendering too. A button to start the game? Do we add a complete UI system like Qt? And that's just for getting beginners to write a little interactive toy program, all of this will be fairly useless for 'real' applications. Sorry to be blunt, but the whole idea was rubbish to begin with.

pandaman 8y ago

> But, one thing is, if it isn't in the standard it does not exist. I am not sure it's true. There are plenty of graphics libraries, including ones with their own standards (like OpenGL), which not only exist but are quite popular and have tons of code written against them.