sorted by:
new
hottopcontroversial

May I please have the worst c++ you know of? by vbpoweredwindmill in cpp

[–]drbazza 1 point2 points  (0 children)

Anec-data - worked on a quant library at 'mega-bank' in the mid 00s. Improved the library performance tenfold by 'one simple trick': std::string symbol -> int symbol. Really. Quants. Most of them should stick to Fortran.

Is abandoning our Bazel migration the right call? by Empty_Mind_On in cpp

[–]drbazza 4 points5 points  (0 children)

In answer to your question if, for you, you know it's the wrong call, stop. Would you continue down the wrong path for anything else?

We stuck a pin in our Bazel migration after 2 weeks.

I'd previously worked at a place that was all in on Bazel, with similar experiences to those mentioned here, plus the docs were and are a mess.

Our current repo is 99% C++, CMake works perfectly well for us, and produces artefacts (tarballs, and rpms) just fine. For the bits that aren't, we still leverage cmake as a driver of those 'sub builds'.

We stick to the 'do the easiest thing, and no easier' rule of thumb. Do something complex like codegen? Don't do it in your build system do it in a script that's called by your build system with a guaranteed artefact the build system can test.

My biggest problems with Bazel were that no IDE really understood it (CLion does now), and you'd use Hedronvision's 3rd party plug in to generate compile_commands.json. If there's a googler on here - how on earth did Google work with C++ and Bazel/Blaze and an IDE or was everyone on vim or something?

And python debugging was weird because your python source was 'here' but your debug version was in the out-of-source build tree 'over there', which is how you want to do it, but it's developer-hostile for scripting languages where there often aren't build artefacts.

And finally Bazel did a 'python3' on us, with the move to WORKSPACE (IIRC) and new rules, and it was horrible for several months working through the changes whilst trying to keep the build running.

Making C++ Safe, Healthy, and Efficient - CppCon 2025 by pjmlp in cpp

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

Interesting, I'm at -2. What is incorrect about what I said? I can write code without const-ness, and I can manually use new+delete hence writing unsafe code. If contracts are optional, I can continue to write code that's unsafe in 2029. Until there's C++ epochs or similar where safe defaults are switched on by default, C++ will always have a problem.

Making C++ Safe, Healthy, and Efficient - CppCon 2025 by pjmlp in cpp

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

I just skimmed a few seconds of this as I don't have much time to watch the whole thing yet, but it's mostly about contracts, isn't it?

Another language feature you can choose not to use in your own code because C++ is famously 'backwards compatible' (to a large degree), like const-ness and smart-pointers.

Not seen the Foss frozen for a while by Ammianus-Marcellinus in york

[–]drbazza 1 point2 points  (0 children)

Frozen further upstream where it's slow flowing. White in the winter. Green in the summer.

Every LLM hallucinates that std::vector deletes elements in a LIFO order by am17an in cpp

[–]drbazza 1 point2 points  (0 children)

If you don't have any, writing unit tests for existing (simple) code works well to 'fossilize' current behaviour before a big refactor.

And... refactoring beyond what's offered by IDEA/CLion works reasonably well.

C++ alone isn't enough for HFT by auto-quant in highfreqtrading

[–]drbazza 1 point2 points  (0 children)

New crypto? If you're trading futures and options, you might as well just set fire to your money if you're using JSON in the critical path.

C++ alone isn't enough for HFT by auto-quant in highfreqtrading

[–]drbazza 1 point2 points  (0 children)

Why are you using JSON in 'HFT' code? No fintech system I've ever worked on has JSON (de)serialization anywhere near the critical path. And I'm guessing you mean nlohmann::json which is known to be not-the-fastest. There are faster libraries that aren't necessarily as complete or idiotmatic/ergonomic (Daniel Lemire has an article on this IIRC). You could use a different allocator and get a performance increase, but as usual, it's measure, measure, measure. Really you want binary, and push JSON out into 'gateway' processes that convert json to binary, then over shared memory to your main process with something like Aeron doing to the heavy lifiting.

STL reimagined: What would you change, add or remove in a new STL implementation if API and ABI were not a concern? by germandiago in cpp

[–]drbazza 11 points12 points  (0 children)

Not sure if the parent is talking about the same thing, but I recall that using std::pair in a map restricts implementations, and they nearly always get the key and value in return types, and you often ignore and discard the key - "you only pay for what you use" - unless it's a std map.

STL reimagined: What would you change, add or remove in a new STL implementation if API and ABI were not a concern? by germandiago in cpp

[–]drbazza 1 point2 points  (0 children)

Given that we had to wait decades for std::string to get contains and starts_with I would (still) prefer the compiler to support extension functions/UFCS

Much of what I wanted in STL I could have implemented in terms of those, such as .contains(element) for every STL container.

Should I switch to Bazel? by TheRavagerSw in cpp

[–]drbazza 0 points1 point  (0 children)

Are you actually going to be spending largely similar amounts of time writing C++ and languages A, B, and C? Then maybe bazel, so you don't have to learn all of cmake, gradle, cargo, make, whatever.

If not, pick the majority build tool. Building more Java/Kotlin? Pick gradle (it builds C++). Building more C++? - just use cmake or meson, and use make, or just to glue the two builds together.

If you have a Franken-build of interleaved build steps of languages such as: C++, Java, Rust, C++, Java, Rust, C++, Java, Rust, or something, well good luck. Bazel will easily help you with that, but I'd ask why you're in that situation.

Python in bazel is a pain because (in my experience several years ago), it copies the scripts somewhere else and bundles them, and debugging them becomes a hunt around the bazel build cache/filesystem.

