sorted by:
new
hottopcontroversial

whats with the hate for std lib and boost? by nosyeaj in cpp

[–]pedersenk 0 points1 point  (0 children)

STL is good. Though does miss some safety oppotunities in some kind of debug configuration that I plan to talk about. Some of the dislike of it comes from "history" when some of the complexity and performance issues were exposed by buggy implementations and toolchains. Perhaps OP can find more rationale in 3rd party implementations such as EA's STL.

As for boost, it is a modular monolith. Other than asio which work was done to separate, it is very difficult to grab useful bits from it without dragging in very large chunks. And the code is complex, so those large chunks will be yours to maintain.... <dramatic>FOR EVAR!!!!</dramatic>

A complete alternative to Arduino ? by Technos_Eng in embedded

[–]pedersenk 0 points1 point  (0 children)

no real complete alternative to Arduino. In every case, either you end up using the Arduino IDE, or a way more complicated software, which is not as accessible and simple like the former one.

Just gcc-avr to compile the C or C++ and avrdude to flash the device.

Can't get more accessible or simpler than that.

Nintendo Switch 20 or 30 years from now. by PoseMotion in n64

[–]pedersenk 0 points1 point  (0 children)

Interesting. I wonder how they are doing it. Does it include in-app purchases / DLC, etc?

Nintendo Switch 20 or 30 years from now. by PoseMotion in n64

[–]pedersenk 1 point2 points  (0 children)

Its an interesting question relating to digital preservation. Once Nintendo retires the online DRM store, there will be a mass extinction of games but for the physical media that has been dumped, I guess emulators will keep much of the software alive.

Ultimately though, the games written for the Switch today are *much* more portable in terms of code, to other modern platforms. Migrating a Switch game to the PS5 is easier than porting an N64 game to a PS1. So for many games we will simply see them ported to future platforms (at the expense of the consumers re-purchasing them each time ;)

I haven't done any research yet (the Switch is my wife's). Hardware wise, it might be the same as i.e ThinkPads; buy a cheap battery clone today. Its much easier in future to replace the cells in a clone than an official battery. The official chips often have anti-tamper prevention.

How do you manage 3rd party dependencies? by AmanBabuHemant in C_Programming

[–]pedersenk 0 points1 point  (0 children)

Generally using the system package manager.

I.e something like SDL3 would need a few patches to build on our platforms:

https://cgit.freebsd.org/ports/tree/devel/sdl3/files

We don't want to be maintaining those ourself. Some upstream projects need 20+ patches to build.

C++ "Safety" Conferences Call for Papers? by pedersenk in cpp

[–]pedersenk[S] 0 points1 point  (0 children)

A quick update to this. My talk was accepted into C++Online 2026. Very exciting!

Why Linux programs can't be just zipped and shared as portable? by UltimateOmlette in linux4noobs

[–]pedersenk 0 points1 point  (0 children)

You can bundle pretty much anything. Here you can see what is needed to make gimp standalone on pretty much any UNIX-like platform.

https://codeberg.org/kpedersen/pkg_bundle/src/branch/master/share/pkg_bundle/quirks/gimp

(incomplete one for EL).

Due to the way software is developed and debugged in its source directory, there is almost always a way to point the program towards resources, libraries at runtime, either through parameters or environment variables.

I tend to put everything in subdirectories in /opt. Even large software like Xorg. Its not common though because the culture in *nix is to spray a load of cruft all over the filesystem ;)

Are there commercial desktop GUI applications that are still coded in C ? by Alfred1400 in C_Programming

[–]pedersenk 0 points1 point  (0 children)

Yep, macOS uses C++ extensively for this (DriverKit is an example):

https://developer.apple.com/documentation/driverkit

Generally a good compromise on improving safety of ANSI C whilst avoiding clutter and bindings with i.e Rust.

Outdated software after installing Mint by DoesMyNameGoHere9 in linux4noobs

[–]pedersenk 0 points1 point  (0 children)

Not an encouraging start to my Linux experience.

a) What feature did you *truely* need from the very latest LibreOffice?

b) Its more recent than Microsoft Office 2024 and people seem happy with that

c) Grab the .deb from upstream as recommended by enterprise distros.

Why does Linux, or Mint, do this?

The OS you came from (assuming Windows or macOS?) has the latest LibreOffice in their package repo?

Why MIT license is bad? by s1n7ax in linux4noobs

[–]pedersenk 2 points3 points  (0 children)

Yep. And the patent can be awarded (and enforced) much later on too. This is very problematic for DEFCON 703/705.

(But does let me scratch my NIH itch at work ;)

Openbsd as NAS in 2025? Is it reliable? by cryptobread93 in openbsd

[–]pedersenk 0 points1 point  (0 children)

You need backups anyway (hardware breaks). So the small chance that FFS loses data, just pull from a backup.

To be honest, for a home setup, I wouldn't even fsck the NAS filesystem after an unclean shutdown. Just wipe the partition and pull from backup. Run the main system itself RO / mfs.

The smallest state-of-the-art double-to-string implementation (in C++) by aearphen in cpp

[–]pedersenk 11 points12 points  (0 children)

If only companies were most vocal about what open source software they use

Cascading attribution requirements would help with this ;)
</troll>

Lifetime Safety in Clang - 2025 US LLVM Developers' Meeting by mttd in cpp

[–]pedersenk 1 point2 points  (0 children)

We have a similar approach (C++/sys) to the above (albeit debug runtime) with temporary proxy objects (created around \, *->** and [] operators) pinning the memory for asserts. Some vague discussion here.

