>>107504212
Sepples is just a clown show at this point, I wonder why anyone still willingly puts up with it.

>>107504212
I haven't used C++ since the 90s, before it was standardized. C++ smokers started the meme that inheritance is a mechanism for code reuse, which poisoned OOP for 20 years.

File: Copilot_20251120_164612.png (3.29 MB, 1024x1536)

3.29 MB PNG

>>107504212
I hope C++ dies in a pile of fire. They should take the Wirthian approach:
>Pascal (1970)Modula-2 (1978)Oberon (1986)Oberon-2Component Pascal
Instead of patching a broken system:
>C C++ C++11 C++14 ...etc... (complexity accumulation)

Wirth was like:
>This isn't pure enough, I'll start over

The C/C++ UNIX mindset is like:
>We must maintain backward compatibility at all costs

https://rentry.co/g7aofwhc

>>107504286
Because there is no choice. There is no alternative to c++.

>>107505762
based POSIX hater

>>107504212
>Obviously, with more teaching, the safety problems and complexity problems will go away.
virtually all of the safety problems go away in modern C++, i think the only one that doesn't is dangling references.
the complexity problem is never going away though.

>>107505762
>The [...] UNIX mindset is like:
>>We must maintain backward compatibility at all costs
Wrong, that's the corpo mindset.
Per your rentry article:
>Everything you open returns a typed handle (e.g., Socket, File, Process).
That's already the case. See the manual pages for the stat type, inodes, etc.
>not process-local ints
Those ints already are 64-bit opaque handles managed by the kernel.
Why are you complaining that they're scoped to processes?

>>107505842
this is the worst cope. why do you believe that anon?

>>107505762
>>This isn't pure enough, I'll start over
>everybody, drop whatever you were doing and start reimplementing everything from scratch is this purer language
>fuck you battle tested debugged impure code
don't be silly anon

>>107506589
> this is the worst cope. why do you believe that anon
Its an objective fact there is no alternative to c++. And by alternative I mean something which is compatible with C, but with more features than C. All other languages are second class citizens forced to use grotesque FFI.

>>107506589
What in modern C++ solves shared mutable references? What are string views, spans, and other views but an invalidation waiting to happen? No, modern C++ fixes only some of the safety issues. See https://www.circle-lang.org/draft-profiles.html

>>107506632
>And by alternative I mean something which is compatible with C, but with more features than C.
Objective-C, D, Swift, Zig, C3, the list goes on.
I don't interface with C very much at all in sepples, not in a way that isn't handled by the standard library of a language.

>>107506650
>What in modern C++ solves shared mutable references?
The only unsafe aspect is dangling references.
>What are string views, spans, and other views but an invalidation waiting to happen?
Again, dangling references.

So... yes. It's just dangling references.

>>107504212
C++ has caused no C alternative to crop up for years clearly that's the actual conclussion here anon

>>107504212
you have to let go of your write-once correctness obsession
if a program crashes, you fix the crash, if it has a bug - you fix the bug
it's ok, it doesn't happen so often that you need to invent a new language that fucks you in the ass every time you get dangerously close to introducing an error
>buh muh uhhh how do I know muh programmerino has no erroreninos
shhhh... it's ok... nothing is flawless... test a lot, run your code, use your programs, fix the bugs
and one day you'll notice there are no more bugs
it's ok baby, you can do it

>>107506831
this mentality indicates you don't do anything that actually requires high reliability, opinion discarded

File: AVT_Niklaus-Wirth_2831.jpg (49 KB, 431x496)

49 KB JPG

>>107506606
Anon, please. If your programming language becomes popular, that means more code will be written in the future. You need to address its issues as soon as possible, or you might end up with something like JavaScript.

>>107506850
I do, but before my code is shipped, it gets 90% branch coverage, goes through 2 static analyzers, CI with all flavors of ASAN, and 3 layers of manual QA
if you erase from a map somewhere while iterating it - it will be caught, and you'll just fix it, and you won't do that again, it's that simple

>>107506850
Memory safety is not sufficient for high reliability contexts, which anybody working in high reliability software already knows, so clearly you don't work in it either.
Safety is important in all contexts, and everybody who sells software has to have reliability in their product.
Your dismissal of him is hypocritical and nonsensical.

