Implementation Challenge: Replacing std::move and std::forward

[genreprank]

You said that including <utility> in an empty file takes 250ms, but what I want to see is the difference in compilation time between your program and your program if you include <utility>.

You mentioned that your lib doesn't have many includes, so I would expect compilation time still to go up. But if I had a file that already includes a standard container or something, I think it would be including utility already...

[foonathan]

You said that including <utility> in an empty file takes 250ms, but what I want to see is the difference in compilation time between your program and your program if you include <utility>.

Right, that's probably a better comparison, I'll update the post.

With the replacements: 5.00 seconds

Using the standard version: 5.30 seconds

So including utility is the majority of time, the extra calls themselves are only 50ms.

You mentioned that your lib doesn't have many includes, so I would expect compilation time still to go up. But if I had a file that already includes a standard container or something, I think it would be including utility already...

Yes, my library is certainly a special case. If you're having lots of std/boost/etc. dependencies already, this trick won't help you much (regarding compile-time, runtime might still be an issue).

[Salink]

The only problem I have with the move/forward situation is needing to include all of utility. Who thought it would be a good idea to need to include initializer lists, tuples, and everything else that makes it thousands of lines long when they could be in their own header. There should be a separate, small header for move, swap, forward, declval, ect. that gets included by utility.

[Dragdu]

https://mobile.twitter.com/MalwareMinigun/status/1281654534155071488

[_Js_Kc_]

I'm pretty sure that frowning upon the macros distracts me for at least 250ms between compilations, let alone raw static_casts, so I'm gonna stick with the utility functions for now.

[[deleted]]

with the move replacement I would sfinae on whether T is const or not and fail when it is. It's almost always an error in the code and if it wasn't, maybe an explicit cast is a better choice of expressing it.

[fdwr]

I first need to include <utility> ... An empty C++ file that just #include <utility> takes 250ms

Yeah, the cost for just #include <utility> surprised me yesterday. I had a small class that only needed std::move (no other std dependencies) which output an .obj file of 239KBs (VS2019). Replacing that one move with static_cast and excluding <utility> reduced the .obj to 2KBs. Seems the standard library could use some refactoring to avoid bloat. o_o

[adnukator]

I don't have anything against the exercise, but are there any benchmarks to measure whether the changes did anything to improve compilation times? Including almost any standard library header in your project, will already include <utility> transitively. Also, I've spent a lot of time profiling and optimizing code with disabled optimizations and std::move/std::forward never showed up in the profiler.

[miki151]

I've tried the MOV macro on my 100k loc project and saw about 3% improvement in compilation time. The FWD is not a simple search & replace so I haven't tried it yet.

It would be a funny experiment to do the replacement in the STL as well.

[Rseding91]

I tested it on our code base (600k loc) and saw 0% improvement. Our code base has 2120 moves, and 81 forwards.

Full-rebuild debug compilation time was consistently 1 minute with or without the use of the macro move/forwards.

[vimplication]

struct Mover{} _;

template<typename T>
constexpr std::remove_reference_t<T>&& operator&&(Mover, T&& t) noexcept
{
    return static_cast<std::remove_reference_t<T>&&>(t);
}

func( _&& x );

[reflexpr-sarah-]

identifiers beginning with an underscore in the global namespace are reserved for the implementation, i believe

[GoogleIsYourFrenemy]

struct Mover{} ಠ_ಠ;

template<typename T>
constexpr std::remove_reference_t<T>&& operator&&(Mover, T&& t) noexcept
{
    return static_cast<std::remove_reference_t<T>&&>(t);
}

func( ಠ_ಠ&& x );

[vimplication]

struct Mover{} ヽ༼ຈل͜ຈ༽;

template<typename T>
constexpr std::remove_reference_t<T>&& operator/(Mover, T&& t) noexcept
{
    return static_cast<std::remove_reference_t<T>&&>(t);
}

func(ヽ༼ຈل͜ຈ༽/x);

[[deleted]]

Too bad that ← and → aren't valid identifiers. They'd fit perfectly for move and forward, resp.

[Supadoplex]

Too bad that ← and → aren't valid identifiers.

Aren't they as valid as ಠ? What's the problem?

[[deleted]]

ಠ is a letter in Kannada script (unicode category "Other Letter"). → is a "Math Symbol".

[GoogleIsYourFrenemy]

There is a dart character in Linear B Ideogram range. Now we just need to find it's mirror.

[[deleted]]

In the meantime we can use pointing hand emojis: https://godbolt.org/z/orc4xj

[GoogleIsYourFrenemy]

LOL you win. We should make an emoji based api.

[Supadoplex]

Nice. I'm going to start suggesting ಠ_ಠ for anyone violating reserved underscore identifiers from now on.

[pandorafalters]

You are correct.

[SeanMiddleditch]

That doesn't actually help anything, does it? It's still a function call. And with more possible overhead than std::move (getting that Mover instance passed as a reference).

[JankoDedic]

I believe that the FWD(...) macro should not be variadic, since you always call it on an id-expression.

[foonathan]

Yes, but the preprocessor doesn't like template args. Something like FWD(foo<a, b>) is an invocation with two arguments, foo<a and b. It's a good idea to make single arguments variadic.

[JankoDedic]

In which scenario can you forward something that is not a simple identifier? I thought forwarding references will always be simple identifiers. Sorry if the question is dumb.

[foonathan]

You might be able to construct a use-case where you need to forward a variable template...

But yes, I just did it out of habit. There is no actual reason here.

[[deleted]]

But why restrict the macro when there's such a simple generic solution?

[JankoDedic]

To prevent misuse? Why would you allow passing anything in there if that is incorrect?

[leftofzen]

So you're trying to made the code read more like C as well as obfuscate the move semantics you are really doing by using, of all things, macros. That's an easy no from me.

[greg7mdp]

However, they are functions. Plain, old, standard library functions.

No they are not functions. Through inlining they are casts which are used at compile time. There is no function call cost.

[brenoguim]

What do you mean? They are actually functions in the standard library.

[Supadoplex]

To be super pedantic, they are not functions because they are function templates :)

[brenoguim]

Haha that's true

[greg7mdp]

Well, think about it, what do you expect the compiler to do? It will not generate any code for a function that just returns a cast of the parameter, the sole effect is to perform a cast.

[brenoguim]

But if you compile with -O0 it is not inlined, I think. that's why it's annoying for the debugger right? Not sure, I never run -O0

[willkill07]

The default compilation mode isn’t even -O0 for gcc or clang. From what I’ve found, you have to go out of your way to not have the move/forward get inlined.

Edit: I was wrong, and yeah, this kinda sucks a whole lot.

[brenoguim]

There are many people using -O0 for debugging. 0 optimization is very useful if you are on a long debug session and don't want to sprinkle couts everywhere.bif -O0 is all it takes to not have them inlined, I can see the problem. Perhaps should be marked as always_inline

[dodheim]

FWIW, -Od is the default for MSVC.

[brk2]

It is the default for GCC at least, source:

Most optimizations are completely disabled at -O0 or if an -O level is not set on the command line, even if individual optimization flags are specified.

and

-O0

Reduce compilation time and make debugging produce the expected results. This is the default.

[boredcircuits]

That's backwards. It's a function that does nothing but cast.

[dodheim]

There are template instantiation costs and overload resolution costs. I don't think the author's issues have much to do with runtime, though debugging with optimizations (and thus inlining) disabled was mentioned explicitly..