16 ms·

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 somebod

by 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.
- nightski 13y ago
  Maybe some effort should be put into making it much easier to use external libraries in a C++ IDE then? With Visual Studio or Eclipse I am still downloading the libs for my architecture, sometimes compiling them with an entire set of potential issues and dependencies, configuring paths, etc... They have NuGet for .NET in Visual Studio, you'd think this could be done for native software. It is actually far easier to do this on Linux with package managers, which is sad for Windows imho.
  - eropple 13y ago
    The main roadblock is the disgusting combinatoric explosion of compiler versions and debug/release single/multi versions. The "answer" seems to be to download as source and plug vcxproj dependencies right into your solution. Which, coupled with Windows's problems with static libraries (I use nothing else on OS X - static library right out of Homebrew), is hilarious.
    - MaulingMonkey 13y ago
      Sometimes that's the answer. But just yesterday this set of library vcxproj s ended up being generated by CMake... with one supported platform each and absolute paths in them. Not worth even checking into the depot, nevermind including in your .sln, not that the first person to take a crack at it didn't try checking them in and adding them to the sln... It's not even that great a library from what I can tell.
      - eropple 13y ago
        Yeah - CMake adds more problems than it solves, IMO. I keep an XCode project and a VS solution and just deal with it.
  - MaulingMonkey 13y ago
    > Maybe some effort should be put into making it much easier to use external libraries in a C++ IDE then? If you're coding to a specific IDE, it can be made pretty simple. > They have NuGet for .NET in Visual Studio, you'd think this could be done for native software. You're quite correct, it can be done for native software. Apparently, even has: http://blog.nuget.org/20130426/native-support.html http://blog.nuget.org/20130426/native-support.html I won't hold my breath for XCode or KDE to support the same, though. > It is actually far easier to do this on Linux with package managers, which is sad for Windows imho. Equally sad, I've found this doesn't apply much beyond "Hello World".
MaulingMonkey 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 No, but keeping these concerns "downstream" causes these problems to be repeatedly re-solved. This is wasteful in it's massive redundancy. How many times have I seen the neophyte make a mistake when trying to link SDL? I've beyond lost count. And that's one of the super easy cases. > For every non-language feature you push into the standard, you increase the amount of coupling the compiler has to an OS. And decrease the amount of coupling the end programs have to the OS, the number of which hopefully significantly outnumber the compiler. All this assuming we're talking about functionality that must interoperate with the OS of course -- things like new container types have no such concerns. > The problem of package and configuration management is an OS problem > The way we maintain packages should be agnostic of any particular OS or language These two statements directly conflict with each other by my parsing. I agree in theory with the latter, but in practice things like #include path configuration are fundamentally language specific. In some distant land of the future where package management is a solved problem, lean standard libraries might make more sense. However, it'd take some convincing to convince me package management is even a solvable problem in the generalized case. OS focused package managers like RPMs and APT have as a rule caused me far more work than they've solved. They don't have the versions I need, they don't configure things for the platforms I need, they don't run on the OSes I need. Even for something as fundamental as, say, integrating the boost libraries, I've found that the moment I want to go beyond "hello world" it's simpler to completely ignore APT entirely and build the bloody thing yourself. Non-OS package managers like PIPs, RubyGems, Cpan Modules, NuGet packages, etc. I've had more luck with. I've heard good arguments against standardization of libraries in the python world -- why freeze the API and discourage competition when package management is easy and works? I've yet to see anything resembling progress of a similar sort in the world of C++. You say "Nix is making great steps towards that capability, which don't require adding bloat to existing solutions" -- but I've yet to see it. I suspect I never will: I suspect it'd take over a decade to become a proper force, and more interest in solving the problem than I've seen. I suspect those who would solve such problems are instead writing entire new languages and ecosystems that will one day relegate C++ to the world of legacy programming, leaving behind so much language cruft. > 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? What's your stance on the .NET Framework? It sounds like the poster child that could have inspired this paragraph in frustration, or perhaps you don't consider that a standard library. It has libraries for scraping websites, accessing RDBMs, parsing text, and many of the dozens of common programming problems that exist, including graphics. You might call it emacs syndrome. I say it's a damn sight better than where C++'s currently at, even if it has given me grief trying to port Mono. > 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. This, at least, I'm willing to not label a corner case. But even C++'s existent pitifully tiny standard library outlines some parts that don't need to be made available on embedded targets, and I see no reason such a graphics library wouldn't also be so outlined, or particularly difficult to "take out".