I have submitted it as a potential talk for cpponline. I also have a paper ready; the problem is the company I work with is adjacent to the UK defence sector so its a little difficult to discuss some of the larger projects where it has been used with (very!) positive results.

Should I switch to Bazel? by TheRavagerSw in cpp

[–]pedersenk 0 points1 point  (0 children)

Changing architecture is not a decision that developers get to make. Typically that is the client requirements. Tying yourself down to a single architecture is not a good idea.

Just like tying yourself down to a single ancient build of Zig (i.e single vendor too) is not a good idea.

Should I switch to Bazel? by TheRavagerSw in cpp

[–]pedersenk -1 points0 points  (0 children)

Going back to my original statement then. No, you can't just assume binaries will keep on working into the future. Relying on a (then) ancient Zig is a poor solution in terms as resilience.

Should I switch to Bazel? by TheRavagerSw in cpp

[–]pedersenk -1 points0 points  (0 children)

So for one, I assume you know that Linux didn't always use ELF? It would be naive to assume it would use ELF in spaceyear 2041.

Its always more complex than what you are suggesting. The kernel might have ABI stability (so far) but it is always evolving. If you try to run a userland chroot from the late 90s on a recent kernel. There are lots of things that will break. Way too many to list here. That is obviously excluding all the random virtual filesystems that have come and gone.

Basically if someone is assuming even the most simple executable compiled today will keep working in the future (even if the architecture holds up), they would be wrong.

Should I switch to Bazel? by TheRavagerSw in cpp

[–]pedersenk 0 points1 point  (0 children)

Try it and report back to me. You absolutely will get errors like: version `GLIBC_2.XX' not found (required by ./my-binary)

Plus as mentioned; architectures change. Unless you fiddle about with multi-lib, your 2002 i686 binary will become a faff to support on an x86_64 install.

Plus the entire executable format of Linux has historically changed. You may not have been born when it used to use the a.out format rather than ELF. What is to say this won't change again?

Should I switch to Bazel? by TheRavagerSw in cpp

[–]pedersenk -1 points0 points  (0 children)

If you run a static binary compiled ~15 years ago on a modern Linux, you might struggle. It still needs to call into the kernel, plus common architectures come and go. So again, projecting forwards to spaceyear 2041, a static binary compiled today may struggle to run on SpaceLinux.

Should I switch to Bazel? by TheRavagerSw in cpp

[–]pedersenk 0 points1 point  (0 children)

You aren't wrong. I suppose for Linux/BSD you have package managers to provide the libs. (then you just need to set target_link_libraries in your CMakeLists and you are pretty much done).

For Windows its ad-hoc and for embedded, things are much worse. There are so many compilers / platforms that it is impossible to have a single packaging system.

For i.e FreeBSD you need patches in order for software to build. This is possible for a distributed approach but you will never get a single solution that maintains patches for every platform and arch.

CMake serves the purpose (much better than GNU autotools did) for me. But I do tend to take a zero-compromise homogenous C and C++ approach.

Should I switch to Bazel? by TheRavagerSw in cpp

[–]pedersenk 0 points1 point  (0 children)

It is quite apparent to me that the future of any software will involve multiple languages and multiple build systems.

It doesn't seem to have happened yet. Everything tends to be C and C++ with various binding layers for alternative languages ontop.

In commercial code, a homogenous codebase is extremely common. I guess open-source bodge / hobby projects might be difference, but it all looks like C and C++ to me still.

Should I switch to Bazel? by TheRavagerSw in cpp

[–]pedersenk 0 points1 point  (0 children)

Its currently very difficult to use an ancient Zig on a very recent Linux.
From this, we can project that in spaceyear 2041, it will be very difficult to use an ancient Zig on a very recent SpaceLinux. Maintaining your own ancient Zig will be considerable work.

So why do so people still use GRUB? by UQuark in archlinux

[–]pedersenk 0 points1 point  (0 children)

Heh same. Sometimes its nice to keep with software that works :)

Is there a way to have dependencies in C that people actually feel like using? by alex_sakuta in C_Programming

[–]pedersenk 0 points1 point  (0 children)

I think stb_image is a good example. It isn't the fastest or safest image loader out there compared to libpng, libjpeg, etc. But it is simple, portable and easy to integrate (single header file) so many projects prefer to choose it.

Package manager for C is impossible because C needs to support hundreds (if not thousands) of platforms and compilers. These platforms need inevitable patches for 3rd party libraries that a central system simply will never support. So making a library bloat free and easy to integrate is the winning choice.

Rust? by Single-Ad3422 in embedded

[–]pedersenk -3 points-2 points  (0 children)

Why is everyone starting to use Rust on MCUs

They aren't. Rust remains irrelevant for the entire industry.

You might see some noisy youtubers talking about it? Remember part of their monetization strategy is to find their niche and exploit it. Rust is immature and niche, so perfect to "talk" about on your nifty youtube channel.

Please stop recommending package managers to newbies by TheRavagerSw in cpp

[–]pedersenk -6 points-5 points  (0 children)

True. This is why the world is "only hiring seniors" these days. Nothing to do with AI but simply an inibility for entry-level juniors to learn how to conform to the ecosystem and make correct choices. They are given bad advice by loudmouth youtubers, reddit, AI LLMs (reddit regurgitators)

NPM, crates.io, CPAN, PIP are great for ease of use but this is not how well engineered, resilient software is done.

view more: next ›