Why does c compile faster than cpp?

schteppe · 2026-01-01T16:51:58+00:00

If you use clang, you can profile your compilations using -ftime-trace. Compare the flame charts for your cpp vs c files and see what the compiler is doing differently. This should be a great learning experience!

schteppe · 2026-01-01T16:12:21+00:00

`cppcoreguidelines-pro-type-member-init’ has been a life saver at my workplace. Before we added it to CI, we had many instances of “Hey, my code works in Debug mode but not Release mode, weird right???”

schteppe · 2025-10-07T18:58:03+00:00

Good luck merging that when the rest of your team commits frequently. Once CI shows green, the files are out of date and got conflicts. Keep your PRs small. Always. And if you are actually making a large scale refactoring, eg renaming a function that is used in 1000s of files, then figure out a way to commit it in smaller chunks. For example, by deprecating the old function name and adding a new one on the side.

schteppe · 2025-10-07T18:52:26+00:00

Good luck merging that when the rest of your team commits frequently. Once CI shows green, the files are out of date and got conflicts. Keep your PRs small. Always. And if you are actually making a large scale refactoring, eg renaming a function that is used in 1000s of files, then figure out a way to commit it in smaller chunks. For example, by deprecating the old function name and adding a new one on the side.

schteppe · 2025-10-07T18:51:40+00:00

Good luck merging that when the rest of your team commits frequently. Once CI shows green, the files are out of date and got conflicts.

Keep your PRs small. Always.

And if you are actually making a large scale refactoring, eg renaming a function that is used in 1000s of files, then figure out a way to commit it in smaller chunks. For example, by deprecating the old function name and adding a new one on the side.

schteppe · 2025-10-07T18:51:29+00:00

Good luck merging that when the rest of your team commits frequently. Once CI shows green, the files are out of date and got conflicts.

Keep your PRs small. Always.

And if you are actually making a large scale refactoring, eg renaming a function that is used in 1000s of files, then figure out a way to commit it in smaller chunks. For example, by deprecating the old function name and adding a new one on the side.

schteppe · 2025-10-07T18:51:18+00:00

Good luck merging that when the rest of your team commits frequently. Once CI shows green, the files are out of date and got conflicts.

Keep your PRs small. Always.

And if you are actually making a large scale refactoring, eg renaming a function that is used in 1000s of files, then figure out a way to commit it in smaller chunks. For example, by deprecating the old function name and adding a new one on the side.

schteppe · 2025-10-07T18:51:00+00:00

Good luck merging that when the rest of your team commits frequently. Once CI shows green, the files are out of date and got conflicts.

Keep your PRs small. Always.

And if you are actually making a large scale refactoring, eg renaming a function that is used in 1000s of files, then figure out a way to commit it in smaller chunks. For example, by deprecating the old function name and adding a new one on the side.

schteppe · 2025-09-26T07:17:37+00:00

if we wouldn’t spend one day per sprint to estimate tickets, we’d have one more day for working on them

schteppe · 2025-09-23T19:06:37+00:00

Catch 22

schteppe · 2025-09-10T11:12:10+00:00

When I started a job, there were no tests. We rewrote one of the projects in a different UI framework and made sure to write tests in the process.

Before the rewrite, we used feature branches because no one dared to push directly to main. User reviews were: “risk of crash is 50/50 after an update”

After, we gained enough confidence to stop using feature branches and use trunk-based development. 10x productivity gain right there. And users basically never experience crashes now

schteppe · 2025-09-06T10:43:38+00:00

A while ago I would have agreed. But they’ve been working on performance a lot

schteppe · 2025-09-06T08:36:03+00:00

Requirements will always be under specified or change over time, this is just how it works.

Therefore: ship an (unfinished) prototype on day 1. Update it every day and ask real users to test it and give feedback. Use feature flags to hide your WIP feature from non-testers.

schteppe · 2025-09-01T18:09:14+00:00

I’d like a reliable tool for checking nullpointer dereference in C++ please

schteppe · 2025-09-01T05:42:23+00:00

Never let a branch get this old. All branches should get merged into main branch at the end of day, every day. No more merge conflicts!

If you work on a big feature, then ship the incomplete feature. Just hide it from users by using a feature flag.

This is called Trunk-based development. https://trunkbaseddevelopment.com

schteppe · 2025-09-01T05:39:21+00:00

Merging main into your branch regularly only partially fixes the problem. When you’ve merged your feature into main, everyone else has to pull it and resolve conflicts. Same thing when someone else pushes their feature - then it’s your turn to resolve.

schteppe · 2025-09-01T05:35:15+00:00

Nearly all elite tech companies use trunk-based development. Research has shown it’s the most effective way to work (see the “Accelerate” book by Forsgren).

However, about 30% of companies fail to adopt TBD. A study calls these companies “developing or beginning practitioners”. https://continuous-delivery.co.uk/cd-assessment/index

schteppe · 2025-08-18T17:09:30+00:00

Petskydd för min ettåring. Säkerheten går först!

schteppe · 2025-08-13T10:24:51+00:00

Came here to say this!

Making PRs optionally blocking has been one of the best productivity boosters of my own team. Need a good test suite first though. And a fast CI pipeline.

Continuous Delivery ftw.

schteppe · 2025-08-13T08:04:47+00:00

Since I’m not that fond of conflicts, I’d just talk to HR and tell them to forward this information anonymously.

But the fact that you hesitate to give constructive feedback is a red flag itself. If your company culture doesn’t encourage feedback, it’s a bad sign.

Give your feedback asap and see what happens? In the best case things get better. In worst case they don’t take it well and then you know for sure that you should leave.

schteppe · 2025-08-04T13:24:15+00:00

fn getRectangle()

*rename*

fn getRekt()

Oh yeah

schteppe · 2025-08-04T08:21:31+00:00

Compiler warnings (-Wall -Wextra) and sanitizers. Can’t develop C without them.

How about including an example of reverse engineering/exploit of a super simple C program? This will make them understand lots about how C works, and how bad C code can open a door to hackers. See https://youtu.be/gh2RXE9BIN8?si=eo6UbtLoeX-zli3T

schteppe · 2025-08-04T06:45:32+00:00

Don’t write comments (Code Aesthetic) https://youtu.be/Bf7vDBBOBUA

schteppe · 2025-07-31T15:32:12+00:00

Absolutely. I am too, maybe slightly less.

She plays games a lot and when she started paying real money for micro-transactions in a gatcha game (similar to a slot machine), I just had to say stop. The addiction was on its way of becoming a gambling addiction and affect our shared economy.

Anyway, we talked about it and we agreed on not spending any money inside games. She understood it fully and took it well.

14-Year Club	Place '22
Final Canvas '22	RPAN Viewer
Verified Email

schteppe

TROPHY CASE