Earlier quoted context omitted.
All 5 major web browsers are written in C++. EDIT: Chrome, Firefox, Safari, IE, Opera
Sure that Safari is C++ and not Objective-C?
Well WebKit is C++, but the UI is probably Obj-C.
Std::string half of all allocations in the Chrome browser process
161–170 of 170 posts
Re: Std::string half of all allocations in the Chrome browser process
#162Earlier quoted context omitted.
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.
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.
You rarely see uninitialized pointers or off-by-one array bounds errors? I wish that was true for my colleagues.
Re: Std::string half of all allocations in the Chrome browser process
#163Earlier quoted context omitted.
That is the kind of magic thinking of C++ programmers sometimes exhibit that drives me insane. Yes, compilers have become excellent at optimizing code, but they aren't magical. The generated code will have some semblance to the code we write. Eliding dynamic allocations is just not possible statically. Heck, we aren't even able to emit warnings for missing deallocations reliably and have to use run-time instrumentati…
That is the kind of magic thinking of C++ programmers sometimes exhibit that drives me insane. I dunno. I've run into too many programmers on the other end of the spectrum. They're reluctant to take advantage of the genuinely zero-cost abstractions that today's excellent optimizing compilers for C++ enable. I can't find the reference now, but I thought I had seen some discussions at one of the ISO C++ meetings (from…
You probably mean N3664 [1]. The compiler is indeed allowed to get rid of allocations in new expressions it deems unnecessary.
You can verify that recent versions of clang allocate no memory in the function
int f() { return *new int(123); }
Re: Std::string half of all allocations in the Chrome browser process
#164Re: Std::string half of all allocations in the Chrome browser process
#165Earlier quoted context omitted.
Hehe, ignorance truely is bliss I guess. Just ask yourself: what size is a char in Java? To unearth 90% of the problems with strings in any language, ask two things: first, what size is char? Any secondly, what is the length of a string? If you cannot talk about these things for an hour, you don't really understand how computers deal with strings.
Actually, no. 90% of the problems with strings in any language is somebody screwing up the character encoding, usually out of ignorance. The fact that every object in Java has some overhead and probably needs some padding for alignment is utterly irrelevant. But since you asked: - 8 bytes generic object overhead per String - 4 bytes for the char[] ref - 12 bytes for the char[] itself, if non-null, plus probably 4 byt…
What many C++ programmers often forget is that most of those overheads exist in C++ as well. They are only less visible. String length? Check. Char array header? 8-16 bytes reserved by the allocator and additional hidden length field created by c++ compiler. Array pointer: another 4 or 8 bytes. I guess the only thing c++ saves is for the fact the string object itself can be stack allocated. That's just 8 bytes for the object header saved.
Re: Std::string half of all allocations in the Chrome browser process
#166Earlier quoted context omitted.
Around 20 years ago we had quite a few systems programming languages to choose from. The widespread of UNIX into the industry, killed the other languages because they weren't the UNIX system programming language and other system vendors weren't able to fight against UNIX based Workstations. So like JavaScript in the browser, C eventually killed the alternatives in the workstation market. C++ was able to gain industry…
C++ bugs are sometimes - too often - faster to find even from disassembly than from source code . Seriously. Yes, it's a very slow approach. But you can see what's really going on, and the picture is shockingly different from the source code point of view. While disassembly is verbose, there's no syntactic sugar that can obscure true function. C++ features, like operator overloading and exceptions, locally hide actua…
Well, the problem with C++ is that it's way too easy to take its features too far. I've seen commercial C++ libraries that overloaded operators to an absurd degree. I don't recall the name at the moment, but it was a database library.
Overloading operators is a great feature, but should be used as sparingly as possible, and only where it makes intuitive sense.
Templates offer even more rope to hang yourself, and even though I'm a late convert to using templates, I would never suggest the feature goes too far. It's kludge fuel, no doubt, but the language needs the feature, and it allows you to do things that are truly useful and elegant.
It never occurred to me that viewing the disassembly could be useful for debugging, and I would imagine it's not normally useful unless you are really doing some pretty sophisticated stuff with the language. It would be extremely educational to understand what the compiler actually does however, but if inspecting the disassembly is instructive on how best to use the language, then I would suspect the language design, or at least the compiler, is doing something wrong.
I do think C++ requires a little too much consideration of how certain operations are implemented, e.g., this very discussion, but it's a price I'm willing to pay for a language that lets me do things any way I want to do them.
I program in Python in my spare time and for small scripting tasks, and can't imagine choosing C++ over Python for any personal project I've done in the past couple years (which tend to be small anyway), but I use C++ at work and am very happy to continue using it after 20 years on and off (mostly on).
Re: Std::string half of all allocations in the Chrome browser process
#167Earlier quoted context omitted.
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 e…
>> 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.
This is true for C++ and doubly true for Java.
In 20 years, I don't think I've ever seen a commercial third-party C++ library that I thought was competently designed and implemented. I was about to offer the exception of mysql++, but then I remembered it's an open-source library so it wouldn't count as commercial. C++ seems to breed a lot of crappy but marginally useful code.
I haven't done much Java, and I don't think it's a bad language, I've never seen a Java development environment that I would even wish on my enemies. Java seems to breed bloated over-engineered but under-flexible designs that require the programmer to do way too much of the kind of stuff that we invented computers to do for us in the first place.
Re: Std::string half of all allocations in the Chrome browser process
#168Earlier quoted context omitted.
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.
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.
[deleted]
Re: Std::string half of all allocations in the Chrome browser process
#169Earlier quoted context omitted.
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.
You rarely see uninitialized pointers or off-by-one array bounds errors? I wish that was true for my colleagues.
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.
Re: Std::string half of all allocations in the Chrome browser process
#170Earlier quoted context omitted.
Actually, no. 90% of the problems with strings in any language is somebody screwing up the character encoding, usually out of ignorance. The fact that every object in Java has some overhead and probably needs some padding for alignment is utterly irrelevant. But since you asked: - 8 bytes generic object overhead per String - 4 bytes for the char[] ref - 12 bytes for the char[] itself, if non-null, plus probably 4 byt…
What many C++ programmers often forget is that most of those overheads exist in C++ as well. They are only less visible. String length? Check. Char array header? 8-16 bytes reserved by the allocator and additional hidden length field created by c++ compiler. Array pointer: another 4 or 8 bytes. I guess the only thing c++ saves is for the fact the string object itself can be stack allocated. That's just 8 bytes for th…
Very late reply, but to clarify, what I meant was not 'was is the size of a string' but 'what is sizeof(char)'. Meaning, if your char is a fixed size it can't represent all characters or is wasteful in 95% of all cases (8, 16 or 32 bit) or if it's variable length the formal complexity goes up for a number of often-used operations.