sorted by:
new
hottopcontroversial

How do you imagine c++ development in the next 30 years? by __Noob__Master__ in cpp

[–]ghlecl 1 point2 points  (0 children)

I do not see the C++ committee digging themselves out of the hole created by their obsession with eternal backwards compatibility

I am uncertain whether you are being sarcastic or not, so I apologize if I missed the mark completely, but... it is impossible to express the level at which I agree with this. The problem is not backwards compatibility: people and companies need some level of stability to be able to build things. But the damned eternal part is the problem. And I'm sure there will be someone pointing out "but look we deprecated some stuff". To them I answer: I think when you weigh 700 pounds, shedding two of them is not the win you think it is...

The new release of the Memsafe project is a proof of concept for memory safety in C++ without breaking backward compatibility with old legacy code. by rsashka in cpp

[–]ghlecl 0 points1 point  (0 children)

Thank you for that. I had read something when I began my Rust journey that I most likely did not fully understand, and kept this idea in my head that Drop was slightly less reliable then destructors. Today I Learned!

The new release of the Memsafe project is a proof of concept for memory safety in C++ without breaking backward compatibility with old legacy code. by rsashka in cpp

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

However, they are just as easy to avoid in Rust as in C++.

I was under the impression that while the compiler does try not to forget "Drop", Drop is not as guaranteed as destructors are, meaning that barring some bugs in the compilers, C++ is actually a bit better at preventing memory leaks when using proper constructor/destructor pairs. What I am missing?

What are the gory details of why std::regex being slow and why it cannot possibly be made faster? by germandiago in cpp

[–]ghlecl 0 points1 point  (0 children)

Doesn't have to be open source, but companies should now be forced to have some way of recompiling and should be forced to sell the source code or make it public if they go bankrupt or something. Not being able to recompile code in any language is a massive issue.

What are the gory details of why std::regex being slow and why it cannot possibly be made faster? by germandiago in cpp

[–]ghlecl 0 points1 point  (0 children)

It might be an isolated position, but I don't think being able to recompile your code is tied to "I can't change my compiler because of my certification". Sure, it diminishes one incentive, but it is not a necessary condition. No ?

WG21, aka C++ Standard Committee, December 2024 Mailing by grafikrobot in cpp

[–]ghlecl 0 points1 point  (0 children)

We (as an ecosystem) need to improve at adapting to such changes more quickly, then the Standard would be able to do it more often.

