3 ms·

C++ is my bread and butter. I neither hate or love the language, just use it and observe the way it is evolving. C++ is still popular because there are a lot o

by wmu 10y ago

C++ is my bread and butter. I neither hate or love the language, just use it and observe the way it is evolving. C++ is still popular because there are a lot of existing projects; nobody would throw away their products. Many things were standardized too late, like threads or strings. Lack of standard solutions had led to produce custom ones, often proprietary. Nobody would rewrite working-for-years subsystem just because C++ finally learnt what a thread is. Another example is variety of incompatible build systems; I wish C++ had something similar to PyPi or CPAN (I even don't dream about Go-like import system). Not to mention incompatible compilers, but I must admit there is a progress. C++ has many substantial problems and when I see that the committee wasting time on such unimportant things, like a 2D graphics library, it makes me upset.

pjmlp 10y ago
A 2D library is important, back in the day all C++ compilers on home computers had one. The goal is not to replace SDL, rather provide a portable way of doing basic 2D graphics. The C culture of leaving the libraries to the OS was one of the reasons why C++ got a chaos of interoperability issues, letting other languages that understood how that is relevant to gain mindshare in the late 90's. C++ needs its batteries.
- fnj 10y ago
  Graphics is IO, not language. There is absolutely no reason for it to be bloating the language itself.
  - nicky0 10y ago
    The standard library isn't the language.
  - pcunite 10y ago
    I understand the purity of this statement. I even wish it could be true. But without a standard library shipping with the language itself (today's approach to things) then who is going to implement this standardized IO addon that a whole lot of us need? The truth is that it just wouldn't otherwise get done. Maybe twenty years from now there will be committees working on separate modules and we'll download those if desired.
  - pjmlp 10y ago
    > Graphics is IO, not language. So lets remove stdio and iostreams from the standard, shall we?! Just for the sake of keeping the standard pure. A language goes hand in hand with its libraries, failure to understand that just leads to oblivion.
- kayamon 10y ago
  If you're referring to Borland's BGI interface, it was god-awful. Had it become a standardized library, it would have set graphics programming back decades. One of the reasons C++ has done so well is that it sticks to its area of competence and doesn't try to do everything for you.
  - pjmlp 10y ago
    It was great, and Borland wasn't the only one. C++ is almost gone from the GUI space, that is how well it has done. The GUIs from desktop and mobile OSes have moved into other languages, leaving C++'s the role of just talking to the GPU and little else.
fnj 10y ago
Modules, dammit! Year after year, decade after decade we have been waiting for modules, and instead we are fed with nothing but minutia.
- Koshkin 10y ago
  I am curious, what would having modules give us that we could not have with classes and namespaces? (I understand that in a language like Java a module, a class, an interface - are all different things. C++ is different in this respect, as it only provides a mechanism and not a policy.)
  - ovao 10y ago
    The main appeal for me is the possibility for substantially decreasing compile times. The current include system really precludes a lot of work in this area.
  - pjmlp 10y ago
    Faster compilation times and metadata for improved tooling.
  - humanrebar 10y ago
    #include is literally expanded to the contents of the file you are including. And that works recursively until the compiler has one giant source file that recursively includes the text in all the headers you included. And in that process all preprocessor macros are also expanded. This happens for every source file that is compiled. It would be nice to skip all that and just have some standard way of listing the already-analyzed contents of a the modules you need. In addition to the obvious performance improvements this would give compilers, this really cuts down on the complexity that third-party tools need to deal with to work well with C++ code. The quality of tooling for C++ has historically been stymied by the complexity of analyzing the code itself. Modules are a huge step in the right direction for helping with this.
    - pg314 10y ago
      As an illustration of how much code gets included (on macOS Sierra): $ echo "#include <iostream>" > foo.cpp $ g++ -E foo.cpp | wc 37799 104779 1280834 Including just iostream in a file means the compiler has to process 37799 (!) lines. For comparison, a C file including stdio: $ echo "#include <stdio.h>" | gcc -E - | wc 456 1638 20880 That still looks bloated to me, but is about 60x times fewer bytes.

by wmu 10y ago

pjmlp 10y ago

A 2D library is important, back in the day all C++ compilers on home computers had one. The goal is not to replace SDL, rather provide a portable way of doing basic 2D graphics. The C culture of leaving the libraries to the OS was one of the reasons why C++ got a chaos of interoperability issues, letting other languages that understood how that is relevant to gain mindshare in the late 90's. C++ needs its batteries.

fnj 10y ago
Graphics is IO, not language. There is absolutely no reason for it to be bloating the language itself.
- nicky0 10y ago
  The standard library isn't the language.
- pcunite 10y ago
  I understand the purity of this statement. I even wish it could be true. But without a standard library shipping with the language itself (today's approach to things) then who is going to implement this standardized IO addon that a whole lot of us need? The truth is that it just wouldn't otherwise get done. Maybe twenty years from now there will be committees working on separate modules and we'll download those if desired.
- pjmlp 10y ago
  > Graphics is IO, not language. So lets remove stdio and iostreams from the standard, shall we?! Just for the sake of keeping the standard pure. A language goes hand in hand with its libraries, failure to understand that just leads to oblivion.
kayamon 10y ago
If you're referring to Borland's BGI interface, it was god-awful. Had it become a standardized library, it would have set graphics programming back decades. One of the reasons C++ has done so well is that it sticks to its area of competence and doesn't try to do everything for you.
- pjmlp 10y ago
  It was great, and Borland wasn't the only one. C++ is almost gone from the GUI space, that is how well it has done. The GUIs from desktop and mobile OSes have moved into other languages, leaving C++'s the role of just talking to the GPU and little else.

fnj 10y ago

Modules, dammit! Year after year, decade after decade we have been waiting for modules, and instead we are fed with nothing but minutia.

Koshkin 10y ago
I am curious, what would having modules give us that we could not have with classes and namespaces? (I understand that in a language like Java a module, a class, an interface - are all different things. C++ is different in this respect, as it only provides a mechanism and not a policy.)
- ovao 10y ago
  The main appeal for me is the possibility for substantially decreasing compile times. The current include system really precludes a lot of work in this area.
- pjmlp 10y ago
  Faster compilation times and metadata for improved tooling.
- humanrebar 10y ago
  #include is literally expanded to the contents of the file you are including. And that works recursively until the compiler has one giant source file that recursively includes the text in all the headers you included. And in that process all preprocessor macros are also expanded. This happens for every source file that is compiled. It would be nice to skip all that and just have some standard way of listing the already-analyzed contents of a the modules you need. In addition to the obvious performance improvements this would give compilers, this really cuts down on the complexity that third-party tools need to deal with to work well with C++ code. The quality of tooling for C++ has historically been stymied by the complexity of analyzing the code itself. Modules are a huge step in the right direction for helping with this.
  - pg314 10y ago
    As an illustration of how much code gets included (on macOS Sierra): $ echo "#include <iostream>" > foo.cpp $ g++ -E foo.cpp | wc 37799 104779 1280834 Including just iostream in a file means the compiler has to process 37799 (!) lines. For comparison, a C file including stdio: $ echo "#include <stdio.h>" | gcc -E - | wc 456 1638 20880 That still looks bloated to me, but is about 60x times fewer bytes.