>>107506854
Based Wirth.
https://streamable.com/s8yhf4
https://streamable.com/oyvp12

Holy yap

>>107506941
Cutting off his dick and calling himself a woman was already hypocritical enough, the rest is unnecessary.

>>107504212
C++ doesn't require a lot of training.

>>107504212
No shit sherlock, we already know that Klaus is a moron, but not an imbecile like you.

>>107506854
>If your programming language becomes popular
>You need to address its issues as soon as possible,
This is an oxymoron. Or are you implying that Ritchie and Stroustrup is kinda morons?

>>107508584
>is kinda
saaaar

File: 1737165775674817.png (48 KB, 800x800)

48 KB PNG

>>107504212
Sorry but I'm still gonna use it, hehe. I'm gonna develop games in C++ and even use modern C++ features...!

>>107508610
>I got neither point or argument so ad homiem
This is serious conversation saaar

>>107508664
I missed the part where that's my problem.

>>107508584
>Or are you implying that Ritchie and Stroustrup is kinda morons?
Yes. Take operator precedence in C as an example, they knew it was broken but never fixed it when they had the chance (C89). Now, with so much more code, it's practically impossible to fix.
At some point, we must stop building software on a broken foundation.

>>107508718
Just remember operator precedence

>>107508718
>they knew it was broken
operator precedence is fine
>broken foundation
nothing wrong with the foundation

>>107508584
>Stroustrup
he is just trolling at this point

>>107508718
Sounds like you can't be asseed to use parenthesis to explicity say how you want operations to be resolved, which in itself is a bad coding practice

>>107508718
zoomie forgot PEMDAS?

>>107508913
>operator precedence is fine
No, bitwise operators have lower precedence than comparison operators..

a & b == c 
is
a & (b == c)

>>107509256
that's unfortunate, you'll have to use parenthesis in this situation

>>107504212
Lol thanks for posting the hourly #FILTERED thread zoomie.
We get it, you can't function without an internet hosted package manager for importing libraries.
Seethe.

>>107509256
you should always use parenthesis in compound operations anyway

>>107505762
>The C/C++ UNIX mindset is like:
>>We must maintain backward compatibility at all costs
C/C++ and Unix break backwards compatibility all the time. Ctrannies are just lazy about throwing away bad code and use backwards compatibility as an excuse for not fixing problems. They don't actually care about it. Backwards compatibility is also a good thing when the original design is good, but that doesn't apply to C/C++ or Unix.

>>107510495
yes, because of C's retardation

>>107505842
rust, zig, c3.
there are.

>>107506632
>I mean something which is compatible with C, but with more features than C
rust, zig, c3

>>107504212
>C++ Experts Don't Live In Reality
You're retarded. Kill yourself.

I don't think I've ever used anything newer than the original 1998 standard, and I make my living writing C++.

>>107512648
>>107512645
None of these are compatible with C. By compatible with C I mean they need to be able to directly #include C include files like c++ can.

>>107504307
>haven't used C++ since the 90s.
I stopped reading there.

>>107513474
C3 literaly can and was made for it.
zig also can (it can even be used as a c compiler).
rust can if you use bindgen.

>>107513474
Zig can do that

>>107513782
Can Zig include linux/io_uring.h the way C and C++ can? I tried it in Rust with bindgen and it created some nonsense because it cannot inlike unions.

>>107514135
You can, but you don't need to, it's already in the stdlib
https://ziglang.org/documentation/master/std/#std.os.linux.IoUring

>>107514241
>IoUring
dropped

>>107504212
>not that they look a whole lot better in Rust
They do. Have you even compared Rust for loops and integrators with C++ equivalents?

>>107514589
>integrators
*Iterators

>>107514589
C++ iterators are always superior, yes.

>>107504212
The cult of C++ is almost as bad as the cult of Rust. Maybe the C++ committee should deprecate some templates. Or something.

>>107512890
y u mad tho

>>107514589
The expression of iterators in Rust is better than C++, but it still looks like shit. Clojure with threading is the king.

>>107514767
In C++, iterator is just two pointers, how is there anything better?

