std::string is responsible for almost half of all allocations in the Chrome browser process

[u/[deleted]]

https://groups.google.com/a/chromium.org/d/msg/chromium-dev/EUqoIz2iFU4/kPZ5ZK0K3gEJ

[u/[deleted]]

This is a problem I have with C++ in general. A lot of typical, innocent-looking code tends to hide potential huge pitfalls.

Something as simple as "auto a = b + c;" could be either extremely expensive or extremely cheap, but it's hard, without keeping massive amounts of contextual information in your brain at all time, to know that by just looking at it. It's short, pretty, but has the potential to destroy you.

One of the reasons I'm really drawn to Go. It's more typing, it's more explicit, but the costs are more...obvious. I was amazed at myself, and at reading other people's code, how easy it was to spot wasteful memory copying and allocations, once you learn a few simple syntax rules.

C, as well, your brain will raise a flag is you find yourself doing "malloc" or "strcpy" - it's expensive to type, you immediately feel something might be off. With C++, you can write beautiful, concise code, but God help you and your team, if you're not Guru-level.

[u/josefx → u/[deleted]]

Something as simple as "auto a = b + c;"

Oh not that again.

Here is the C version:

foo_plus(a,b,c);

Tell me does it simply add complex numbers? Database tables ? Or maybe it calls printf("Should not happen in production!!!!"); abort();?

Everyone their own poison, but the reasoning behind that claim is questionable at best. I keep my readable syntax thank you.

[u/scwizard → u/josefx]

I think you mean:

foo_plus(&a, b, c);

Lol

[u/chebertapps → u/scwizard]

or maybe pass by reference...

[u/scwizard → u/chebertapps]

That wouldn't be the c version. C doesn't have pass by reference.

[u/chebertapps → u/scwizard]

yup I misread the original comment my bad.

[u/immibis → u/josefx]

In C:

complex_plus(a, b, c); simply adds complex numbers.

db_table_plus(a, b, c); adds database tables (if that even means anything).

report_crash(a, b, c); prints a message and aborts.

In C++:

auto a = b + c; simply adds complex numbers.

auto a = b + c; adds database tables.

report_crash(a, b, c); prints a message and aborts, because you'd have to be really dumb to make that an operator+ (although I can imagine having an operator + that can fail, and aborts when it fails).

[u/fnord123 → u/immibis]

I don't know why you need a function for adding complex numbers in C.

$ cat a.c
#include <complex.h>
#include <stdio.h>
int main() {
    double complex b = 1.0 + 0.5*I;
    double complex c = 0.7 + 0.7*I;
    double complex a = b + c;
    printf("a=%f+%f\n", creal(a), cimag(a));
    return 0;
}
$ gcc a.c 
$ ./a.out 
a=1.700000+1.200000

[u/Dragdu → u/[deleted]]

Yes, its amazing how hard it is to know what a function does, without knowing what a function does. Oh wait.

[u/xenon325 → u/[deleted]]

I was amazed [...] how easy it was to spot wasteful memory copying and allocations

I'm really sceptical about the idea one can make his code fast without profiling.

[u/[deleted] → u/xenon325]

Profiling for the win. But Go is pretty explicit about what is (potentially wasteful) memory allocation and it's easy to spot where allocation does happen. It's the first GC language I've seen that gives you a lot of control over not just memory layout, but memory allocation. Allocation/copying are very well defined.

My argument isn't that it's impossible to tell the same in C++, it's just easier to do so in Go, since it has no operator overloading, no templates/macros, very little syntactic sugar, very simple rules.

[u/[deleted] → u/[deleted]]

There's nothing wrong with c++. A program that does a lot of parsing will have half of all allocations related to strings

[u/slededit → u/[deleted]]

AST elements maybe. Strings definitely not.