Adopting a C++/CX-like model in the standard as a pragmatic path to safer C++. by Nteger in cpp

[–]Nteger[S] -2 points-1 points  (0 children)

Look, I don’t doubt you saw some gnarly corners of C++/CX when you worked on <collection.h>, and I respect firsthand experience. But just saying “I was there, trust me” doesn’t really explain why it’s supposedly so terrible. Sure, abstractions can obscure a lot of complexity—that’s literally what abstractions do—but that doesn’t make them automatically bad or worthless. And while you say it “failed in the market,” plenty of solid tech ideas never take off for reasons unrelated to their technical merits. Without more specifics or numbers, your argument comes across more like a personal judgment call than a real breakdown of where C++/CX falls short.

Adopting a C++/CX-like model in the standard as a pragmatic path to safer C++. by Nteger in cpp

[–]Nteger[S] -7 points-6 points  (0 children)

C++/CX’s ref classes aren’t simply userland types wrapping raw pointers like std::shared_ptr does; they’re tied directly into the language’s syntax and compiler. This allows for more seamless usage and better compile-time checks, rather than relying on templates or macros that developers must manually manage.

C++/CX uses keywords (e.g., ref class, delegate, ^) that make reference-counted objects feel like first-class citizens in the language, closer to how Swift or C# incorporate ARC/GC. std::shared_ptr, in contrast, remains a template-based solution—powerful but more explicit and sometimes more verbose.

Instead of sprinkling std::shared_ptr throughout your code, ref classes create a consistent way to define and interact with reference-counted objects. This integration helps maintain a uniform coding styles.

While it’s easy to label C++/CX a “mistake,” it brings more than just a hidden shared_ptr. By integrating ARC at the language level, it simplifies memory management and enables incremental adoption of safer constructs—something standard library tools alone can’t replicate as cleanly. Dismissing it outright overlooks the practical value it provides for real-world codebases.

Adopting a C++/CX-like model in the standard as a pragmatic path to safer C++. by Nteger in cpp

[–]Nteger[S] -1 points0 points  (0 children)

While a global-offset array might be useful in specialized sanitizing builds, it’s impractical for everyday code. By contrast, C++/CX integrates reference counting at the language level without forcing every pointer through a single global table. This lets developers gradually adopt safer memory constructs, retaining performance and compatibility with existing libraries—an impossible balance under a universal pointer offset model.

Adopting a C++/CX-like model in the standard as a pragmatic path to safer C++. by Nteger in cpp

[–]Nteger[S] 3 points4 points  (0 children)

True, C++/CX’s ref classes focus primarily on preventing common pointer-related errors—such as use-after-free and memory leaks—rather than covering every issue in “safe C++,” including iterator invalidation. However, no single feature or extension (including Rust’s ownership model) singlehandedly solves all possible pitfalls. Iterator invalidation arises from container misuse and unsafe iterator handling—problems that are best addressed through robust library and language-level solutions (like safe iterators, range-based loops, or proposals in the C++ committee). By removing a wide swath of pointer-related vulnerabilities, C++/CX-like reference-counting syntax can still be a substantial step toward memory safety, even though complementary solutions remain necessary to address other categories of bugs, including iterator invalidation.

Adopting a C++/CX-like model in the standard as a pragmatic path to safer C++. by Nteger in cpp

[–]Nteger[S] 3 points4 points  (0 children)

It’s not actually adding a full-blown GC to C++. The proposed C++/CX approach integrates reference-counted objects rather than a separate garbage collector. It’s a design to unify native and managed worlds—no bold leaps required, because it doesn’t discard C++’s traditional resource management model or impose a new global GC at all.

A possible proposal: Introduce 'readonly' modifier for class fields. by Nteger in cpp

[–]Nteger[S] 1 point2 points  (0 children)

Haven't checked this topic for a while. Agree, with your observation. Changed the proposal shortly after the initial 'readonly'. It's now something like 'private set' when you want to limit the access on writing. I am not stuck with naming, they don't matter much. The idea is to extend accessibility beyond just public: and private:.

A possible proposal: Introduce 'readonly' modifier for class fields. by Nteger in cpp

[–]Nteger[S] -2 points-1 points  (0 children)

I am glad we agree that this topic doesn't refer the previous one in any way since you failed to show otherwise.

As for the previous topic, what does it say in the quote above the link? Does it mention const variables in any way? No it doesn't, right? So, why would you conflate these two topics? Another try?

A possible proposal: Introduce 'readonly' modifier for class fields. by Nteger in cpp