>>107504212
>If you watch these conference videos from people like Klaus, Jon Kalb, and Bjarne, it becomes painfully obvious that they either have their heads buried in the sand, or that they live in an alternate reality. Who the fuck thinks that it's not a language problem that competent use requires hundreds to thousands of hours of training? This isn't even getting into all the retarded fuck-ups of formal syntax and bad library designs that they love to hand-wave away, or the fact that implementations can't keep up with the half-baked designs that have been added since C++20.
But Bjarne Stroustrup has literally proposed that profiles could help with training and education, and profiles are a language feature.
IMO, just strip any and all runtime semantics and code generation from profiles, and make some modernization profile.

>>107514776
That puts unnecessary restriction on having to deal with continuous data in memory.
Rust iterators are even simpler, it's literally just one function. Thanks to that, implementing Iterator is very easy and you can use them in all sorts of scenarios, in memory arrays, trees, linked lists, async channels, network streams, etc.

>>107515247
Contiguous data is optimal.
If you know what you're doing, extra work to use non-contiguous data is a non-issue.

>>107514776
Iterators suck to pass in pairs, especially when you deal with more than one container, and are easily invalidated.

>>107515247
Contiguous or assuming a linked list.

>>107515311
Optimal in many cases, but sometimes you really do have to work on a map or tree. The backing memory may be contiguous, but the placement of elements within will not be contiguous.

>>107515321
You don't have to pass anything in pairs.
>but sometimes you really do have to work on a map or tree.
So just implement full iterator.

>>107515311
And what if you want to iterate over values coming from a network stream?

>>107515516
You write a special iterator that does just that.

>>107515585
Example?

>>107515677
It's context dependent, C++ iterators can be implemented any way you want.

for (auto it = iterable.begin(), end = iterable.end(); it != end; ++it) { 
}

As long as this code compiles, you can write

for (auto& item : items)

There's no magic, for non-pointer iteration, this simply means that your beegin is the iterator, and end is simply some empty struct which does nothing more than lead to a call to it != end where your iterator checks if it finished iterating or not.

no thanks fag

>>107505842
One thing is always true: where you can use C++, you can use C. In particular, if someone gave you C++ interfaces, a thin layer of wrappers will hide them. Using C instead of C++ has several practical benefits: faster development cycle, reduced complexity, better support by tools such as debuggers, higher portability and interoperability. When C++ is an option, C is probably a better option.

Another thing is always true: where you can use a managed environment (where the behavior of wrong programs is defined), using it will save a lot of trouble. C++ (like C) is designed for unmanaged environments (where the behavior of wrong programs is undefined). Unmanaged environments make it very hard to locate faults and impose no limit on the damage done by an undetected fault. In theory, C++ implementations can run in managed environments, but in practice they don't because of innumerable compatibility issues.

Yet another thing is almost always true: picking up a new language is easier for an experienced C++ programmer than working in C++. This is the result of the exceeding complexity of C++.

People who think there's no point in comparing programming languages, for example because "business considerations dominate technical considerations", are free to start their new projects in COBOL (COmmon Business-Oriented Language).

>>107515311
>Contiguous data is optimal.
Depends.

>>107505762
>The C/C++ UNIX mindset is like:
>>We must maintain backward compatibility at all costs
That's Microsoft, not Unix. Your 2018 meme is stale, fake and gay, and your computer is, in fact, a fast PDP-11.

>>107517415
The problem with C, is that its not very productive. Perfectly fine for software whose requirements are well understood. But for exploratory coding, C++ is needed. I recently switched back to C++ from C because of how utterly unproductive C was for experimental coding.

>>107517448
>exploratory coding
Just use an actual high level language for that. Sepples is the worst of both worlds.

Ironically, thanks to its fast compile times, even C is arguably better for that.

>>107517485
Most high level languages suck for handling binary data. My software is reading binary data files. Overlaying C structs directly onto the file bytes.

>>107517427
It really doesn't. Modern CPUs have L3 nearing 100MiB, linked lists lost.

>>107517662
>Overlaying C structs directly onto the file bytes.
This doesn't work unless you're a fizzbuzzer who only supports one OS and one hardware architecture.

>>107517852
It works fine on all systems that anyone cares about. No, I will not support your obsolete risc chip that cannot read unaligned memory.

>>107518112
>it works fine on x86_64 desktops
like I said