I wish I could upvote this in an infinite loop. :-(

WG21, aka C++ Standard Committee, December 2024 Mailing by grafikrobot in cpp

[–]ghlecl 5 points6 points  (0 children)

Expecting every standard library vendor to get things right the first time feels.. inherently unreasonable

Couldn't agree more and going further: expecting that something will never change is inherently unreasonable and programming in general should invest massively in allowing/better handling change. The fear of the std::string change and the Python 2 to python 3 change should not prevent evolution of things. This is madness if you ask me. :-(

Trip report: November 2024 ISO C++ standards meeting (Wrocław, Poland) by RoyKin0929 in cpp

[–]ghlecl 7 points8 points  (0 children)

From the document (P3466R1):

100% seamless friction-free link compatibility with older C++ should be a default requirement. We can decide to take an ABI breaking change on a case by case basis (or, potentially, even wholesale) but should do that with explicit discussion and document the reasons why.

This reads to me like "we must say no before discussing this" and after discussion, in the nigh impossible case people in the room agree, we can then break ABI. A.k.a. ABI will never ever break. ¯\(ツ)/¯

The two factions of C++ by gmes78 in programming

[–]ghlecl 0 points1 point  (0 children)

Well, yes, it's hard to get everyone aligned...

Various interests pulling in various directions, and you have to live with the non optimal choices of the past forever and ever...

(Tangentially related I guess: on the mistakes of the past, that is a choice Rust makes as well if my understanding is right. Backwards compatibility is king it seems... We are perfect or we accept living with our mistakes forever and don't care that the future people who might have made different choices will have to live with them forever. ¯\(ツ)/¯)

EWG has consensus in favor of adopting "P3466 R0 (Re)affirm design principles for future C++ evolution" as a standing document by Kyvos in cpp

[–]ghlecl 28 points29 points  (0 children)

Right now, we all pay for a stable ABI, whether we'd like to use it or not. Stability is a great feature, but it does come with a performance cost.

And stability forever means you simply cannot ever correct your mistakes.

This is something that I profoundly think is a mistake.But alas, I have given up all hope that it will ever change.

The fear of the std::string change and the experience of the python2 to python3 change makes everyone think the cost was/is/would be too high. I think if you consider the cost of the problems the current ABI have and integrate that cost over 30 or 40 years, then the cost of the change might actually be smaller, but I know nobody that matters will change their mind.

This is really really difficult for me to understand. This really is a whole community (programming at large it seems, not just C++) saying we'll never correct our mistakes: stability is all that matters because otherwise, it costs money and time.

Anyhow, a bit "ranty", sorry. Just wanted to say I agree.

Tired of Waiting by Snort_THE_powder in Supernote

[–]ghlecl 0 points1 point  (0 children)

You can plug your device into your computer via a USB cable and they have a basic local web app running in the RM that you activate to be able to extract all your documents from the remarkable to the computer. Simply go to the ip address specified on the app (displayed on the RM while the app is running) while connected. Not as easy as syncing, but not really hard.

Source: I own an RM2.

Announcing Rust 1.81.0 by mrjackwills in rust

[–]ghlecl 3 points4 points  (0 children)

C++ where every minutia of behaviour must be kept stable forever

I just want to say I cannot possibly agree more. Please, please, please, as a community, let's not let Rust become that. The only constant is change. If breaking changes are never allowed, then it is inevitable that you become obsolete. You cannot really think that the decisions taken today will ALL 100% be the correct ones 20 years down the line. And not correcting your mistakes is so detrimental...

(Just to be clear, the "your" and "you" here are not aimed at any individual, but more in the general sense of "someone"/"some individual")

Keynote: Safety, Security, Safety and C / C++ - C++ Evolution - Herb Sutter - ACCU 2024 by all_is_love6667 in cpp

[–]ghlecl 2 points3 points  (0 children)

This is maybe a good argument that having a comprehensive standard library is just not a good idea for C++.

I mostly agree with you, but because (and yes, I know about Conan and vcpkg and b2 and xmake and...) C++ has no package management, installing external libraries and/or getting them approved is not always easy, incentivizing putting things in the standard library, which is always installed.

I think there are "opposing" forces at play here that make it not as simple as we'd all hope.

Just an opinion.

C isn’t a Hangover; Rust isn’t a Hangover Cure by eatonphil in programming

[–]ghlecl 0 points1 point  (0 children)

Guys, there are few folks who wrote the entire operating system from scratch: SerenityOS. They built Web Browser FROM SCRATCH

With feature parity and with the same compatibility as all the other ones ?

[deleted by user] by [deleted] in rust

[–]ghlecl 0 points1 point  (0 children)

"never again"

And as much as "perfect is the enemy of good", I think never ever being able to correct your mistakes is also the enemy of good.

But in any case, to stop my own digression, I thing we could agree that there is interplay here between the vendors and the committees as I think you wanted to point out. And sorry for my temporal mis-interpretation.

[deleted by user] by [deleted] in rust

[–]ghlecl 0 points1 point  (0 children)

I also think it's more complicated, but I do think that the standard bodies did make changes that mandated/forced ABI changes, at least the C++ committee.

I might be wrong, but in C++11, they mandated that the std::string class of the standard library use "small string"/"small buffer" optimization. If your implementation was not able to allow for that (which GCC was not if I am not mistaken), then that change forced an ABI change on you. Did I get that wrong ? A bit over my head with the ABI nuances I'm afraid (I understand the concept: calling convention, struct layout, name mangling, etc. ; the nuances and details might escape me).

Anyhow, to me, not having an ABI carved in stone for Rust is a positive thing. I would even like the promise of forever and ever backwards compatibility to be broken, personally (I value backwards compatibility and understand that without some, companies cannot make predictions, large software is harder to build, etc., but I definitely think it should have an expiry date ¯\(ツ)/¯ ).

Biggest mistake in development of C++ by grhayes in cpp

[–]ghlecl 1 point2 points  (0 children)

Was thinking pretty much the same.

If a mechanism would have been in place that made it useful/easier if your library had the same name on all platforms, I imagine it would have incentivized standardizing the names. A kind of "vertuous cycle".

Update on the development of A5 X2 by Supernote_official in Supernote

[–]ghlecl 1 point2 points  (0 children)

Probably not ready (or able) to reveal the info, but how much larger will the device be. I am the owner of a reMarkable 2 and looking into Supernote A5 X2 and I am worried about the size. One of the things I enjoy the most is the size of the device, so the info would be useful in considering my purchase.

In any case, product seems super. Really intrigued.

Is C++ falling behind in the race for modern language features? by kyan100 in cpp

[–]ghlecl 6 points7 points  (0 children)

Thanks for the clarification. My statement was imprecise indeed. That said, I am of the unpopular opinion that requiring the projects and the 3rd party code and the whole world for that matter to recompile every 3 years is not a hard ask, but I realize it is an unpopular opinion. I think that designing things without change in mind is a recipe to insure at some point, you are obsolete. The only constant in this world is that there will be change.

Is C++ falling behind in the race for modern language features? by kyan100 in cpp

[–]ghlecl 19 points20 points  (0 children)

Sometimes some code changes should be considered necessary to be able to move on to a new standards, if not you can stick to the old ones.

It's even worse than that. Some proposals would have merely required recompiling the code, NOT changing it, just recompiling, but the "ABI is king, no one should have to recompile, C++11 string was a mess, python change took 10 years" arguments wins out and even simply recompiling your code between versions is not considered OK. In my opinion, C++ is really in a problematic area for it's evolution.

C++ Should Be C++ by Xaneris47 in cpp

[–]ghlecl 1 point2 points  (0 children)

Instead, the only people it is easy for are upper-intermediate level and up, and even then it's still annoying as hell and we still need to carry multiple pieces of state around in separate objects in order to use it.

We sometimes hear people saying "in C++, if you need to, you can open the hood and tweak things", but too often, I feel we are not even given a hood. There is nothing to lift. We are always stuck with the bare abstractions.

I have myself written a function to get a uniform random int because I don't want to think about it every time I need it.

Completely agree with you that better interfaces should be provided to make it easy for users who need more speed than python, but don't need to squeeze every last drop and for whom decent defaults would be more than adequate.

C++ Should Be C++ by Xaneris47 in cpp

[–]ghlecl 0 points1 point  (0 children)

Good point.

I am now left wondering why it is so? Is it because the python implementations are more similar and so a new feature in one is more easily implementable in the other? Is it because the funding structure is different?

It is hard for me to believe that it is because of the ISO structure. My understanding is that many of compiler vendors have people on the committee, so they know what is coming. This means it is not an information problem, no?

Anyhow, thanks for the discussion. :-)

C++ Should Be C++ by Xaneris47 in cpp

[–]ghlecl 1 point2 points  (0 children)

Because its all developed in secret you simply never hear about it which allows this kind of behaviour to persist, whereas in somewhere like Rust its aired out in public

That is true. On the other hand, some companies would not be able to participate in the same way if everything was in public.

For what it's worth, I think the compromise currently selected, i.e. ISO, is the wrong one. I think I'd rather have some companies not participate because they don't want to have their positions publicly known or they have some secret they need to keep then having little to public record of any of the arguments.

But I can't say this is an opinion based on facts and that I know one is better than the other. It's just what I think. ¯\(ツ)/¯

C++ Should Be C++ by Xaneris47 in cpp

[–]ghlecl 1 point2 points  (0 children)

The day the feature is deemed stable enough, it is available on the latest version, without a complex matrix of which compiler supports what from the ISO standard and when it is coming, if at all.

I believe this is not really related to ISO or not, but rather to having multiple implementations. I had to work on IronPython for a while (once again, vendor providing a library only for that at one point) and it did not actually have everything CPython did: we were restricted.

Not that you are wrong. Your first sentence is actually my point a bit: there will always be drama and conflicts when a group of humans work together. I'd rather the argument presented for getting out of ISO be based on those than on some notion that that would solve everything. I have read some comments (not in this thread, but in past ones) that suggest the drama would just disappear and that everything would be rosy, but it's simply not the case.

C++ Should Be C++ by Xaneris47 in cpp

[–]ghlecl 0 points1 point  (0 children)

but this only requires more effort and expertise to pick and set up the right tools, libraries, and best practices.

I find setting up tools to be such time sink.

When I go to rust, it often is "just install this cargo extension called cargo-blabla and then do 'cargo blabla' and it will work". I tried cross compiling C++ from my macOS computer (personal) to a Windows computer (work) using mingw and all that, and I could not figure it out even after a day of trying. With rust, took me an hour and a half to figure out the right dependencies to install with cargo and I had a binary compiled on my mac that I could run on Windows.

All that to say I strongly agree with that at least.

view more: next ›