BB_C @ BB_C @programming.dev

Posts

2

Comments

91

Joined

2 yr. ago

What are your thoughts on oop?

I don't like it. Reasons are well documented by others if you look for them.

I also wrote that part half-jokingly, and as a way to intrigue people to read until that part. And now you called my bluff 😶

The most important part of curl is the library, not the CLI tool. And the TLS backend is very much relevant due to varying features supported, different licenses involved, and varying levels of ease when it comes to building and distribution.

That's when you're providing binaries. Otherwise, you would have to be wary of potential compatibility issues with libcurl packages provided by different Linux distributions for example.

See CURLOPT_ECH for a recent and still evolving example of this.

Another huh from me. Or maybe I'm missing something, because this should all be obvious.

The source of the standard library is a rustup component that everyone should have installed. As for crates, you don't have to manually download any sources. Just add the crate as a dependency, and jump around definitions as much as you like. You can remove the dependency later if you decide to not use it.

this wasn’t easy for me to find

Huh! This is the internal ExitCode, and it's two jump-to-definition calls away. The first to get to the public type definition, and the second from the public type's struct field to the private type.

ExitCode is a struct, therefore it behaves like a type with many fields which define the types contained in the struct.

That's a bit too off. structs in rust are product types. A struct may define zero or more fields. And fields can be named or not. if not, such structs are called tuple structs.

In the doc page, if you clicked on source, it would have taken you to the definition.

  rust

    
pub struct ExitCode(imp::ExitCode);

  

That's a public struct with one unnamed private field. The type of the private field also happens to be private/internal.

As for why, usually the purpose is providing type safety, a unified interface,... etc. Notice how for example a windows-only extension trait is implemented that allows converting raw u32 exit codes into ExitCode.

So now you have exit codes possibly sourced from u8 or u32 values depending on the platform. And you need a safe unified interface to represent them.

I hope that's an enough starting point.

I would move all struct members from Foo

<false>

into a “new” Foo

<true>

and return that?

Yes... if you don't define Drop for Foo.

If you do, then you will have to either use mem::take()/mem::replace() with each field, or if you don't mind unsafe {}, you can just do a trivial transmute. Justunsafe { transmute(self) } should work.

I'm stating the obvious here, but if you have ownership at the time of conversion, then you can just change the type, you don't have to use dyn (a la impl Foo<false> { fn into_debug(self) -> Foo<true> {} }). That may require some code restructuring of course.

Yeah, I got that.

I'm asking what would be the benefit of not using a single error enum for all failure reasons?

Later: short summary of the conclusion of what the committee didn't do (read 307 minutes)

Fixed that for you.

If you read the post, you will see it explicitly stated and explained how the committee, or rather a few bureaucratic heads, are blocking any chance of delivering any workable addition that can provide "safety".

This was always clear for anyone who knows how these people operate. It was always clear to me, and I have zero care or interest in the subject matter (readers may find that comment more agreeable today 🙂 ).

Now, from my point view, the stalling and fake promises is kind of a necessity, because "Safe C++" is an impossibility. It will have to be either safe, or C++, not both, and probably neither if one of the non-laughable solutions gets ever endorsed (so not Bjarne's "profiles" 😁), as the serious proposals effectively add a non-C++ supposedly safe layer, but it would still be not safe enough.

The author passionately thinks otherwise, and thinks that real progress could have been made if it wasn't for the bureaucratic heads' continuing blocking and stalling tactics towards any serious proposal.

I’ll wait for the conclusion of what the C++ committee does

🤣 🤣 🤣 🤣

use-case?

It’s quite simple. Just remove the permalink field! If you are calculating it then no need to store it in the struct.

This is inefficient. It should be the other way around. Remove base_url and rel_permalink, and store permalink and the rel_permalink offset.

That way, you can get a zero cost &str for any of the three.

This is neither news, nor majorly relevant. Having rustc_codegen_gcc as a rustup component is going to be way more relevant, and is much closer to delivery, just to give an example.

The post itself (not the content of it) appearing on the official blog was sort of pleasantly surprising (brought tears to my eyes, i tell ya). Hopefully that was a result of maturity, rather than external pressure.

Is this going to be re-posted every month?

Anyway, I've come to know since then that the proposal was not a part of a damage control campaign, but rather a single person's attempt at proposing a theoretical real solution. He misguidedly thought that there was actually an interest in some real solutions. There wasn't, and there isn't.

The empire are continuing with the strategy of scamming people into believing that they will produce, at some unspecified point, complete magical mushrooms guidelines and real specified and implemented profiles.

The proposal is destined to become perma-vaporware. The dreamy guidelines are going to be perma-WIP, the magical profiles are going to be perma-vapordocs (as in they will never actually exist, not even in theoretical form), and the bureaucracy checks will continue to be cashed.

So not only there was no concrete strike back, it wasn't even the empire that did it.

systemd

Interesting. So they did it two years ago for the lols.. i mean for the u8"😀"s...which wasn't even really needed as one of the PR comments pointed out.

Yes, the mission creep is so bad the shit show that is systemd has emoticons.

Multi-threading support

Who stopped using pthreads/windows threads for this?

Unicode support

Those who care use icu anyway.

memccpy()

First of all, 😄.
Secondly, it's a library feature, not a language one.
Thirdly, it existed forever in POSIX.
And lastly, good bait 😄.

whats so bad about Various syntax changes improve compatibility with C++

It's bad because compiler implementations keep adding warnings and enabling them by default about completely valid usage that got "deprecated" or "removed" in "future versions of C" I will never use or give a fuck about. So my CI runs which all minimally have -Wall -Werror can fail with a compiler upgrade for absolutely irrelevant stuff to me. If it wasn't for that, I wouldn't even know about these changes' existence, because I have zero interest in them.

Those who like C++ should use C++ anyway. They can use the C+classes style if they like (spoiler alert: they already do).

I can understand. But why would you not use newer C versions, if there is no compatibility with older version “required”?

Because C doesn’t exist in a vacuum, and Rust exists. Other choices exist too for those who don't like Rust.

My C projects are mature and have been in production for a long time. They are mostly maintenance only, with new minor features added not so often, and only after careful consideration.

^{Still interested in knowing what relevant projects will be using C23.}

That's good and all, but we all explicitly pass -std=gnu99 (or -std=c99 if you don't care about MSYS2 compat) in our build scripts buddy 😉

Okay, maybe not all all. But you get the idea.

Are there any relevant projects who use the increasingly C++-infested newer versions of the language?

Correct link without /edit/: https://github.com/Nutomic/ibis/releases/0.1.2

With hyper-threading and preemption in mind, maybe it's concurrency all the way down 😎 . But we should definitely keep this on the down low. Don't want the pesky masses getting a whiff of this.

🤣

I don't know, and I don't want to get personal. But that's usually a sign of someone who doesn't even code (at non-trivial levels at least), and thinks programming languages are like sport clubs, developers are like players contracted to play for one and only one club, and every person in the internet gantry need to, for some reason, pick one club (and one club only) to be a fanboy of. Some people even center their whole personality around such fanboyism, and maybe even venture into fanaticism.

So each X vs Y language discussion in the mind of such a person is a pre-game or a pre-season discussion, where the game or season is an imaginary competition such people fully concoct in their minds, a competition that X or Y will eventually and decidedly "win".

Maybe that was an exaggeration on my part. Some junior developers probably fall into these traps too, although one might expect, or maybe hope, that their view wouldn't be that detached from reality.

I'm hoping to finally finish and send out a delayed new release for one of my older and mature CLI tools this weekend. It's written in C btw 😄