Hacker News Reader

Comment by saagarjha | Hacker News Reader

> If you actually want to measure the memory allocation in C++, then you need to ask the system to give you s bytes of allocated and initialized memory. You can achieve the desired result in C++ by adding parentheses after the call to the new operator

Is this an actual thing? You can force reification of overcommitted memory just by calling operator() on it?

View on HN

It's not `operator()`, it's value initialization. If you're particularly masochistic you can read more about it at https://en.cppreference.com/w/cpp/language/value_initializat....

Ah, that makes more sense. Thanks.

I don’t think that guarantees the memory gets committed. The compiler/standard library combination is allowed to know how the OS behaves, so if it, say, initializes new pages with 0x00, it can use that information to skip the initialization of that memory.

The example given:

    char *buf = new char[s]();

Put into Compiler Explorer:

    https://gcc.godbolt.org/z/QAs9gz

However, doing this is a very strong code smell. At the very least, using `new` and assigning to a raw pointer is a sign that the C++ developer is managing memory manually and is likely to hit a lot of problems including memory leaks or segmentation faults. Also many would forget that this is calling `operator new[]()`, not `operator new()` and might confuse with placement-new `operator new(...)` or `operator new[](...)`. And the developer might also forget that `new` could throw an exception... [0]

The developer should instead be using, at a minimum, a `std::unique_ptr<char[]>` [1]. Or, IMO, a `std::vector<char>` which reminds the developer not only of the pointer but also of the count of bytes which have been allocated (.capacity()) and also of the valid range which has been initialized (.size()).

IMO, if the developer wanted a pointer to a byte array then it's a lot easier to use `malloc()` than trying to remember all the different ways you can get screwed by `operator new`:

    std::unique_ptr<char, std::function<void(char*)>> m{
        (char*)std::malloc(count), std::free
    };

[0]: https://en.cppreference.com/w/cpp/language/new

[1]: https://en.cppreference.com/w/cpp/memory/unique_ptr

I gave up on C++ in part because the language changes too much.

I paid for lessons on it. The std:: stuff didn't exist, templates were a recent invention, and people were starting to agree that putting the overload keyword everywhere was bad style. Mostly, people were just excited about // comments and cout.

I keep hearing about how C++ is supposed to be done, and it seems to change every year. I don't know what people do with the older code as it becomes unfashionable with "very strong code smell". Updating it is risky busywork, kind of like porting to Python 3, with potential for serious bugs. Leaving it in place will make developers differently unhappy.

It isn't easy getting everybody on a team to agree on what subset of C++ is OK to use. People will sneak in their must-have feature. You'd have better luck getting agreement between emacs and vi.

C++ makes no pretense of ever planning to be "done". "Done" is another word for dead. Even COBOL is still evolving.

Failing to keep up with evolving languages is called stagnation. Everyone is free to stagnate, but I do not advise it.

You use the subset of the language supported by the compiler you have. Code using newer features is better because the new features were added for sound engineering reasons, not just to be different.

It's the opposite of sound engineering. Every version of C++ contains a new feature that does 11% of the proper solution because the feature in the last version only did 9% of the proper solution. Despite all that churn the language is still as far behind ML as ever.

I see that you have not been keeping up.

What has the parent comment not keeping up with? Was it a reference to the ‘11%’ or to C++ being ‘behind ML’? Just curious to see what your objection was.

11%

If you think C++ changes too much, you're going to love today's Java/Typescript flavor-of-the-month web UI toolkit.

Yes it is hard to keep up, but so it is like any other language with mainstream usage.

Languages either evolve to fulfill market needs or they die.

Even C17 has plenty of differences down to K&R, not counting all the compiler specific extensions.

C has changed much less over the years. Arguably C89 was the most important change, C99 brought a bunch of small quality of life improvements (which you might or might not need, arguably the most important are stdint and snprintf), C11 got us a threading model, C17 is a bugfix.. After C89, no new version of the standard really changed the way you write idiomatic C without code smells.

Fact is it did change, it even introduced breaking changes, like gets() and Annex K removal on C11.

And you are missing the compiler extensions that I also mentioned.