>>107517415
>Yet another thing is almost always true: picking up a new language is easier for an experienced C++ programmer than working in C++. This is the result of the exceeding complexity of C++.
Depends on what that new language is. Without an actual specification, not the one based on Ferrous Systems' that appear fake and incomplete, Rust might even at this point be more complex than C++ in multiple ways.
Otherwise, I encourage you to explain for instance https://github.com/lcnr/solver-woes/issues . There are many other examples as well.

>>107517415
>When C++ is an option, C is probably a better option.
Both C++ and Rust has some different trade-offs relative to C, for instance, what ability they have to support a variety of abstractions. Also, there are many different kinds of complexity.

Your arguments are too dishonest and incompetent to be sincere.

>>107518492
Rust is more complex than C++ if you're writing code, and easier if you're a npm level midwit.

>>107518578
Are you a Rust evangelist, setting up strawmen?

>>107513474
>By compatible with C I mean they need to be able to directly #include C include files like c++ can.
The mistake is Ctrannies specifying OS APIs as "C include files" instead of a language-independent calling convention.

>>107513474
>they need to be able to directly #include C include files like c++ can.
C++ can't do this. C++ is not a superset of C. You can write C code that C++ compiler can't compile.

>>107517415
>People who think there's no point in comparing programming languages, for example because "business considerations dominate technical considerations", are free to start their new projects in COBOL (COmmon Business-Oriented Language).
COBOL is actually a better language than C and it had some advancements in programming languages like record and string processing. C didn't introduce any new features to programming and didn't do anything that older languages didn't already do better.

>>107519439
Most C headers are written to compatible with C++.

But besides that, real programmers fork the C++ compiler and make it accept C syntax in C++ mode. I have my own fork of clang which I added various new features, the most important being it allows implicit cast from void*. Its so much better without having to shit pointer casts all over the place.

Another feature I added to C++, is allowing out of line methods to be declared outside of the class body. This means private functions don't shit up the public interface.

>>107519524
Bait used to be believable.

File: not bait.png (91 KB, 1400x1050)

91 KB PNG

>>107519912

>>107504212
>He has such inane suggestions as removing all "raw" or plain for loops in favor of std::algorithm functions and ranges
C++ is embodiment of boomer mentality.

>>107504212
They hate their children. They want to leave behind a mess so that their children could never improve or if they try they will have to pick a path chosen by them.

>>107506766
>Objective-C, D, Swift, Zig, C3, the list goes on.
Not all people are h1-b hired to build iphone app.

>>107520317
holy fuck, classic theme, I miss it so much...

>>107520384
ranges blow up compile times, stack sizes, make debugging a nightmare, and are a huge vector of undefined behavior. All that, and they're stateful as fuck, like the committee is dedicated to just assfucking everyone constantly to sell more books.

File: c_chad.jpg (21 KB, 735x884)

21 KB JPG

>std::algorithm functions and ranges
C doesn't have this problem.
>>107522015
C doesn't have this problem.
>>107517415
>picking up a new language is easier for an experienced C++ programmer than working in C++.
Holy fucking KEK.
C also doesn't have this problem.

>>107522282
>C doesn't have this problem.
Because you can't even do that in C.
>getting shot in the arms and legs is LE BAD
>let's have all our soldiers be people with no arms or legs, so they can't get shot in them!

>>107520317
Post the code. Can you add metaprogramming (templates)? I remember win-lcc has some kind of function overloading + metaprogramming.

>another day another anti-c++ cope thread by eglin because they can't control an international standard with multiple compilers like they can control troonlang
modern c++ solves 99% of the muh safety concerns (which are already blown out of proportion when it comes to software bugs)

>>107505842
C#
>>107513474
C#

>>107520317
what is the point of having functions out of line? why not just write a regular function and then pass a pointer to the object? does this way not induce more complexity, as you have to search any number of files to see if a implementation exists, as opposed to all of the definitions being in one place?

>>107523729
>modern c++ solves 99% of the muh safety concerns
But the way it does it isn't even implemented in C++. Beautiful design.

>>107519357
>The mistake is Ctrannies specifying OS APIs as "C include files" instead of a language-independent calling convention.
but OS APIs are language independent and have their own calling conventions? Oh but let me guess, you *NEED* to support Windows where what you just wrote is actually true? Kek.

