So has an alternative to C++ for Systems Applications Programming been found or created yet?

So has an alternative to C++ for Systems Applications Programming been found or created yet?

Attached: 1200px-ISO_C++_Logo.svg.png (1200x1349, 69K)

install c

>I want to use an outdated language that isn't even capable of classes

>I need syntactic sugar to make classes

Attached: 1511692894806.png (703x911, 19K)

Yes, 20 years ago.

Yes, but Jow Forums has decided to collectively hate it

Not him but of course I don't.
I don't need the syntactic sugar of C or assembly either.
Does that mean I should program everything in machine code? No you retard.
Syntactic sugars are there for your convenience, use them.

Also, C++ allows you to do things that C simply can't do. Such as superior template based generics and type traits.
Void pointers are utter trash and inefficient.

D?

There have been replacement languages for C (and C++) for many years (Ada, Fortran, PL/I, others) and have not been used for historical reasons mostly having to do with bad compiler implementations and not having enough memory. Good programming languages unfortunately dont run well in 64k of memory. Also C provides a low bar of entry for unskilled and self taught programmers which is mostly the only people they could find in the 70 and 80s. The fact that personal computers in the 80s took over the computer and ran directly on memory meant that a language of low complexity and unconstrained memory rules was required. The fact that the unix kernel completely dominated and shut out all operating systems work also greatly contributed to C's monopoly of 'systems programming'

Yes, Rust.

Why would I want a language that constantly nags me for being "unsafe"

this is a stupid question but it actually touches on a real issue worth mentioning

using an unsafe language is something that stupid programmers do by simply throwing up inherently shit code and that fixing it in a debugger

unsafe in the context of Rust simply means relaxing the typing rules so that the compiler doesnt complain when variables hold actual hardware memory values, the rest of the language remains safe

I really want to know what user meant by this.

Not really. C++, as horrible as it is, is the best option.

>C++ for Systems Applications Programming
Da fuck?@?!?
> are you a google cuck?

this

*YOU* are full of bullshit.

>C++ is a horrible language. It's made more horrible by the fact that a lot of substandard programmers use it, to the point where it's much much easier to generate total and utter crap with it. Quite frankly, even if the choice of C were to do *nothing* but keep the C++ programmers out,
that in itself would be a huge reason to use C.

In other words: the choice of C is the only sane choice. I know Miles
Bader jokingly said "to piss you off", but it's actually true. I've come
to the conclusion that any programmer that would prefer the project to be
in C++ over C is likely a programmer that I really *would* prefer to piss
off, so that he doesn't come and screw up any project I'm involved with.

C++ leads to really really bad design choices. You invariably start using
the "nice" library features of the language like STL and Boost and other
total and utter crap, that may "help" you program, but causes:

- infinite amounts of pain when they don't work (and anybody who tells me
that STL and especially Boost are stable and portable is just so full
of BS that it's not even funny)

- inefficient abstracted programming models where two years down the road
you notice that some abstraction wasn't very efficient, but now all
your code depends on all the nice object models around it, and you
cannot fix it without rewriting your app.

In other words, the only way to do good, efficient, and system-level and
portable C++ ends up to limit yourself to all the things that are
basically available in C. And limiting your project to C means that people
don't screw that up, and also means that you get a lot of programmers that
do actually understand low-level issues and don't screw things up with any
idiotic "object model" crap.

Attached: javaEe.jpg (290x283, 19K)

>It sucks. Trust me - writing code in C++ is a BLOODY STUPID IDEA.

The fact is, C++ compilers are not trustworthy.

- the whole C++ exception handling thing is fundamentally broken. It's
_especially_ broken for kernels.
- any compiler or language that likes to hide things like memory
allocations behind your back just isn't a good choice.
- you can write object-oriented code (useful for filesystems etc) in C,
_without_ the crap that is C++.

Attached: taylor-swift-bikini-paddleboard-0729-17-420x560.jpg (420x560, 41K)

You can take your tech tips and shove it, Linus

Go.