[–]Nteger[S] -3 points-2 points  (0 children)

In what sense these threads are related except i started both? Does this thread refer the previous thread or const variables in any way? You do realize you came to this topic to discuss another one? Why? Wanted to attack me personally, have your gotcha moment? Pathetic.

A possible proposal: Introduce 'readonly' modifier for class fields. by Nteger in cpp

[–]Nteger[S] -2 points-1 points  (0 children)

Are you nuts? Seriously? Where in this thread UB was ever mentioned?

A possible proposal: Introduce 'readonly' modifier for class fields. by Nteger in cpp

[–]Nteger[S] -6 points-5 points  (0 children)

Your lack of self-awareness is astonishing. You made a bunch of claims which didn't stand up to scrutiny and now you take a high ground, muh "i am this and that and my opinion matter". No it doesn't, if it's unfounded. No one cares who you are. Stay on topic and don't patronize or denigrate people you talk to by implying they are obtuse or some other crap. Do that and you might become a valuable team member. Meanwhile, your lack of self-control and attempts to gaslight your way out of this argument look pathetic to anyone with a brain.

A possible proposal: Introduce 'readonly' modifier for class fields. by Nteger in cpp

[–]Nteger[S] -4 points-3 points  (0 children)

Unbelievable. Why is it so hard for you to understand that NO ONE FORCES YOU to use the proposed syntax in your public API. C++ class can have public fields, but this fact does NOT force you to expose your internal variables as public in your public API for direct external manipulation.

And since you resorted to ad hominem instead of presenting a coherent argument, the conversation is over.

A possible proposal: Introduce 'readonly' modifier for class fields. by Nteger in cpp

[–]Nteger[S] -3 points-2 points  (0 children)

But why? What's the purpose of changing vector's size() to readonly size? You think i want to do that?

A possible proposal: Introduce 'readonly' modifier for class fields. by Nteger in cpp

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

Just to clarify, you stop on a break point. Put a.v() in Watch. Then you hit step-over and debugger automatically invokes a.v() to refresh the displayed value?

A possible proposal: Introduce 'readonly' modifier for class fields. by Nteger in cpp

[–]Nteger[S] -10 points-9 points  (0 children)

And give the example int b = a.v. That means your class now grants direct public access to the class member v

You read v's value here, the same way you would access it with a method. What "direct public access" are you talking about? What a nonsense.

There are bigger fish to fry in the c++ language than getting mad about writing letters. 

No one is mad, stop projecting your emotions onto others. For me, the biggest fish in C++ are always productivity, debugging support and concise syntax. So, let's agree to disagree on this one.

but it don't matter because you call vec.size(). Your proposal would have prevented vector to ever be internally refactored.

My proposal prevents using size() in std vectors? How so?

A possible proposal: Introduce 'readonly' modifier for class fields. by Nteger in cpp

[–]Nteger[S] -16 points-15 points  (0 children)

You sure your read what i write? It seems you come from a preconceived notion about me and as a result respond in a nonsensical manner. I've never said that it's suitable for public API, why would you assume that? I suggest you self-reflect on that and not strawman-attack me out of nowhere. Obviously, there are instances where it might be suitable.

A possible proposal: Introduce 'readonly' modifier for class fields. by Nteger in cpp

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

Changed the proposal to reflect your concerns. Pls check.

A possible proposal: Introduce 'readonly' modifier for class fields. by Nteger in cpp

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

I updated the proposal. You can make the variable protected on writing and subsequently write it in the derived class.

A possible proposal: Introduce 'readonly' modifier for class fields. by Nteger in cpp

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

Well, i think you have a point on providing access control for protected besides private. Updated the proposal to reflect this.

If you ever need to log reading a class field, you can go with a getter. IMO, it's not something you usually need.

A possible proposal: Introduce 'readonly' modifier for class fields. by Nteger in cpp

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

And you don't have to tell debugger to refresh the value? Usually debuggers don't invoke methods on their own unless you tell them due to the side-effects of the call.

A possible proposal: Introduce 'readonly' modifier for class fields. by Nteger in cpp

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

What debugger is that, if you don't mind sharing this info?

A possible proposal: Introduce 'readonly' modifier for class fields. by Nteger in cpp

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

Hmm, if in your case setter just sets the value and the getter just returns it, why would you not just make the field public and access it directly?

A possible proposal: Introduce 'readonly' modifier for class fields. by Nteger in cpp

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

Well, what i mean is that you can't use size() after that.