You Are Not the Compiler — You're the Developer

Modern C++ gives us powerful tools like emplace_back() and perfect forwarding — tools that allow in-place construction and the avoidance of unnecessary temporaries. As developers, we understand how these tools work, and we know how to squeeze performance out of a language known for its fine-grained control.

But just because we can out-think the compiler doesn’t mean we should.

Here’s the thing:

The compiler is better at optimisation than we are. Our job is to write code that is clear, correct, and maintainable — and to trust the compiler to do its job.

emplace_back() and the Illusion of Manual Optimisation

Take this common example:

someVector.emplace_back(42, "hello");        

If you're working with a std::vector<MyStruct>, and MyStruct(int, const char*) exists, this may behave as expected.

But what happens if someone later adds a MyStruct(int, std::string) constructor? Or if the container type changes? Or if the overloads become ambiguous?

Suddenly, behaviour changes — not with an error, but silently — because overload resolution picks a different constructor.

You can fix this by being explicit:

someVector.emplace_back(MyStruct{42, "hello"});        

Yes, it creates a temporary. And yes, you could avoid that temporary. But in practice, the compiler — especially with C++17 and guaranteed copy elision — will most likely remove it. The performance is there either way.

What you've done instead is make your intent crystal clear. No overload ambiguity. No risk of subtle breakage. Just a line of code that says exactly what it means.

The Developer’s Role Isn’t to Beat the Compiler

The point isn’t to avoid emplace. It’s to use it intentionally — when it expresses clear construction, or when you’re in a context where the performance gain actually matters and has been measured.

As a developer, you can recognise where optimisation is possible. But you also understand what optimising too early — or too aggressively — can cost in terms of code clarity, future maintainability, and correctness.

You write clear code first. You profile later. You optimise only when the data justifies it.

And in doing so, you’re not writing code for the compiler — you’re writing code for other humans.

My Philosophy

Much of my work in C++, C#, and Delphi has centred around scalability, maintainability, and clean design — from embedded protocol stacks to SDKs and distributed systems. The deeper I go into systems programming, the more I return to this truth:

The best code is that which expresses your intent clearly — and lets the machine take care of the rest.

About Me

I'm a seasoned software engineer focused on architecture, clean code, and cross-platform backend systems. I've recently been working in C++17 on embedded stacks and reusable libraries, applying long-standing design principles from a background in Delphi and C#.

I recently relocated to Madrid and am open to new opportunities in C++, SDK/API development, and technical leadership — particularly in environments that value engineering excellence and clarity of thought.

Available for remote roles or on-site/hybrid positions in Madrid; open to EU/EEA opportunities (CET±2 preferred).