It did not change even more, because nowadays C is left for UNIX clones and embedded development, having been superseded by other languages on most corporations, even its major compilers have been rewritten in C++.

I don’t know if parent is ‘missing the compiler extensions [you] mentioned’ or is just not addressing them. But I will take a stab: compiler extensions may be neat/effective/revolutionary, but they are unequivocally not a part of a programming language. That is why they are compiler specific extensions. I could code a compiler extension for LLVM that is a conservative, generational garbage collector and have the extension flag be —-no-more-manual-memory, but no one is then going to say that because that extension exist C++ is a garbage collected language.

tl;dr -> compiler extensions are by definition not part of a language, no matter how useful, and therefore do not count towards the argument.

C++ supports garbage collection since ISO C++11.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n267...

C++ changes too much???

It's the weirdest thing I've read today.

Perhaps I can give you something weirder to read.

The other big complaint I have about C++ is that it is too high-level. It isn't very good for low-level control. :-)

Writing start-up code and linker scripts to support C++ code running without the libraries is not easy. All sorts of things, such as tables of constructors, need a solution. Typically that would involve a lot of assembly code. I'd need to disable lots of C++ functionality unless I wanted to write complicated things like a stack unwinder for exceptions.

It's just easier to use plain old C. The result is smaller too, which is important.

And someone said I was trolling hahaha

It's weird feeling surrounded by web programmers who think Python and Javascript are the lowest you'd ever want to go.

C++ is annoyingly high-level if you are trying to write code to go in a flash chip. The code starts running at a specific address at soon as the CPU starts. There is no OS unless your code implements one. There is no C++ library unless you port one.

That's a fair point and it's a project I'd like to tackle someday in spare or paid time.

I don't think C++ is annoyingly high-level in that case: just annoyingly lacking in the ecosystem to support it.

Eh I'd say using malloc in place of new is more code smell than anything here. If you want a byte array make a byte array

    std::make_unique<std:::array<char, SIZE>>()

If you don't know how big you want the byte array make a vector.

    std::vector<char>(size)

It's baffling to me how many C++ developers don't use the standard collections. The only one that really sucks is unordered_map.

vector<bool> also sucks

That's fair. But in my experience that's rather rare and easy to work around.

Small vectors are also bad. There should be some kind of small vector optimization, just like what is common for std::string.

Sometimes your just need a buffer for a syscall. Newing a buffer is canonical and unique_ptr isn’t free enough to use in the most performance sensitive contexts.

Can you give an example of unique_ptr being too heavy?

I worked with a team which used raw pointers instead of unique_ptr as they use more memory (twice as much, I think). The core data structure was a tree, and the tree was several hundred GB in size. So they were doing whatever they could to shave off memory.

Without a custom deleter unique_ptr should have zero overhead.

unique_ptr does not have any memory overhead. (unless you use a custom deleter, but even then you could use one which does not use memory)

Unique pointers imply ownership of the underlying memory. If you have multiple references to the same data, or in your case a tree, it might make sense to use raw pointers (or references) to access the tree data. It would not make sense to grant ownership of the same memory to two unique_ptr, or make copies of data unnecessarily.

In that case, you'd have something like `std::vector` or `std::unique_ptr` which owns the actual allocation (and governs the scoping and therefore deallocation), while using `vector.data()` or `unique_ptr.get()` to pass around an unowned pointer. All raw pointers can then be considered to be unowned by convention.

> using `new` and assigning to a raw pointer is a sign that the C++ developer is managing memory manually and is likely to hit a lot of problems including memory leaks

There is no need to badmouth all c++ developers. Plenty of us can keep our memory straight just fine. just because you don't like pointers, does not mean the rest of us can't use them perfectly safely.

The rest of us isn't that big number according to Microsoft and Google security reports.

I surely have my share of C++ pointer mistakes done since I got hold of C++ARM and Turbo C++, after years of Assembly and Turbo Pascal programming.

Not only C++, but any other language with manual memory management, because keeping track of where everything is going manually, just doesn't scale.

I think the evidence is pretty clear that programmers can't, in general, use bare pointers properly. The very best write use after free, double free, stack smashers, and all manner of other memory related bugs. We can see the evidence of this fact in the CVEs, the syzkaller bugs, etc. If you haven't been bitten by a serious instance of one of these, then you just haven't written very much C++.

