Hacker News Reader

Comment by b20000 | Hacker News Reader

b20000

i was in a leetcode BS interview a while ago with a googler who thought i could not write code in c++ because i could not remember lambda syntax. i only use maybe 30% of c++ features in my software and have been doing this for over 20 years. it’s only recently i started using lambdas more, but still stay away from them because of the potential hidden allocations.

View on HN

If you're not capturing variables that allocate memory (like std::vector or std::string), there will be no allocations. And if you're that sensitive about hidden allocations, chances are that you're going to avoid most of these STL types in the first place (no allocating constructors or RAII), so you won't probably need to worry about this. Even the people using C-like C++ ("Orthodox" C++) seem to use lambdas liberally when it make sense.

(Or maybe you're talking about putting a lambda into an std::function, which is a totally different thing and will probably incur heap allocation?)

I interview a lot of C++ developers who have 20 or more years of experience I feel really bad when the vast majority of them fail to keep up with modern standards or take the time to understand their tools resulting in all kinds of misconceptions based on outdated information.

Lambda expressions do not involve any kind of hidden allocations, their definition is precisely formalized and can be reviewed in S 7.5.5 of the standard. Even if you don't care to read the standard, there is no shortage of resources online that explain what a lambda expression is, and none of them involve anything to do with hidden allocations:

https://en.cppreference.com/w/cpp/language/lambda

I'm sorry to pick on you specifically, but it's a major problem that is entirely unnecessary. It's almost heartbreaking that the people who should have the most experience in a subject based on decades of knowledge are often the ones who carry the biggest misconceptions and spread the most misinformation.

Maybe the allocations I was referring to came from using std::function. My point was that if you are not careful when you write software in C++ and use modern features, you will get behaviour you don't want or didn't expect.

I have no time to read the standard or keep up with it. Maybe that is what people at Google can afford to do? I'm guessing that is where you work.

I run a small business, and I have to juggle a lot more than just writing code. When I have a problem, I figure out where it's coming from, and fix it. If you run your own business I'm sure you understand that.

Not keeping up with the standard has nothing to do with ignorance or refusal, but with constraints. I also don't think it should be required to know the standard, or the syntax for features you don't need to use everyday of the top of your head. If you are not sure, look it up. That's what the internet is for.

In any case, no need to be arrogant and dismiss people with experience as stupid or ignorant, or blaming them for spreading misinformation, simply because they don't know certain syntax by heart or don't keep up with the standard.

>My point was that if you are not careful when you write software in C++ and use modern features, you will get behaviour you don't want or didn't expect.

This is an unsubstantiated point and simply untrue. Modern features have worked hard to maintain what is referred to as "zero cost abstractions".

>If you run your own business I'm sure you understand that.

I do own and operate a business, a quant firm engaged in HFT. It's part of the reason why I hire so many C++ developers.

>Not keeping up with the standard has nothing to do with ignorance or refusal, but with constraints.

The ignorance comes from going into an interview where one would presumably be expected to have a basic understand of modern C++ functionality and then proceeding to call that interview BS when in fact it was you who simply had a poor understanding of what was expected.

If you don't want to use lambda expressions or you feel like using C++ like it's still the year 2003, so be it, that is your choice... just don't be surprised and go around calling interviewers full of BS when you continuously refuse to keep your understanding of technology up to date.

The problem in this case is not with the "BS interview" or the interviewer, the problem is with you. If you do not keep your understanding of C++ up to date, for whatever reason, then an interviewer is right to reject you for it in favor of someone who does take the time to keep their skills up-to-date.

What kind of hidden allocations?

That are used to hold captured variables and values.

Internally, lambdas are function pointers + the context, and the context may or may not be dynamically allocated depending on how lambdas are used.

People who think that lambdas may cause heap allocations are confusing lambdas with std::function.

Lambdas are essentially syntactic sugar for an anonymous struct holding references to/copies of captured variables and an operator() method with your code. Not 100% precise, but memory-wise that's how it works (and has to work). No dynamic memory allocation is involved here at all.

If you put a lambda (or any other callable) in a std::function, the std::function will copy that functor object, either into its own small-buffer-optimized in-place storage or (above a certain functor size) into heap-allocated memory.

There is no dynamic allocation at all, unless you assign the lambda to an std::function, in which case it _may_ require dynamic allocation if the size of the captured variables exceed the internal storage capacity (typically 32 bytes) of std::function. There are types (usually called 'function_view') floating around that don't dynamically allocate at all, and that can be used as a cheap alternative when the function is not stored for later use.

Internally, lambdas are structs with the "function call" operator overload. Context is done via members of the struct: capture by-value, and the struct copies them and stores its own, capture by reference, and the struct member is a reference. There should be zero heap allocation in any case.

If I'm reading this right, then "lambda" in C++ isn't "lambda" in Scheme/CommonLisp, where captured variables need be heap allocated rather than stack allocated to construct closures?

You're right. Lambdas in C++ are syntactic sugar over something the core language has allowed you to do since before C++98. Since you control which variables you capture into the closure, and how, when writing the lambda, all of the information regarding how to make it (e.g. it's size, data members, etc) is static, and so it does not require the use of the heap at all. A concrete example. The following C++ examples do the same thing, and neither touch the heap:

    // A. Using a struct. The old manual way.
    struct my_lambda {
        my_lambda(int c) : c_(c) {}
        int operator() (int x) const {
            return x == c_;
        }
        int c_;
    };
    
    auto f(vector<int> numbers) {
        my_lambda lam(2);
        // remove all the matching elements
        erase_if(numbers, lam);
        return numbers;
    }

    // B. Using a lambda
    auto g(vector<int> numbers) {
        int c = 2;
        erase_if(numbers, [c](int x) { return x == c; });
        return numbers;
    }

It is complicated. In C++ closures can close over local variables either by value or by reference (the choice can be made for each variable closed over).

When closing over a variable by reference, if the lambda need to survive the local scope heap allocating the closure itself won't help. Instead you need to explicitly heap allocate the closed over variable itself (and close over the, usually smart, pointer).

When closing over by vale, there is no such issue, closed over variables are copied over along the lambda and it can be safely, for example, be returned from a function.

Copying might be expensive if the lambda is closing over an expensive to copy object, but move semantics are always an option.

Lambdas are value types, they are usually copied around. so when closing over ither va

You capture by value a variable that allocates and you get a heap allocation.

That's dependent on the captured type's copy (or move) behavior, and is completely different from your claim that how the lambda is used can influence this. Lambdas themselves never heap allocate.

Reply on news.ycombinator.com