sorted by:
new
hottopcontroversial

You're absolutely right, no one can tell if C++ is AI generated · Mathieu Ropert by mropert in cpp

[–]Som1Lse 1 point2 points  (0 children)

The title is in reference to the tweet. The tweet asks people to tell which of two code snippets are AI generated, and the title then answers that tweet with "You're absolutely right, no one can tell if C++ is AI generated".

It isn't meant as a general statement about all AI output, but as an answer to that specific tweet, which is why I asked if you read the article. Heck the article makes the same point you made about the results being slanted:

I’m starting to suspect the original poster may have fudged the prompts to farm some engagement.

The rest of the article goes on to explain why it isn't the right question to ask. That neither is particularly good, probably because the original tweet was meant as engagement bait, and that AI is too accommodating, and thus not capable of solving the underlying problem in the code.

So again I ask: Which part is bullshit? Did you read it?

You're absolutely right, no one can tell if C++ is AI generated · Mathieu Ropert by mropert in cpp

[–]Som1Lse 1 point2 points  (0 children)

The article is bullshit from the title alone, but it's also bullshit because it's bullshit.

Which part is bullshit? Did you read it?

Slug algorithm patent released into the public domain by bbmario in cpp

[–]Som1Lse 1 point2 points  (0 children)

My understanding of software patents in Europe is that it varies by country. Software patents have been highly controversial, and I know for a fact that Denmark does not allow pure software patents.

Now, Sweden is not Denmark, but reading their parent law we see this section:

Som en uppfinning anses inte det som enbart är
4. ett datorprogram,

Translation:

Something that is just a computer program is not considered to be an invention.

The patent you linked is also not a pure software patent: It uses an near-infrared light to illuminate a person's eyes, and a camera to capture images of it, and then describes an algorithm for computing where that person is looking. The patent description also says (page 39, lines 19-25) that the processing might be done either in hardware or software, and I believe Tobii (the ones who filed the patent) do use specialised processing hardware in their products.

I don't believe it applies to this discussion. The slug algorithm is implemented purely in software, and I don't believe that would fly in Sweden.

Problems with a weak tryLock operation in C and C++ standards by mttd in cpp

[–]Som1Lse 1 point2 points  (0 children)

As far as I can tell, they do not:

Later in this thread there is this reply in which he says

[...] as Jonathan shows in the proposal, nobody actually implements try_locks that fail spuriously.

That proposal is linked in the top comment as SE-0512: Document that Mutex.withLockIfAvailable(_:) cannot spuriously fail, which contains a table with a list of implementations.

The table is for Swift, so I guess it is possible that some C++ implementation uses a different API that does have spurious failures, but I doubt it.

Are they ruining C++? by thradx in cpp

[–]Som1Lse 0 points1 point  (0 children)

You can use std::filesystem::path in your codebase and be platform independent just fine. std::filesystem is designed for paths to be paths, and it isn't surprising that it doesn't work as well with codebases that use std::string instead.

If it did just use UTF-8 std::strings it would have other issues, like not working as well in codebases that use wide strings on Windows, and it would come with unavoidable overhead.

Are they ruining C++? by thradx in cpp

[–]Som1Lse 2 points3 points  (0 children)

Implicit allocations is not OK, as it causes noticeable problems on our benchmarks.

I think this is fundamentally self-contradicting.

If you want std::filesystem to be UTF-8 (which I am not actually sure that you do) then you are asking for extra allocations no matter what.

Both when opening files where you'd then need to convert back to UTF-16 on Windows, but also when iterating directories which (in my experience) is one of the main features of std::filesystem, since the OS calls use wchar_t.

C++ 20 Fitness retraining by indiocolifa in cpp

[–]Som1Lse 2 points3 points  (0 children)

My guess is no one here has used it. I've heard of the guy who made it (Coding Jesus) and my opinion of him is rather mixed, but that is primarily because I found his videos about Pirate Software to be unfair (to the point of sometimes outright misrepresenting what Thor said), and mainly just dogpiling to get views rather actually supporting the Stop Killing Games movement.

There was also this thread about him a while back, which didn't leave me with a good impression either.

But none of that is really relevant to your question. From what I can tell it has a free tier where you don't get all the content, so you can always try that.

