5 ms·

Do we really need a vector graphics library in standard C++? Why not just create a new ISO standard using Cairo as the base, and stop making the language even m

by sparkie 13y ago

Do we really need a vector graphics library in standard C++? Why not just create a new ISO standard using Cairo as the base, and stop making the language even more bloated that it currently is. If the proposed graphics API does not require changes to the language it really doesn't need to be there.

oscargrouch 13y ago
yeah.. i dont think that add much to the language.. as for 2d we are better of pluging into the native 2d api of the systems we are plumbing.. thats the true value of C and C++ What c++ is trying to be, java?
- adamnemecek 13y ago
  I mean, C++ is the de facto standard for graphics drawing so it kind of makes sense. It's kind of similar to how Go has a HTTP library as a part of the standard library.
MaulingMonkey 13y ago
Quality standard libraries are wonderful in that you can rely on their presence. A thousand ad hoc separately licensed libraries with wildly varying build chains, supported compilers and operating systems, with similarly varying code quality, naming conventions, build configuration options, conflicting runtime selection, error handling styles, documentation quality, etc. may be the bread and butter of your standard C++ programmer -- I know it is of mine -- but it hardly seems like the ideal state of things, especially having also used languages with much, much larger standard libraries. What practical problems have you, personally, run into as a result of standard library "bloat"? Just yesterday, as a practical problem I've personally had with the "leanness" of non-standard libraries, I spend a good half the day trying to wrangle a set of third party libraries into submission. 4 library configs x 3 platforms varying just enough to spend a good half the day setting up library paths, library names, library dependencies, tracking down #defines for "optional" functionality that was forgotten (or off because it doesn't work yet -- I haven't figured out which) on one platform, all in yet another build system (adapting their projects to ours would take too long), harmonizing runtime library settings to match instead of crash... A whole lot of busywork that simply doesn't happen for standard libraries, because "batteries included" means it's already been taken care of, without cutting off the rabbit hole of extra libraries when you need them.
- oscargrouch 13y ago
  It would be ok, if started from the beggining with this.. maybe people would use it.. and then when ios and android happen, its would be adapted to work on them.. but now? people that have C++ or already have they own toolkits, or use some provided by the platform.. i think its just too late for this.. its different with a network stack... its badly needed! and you use it in every way... (backend, frontend) i think people just wont use it.. because of the points i've made earlier.. A better proposition for graphics(because its futuristic) would be to focus on what LLVM are doing for instance... like the ability to compile directly to gpu instructions.. In the direction of Opencl, cuda.. heterogeneous computing.. something that can make graphics AND vectorized computation ..than it would be just a matter of creating 2d graphics kernels, and wrap a api on top of it, C++ has a unique position here! they need to think looking forward.. not backwards..
  - MaulingMonkey 13y ago
    > It would be ok, if started from the beggining with this.. maybe people would use it.. and then when ios and android happen, its would be adapted to work on them.. but now? I'll grant a graphics library seems a tad silly at this point, I'd much rather see more containers, or working modules. I'm more concerned by the aversion to standard library "bloat" than a specific aversion to a 2D graphics library.
- pcwalton 13y ago
  > What practical problems have you, personally, run into as a result of standard library "bloat"? Well, you don't want a graphics library in a kernel, for example. In Rust most of the feature requests for the standard library are to remove things these days, for this reason (see M:N scheduling, GC, etc.) :)
  - MaulingMonkey 13y ago
    Kernel hacking's a bit of a corner case, wouldn't you agree? C's standard library doesn't seem to encumber Linux much: They just eschew it or implement it. C++'s language semantics are a much bigger problem, last I heard Kernel devs generally didn't like the idea of implementing the supporting cruft behind exception handling, for example.
Sharlin 13y ago
Apparently it's an often-requested feature. But the question you stated is exactly what the Committee is trying to find an answer to by forming the study group. Nothing's been decided yet; they're just trying to chart the possibilities.
Someone 13y ago
Neither of the containers requires changes to the language, nor does the regex support, the RNG support, etc. Taking that to the extreme, you don't even need character I/O streams, as people could build them on raw byte streams, adding char-to-byte conversions and formatting. All of these were included to counter one of the weakest points of C and C++: the language may be portable, but even simple programs aren't. That's one area where Java was a huge improvement over C. So, the argument should not be "If the proposed graphics API does not require changes to the language it really doesn't need to be there.", but one should ask "how far should we go in adding standard libraries?". The answer to that question should guide the answer to the "Do we want a 2D graphics API in the standard?" question. I find 2D graphics going a bit far for that, but can see why people would see this otherwise. And to those stating that they don't see that making it into embedded use: C++ already has optional features (http://en.wikipedia.org/wiki/C11_(C_standard_revision)#Optional_features http://en.wikipedia.org/wiki/C11_(C_standard_revision)#Optio...). Yes, that is less than ideal from the portability viewpoint, but that's the real world for you.