>using an unsafe language is something that stupid programmers do by simply throwing up inherently shit code and that fixing it in a debugger
Yeah, or I just don't want to spend time formally proving to the compiler in its own language that a construct is in fact safe, when I can trivially prove it to myself in a matter of seconds.

relevant 11 years ago, not so much any more

None of that has changed in 11 years.

Exception handling is a fundamentally harmful idea.
>allocations behind your back just isn't a good choice.
Agreed.

btw your newlines are annoying

>STL and Boost are no longer garbage
>C++11 not only adds features that make it possible to write much more efficient code than C++98, it makes them idiomatic.
>memory allocation is only abstracted away if you choose it to. Custom allocator support is supported by all STL containers and can easily be added to your own code.
>every OOP implementation in C (e.g. gobject) is a titanic piece of shit
Basically the only thing that's true is that exceptions suck.

>he doesn't know about macros

>Macro-based templating
>Templating without vague linkage
horrifying

If you have such a great method of proving correctness, why won't you make your own language that implements it in the type system? I can't imagine how great would be a language with safety of Rust and simplicity of C. Or did you mean "convincing myself" instead of "proving"?

Not "macro-based templating", just "macros". Turns out you can do quite a lot (not everything though) with it if you aren't a brainlet.

>If you have such a great method of proving correctness, why won't you make your own language that implements it in the type system?
Because it's not a formal method, duh. In the vast majority of cases it is simply obvious, and then there's no need to waste time on proving it formally.

So that's just "convincing yourself" and not "proving".

You can do quite a lot with C++98 TMP, that doesn't mean it's a good idea or a feature worth advocating the use of.

Yes, that's exactly what I'm saying. There's no need to waste time on proving every part of your program formally correct. Especially so when the aspects of the program that are proven are just a subset of relevant aspects anyway (it's not like you can't write programs that are "buggy" in Rust).

Also, even when you do choose to formally prove parts of a program, it's a great thing to be able to do so in a system and language of your own choice, rather than having to use the one system and language that the compiler gives you.

struct MyException{
std::wstring ex;
MyException() = delete;
MyException(const std::wstring& e):ex(e){}
};

try {
if(/* something */)
throw MyException(L"Jesus");
}
catch(MyException e){
return;
}


I am trying to compile this in VS17 this is the error I am getting.
Error (active) E0289 no instance of constructor "MyException::MyException matches the argument list. argument types are:
(const wchar_t[5])

wtf. I have similar code in some other project there it doesn't complain about wchar_t to std::wstring

What I want to say is that C isn't as limited as people think. You can make generic linked lists or OO programming in it. That's just enough for operating systems. In this context the advantage of C is that it doesn't do anything behind the back like C++ does. While I do see that someone might want a higher abstraction when making some applications, I suppose that system applications would follow requirements similar to those of operating systems.

For systems level coding "C" should be your first and with the exception of writing specific code in assembler, your only choice.

>not using std::string with the u8 string literal

Yes, it's called Rust, but Jow Forums decided to hate it because muh sjws.

>In this context the advantage of C is that it doesn't do anything behind the back like C++ does.
What's better about smuggling things behind macros instead of behind templates? I seriously don't get this.

The advantage of type system is that it's proven automatically though. Well, as long as you write the kind of code that the compiler likes. The nice thing, however, is that it should be trivial for trivial parts of your program. And then only the tricky parts of the program need more thought - and that's just fine. It's just expected to spend more time on the difficult parts. Actually the perfect type system would not require any additional work from the programmer and only give errors when there indeed is an error in the program. But yeah, I do see how too restrictive type system with wacky rules could get in your way. The question is where the Rust's compiler stands but I'm not knowledgeable enough to argue about it.

its capable of everything, its a question wheather you're capable of using it.

obviously you're to retarded for it if you cant into c++

>The question is where the Rust's compiler stands
Let's just say that "lifetime hints" was where I stopped reading the Rust documentation.

C++ doesn't allow for horrible design choices instead it gives freedom to a shitty programmer like you who doesnt know shit. If you're shit at programming dont blame the language

