24 ms·

So which web browsers are not written in C++?

by IvyMike 12y ago

rwmj 12y ago
Almost all of Windows (including apps that predominantly do string and tree manipulation) is written in C++. Almost all of Linux userspace is written in C. These are still terrible, insecure, fragile languages which cause frustration and loss to programmers and users every day.
- panzi 12y ago
  > Almost all of Linux userspace is written in C. Depends on what you count. Qt can be seen as (part of the) Linux userspace. KDE applications are usually written in C++ (partially in QML+JavaScript), Gtk applications are written in C or Vala (a few in C#). If you don't count DE frameworks basically the only thing left would be libc, which of course is C (but available in some form under every noteworthy OS).
- ibebrett 12y ago
  what experience do you have with writing c++? what is the last large project you completed with it? i'm not a huge fan of c++, but it has been the foundation of an extremely large number of wildly successful and pervasive projects.
  - rwmj 12y ago
    I have in the past written many large C++ projects. I now try to avoid it as much as possible, but the last time I programmed in C++ was just two weeks ago[1], and it reminded me how bad it was -- terrible error messages, and abysmal performance of the final program. At some point I will have to replace it because the program doesn't meet our performance requirements, and no one can tell me why[2]. (Edit: Apparently [2] has been answered now) [1] http://git.annexia.org/?p=virt-bmap.git;a=tree http://git.annexia.org/?p=virt-bmap.git;a=tree [2] https://stackoverflow.com/questions/27152834/how-to-improve-performance-of-boost-interval-map-lookups https://stackoverflow.com/questions/27152834/how-to-improve-...
    - IvyMike 12y ago
      In #2, I'm curious why you didn't like sehe's answer?
    - nostrademons 12y ago
      Clang's error messages are much better than GCC - it will even spell-correct your typos and suggest which symbol you actually wanted to type. Around 2010 Google switched to a hybrid Clang + GCC environment (the same source code would be piped to both compilers, the error messages from Clang would be piped back to the user while the object files from GCC were linked to form the final binary), and C++ developer happiness skyrocketed.
      - pja 12y ago
        To be honest, I think gcc has pretty much caught up with clang with gcc-4.9 when it comes to error message quality. I have a slight preference for the way clang chooses to highlight the entire AST parent node that it thinks is responsible for the error, but the approach g++ takes is perfectly clear.
    - DannyBee 12y ago
      Of all the things you shudl expect from a non-C++ language, performance is highly unlikely to be on that list. If you can't get something to be performant with C++, it's pretty unlikely you'll get it to be performant with most other languages. (Unless you want to try it in fortran)
      - tptacek 12y ago
        I expect C programs to outperform C++ programs, simply by virtue of being more explicit (about everything, from allocation to levels of indirection).
        vardump 12y ago
        Not always faster. Try comparing qsort to stl::sort... Hint: stl::sort is a lot faster. It can inline the comparison function. Ok, it just shows how slow function pointers are. I'm assuming compilers still can't optimize the function pointer away in qsort. Of course a specialized sorter in C would be faster, one that can inline comparison function. C++ copy pasting automation... err, I mean templates are useful, because it can often inline your function and data type in the algorithm without using function pointers. At cost of generating same or similar algorithm code multiple times bloating the binary.
- vardump 12y ago
  Shame you're downvoted, because you're pretty much right. Don't get me wrong, correct code can very well be written in C/C++. It's just 95% of the programmers using those languages are not very skilled. The programs tend to be wrong and fragile. In C++, most of this fragility derives from its C-roots. C/C++ is also a poor match to today's CPUs. It's very slow compared to what the hardware is capable of. Compare for example with Intel ispc (https://ispc.github.io/ https://ispc.github.io/). It gives some idea how much performance we're currently missing. When C was young, memory latency was typically 1 or 2 clock cycles. There was no pipelining, at most a simple state machine that would finish in a few clock cycles. A branch didn't cost much. A few cycles at most. Neither did a pointer reference. Random access was almost as fast as sequential access. Today's CPUs have memory latency of 150-300 clock cycles. A modern CPU core can typically retire 1-4 instructions per clock cycle. A single instruction takes typically about 16 clock cycles from decoding until retire. So CPUs have to often execute blind and just guess where the execution flow will go. Branches modify this flow. CPUs simply guess the flow, branch predict. When they're wrong, they just have to invalidate currently executing instructions and start again. Branches are something to avoid. Especially unpredictable ones. Function pointers are branches. Even though they can be predicted, they often just fall out of the branch predictor cache. We need something that can minimize the costs modern CPUs are bad at. C/C++ is very branchy and uses slow function pointers often (vtable, switch jump tables, etc). The problem is, there's more variation among CPUs than ever before, even within same instruction set architecture. For x86, not only the costs for instructions are wildly different, but the instruction set support is fragmented. C/C++ is not the last word. Unsafe and way too slow compared to what current hardware is capable of. The problem is, the language that is safer and a good match just does not exist yet. Some safety can be sacrificed for greater speed, but it should be situational choice by the programmer, not the only way or even default. C/C++ is what I do at my day job.
  - fleitz 12y ago
    >> It's just 95% of the programmers using those languages are not very skilled. High level languages just make it easier for crappy programmers to approximate a working solution.
    - 12y ago
- srj 12y ago
  What's fragile, insecure, and terrible about them? I've written C/C++ (among other languages) for years at work and it's quite rare that I see a bug that could be attributed to the language.
  - robotresearcher 12y ago
    You rarely see uninitialized pointers or off-by-one array bounds errors? I wish that was true for my colleagues.
    - srj 12y ago
      Late reply - sorry that I missed your response. I've found that RAII classes like std::unique_ptr have really helped. Errors like an uninitialized pointer are often caused by poor ownership semantics in the program design, and I don't think you escape that in reference counted languages. You'll still have a messy class design without clear ownership, and there are types of resources other than memory to manage (file handles, locks, sockets). I'm not saying that your colleagues are bad engineers, I've had many troubles with ownership design over the years and still do at times. I just don't think C++ is unique in this regard even if it does force you to think about it more regularly since memory interaction is so common.
  - deleted 12y ago
    [deleted]
sedachv 12y ago
C: Lynx, w3m, Mothra Java: Lobo, gngr (https://gngr.info/ https://gngr.info/) Limbo/Inferno: Charon Lisp: Closure, eww

So which web browsers are not written in C++?

by IvyMike 12y ago

So which web browsers are not written in C++?

rwmj 12y ago

Almost all of Windows (including apps that predominantly do string and tree manipulation) is written in C++. Almost all of Linux userspace is written in C. These are still terrible, insecure, fragile languages which cause frustration and loss to programmers and users every day.

panzi 12y ago
> Almost all of Linux userspace is written in C. Depends on what you count. Qt can be seen as (part of the) Linux userspace. KDE applications are usually written in C++ (partially in QML+JavaScript), Gtk applications are written in C or Vala (a few in C#). If you don't count DE frameworks basically the only thing left would be libc, which of course is C (but available in some form under every noteworthy OS).
ibebrett 12y ago
what experience do you have with writing c++? what is the last large project you completed with it? i'm not a huge fan of c++, but it has been the foundation of an extremely large number of wildly successful and pervasive projects.
- rwmj 12y ago
  I have in the past written many large C++ projects. I now try to avoid it as much as possible, but the last time I programmed in C++ was just two weeks ago[1], and it reminded me how bad it was -- terrible error messages, and abysmal performance of the final program. At some point I will have to replace it because the program doesn't meet our performance requirements, and no one can tell me why[2]. (Edit: Apparently [2] has been answered now) [1] http://git.annexia.org/?p=virt-bmap.git;a=tree http://git.annexia.org/?p=virt-bmap.git;a=tree [2] https://stackoverflow.com/questions/27152834/how-to-improve-performance-of-boost-interval-map-lookups https://stackoverflow.com/questions/27152834/how-to-improve-...
  - IvyMike 12y ago
    In #2, I'm curious why you didn't like sehe's answer?
  - nostrademons 12y ago
    Clang's error messages are much better than GCC - it will even spell-correct your typos and suggest which symbol you actually wanted to type. Around 2010 Google switched to a hybrid Clang + GCC environment (the same source code would be piped to both compilers, the error messages from Clang would be piped back to the user while the object files from GCC were linked to form the final binary), and C++ developer happiness skyrocketed.
    - pja 12y ago
      To be honest, I think gcc has pretty much caught up with clang with gcc-4.9 when it comes to error message quality. I have a slight preference for the way clang chooses to highlight the entire AST parent node that it thinks is responsible for the error, but the approach g++ takes is perfectly clear.
  - DannyBee 12y ago
    Of all the things you shudl expect from a non-C++ language, performance is highly unlikely to be on that list. If you can't get something to be performant with C++, it's pretty unlikely you'll get it to be performant with most other languages. (Unless you want to try it in fortran)
    - tptacek 12y ago
      I expect C programs to outperform C++ programs, simply by virtue of being more explicit (about everything, from allocation to levels of indirection).
      - vardump 12y ago
        Not always faster. Try comparing qsort to stl::sort... Hint: stl::sort is a lot faster. It can inline the comparison function. Ok, it just shows how slow function pointers are. I'm assuming compilers still can't optimize the function pointer away in qsort. Of course a specialized sorter in C would be faster, one that can inline comparison function. C++ copy pasting automation... err, I mean templates are useful, because it can often inline your function and data type in the algorithm without using function pointers. At cost of generating same or similar algorithm code multiple times bloating the binary.
vardump 12y ago
Shame you're downvoted, because you're pretty much right. Don't get me wrong, correct code can very well be written in C/C++. It's just 95% of the programmers using those languages are not very skilled. The programs tend to be wrong and fragile. In C++, most of this fragility derives from its C-roots. C/C++ is also a poor match to today's CPUs. It's very slow compared to what the hardware is capable of. Compare for example with Intel ispc (https://ispc.github.io/ https://ispc.github.io/). It gives some idea how much performance we're currently missing. When C was young, memory latency was typically 1 or 2 clock cycles. There was no pipelining, at most a simple state machine that would finish in a few clock cycles. A branch didn't cost much. A few cycles at most. Neither did a pointer reference. Random access was almost as fast as sequential access. Today's CPUs have memory latency of 150-300 clock cycles. A modern CPU core can typically retire 1-4 instructions per clock cycle. A single instruction takes typically about 16 clock cycles from decoding until retire. So CPUs have to often execute blind and just guess where the execution flow will go. Branches modify this flow. CPUs simply guess the flow, branch predict. When they're wrong, they just have to invalidate currently executing instructions and start again. Branches are something to avoid. Especially unpredictable ones. Function pointers are branches. Even though they can be predicted, they often just fall out of the branch predictor cache. We need something that can minimize the costs modern CPUs are bad at. C/C++ is very branchy and uses slow function pointers often (vtable, switch jump tables, etc). The problem is, there's more variation among CPUs than ever before, even within same instruction set architecture. For x86, not only the costs for instructions are wildly different, but the instruction set support is fragmented. C/C++ is not the last word. Unsafe and way too slow compared to what current hardware is capable of. The problem is, the language that is safer and a good match just does not exist yet. Some safety can be sacrificed for greater speed, but it should be situational choice by the programmer, not the only way or even default. C/C++ is what I do at my day job.
- fleitz 12y ago
  >> It's just 95% of the programmers using those languages are not very skilled. High level languages just make it easier for crappy programmers to approximate a working solution.
  - 12y ago
srj 12y ago
What's fragile, insecure, and terrible about them? I've written C/C++ (among other languages) for years at work and it's quite rare that I see a bug that could be attributed to the language.
- robotresearcher 12y ago
  You rarely see uninitialized pointers or off-by-one array bounds errors? I wish that was true for my colleagues.
  - srj 12y ago
    Late reply - sorry that I missed your response. I've found that RAII classes like std::unique_ptr have really helped. Errors like an uninitialized pointer are often caused by poor ownership semantics in the program design, and I don't think you escape that in reference counted languages. You'll still have a messy class design without clear ownership, and there are types of resources other than memory to manage (file handles, locks, sockets). I'm not saying that your colleagues are bad engineers, I've had many troubles with ownership design over the years and still do at times. I just don't think C++ is unique in this regard even if it does force you to think about it more regularly since memory interaction is so common.
- deleted 12y ago
  [deleted]

sedachv 12y ago

C: Lynx, w3m, Mothra Java: Lobo, gngr (https://gngr.info/ https://gngr.info/) Limbo/Inferno: Charon Lisp: Closure, eww