>>107523927
Because at that point why even use C++. This is one the reasons I went back to C for ages. I was sick of the inconsistency. If I was sometimes forced to use free functions, why not just use them all the time, then why even bother with c++.

In C a common patter is to mark functions as static, limiting their scope to the current file. In c++ because all functions must be declared in the public interface you cannot do this. My feature restores the ability to make module private functions. I use out of line functions with __attribute__((internal_linkage)), to make them full equivalent to C static functions.

>>107525130
>In c++ because all functions must be declared in the public interface you cannot do this.
smartest cnile

>>107525256
I don't exactly know what your issue is. Maybe my terminology is bad.

class MyClass
{

private:
  void some_internal_func();
}

This is what I want to avoid. some_internal_func(), should not be visible in the header file. It should only be defined in the source file. With my altered compiler, I am no longer forced to put everything in the class definition.

>>107525360
So don't put it in the header, where's the problem.

>>107525373
C++ does not allow you to add member functions unless they go in the header file. This forces you to make all your private functions free functions. This inconsistency drives one to the point of saying screw it, if I will just go back C.

>>107525393
And how is this a problem? Don't make a member function if you don't need one.

>>107525404
Because if half my functions can't be member functions it creates this horrible inconsistency. This was one of the primary reasons I went back to C for 5 years. These kind of issues wreak havoc on people with any kind of executive function disorder. I only went back to C++ after hacking the compiler to fix the out of line function restriction.

>>107525471
Maybe you should just stop writing dogshit code.

>>107525471
If I understand you correctly: https://en.wikipedia.org/wiki/Uniform_function_call_syntax There have been different proposals for C++ to add this, but none adopted.

If a job wants to hire me to write rust and pay me decently who cares. Otherwise if my current job says anon should we start doing new development in rust I will say no because it’s obviously risky and the upside is uncertain for me anyway.

>>107504212
>with more teaching, the safety problems
rusttroons are so easy to spot

>>107525882
>safety is when... troons

I don't have any major issues with C. Yeah, it could be better. But it can also be worse. A lot worse.
C++ I don't really like. It's too much.
I don't want anything to do with Rust.
Does this make me a "no coder"?

>>107526048
No, it makes you sane.

>>107526037
https://materialize.com/blog/rust-concurrency-bug-unbounded-channels/

>>107526048
Some of us are pining for a successor language to both C++ and Rust that is significantly better, also in the different critical regards. But that is easier said than done, and many have tried and put a lot of work, effort and energy into it.

>>107526048
No, that makes you a midwit

Go was created for people like you.

>>107526119
>safety is when... rust

>>107526125
The language isn't the issue.
If you actually watch videos linked in OP, it absolutely BTFOs rustroons by showing that simply changing how you write code gives 99% of benefits.

File: screenshot.png (605 KB, 1280x720)

605 KB PNG

>>107525716
Erm anon, if you think this way and don't submit to rustroons, you're actually... A jew unironically, because jew = intelligent.

>>107526448
>>107526119

>>107526486
>>107514780

>>107526534
>>107526540
yes I read that article, rust needs sanitizers at runtime to debug trivial problems, what else is new?
If you weren't a /pol/tard you'd know that anyone employed has to care about safety and employment means using something else than rust by default.

>>107526566
>>107526119

>>107526729
midwit

>>107526746
Is you, at best. >>107526119

>>107526486
Yeah, just upgrade all the existing shit you work with, and ignore POSIX/OS APIs, and upgrade your existing code base, and re-re-re-educate your C++ devs yet again, and watch out for UB caused by the retarded implementation of filter views.

>>107514780
Profiles are vaporware and won't solve anything. They are a simple kneejerk reaction to everyone else waking up to smell C++'s shit.

File: screenshot.png (797 KB, 1280x720)

797 KB PNG

>>107526823
already a solved problem, midwit

>>107526819
Ok midwit, now go watch the video, because 99%, also known as midwits, did not.

>>107526844
Profiles may offer a more lightweight alternative to epochs or Rust editions, depending on what kind of profiles are discussed.

>>107526972
It would be great if one profile would go by the name MISRA and then every single compiler would be forced to, at compile time, enforce it.
That would end this hysteria about safety, all perpetrated by lazy compilerniggers who can never do anything properly.

c++ is so fucked up that some people are willingly using rust instead