IMO the debate about whether programmers can safely handle bare pointers is over. They can't. The only question is whether smart pointers help enough to make the extra line noise worth it.

And the guys that implement smart pointers are what, exactly? Uberprogrammers? Is there a certificate to get into that club? What about compiler authors, that deal with, gasp, optimizations of these bare pointers? Kernel developers? Embedded system engineers?

It is ok to stay above a certain level of abstractions consciously, but stating that one cannot go below safely is just steadying mediocrity.

> And the guys that implement smart pointers are what, exactly? Uberprogrammers? Is there a certificate to get into that club? What about compiler authors, that deal with, gasp, optimizations of these bare pointers? Kernel developers? Embedded system engineers?

One cannot do any of those things safely by hand. Compilers, kernels, and embedded systems do indeed do these things; they also have bugs.

You are contradicting yourself. If one cannot do these things safely by hand, then noone can implement the automatic abstractions either.

You cannot safely control an internal combustion engine's valve timings by hand, but it is clearly possible to implement this automatically (and fairly simply). Some things are much easier for machines to do than humans, even though the machines are designed and build by humans.

> Is there a certificate to get into that club?

There is and the large majority fails at it, as proven by the CVE database, in spite the rigorous process to contribute code to the Linux kernel for example.

I call bullshit. And arrogant bullshit at that. The wast majority of bare metal components is highly functional and relatively bug free.

You can call whatever you like, CVE database, yearly security reports, and OS release notes from all major OSes provide the necessary facts.

Sadly liability still isn't a thing on software development.

That's not the point. Smart pointer implementations aren't some dark magic, they're just the opposite: mostly fairly simple to implement (shared_ptr is a little trickier), and obviously right by construction: the compiler does the hard work of making sure the constructors and destructors get called appropriately (and this is a little harder but still far far easier than making sure that malloc() and free() match in all actual uses).

The statement you quoted is simply a fact, not badmouthing. If there is any badmouthing by implication, it wouldn't be "all" C++ developers, just those who don't realize they're doing something spooky when their code looks like Foo *foo = new Foo.

> just because you don't like pointers, does not mean the rest of us can't use them perfectly safely.

I actually use pointers quite safely. I just no longer see a need to ever return an allocation from `new` to a raw pointer unless I'm implementing my own pointer class.

Herb Sutter's correct [0]. `std::unique_ptr` or `std::shared_ptr` or some other pointer container should __always__ hold new-allocated objects. Just like you should __always__ wear your seatbelt. It's no danger to you or anyone else, it's slightly inconvenient, and it saves a metric ton of headaches about "what if?". Because in reality a pointer container explicitly marks the scope of the allocation and if you're not wanting to use C++'s scoping rules then why are you using C++?

[0] https://www.youtube.com/watch?v=JfmTagWcqoE

This is one of the best troll posts that is getting taken seriously ever... wow.

The std::function<void(char*)> is the tell :-)

Why do you think that marks a troll? Have you never had to use a C library which wants you to use the library's structure allocator / deallocator? In that case, this translates very well to malloc/dealloc.

@unlinked_dll has it correct: the C++ way to allocate an array of chars is `std::vector<char>` (or `std::array<char, size>`).

It's a bit bloaty and verbose as well, you could just use void(&)(void *).

Doesn't that break when std::free does not have the default C++ calling convention? I think `decltype(std::free)` would be easier to read anyway, but writing a deleter class that calls std::free in its operator() has the advantage that it will not use any memory in the unique_ptr thanks to the empty base class optimization.

I don't think that's possible, and in that case the std::function wouldn't work either.

I was thinking about calling conventions because std::free can use extern "C", but the function pointer declaration in C++ code points to an extern "C++" function, and the standard says these are two distinctive types. Are they guaranteed to be compatible - since they're only linkage specifiers, not calling conventions? I'm not sure.

std::function would still work in this case because pointers to C functions have a normal operator().

Oh, right, it would work. Anyway, it looks like compilers have a known bug and they’re supposed to treat the types as incompatible.

Reply on news.ycombinator.com