by sparkie 13y ago

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.

nightski 13y ago
Maybe some effort should be put into making it much easier to use external libraries in a C++ IDE then? With Visual Studio or Eclipse I am still downloading the libs for my architecture, sometimes compiling them with an entire set of potential issues and dependencies, configuring paths, etc... They have NuGet for .NET in Visual Studio, you'd think this could be done for native software. It is actually far easier to do this on Linux with package managers, which is sad for Windows imho.
- eropple 13y ago
  The main roadblock is the disgusting combinatoric explosion of compiler versions and debug/release single/multi versions. The "answer" seems to be to download as source and plug vcxproj dependencies right into your solution. Which, coupled with Windows's problems with static libraries (I use nothing else on OS X - static library right out of Homebrew), is hilarious.
  - MaulingMonkey 13y ago
    Sometimes that's the answer. But just yesterday this set of library vcxproj s ended up being generated by CMake... with one supported platform each and absolute paths in them. Not worth even checking into the depot, nevermind including in your .sln, not that the first person to take a crack at it didn't try checking them in and adding them to the sln... It's not even that great a library from what I can tell.
    - eropple 13y ago
      Yeah - CMake adds more problems than it solves, IMO. I keep an XCode project and a VS solution and just deal with it.
- MaulingMonkey 13y ago
  > Maybe some effort should be put into making it much easier to use external libraries in a C++ IDE then? If you're coding to a specific IDE, it can be made pretty simple. > They have NuGet for .NET in Visual Studio, you'd think this could be done for native software. You're quite correct, it can be done for native software. Apparently, even has: http://blog.nuget.org/20130426/native-support.html http://blog.nuget.org/20130426/native-support.html I won't hold my breath for XCode or KDE to support the same, though. > It is actually far easier to do this on Linux with package managers, which is sad for Windows imho. Equally sad, I've found this doesn't apply much beyond "Hello World".

MaulingMonkey 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 No, but keeping these concerns "downstream" causes these problems to be repeatedly re-solved. This is wasteful in it's massive redundancy. How many times have I seen the neophyte make a mistake when trying to link SDL? I've beyond lost count. And that's one of the super easy cases. > For every non-language feature you push into the standard, you increase the amount of coupling the compiler has to an OS. And decrease the amount of coupling the end programs have to the OS, the number of which hopefully significantly outnumber the compiler. All this assuming we're talking about functionality that must interoperate with the OS of course -- things like new container types have no such concerns. > The problem of package and configuration management is an OS problem > The way we maintain packages should be agnostic of any particular OS or language These two statements directly conflict with each other by my parsing. I agree in theory with the latter, but in practice things like #include path configuration are fundamentally language specific. In some distant land of the future where package management is a solved problem, lean standard libraries might make more sense. However, it'd take some convincing to convince me package management is even a solvable problem in the generalized case. OS focused package managers like RPMs and APT have as a rule caused me far more work than they've solved. They don't have the versions I need, they don't configure things for the platforms I need, they don't run on the OSes I need. Even for something as fundamental as, say, integrating the boost libraries, I've found that the moment I want to go beyond "hello world" it's simpler to completely ignore APT entirely and build the bloody thing yourself. Non-OS package managers like PIPs, RubyGems, Cpan Modules, NuGet packages, etc. I've had more luck with. I've heard good arguments against standardization of libraries in the python world -- why freeze the API and discourage competition when package management is easy and works? I've yet to see anything resembling progress of a similar sort in the world of C++. You say "Nix is making great steps towards that capability, which don't require adding bloat to existing solutions" -- but I've yet to see it. I suspect I never will: I suspect it'd take over a decade to become a proper force, and more interest in solving the problem than I've seen. I suspect those who would solve such problems are instead writing entire new languages and ecosystems that will one day relegate C++ to the world of legacy programming, leaving behind so much language cruft. > 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? What's your stance on the .NET Framework? It sounds like the poster child that could have inspired this paragraph in frustration, or perhaps you don't consider that a standard library. It has libraries for scraping websites, accessing RDBMs, parsing text, and many of the dozens of common programming problems that exist, including graphics. You might call it emacs syndrome. I say it's a damn sight better than where C++'s currently at, even if it has given me grief trying to port Mono. > 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. This, at least, I'm willing to not label a corner case. But even C++'s existent pitifully tiny standard library outlines some parts that don't need to be made available on embedded targets, and I see no reason such a graphics library wouldn't also be so outlined, or particularly difficult to "take out".