There is an abundance of awful C++ programmers who routinely abuse those features. Although I don't agree with the entire statement
>Quite frankly, even if the choice of C were to do *nothing* but keep the C++ programmers out, that in itself would be a huge reason to use C.
This absolutely holds.

why Jow Forums only likes jobless languages?

Templates are actually fine. I think. I find C macros to be pretty ugly actually but they do the job. I just wouldn't want to bring all that other shit from C++ (like classes, overloaded operators). If I was doing a personal project I could indeed use C++ but limit myself to C and templates but that doesn't work when you add other people.

javascript. /thred

C++ has evolved into a horribly complex, unmaintainable language. Embrace static typing and use Ada.

Agreed. For the most part when I write C++, I simply write C but with metaprogramming features like templates and constexpr. And if it's not a personal project, I'd much rather be writing C in a group than C++.

Is that the language with unreadable syntax?

Just my opinion, but I find it to me the most readable of any language that I've seen. I'm also fluent in the english language, so that helps.

I am using L"Jesus" compatible with std::wstring not std::string

C++ is statically typed you fucking mongoloid.

>Ada
Really more of a military programming language than anything else. Massive amounts of forethought and correct long term predictions are needed to get the most out of this language. The language is really inflexible when it comes to design and refactoring.
>Fortran
Could have been a contender had IBM kept it up to date at a decent clip.
>PL/I
Sank under the weight of its own IO suite.

That said, a lot of these languages were good for their intended use but some were ahead of their time. Computers at the time weren't ready for programs that were coded to high level hardware abstractions.

>which is mostly the only people they could find in the 70 and 80s
There weren't any real formal programming courses or departments of that era. Programming in the 70's was still considered an act of electrical engineering and stayed that way for a long time into the 80's.

>unix kernel completely dominated and shut out all operating systems work
It was cheap, fast, and goodnuff. IBM wanted to fleece corporations silly for TOS/360. Gary Kildall wanted to milk CP/M for all it was worth. It wasn't until Microsoft that another cheap, worthwhile OS entered the arena. VAX was cool but you had to be a business to be able to afford it.

Attached: 1413644595291.jpg (300x400, 22K)

yes STL is stable, portable and efficient you mong.

Ultimately lthere is a lot of momentum behind C and people with large codebases and established development pipelines don't see a reason to change for some marginal improvement to something that is more of a nuisance than a real problem to them which I respect. But I hate with passion anyone who prefers to use something unsafe and inferior language as some kind of cultural statement. You can always spot these people talking about "real" programmers who can "handle their shit", but never having some factual debate.

I suspect that some of these people just got caught with most of their knowledge obsolete and this is how they cope, by blaming the whole world around them.

Attached: 1522378513678.jpg (996x1390, 163K)

STL is trash, so many classes have broken specs. O(1) iterators mean garbage hashmaps. std::function allocator support never caught on and was just abandoned because no stdlib vendor decided to fix it. Everything about std::variant is awful, but especially std::visit.

>so many classes have broken specs.
The worst have been deprecated with intention to remove them entirely in future revisions. Working replacements have been put in place and aren't difficult to migrate.
>Everything about std::variant
It's the best they can do to cope with the fact that you need it for actual systems programming and there is no such thing as a standard variant. Bitch all you want about variants, they're a staple of type loose interfaces, older systems, and low to mid level database APIs.

Attached: 1409346773812.jpg (500x375, 49K)

The O(1) iterator operator++ rule has not been relaxed to allow for a hashmap implementation of std::unordered_map. std::function's Allocator support was deprecated not because it was inherently broken, but because of buggy implementations and too much apathy to fix it. std::variant is a C++17 addition and it's already garbage.
>It's the best they can do to cope with the fact that you need it for actual systems programming
Github NEETs can build better pattern matching interfaces with ease, std::visit is fucking garbage and it's not because of C++ limitations. Also
variant v3;
v3 = "abc"; // OK but chooses bool
std::variant didn't need to be this bad, but it is.
>and there is no such thing as a standard variant.
A variant needs to be nothing more than a union of each member type plus an enum tag to discriminate between them. I'm not sure what you mean by this, or what else a variant could be.

