Hacker News Reader

Reminds me of this anecdote I came across on the internets one time: https://groups.google.com/forum/message/raw?msg=comp.lang.ad...

The ultimate in garbage collection indeed!

Highly recommend reading that short tale! This lore is slowly being forgotten, thanks for that link.

(Is there a canonical lore repository for this kind of thing, other than the Jargon file?)

haha that's a good one!

I have heard of calculating a "memory budget" and pre-allocating that, but calculating a "leak budget" and doubling that doesn't seem like hygienic programming.

Doesn't have to be hygienic, it's enough that fixing it doesn't justify the time/money costs for the programmer.

We wouldn't want the programmer to spend too much money/time on fixing errors. After all, it's not like people would die if there's an error in the missile software: http://www.gao.gov/mobile/products/IMTEC-92-26

Not to mention they added even more HW to work around the leaks. No wonder those projects always run over budget.

>We wouldn't want the programmer to spend too much money/time on fixing errors. After all, it's not like people would die if there's an error in the missile software

When exactly did pkg_config became missile software?

As they say in meme-land, "that escalated quickly".

Here's a novel idea: how about the appropriate level of effort/time/YAGNI-stuff based on the domain?

Or do you write one-time scripts with MISRA rules?

The sub-thread I replied to was linking to an anecdote about missile software.

But I still think not freeing is pretty lame even in short-lived tools. If one is using a no-op deallocator at least the code is designed properly and could be repurposed.

The problem with counting leaks is it counts memory you need until the very end of your program. There is no point calling free as you are exiting anyway, and I have seen programs where freeing everything took .5 seconds as the program was closing.

As someone whose startup was probably hindered by an almost religious adherence to testing with Valgrind (hardware was way too slow), I'd still say finding the real leaks and bugs is a lot easier when you don't have the noise of "expected" leaks.

I submitted this post to HN a few months ago.

The discussion is at https://news.ycombinator.com/item?id=14233542

It seems you can no longer view Google groups without logging in?

> As for the "memory leaks" --- I haven't looked at the source, but something whose runtime is very short-lived, like pkg-config, may be very well justified in allocating and never freeing, letting the process exit itself be the "ultimate free". I've seen and done this many times myself.

This makes sense, and then somebody has a vision for a use case beyond the original imagination, goes to turn the code into a library and spends countless hours smartening up lazy resource management. Whether the original author should be "more responsible" is open for debate, but I've personally run into the above situation, and only mention for another perspective on The Life of Code.

Edit: s/coffee/code/

That's the classic KISS/YAGNI vs. (not sure if there is an initialism for it) robust extensible modular best practices etc. debate, for which there has been much bikeshed from both sides.

You might be looking for the term 'SOLID' ;)

e: it may be worth noting that I can't for the life of me remember what the I and D stand for... clearly I am much more of a KISS kind of programmer.

>This makes sense, and then somebody has a vision for a use case beyond the original imagination, goes to turn the code into a library and spends countless hours smartening up lazy resource management.

That's THEIR problem then.

Why should the original author care for that?

> That's THEIR problem then.

It is their problem, clearly.

> Why should the original author care for that?

That's the question. Don't you think it's easy to think of reasons, though? What if the person porting the code to a library was a later version of the original author?

Will you also call them lazy because they didn't care about being thread safe or UTF8-ready?

> Will you also call them lazy because...

I said it's lazy resource management. I'm really not trying to condemn, here, just provoke questions.

>What if the person porting the code to a library was a later version of the original author?

Then they know what they need to add, and can add it now that they need it -- instead of having it slowing them down when they didn't need it

> As for the "memory leaks" --- I haven't looked at the source, but something whose runtime is very short-lived, like pkg-config...

To be fair in the other direction, it's a minority of interesting software projects that don't care about memory leaks. Also, there are ways to "skip" freeing memory in C++ safely using appropriate allocators. In actuality, you'd have your allocator, in its destructor, clean up itself and all its objects at the same time. It's nearly the same performance without sacrificing correctness or lowering standards with respect to leaking memory.

"Using C++" does not mean "Using lots and lots of features of C++ just because". That some people do that is hardly a criticism of C++, more of the lousy programmers that write software like that.

Unfortunately it seems that the majority of C++ code out there is like that. It could be said that C++ makes it far easier than C to introduce unnecessary abstraction and indirection, without realising the true costs.

I've noticed that using a lower-level language, where abstractions have to be built explicitly, tends to cause one to rethink the problem and often come up with an even simpler and more efficient solution, by approaching it from another direction which using a higher-level language may not even allow.

An example of this I encountered several years ago was with several coworkers who were trying with utmost effort to optimise a piece of code which the profiler had indicated was taking a substantial amount of time --- and a lot of it consisted of memory allocation and copying. They tried lots of "classic" tricks like unrolling, inlining, even reorganising the layout of several classes in an attempt to be more cache-friendly. I looked at the algorithm and realised rather quickly that the code in question was not necessary at all; some trivial modifications to code elsewhere which was using it and deleting that code completely resulted in 30x faster performance and 1/10 memory usage. Due to their background, my coworkers were stuck in the mindset that it was necessary to perform all that convoluted processing, and neglected to see the bigger picture.