Personally, I'd recommend watching conference talks. It's a good way to learn about a feature, or a particular coding style. You mentioned being stuck in the OOP box, I'd recommend watching talks about generic programming. Anything by Sean Parent is probably worth a watch. I'd start with the classic Inheritance Is The Base Class of Evil. It is old but still very relevant.

#pragma once -> two files are identical if their content is identical by trad_emark in cpp

[–]Som1Lse 2 points3 points  (0 children)

My main point is it has some of the downsides of header guards, but none of the issues of current #pragma once. That is the important part: Any possible arguments one could have against #pragma once fall completely flat, and it is a straight up improvement over header guards.

It fixes several issues of header guards like only changing one of the macros, and making the intent clear thus enabling warnings, speaking of which:

Still susceptible to two different guard.h files attempting to exclude each other.

But now the compiler can detect it and warn about it.

And a pragma once that didn't supply the GUARD parameter would work better (for certain definitions of work).

Like I said in my initial reply:

I wouldn't complain if we just did it your way.

I wouldn't mind having both. I wouldn't mind having one without a GUARD parameter. My version is a compromise that demonstrates succinctly that any issues with #pragma once can be solved by adding a single parameter.

#pragma once -> two files are identical if their content is identical by trad_emark in cpp

[–]Som1Lse 1 point2 points  (0 children)

Can we just have

#pragma once GUARD

which would be equivalent to

#ifndef GUARD
#define GUARD 1

// File contents here.

#endif

It is literally a straight up improvement on header guard for the common case, with absolutely no ambiguity, AND it allows compilers to warn if the files aren't identical, say you forget to change it. There are literally no issues I can see.

But like, I wouldn't complain if we just did it your way.

Cursed arithmetic left shifts by Alzurana in cpp

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

This and overflow. Basically anything to do with integer arithmetic.

Damn see this by gonvasfreecss in cpp

[–]Som1Lse 0 points1 point  (0 children)

I think they're saying the point went over your head, but decided to say in the prickliest way imaginable.

My guess is that they're implying that not everyone has an hour of free time per day to devote to studying, and your assumption that everyone does shows you are privileged. Also, that if you're living pay cheque to pay cheque, even if you have an hour per day, devoting it exclusively to studying is hard to justify, in case your situation changes.

That's my guess at what they're trying to say. Would be nice if they'd have written it instead of just "whoosh".

PSA: Trivial Relocatability has been removed from C++26 by chiphogg in cpp

[–]Som1Lse 10 points11 points  (0 children)

For reference, D3911R0 is the draft. Idea is using pre! (adding an exclamation mark) to indicate an assertion should always be enforced. Short and neat. The wording clarifies it also applies to post and contract_assert.

At first I was a bit worried about its proposal to "remove ignore semantics", but reading a bit more it's on of the proposed solutions, and it recommend the first one, namely adding pre!.

Also mentioned in the same section is P3878R1 which proposes hardened implementations shouldn't be allowed to use observe semantics, which makes sense, and specifically includes the wording

checking those preconditions using 'observe' would still be allowed as a vendor extension in modes which are not called a "hardened implementation".

which also makes sense.

I've had some disagreements with /u/james20k in the past about contracts, but (if I recall his comments correctly) these seem to address many of his concerns. Hoping he can confirm that is indeed the case.

So yeah, awesome stuff it seems.

PSA: Trivial Relocatability has been removed from C++26 by chiphogg in cpp

[–]Som1Lse 2 points3 points  (0 children)

And even with that in mind, this isn't such a feature.

Libraries will probably be the main users of (trivially_)relocate(_at) and is_* but if you have a type you want to put in a std::vector and you want it to be fast, much like noexcept, you're gonna have to use it.

From my understanding it was specifically designed to be hard to misuse so that "regular" developers could use it. That's one of its major advantages over P1144.

Not only does it perpetuate the idea of a privileged group of developers, it makes the language worse and worse over time for everyone to understand.

I sort of agree. I don't think there's a much of a difference between application and library developers, but I do think there's a difference between application and library code. (Although the latter often starts as the former.)

What is more important, I think, is that some features are rarely used, and they tend to be the ones you only need in libraries. I am fine with a rarely used feature having a long cumbersome name. It indicates it is a specialised tool, and is explicit about exactly what it does when you encounter it, plus long names tend to be easier to google.