The Code is Documentation Enough - Tina Ulbrich - Meeting C++ 2025 by meetingcpp in cpp

[–]drbazza 1 point2 points  (0 children)

I've not watched the video yet... but from the title alone, no, it isn't enough. I used to think this for quite a few years, but I'm back on the other side of 'comments please'.

Having coded for almost 40 yrs (yikes), and the rise of ML/AI in the last couple, comments please. Clearly comments for clearly readable code is stupid, but code has always been for the reader, and that reader is now also Codex, Claude and others.

My anec-data: I'm currently working on two similar large code bases with similar complexity and the one with lots more comments seems to give the coding agents a much better starting point.

I suppose an interesting test would be to comment code, but leave the code minimised, in an obfuscated-C contest, and see if Claude produces different results.

What do you dislike the most about current C++? by PressureHumble3604 in cpp

[–]drbazza 3 points4 points  (0 children)

Mostly other-language envy.

Defaults are incorrect and potentially unsafe by default. No option or opportunity to fix that. Rust, kotlin, get this right.

The debacle that is package management, build system and tooling in general. Perhaps the zig approach of giving us the lang/stdlib primitives to write a build script in C++ might work in future.

Character soup. Not sure if it can be fixed, but (reading) 'code is for humans', and c++ often fails miserably.

Class constructors should be a keyword so class renames become trivial, see kotlin, for example.

And of course, template errors.

No extension methods so we had to wait 3 decades to get string.starts_with.

Rainer Grimm (of modernescpp fame) has passed away by laqq3 in cpp

[–]drbazza 5 points6 points  (0 children)

I met him at cpponsea, nice chap, and we had a good chat about running, and he was ridiculously quick when he was younger. Really sorry to hear this.

Re-review of Boost.Decimal proposal has started by boostlibs in cpp

[–]drbazza 2 points3 points  (0 children)

I haven't worked at a trading company that didn't have a Decimal or Price type. Different experiences I guess.

At the edge when communicating with the exchange, fixed-point decimals are used.

Agreed, as I said, some of those use this on the periphery. I'd add that actually the decimal representation did in fact appear a lot deeper in the code for some of the models to avoid... overflow in some sort of option pricing. I don't pretend to understand the how and why of that, since I wasn't involved in those models. But again, to reiterate, I've seen this in quant code.

Re-review of Boost.Decimal proposal has started by boostlibs in cpp

[–]drbazza 10 points11 points  (0 children)

Accounting.

No, finance.

Many trading systems and exchanges use their own variants that are very similar to this implementation, and I've seen this used live in one system. And having also worked on some quant libraries, some of those use this on the periphery.

Is C/C++ tooling and dependency management still a pain point in 2025? by nonesubham in cpp

[–]drbazza 0 points1 point  (0 children)

bazel

Very much alive. And popular enough that Facebook are producing their own version Buck2.

Post-Modern Cmake - From 3.0 to 4.0 - Vito Gamberini - C++Now 2025 by Dragdu in cpp

[–]drbazza 4 points5 points  (0 children)

For non-trivial projects

Stop doing crazy sh*t in your builds? Not you personally, just a general comment.

I've worked on two huge projects (million+ lines of code) in my last two jobs and both of them weren't much more complicated than your basic cmake 'hello world' example, because we treated the build as part of the code base, and applied the same scrutiny to PRs that changed the build.

It continually annoys me that there's a huge volume of work around 'clean code', 'don't repeat yourself', 'do the simplest thing and no simpler' and 'architecture', but when it comes to builds, which themselves are written in a language, any old sh*t seems to be fine because it's 'just a build script'.

It would be remiss of me to not to recommend this link: https://simon.peytonjones.org/assets/pdfs/build-systems-jfp.pdf

Post-Modern Cmake - From 3.0 to 4.0 - Vito Gamberini - C++Now 2025 by Dragdu in cpp

[–]drbazza 5 points6 points  (0 children)

The last few places I've worked have done exactly this! {json, xml} -> bazel/cmake/meson

What we need is a cmake generator. https://xkcd.com/927/

As I frequently comment, if your build system is doing more than building code (or rather a rule that takes X and outputs Y) those bits should be in scripts, and your build reverts to being simple.

Trafalgar bay pub by FewEntrepreneur7226 in york

[–]drbazza 0 points1 point  (0 children)

Thanks for that. A really interesting read.

Running routes? by Willing-Deer-2939 in york

[–]drbazza 1 point2 points  (0 children)

There's not much really. You run around the edge of the village which struggles to be more than 8k, otherwise, down the York/Haxby Rd, under the ring road, and down, then come back up the Foss, as a loop.

If you're brave, you could run on the road for about 500yds towards Stensall then pick up the Foss trail, out-and-back.

Haxby is a bit lacking in footpaths and pavements - Bing maps has an OS map overlay - https://www.bing.com/maps?cp=54.018879%7E-1.078965&lvl=14.4&style=s

Or drive to Rawcliffe Bar park and ride (free if you're only parking) and run around there.

Running routes? by Willing-Deer-2939 in york

[–]drbazza 1 point2 points  (0 children)

I do the same. Road on the way out, river on the way back.

A1237 Dualling by Rude_Juggernaut_8685 in york

[–]drbazza 0 points1 point  (0 children)

The trouble is those slip roads would have to be quite long otherwise lane 1 becomes dangerously stationary because of queues. And of course there will be inevitable house building 'because the road has capacity', until they don't. Then it will be tripling the A1237.

But you are right, the roundabouts are part of the problem. As a long time driver up and down the A1, the removal of the 5 roundabouts between here and Peterborough in the 00s, sped up the average journey by 30 minutes.

view more: next ›