I've only written patches of C++ in a couple of tiny projects, and something I've had trouble with in both cases is trying to figure out the somewhat objectively "right" or "best" way to write it. It's not a language I'm fluent in (the vast majority of my experience has been in Objective-C and Swift) so I find myself spending a good chunk of time doing research trying to figure out what the most widely accepted/correct way to do [insert thing] is in C++.

So if what's written here is true, I may be unwittingly baking bad practices into my C++ knowledge as a direct result of trying to accomplish the exact opposite…

Which leads me to the question: what is the "right way"? I've seen highly vocal critics of writing C++ as "C with extras", so I assume some middleground is where I need to target?

lots of people who have produced super high quality, money making software in c++ ignore almost everything advised by stroustrop and other modern c++ advocates. don't worry about it, just aolve your own problems.

I would read books like Scott Meyers' Effective Modern C++, watch cppcon talks. There's a lot of very high quality C++ content out there these days.

Generally there's a lot of emphasis on RAII, clear ownership semantics, leveraging more of the standard library as its grown, using lambdas, avoiding shared mutable state, judicious but not excessive use of inheritance and in particular avoiding implementation inheritane, encapsulation.

It's not so much a middle ground in the sense you are thinking. The people I'm talking about don't advocate developers, particularly non expert, going crazy with templates. People do that on their own.

Hope that helps.

The right way is, to speak in philosophical terms, totally a pragmatic choice. If nothing in C++ is working for you, don't use it. If a really obscure technology is making you go really fast, use it.

The one and only thing that muddies this picture is other people. Once you are collaborating on a program(whether on the same team, through end-user code, or through a library or API call) all your tricks, preferences and conventions are subject to other people's inept groping and misunderstanding. And that is where you get into standardized best practices. They are basically guaranteed to not actually be the best practice, but they're the one you can compromise on.

> Unfortunately it seems that the majority of C++ code out there is like that. It could be said that C++ makes it far easier than C to introduce unnecessary abstraction and indirection, without realising the true costs.

Citation needed? Better developers are more aware, in any language. There are some cases where idiomatic C++ may introduce more indirection over C (though I can't think of any); there are plenty where idiomatic C introduces more indirection than C++. However, with a little more effort and awareness, the faster and more maintainable solution is always accessible.

> I've noticed that using a lower-level language, where abstractions have to be built explicitly, tends to cause one to rethink the problem and often come up with an even simpler and more efficient solution, by approaching it from another direction which using a higher-level language may not even allow.

Having lots of developers, re-implement many things, mostly just results in much more buggy code. Getting things exactly right is hard. Having a bigger standard library and safer abstractions is a huge edge.

I don't think your anecdote has anything to do with C vs C++. I think basically some negative experiences with so-so C++ devs has colored your thinking rather than technical reasons.

My experience has been the opposite of yours. Freeing is always a good idea so you can use tools like valgrind to find memory bugs without needing to sort through all the false positives. Your short-lived program today can become a service tomorrow. c++is worth it just for RAII

Valgrind does not force the user to read mem leak reports along errors. Actually IIRC, by default you don't get detailed leak reports.

True, the defaults are pretty lame, but my point is if you don't free, and you start using data you intended to free, that's a memory bug valgrind won't be able to help you with unless you free your memory.

FWIW, this is in my bashrc along with a myriad of other programs that have lame defaults: alias valgrind='valgrind --leak-check=full --show-reachable=yes --track-origins=yes --track-fds=yes --error-limit=no'

> As for the "memory leaks" --- I haven't looked at the source, but something whose runtime is very short-lived, like pkg-config, may be very well justified in allocating and never freeing, letting the process exit itself be the "ultimate free".

But sometimes the code grows and what was once a stand-alone executable is about to become a component in a larger executable. With C++ you get a correct component out of the box (if you use RAII consistently), but with C you have to audit all of the code and clean up the leaks.

bit of a tautology there. correct if correct.

Correct if correct, portable if portable, modular if modular, and future-proof if the future isn't too surprising.

Converting the code to pure C without GLib would increase the code size considerably, since GLib provides utilities, such as hashtables, trees, and better string handling, that the standard C++ library provides but the standard C library does not.

> My experience has been the complete opposite.

Keyword: "can".

> what should be compared is "C++ standard library only" and "C standard library only"

The C++ standard library has more features though.

Never freeing is sloppy, it means resource handling was likely not thought through. I would be concerned about non-memory resource handling in particular.

If one must use this "trick", it's better to think things through, add the appropriate release calls and then somehow replace the release function with a no-op.

Anyway, you're welcome to take a C++ project and translate it to a fast C project with fewer dependencies and lower memory consumption. Then we can discuss facts instead of your personal opinions.

Never freeing is common practice in embedded systems where you should be pre-allocating all data (after worst-case analysis). This removes any possibility of fragmentation issues, etc. Many coding standards forbid dynamic allocation for embedded & real-time systems also for safety & reliability reasons.

It is not unusual to have allocate-only heaps for exactly these reasons.

I agree, but the C idiom is to just not call free, without pre-allocating anything. It's an optimisation to avoid waiting for the resources to be released, with the idea that they will be anyway when the process is killed.