4 ms·

Quality standard libraries are wonderful in that you can rely on their presence. A thousand ad hoc separately licensed libraries with wildly varying build chai

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.
  - pjmlp 13y ago
    Starting with Windows 8, there is support for C++ at the kernel level, including exceptions.
    - pcwalton 13y ago
      The I/O Kit in Mac OS X has been C++ from the beginning, in kernel space (sans exceptions, though).
      - pjmlp 13y ago
        True, I forgot to mention it. Also on OS/400, BeOS and Symbian.
    - asveikau 13y ago
      It's been possible to use a subset of C++ in kernel mode on Windows for longer than that. I have seen code that does it that predates Win8 by more than a decade. (Not that I consider it good or a good idea.)
sparkie 13y ago
I run into many of the same issues as you, but pushing some library to become standard does not solve the problem at all - it just forces the problem on somebody else. Somebody still needs to configure and maintain the library for a particular distribution, but rather than it being a distribution's package maintainer (or yourself), the problem is pushed onto the compiler/standard library devs, and the distribution's maintainers will still need to configure the standard library for their own distributions anyway. This is the "bloat" - it's increasing the workload for those developers. (I don't personally work on a C++ compiler, but I've worked on tooling for other languages, and I've maintained packages.) The problem of package and configuration management is an OS problem and should not be the responsibility of compiler developers who would ideally be working on an OS-agnostic language compiler. For every non-language feature you push into the standard, you increase the amount of coupling the compiler has to an OS. (It's already the case with existing APIs, even down to basic IO - it actually forces the operating system to be designed to match the requirements of the language, and thus limits to scope for experimentation and other solutions.) C++ has significant usage outside of our mainstream operating systems. It's used in embedded systems, and they have the exact opposite problems you describe - the trouble of taking things out of the language, rather than putting them in. The way we maintain packages should be agnostic of any particular OS or language - we need a way to eliminate the "hidden knowledge" that goes into building and configuring the packages in the first place, so that any particular setup can be automatically reproduced. It's not a solved problem yet, but Nix is making great steps towards that capability, which don't require adding bloat to existing solutions. (We usually call it the Open/Closed principle) The C++ Committee are attempting to solve the problem in a different way - by saying "we'll handle everything for you". What about adding libraries to ISO C++ for scraping websites, or accessing RDBMS, parsing text, or one of the dozens of common programming problems that exist? Why graphics in particular, and where do we stop attempting to push things into the standard? Screw it, why don't we just make ISO C++ a standard operating system?
- widdershins 13y ago
  I think Herb has said the answer to "why graphics in particular" is: beginners. If someone wants to start out programming in C++, it can be disheartening to learn that just drawing some simple shapes requires using external libraries, with all the complexity that brings.

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.
- pjmlp 13y ago
  Starting with Windows 8, there is support for C++ at the kernel level, including exceptions.
  - pcwalton 13y ago
    The I/O Kit in Mac OS X has been C++ from the beginning, in kernel space (sans exceptions, though).
    - pjmlp 13y ago
      True, I forgot to mention it. Also on OS/400, BeOS and Symbian.
  - asveikau 13y ago
    It's been possible to use a subset of C++ in kernel mode on Windows for longer than that. I have seen code that does it that predates Win8 by more than a decade. (Not that I consider it good or a good idea.)

sparkie 13y ago

I run into many of the same issues as you, but pushing some library to become standard does not solve the problem at all - it just forces the problem on somebody else. Somebody still needs to configure and maintain the library for a particular distribution, but rather than it being a distribution's package maintainer (or yourself), the problem is pushed onto the compiler/standard library devs, and the distribution's maintainers will still need to configure the standard library for their own distributions anyway. This is the "bloat" - it's increasing the workload for those developers. (I don't personally work on a C++ compiler, but I've worked on tooling for other languages, and I've maintained packages.) The problem of package and configuration management is an OS problem and should not be the responsibility of compiler developers who would ideally be working on an OS-agnostic language compiler. For every non-language feature you push into the standard, you increase the amount of coupling the compiler has to an OS. (It's already the case with existing APIs, even down to basic IO - it actually forces the operating system to be designed to match the requirements of the language, and thus limits to scope for experimentation and other solutions.) C++ has significant usage outside of our mainstream operating systems. It's used in embedded systems, and they have the exact opposite problems you describe - the trouble of taking things out of the language, rather than putting them in. The way we maintain packages should be agnostic of any particular OS or language - we need a way to eliminate the "hidden knowledge" that goes into building and configuring the packages in the first place, so that any particular setup can be automatically reproduced. It's not a solved problem yet, but Nix is making great steps towards that capability, which don't require adding bloat to existing solutions. (We usually call it the Open/Closed principle) The C++ Committee are attempting to solve the problem in a different way - by saying "we'll handle everything for you". What about adding libraries to ISO C++ for scraping websites, or accessing RDBMS, parsing text, or one of the dozens of common programming problems that exist? Why graphics in particular, and where do we stop attempting to push things into the standard? Screw it, why don't we just make ISO C++ a standard operating system?

widdershins 13y ago
I think Herb has said the answer to "why graphics in particular" is: beginners. If someone wants to start out programming in C++, it can be disheartening to learn that just drawing some simple shapes requires using external libraries, with all the complexity that brings.