by sparkie 13y ago

oscargrouch 13y ago

yeah.. i dont think that add much to the language.. as for 2d we are better of pluging into the native 2d api of the systems we are plumbing.. thats the true value of C and C++ What c++ is trying to be, java?

adamnemecek 13y ago
I mean, C++ is the de facto standard for graphics drawing so it kind of makes sense. It's kind of similar to how Go has a HTTP library as a part of the standard library.

MaulingMonkey 13y ago

Quality standard libraries are wonderful in that you can rely on their presence. A thousand ad hoc separately licensed libraries with wildly varying build chains, supported compilers and operating systems, with similarly varying code quality, naming conventions, build configuration options, conflicting runtime selection, error handling styles, documentation quality, etc. may be the bread and butter of your standard C++ programmer -- I know it is of mine -- but it hardly seems like the ideal state of things, especially having also used languages with much, much larger standard libraries. What practical problems have you, personally, run into as a result of standard library "bloat"? Just yesterday, as a practical problem I've personally had with the "leanness" of non-standard libraries, I spend a good half the day trying to wrangle a set of third party libraries into submission. 4 library configs x 3 platforms varying just enough to spend a good half the day setting up library paths, library names, library dependencies, tracking down #defines for "optional" functionality that was forgotten (or off because it doesn't work yet -- I haven't figured out which) on one platform, all in yet another build system (adapting their projects to ours would take too long), harmonizing runtime library settings to match instead of crash... A whole lot of busywork that simply doesn't happen for standard libraries, because "batteries included" means it's already been taken care of, without cutting off the rabbit hole of extra libraries when you need them.

oscargrouch 13y ago
It would be ok, if started from the beggining with this.. maybe people would use it.. and then when ios and android happen, its would be adapted to work on them.. but now? people that have C++ or already have they own toolkits, or use some provided by the platform.. i think its just too late for this.. its different with a network stack... its badly needed! and you use it in every way... (backend, frontend) i think people just wont use it.. because of the points i've made earlier.. A better proposition for graphics(because its futuristic) would be to focus on what LLVM are doing for instance... like the ability to compile directly to gpu instructions.. In the direction of Opencl, cuda.. heterogeneous computing.. something that can make graphics AND vectorized computation ..than it would be just a matter of creating 2d graphics kernels, and wrap a api on top of it, C++ has a unique position here! they need to think looking forward.. not backwards..
- MaulingMonkey 13y ago
  > It would be ok, if started from the beggining with this.. maybe people would use it.. and then when ios and android happen, its would be adapted to work on them.. but now? I'll grant a graphics library seems a tad silly at this point, I'd much rather see more containers, or working modules. I'm more concerned by the aversion to standard library "bloat" than a specific aversion to a 2D graphics library.
pcwalton 13y ago
> What practical problems have you, personally, run into as a result of standard library "bloat"? Well, you don't want a graphics library in a kernel, for example. In Rust most of the feature requests for the standard library are to remove things these days, for this reason (see M:N scheduling, GC, etc.) :)
- MaulingMonkey 13y ago
  Kernel hacking's a bit of a corner case, wouldn't you agree? C's standard library doesn't seem to encumber Linux much: They just eschew it or implement it. C++'s language semantics are a much bigger problem, last I heard Kernel devs generally didn't like the idea of implementing the supporting cruft behind exception handling, for example.

Sharlin 13y ago

Apparently it's an often-requested feature. But the question you stated is exactly what the Committee is trying to find an answer to by forming the study group. Nothing's been decided yet; they're just trying to chart the possibilities.

Someone 13y ago

Neither of the containers requires changes to the language, nor does the regex support, the RNG support, etc. Taking that to the extreme, you don't even need character I/O streams, as people could build them on raw byte streams, adding char-to-byte conversions and formatting. All of these were included to counter one of the weakest points of C and C++: the language may be portable, but even simple programs aren't. That's one area where Java was a huge improvement over C. So, the argument should not be "If the proposed graphics API does not require changes to the language it really doesn't need to be there.", but one should ask "how far should we go in adding standard libraries?". The answer to that question should guide the answer to the "Do we want a 2D graphics API in the standard?" question. I find 2D graphics going a bit far for that, but can see why people would see this otherwise. And to those stating that they don't see that making it into embedded use: C++ already has optional features (http://en.wikipedia.org/wiki/C11_(C_standard_revision)#Optional_features http://en.wikipedia.org/wiki/C11_(C_standard_revision)#Optio...). Yes, that is less than ideal from the portability viewpoint, but that's the real world for you.