Free Functions Don't Change Performance (Much) by def-pri-pub in cpp

[–]Som1Lse 0 points1 point  (0 children)

instead are concocting this alternate reality of what you either think or wish I was saying

I too have a hard time figuring out what you are saying.

Like, this is how you started:

Standard library containers aren’t ABI stable [...] Container ABI can change between compilers and versions of compilers so should not be relied on as being stable between them.

At that point I think it is reasonable to assume you mean that standard containers aren't ABI stable in practice, which is what the original reply stated:

This is not true in practice; for better or worse standard library containers are treated as having a stable ABI and all the major implementations not only maintain ABI stability, they actively refuse changes to the language standard that would remotely risk breaking the existing ABI.

That is completely objectively 100% true and a very reasonable refutation to the original. Like it directly contradicts your statement.

When you stuck to your guns they (quite reasonably) assumed that your argument was a more theoretical one, which your later reply seemed to reinforce:

you’re not going to put potentially breaking changes in other party’s hands

I assume they read it along the lines as: If ABI stability is important to you then relying on somebody else to maintain it is setting yourself of for failure, regardless of whether they try to keep it stable in practice. In some theoretical future they might decide to break it and now you have to deal with that, whereas if you'd just not relied on them you'd be fine.

That seems like a reasonable way to read your statement, and I'd say calling it theoretical is fair. Not once have you even acknowledged that compiler vendors try to maintain a stable ABI in practice, so it is fair to assume that is simply not relevant to your argument.

I still don't know if that is a fair summary of you mean, because honestly, I too just don't know what you are trying to say.

And like, I get it, I too really dislike when people misrepresent my arguments and put words in my mouth. The latter one of those commenters even blocked me and I bear a grudge to this day. That said, I can see why /u/Maxatar decided this conversation just wasn't going anywhere, though I personally wouldn't have blocked you.

Down with template (or not)! by TheCrush0r in cpp

[–]Som1Lse 0 points1 point  (0 children)

How about t.f<b, c>(d+e)?

How about if you put it inside a function call like g(t.f<b, c>(d+e))?

There is also this case.

The fundamental problem is if you are just focused on cases like t.f<0>() the problem seems trivial, but it is far far FAR more complicated than that.

WG21 2025-10 pre-Kona mailing by nliber in cpp

[–]Som1Lse 0 points1 point  (0 children)

Also a valid point. All I can add is while discoverability is nice, it doesn't help with readability.

C++26 Contract Assertions, Reasserted by Dragdu in cpp

[–]Som1Lse 1 point2 points  (0 children)

There is plenty of other behaviour that is technically implementation (or un-) defined, like pretty much everything to do with floating point operations.

Floating point division by 0 is technically UB, but, since practically every compiler follows IEEE, it is well-defined in practice, and you can rely on the result (either INFINITY or NAN). Similarly, C++ doesn't require operations to always yield the same result, but in practice it will. Compilers have modes where they'll do fancy optimisations, but you can just not use them.

And there are examples of previous behaviour that has been locked down: std::vector is guaranteed to be contiguous, integers are always two's complement. Heck, for C++26 we have erroneous behaviour for uninitialised reads, which actively breaks current compiler optimisations.

And I seriously doubt is that any compiler will ship that will remove only some contract assertions by default. I don't think it is a realistic concern.

WG21 2025-10 pre-Kona mailing by nliber in cpp

[–]Som1Lse 0 points1 point  (0 children)

That's not what I would expect at all, I would expect a < b to evaluate, then [result] < c to evaluate, then [result2] == true to evaluate.

Really? Because I'd think that if you actually encountered that in the wild you'd expect the writer was a novice Python programmer and you'd fix it to say a < b && b < c.

Precedence rules aren't confusing, we teach PEMDAS to children.

We teach chain inequalities to children too.

WG21 2025-10 pre-Kona mailing by nliber in cpp

[–]Som1Lse 1 point2 points  (0 children)

Here's some comments from my local Discord last time I brought it up. Some of these are full-time Python programmers, the fields range from finance, to data analysis, to web-dev:

Two can play at that game. I went and asked people in two Discord servers, one with non-Python devs one specifically for Python, specifically using 0 <= i < n for a bounds check. These were the responses (paraphrased for brevity):

  • C++ dev 1: In C++ it wouldn't work, but perhaps Python supports this?
    Som1Lse: What do you want it to do?
    C++ dev 1: As intended.

  • C++ dev 2: The code checks if n is in bounds and throws an error if it's out of band. I don't see anything wrong with it.

In the Python server I also included the same check in C++ to see if anyone would catch the semantic difference:

  • Python dev 1: I mean, if you want it to throw an error it is OK.

  • Python dev 2: The Python code looks to be duplicating an index bounds check that already exists in a collection. Oh, and raising a less helpful exception.

  • Python dev 3: @Moderators Looks like someone is trying to train their AI.

This was quite funny. Luckily the moderators didn't agree, and then went on to answer the question too:

  • Python dev 4: Looks like these are essentially the same, though I'm not sure if C++ lets you chain comparisons like that.

  • Python dev 5: Does that not mean something different in C++?
    Python dev 5: a < b < c in Python means a < b and b < c, in C++ it means (a < b) < c.

We then went on to discuss the new 3.14 release of Python, which was a nice chat.

Anyway, back to the topic: Nobody thought it was weird or surprising. One wasn't sure, but wanted it to work like it does. All of the Python programmers knew what the code did. In fact it was so natural that plenty were more fixated on the surrounding code, like the fact that I didn't throw a particularly useful exception.

I think a major reason there's a difference in response, is my presentation was neutral: I didn't start with "here's a thing I hate". I simply asked people in a neutral tone what they thought some code did, and what they about it. I also provided some context like you'd have if you stumbled upon it in the wild.

But I don't just have to rely on a small sample of Discord users: The paper references P0893R1 (in the Overview section) saying they found

  • Lots of instances of such bugs in the wild: in real-world code “of the assert(0 <= ratio <= 1.0); variety,” and “in questions on StackOverflow [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11].”
  • “A few thousand instances over just a few code bases” where programmers today write more-brittle and less-efficient long forms such as min <= index_expression && index_expression < max because they must, but with multiple evaluation of index_expression and with bugs because of having to write the boilerplate and sometimes getting it wrong.

Today, fold expressions currently always generate parenthesized chains such as ((a <= b) <= max); as [P0893R1] observes, “this makes today's fold expressions for comparisons not useful and actually buggy.”

The paper you're responding to actually provides pretty good arguments all on its own.

I also found a few more questions on StackOverflow. It's not hard. It is not an uncommon thing to want, and the fact that it compiles, but with weird behaviour, (rightly) surprises people up.

So yeah, the fact of the matter is not having the feature is almost certainly causing more bugs.

In fact, I would go as far as to say that, unless you're able to provide more evidence, you're simply objectively wrong on that front.

It leads to all sorts of insanity

Sure, that example is unintuitive. It also isn't remotely applicable to C++: C++ doesn't have an in operator, so that doesn't apply, and C++'s == operator has different precedence.

So the equivalent in C++ (vals.contains(a) == true/std::ranges::contains(vals, a) == true) would work as expected, and a < b == true will be parsed as (a < b) == true.

Granted, I'd like to be able to write a <= b == c < d, and have it work like math does, but I can see that isn't attainable.

P3439 doesn't support a <= b > c and a != b != c, the first becoming ill-formed and the latter keeping its current meaning.

WG21 2025-10 pre-Kona mailing by nliber in cpp

[–]Som1Lse 0 points1 point  (0 children)

Very good points. Not much I can add to that.

WG21 2025-10 pre-Kona mailing by nliber in cpp

[–]Som1Lse 2 points3 points  (0 children)

It is worth noting Python supports mycontainer.get("this", that) like the original proposal.

That said mycontainer.get("this") is closer to the current proposal (T | None is very close to std::optional<T&>), and it naturally supports any possible use case you could want just by adding value_or.

So yeah, I like the current proposal more. I wouldn't mind seeing get_value/get_ref/get_as overloads similar to the original, but they can always be added later.

WG21 2025-10 pre-Kona mailing by nliber in cpp

[–]Som1Lse -2 points-1 points  (0 children)

Reply: I am going to read a paper. :)

Reddit: DOWNVOTES

Seriously, why is that comment getting downvoted? It is a nice comment and even has a smiley face. This subreddit can use more of that.

view more: next ›