File: screenshot.png (643 KB, 1280x720)

643 KB PNG

>>107527041
No, some people are just mentally illl.

>>107526823
>and ignore POSIX APIs
finally some good suggestions

>dude finished his talk
>question time
>first faggot to speak up has to say he disagrees instead of wanting to ask something

File: screenshot.png (789 KB, 1280x720)

789 KB PNG

>>107506776
Because C++ is the safest programming language in the world.

>>107504212
True. But Hare experts do live in reality, just see https://www.youtube.com/watch?v=6wQ7pl7DVHw

File: screenshot.png (1.06 MB, 1280x720)

1.06 MB PNG

>>107527215
>Playback on other websites has been disabled by the video owner

>>107526514
>>107527045
a bold approach to blame your users for your retarded decisions
let's see how it works out for them

>>107527269
>>107514780

>>107527269
>use tool incorrectly
>tool is a problem
kill yourself, tranny

>>107527269
>>107527309
samefag.

>>107525360
if you really need to, a solution to that is.

// foo.h
class foo {
public:
  void some_api();
private:
  int some_data = 0;
  class p;
};
// foo.cpp
class foo::p {
  foo& self;
  void update();
};
void foo::some_api() {
  auto p = p{*this}; // at top of each function
  p.update();
}
void foo::p::update() {
  self.some_data++;
}

>>107527962
Too bad nobody needs this.

>>107526181
I don't know Go. But from what little I've seen of it it, it doesn't look too bad. It's not a systems programming language though, and that's what I do.
>a midwit
Maybe, because I like things simple. But I've seen a lot of systems fail because they get too complex. I see C++ and Rust as giving into the complexity by admitting defeat instead of fighting against it.

>>107528579
Systems programming is complex. You can acknowledge that or not, but it won't go away just because you choose to ignore it.
There is a reason why modern C++ and Rust look like they do. It's not an admission of defeat, it's an attempt to formalize what otherwise would have to rely on the limited mental capacity of dev teams.

>>107528626
>Systems programming is complex.
Complexity comes from not understanding the problem.

File: artworks-qq7INrY8D1j2Myo4(...).jpg (39 KB, 500x500)

39 KB JPG

>>107528742
It sure is

>>107528742
Is this why cnile projects are so clusterfucked?

In systems software, adding complexity is usually seen as a shortcut to achieving some goal. The story usually goes that there's no time to understand the problem and design a proper solution. The reality is the opposite, systems get worse and more difficult to maintain over time because they're not well understood. This is not a language problem or a technical problem, it's a human problem.
Now on the language side, some languages lend themselves to more or less semantic scrutability across the entire scale of the project. That's a technical problem.

>>107528893
Tell us more about how adding abstractions makes things more complex.

>>107513474
Also DMD:

/*cfoo.c*/
#include <stdio.h>

void say_hello(void) 
{
    puts("Hello!");
}
---
/*dfoo.d*/
extern(C) void say_hello();

void main() 
{
    say_hello();
}

https://dlang.org/blog/2017/10/25/dmd-windows-and-c/

>>107528907
Adding abstractions doesn't necessarily make things more complex than they need to be. But not all abstractions are created equal. And then you can have abstractions on abstractions.
One of the classic problems I've seen in my career is that people rush to solve a problem in code before it's solved in their minds. You don't need a huge language for the vast majority of problems I've seen. You need the right frame of mind. And even if you do have a simple language you can still easily fail because you thought you were clever enough to code your way out of bad design.
My problem with C++ is it tries to solve so many types of problems, most of which are self imposed problems, in the standard itself by letting complexity out of control. So then they add on a language feature to deal with that and the whole thing just spirals.
I do think Rust or something that comes after Rust will take over as the dominant active systems programming language eventually. This is obviously inevitable. Just like adding wrapper upon wrapper on web technologies are inevitable. But C won't be completely replaced because it just wont be economically justifiable to migrate every system in production from C to Rust. Even with AI. Not before I retire, anyway.

File: screenshot.png (727 KB, 1280x720)

727 KB PNG

>>107529111
Your only problem with C++ is that you're a midwit and project your own lack of intelligence onto C++.
If you yourself understood what you're doing, C++ having a syntax for any problem under the sun wouldn't scare you, because you'd be able to pick the correct one.