C#

THIS, except templates can be extremely useful if used correctly (and are the only reason I'm still using C++). The problem is that nobody really understands how generic containers need to interact with elements of a language in which addresses must remain fixed. This goes for the macros-then-include pattern in C - template or macro'd out container pattern, there is no such thing as a general-purpose one-size-fits all container (except for std::vector, which has a stupid name and takes all of an hour to write).

Everywhere I've worked with C++ there has been abundant use of boost and the STL. Both are broken beyond salvaging, causing anything that touches them to be the same - bloated, instant heap fragmentation because std::set and std::list are fucking everywhere, and this insipid obsession with separating algorithms and containers with stupid shit like std::sort() being an example. The iterator pattern is only a half-baked solution to the problem of accessing container elements, and there aren't any good intrusive containers that let you build linked lists or RB trees directly into flat buffers using indices instead of pointers.

I could seriously go on for an entire book about how the STL sets an idiotic precedent for how the language needs to be used given the constraints on how objects need to be allocated and used.

I find both variant and any useless as they are.
Both need to support some kind of dynamic_cast to a base type of whatever it contains, among other things.

dynamic_cast specifically? I don't see what's wrong with using the built in accessor methods. dynamic_cast has very specific semantics in C++ at present.

Here is what I mean:


class base{ public: virtual ~base(){} };
class derived : public base{};

std::any actiallyIsDerived = derived{};


// Later, in code that for good reasons only knows about "base"

auto &base = std::any_cast(actuallyIsDerived);


You get a bad_any_cast if you don't match the type exactly, which makes std::any useless for "peeling apart" generic message packets or similar.

What's the point of C++ being mostly backwards compatible with C when it has a C++ alternative to many of the C features?

Attached: 1521286311131.png (929x768, 55K)

The C++ features are supposed to be type-safe. That said, bare "new" was a mistake (no alignment or allocator control until recently, and its way too late now).

there was literally nothing wrong with malloc

I see. I'm not sure how you'd make that work though.

just needed an alignment argument, and no excuse for it not having one
posix_memalign, __aligned_malloc, and manual malloc+alignment size etc.. are flimsy bandages

"default alignment" is meaningless on a system where alignments may range from 4 bytes to 128 bytes, or even a whole page. want to waste up to 4KiB every malloc? I don't

Same mechanism behind throw{}catch(base &), except without going through the runtime's EH system. Any C++ ABI has to support this if it supports exceptions.

This is accomplished using vtordisp offsets available through the type info table. In the case of the MS ABI, the type info blocks are actually ordered in the same way a dynamic_cast is performed (which makes sense), with the root at the beginning. So what it will do is simply jump to the root of the inheritance hierarchy and cast down. At least, that's what it did back with the VS2013 CRT.

Agreed. Nothing C++ has fixes this problem though.

meant "try{}catch(base&){}", but you get the idea.

Java, Rust, and Go exist, however they are vastly inferior as they try to be "easier", and in Rust's case, only exists due to the Mozilla developers being too retarded for C++. No one has been able to make a good successor to C++.

Attached: e27a217e-4f2d-43e5-9d1c-8411c46ac65f.png (1000x1354, 916K)

it's called C

Just flashed my first rust hello world on a stm32 board that I had gathering dust.
It was pretty simple, would recommend.

>been found
Yeah, they're looking for it really hard.

I can't keep track of the number of data structures in c++. There are about a ___?

>things people can only say on Jow Forums and would get them fired IRL
I really love how C++ shills only good reason they can offer as to why C++ is good is because its 'harder', like being difficult is somehow a compelling reason to use any language. C++ is indeed difficult and that difficulty does not buy you anything expect lame bragging rights that you do things by hand that the compiler could and should do for you

KILL YOURSELF

In each of the cases that poster listed, simplifying the languages caused them to be of less utility. Your argument would hold water if he was comparing C++ favorably to C.