Let's talk about C++

Let's talk about C++

Other urls found in this thread:

imgur.com/a/jQUav
twitter.com/SFWRedditGifs

#include

int main(void)
{
if ("Rust is for faggots")
std::cout

C with namespaces, methods, maybe constructors and destructors and templates would be enough

>methods
>namespaces
unnecessary bloat
all it would need is RAII, templates and operator overloading

>RAII
nope, RAII is unnecessary bloat that forces you to write wrapper classes with constructor and destructor for everything, simple defer keyword would be enough
>namespaces
because prefixing everything manually is so much comfier???

These posts are eerily converging onto a version of Go without garbage collection.

Reference counted Go? What about cycles?

I'm fine with standardizing __attribute__((cleanup)) as well

>Go
I like many things Go did, but it's just not C (specially performance-wise), definitely would take how packages and their importing/initialization works

isn't that GCC extension?

Yeah, I'd be fine with c++ going away forever if I could just have go with c's memory management.

>
>>RAII
>nope, RAII is unnecessary bloat that forces you to write wrapper classes with constructor and destructor for everything, simple defer keyword would be enough
A big part of c++ raii bloat, if not all, is eliminated at compilation inlining if it's made a clever way
>>namespaces
>because prefixing everything manually is so much comfier???
You just cannot avoid some sort of namespaces, at least from the libraries you must use

one of their particularly autistic ideas is the whole "let's rewrite all C programs in go" mentality, it's funny as hell

source? haven't seen this yet

You are probably confusing it with Rust.
brainlet

it is
works with clang, too

>int main(void)
Disgusting.

C++ is frustrating because it's becoming the language it always should have been, but at the most excruciatingly slow pace possible.

Pre-11 C++ is horrid and I'm happy to see it finally dying off.

>but at the most excruciatingly slow pace possible
this
And at the end of next decade, it still won't have a proper macro system and no, preprocessor macros, templates, metaclasses and everything else can't replace it.

t. GNU coding style nigger

Nope, that's Rust. Go admits to being slower than C/C++ and actually has a pretty good C FFI. Hell, it can even parse C headers and most types are compatible with the C ABI.

Go is java. Seriously. I'm a kernel programmer with an extensive knowledge of both Rust and C++. Go is java with the addition of coroutines, which is fine, right, but well, why the fuck would you recreate java you fucking moron? It's just java. Fucking java. With coroutines. Java with coroutines. What a genial idea.

Rust has a lot of good flake on this board, but while it has some really good idea (their implementations of OOP is genius), it is also weird. Rust read like someone who, while extremely intelligent, had never heard of any language made those past 30 years and recreate the wheel. Slightly better wheels, mind you. But slightly strange wheels nonetheless.

>nope, RAII is unnecessary bloat that forces you to write wrapper classes with constructor and destructor for everything, simple defer keyword would be enough
RAII is for library dev. Once the constructor and destructor of your RAII classes are made, their utilizations are incredibly intuitive, easy, the best of the best of the best. No other keywords like 'finally' and 'defer' offer that level of intuitiveness. You fucking java 'finally' loving moron.

That guy knows what's up.

Well it is Java that compiles down to native architectures at least. Also, even Java has generics but that's apparently too hard for the usual google programmer to understand.

>their implementations of OOP is genius

Elaborate.

Basically, they decided to divide a class between a collection of data (a struct) and a collection of methods (an implementation). So you don't have a class that have both data and methods. You a collection of data, a collection of methods, and when both are linked, you have a class.

Okay, that's not revolutionary. I don't remember, but I think Ada had that far before. It's also a logical leap from every functional programming language out there. But it's still good, fun, and slightly weird.

How does that even work? Methods assume and depend on certain data being present. That's what makes them methods, they have a this instance with the data they operate on.

Is it like Python where a method call is just sugar for Class.instance_method(self, *args)?

>traits
>new

But I agree, it's a nice way to implement dynamic dispatch.

let me name programming languages that are better than C++ in just about every aspect and this is just from the top of my head

C
C#
R
Rust
Erlang
Haskell
Java
Kotlin
Lua
Python
Scheme
Common Lisp
Lisp
ASM
Fortran
Pascal
Delfi
Prolog
OpenCL

and even fucking PHP and Javascript

Fuck C++. Ask me again in 30 years when that shit language for video games is actually finished and when someone produces a working compiler for it.

Only reason they did not add generics is because those would drive compile time too high. It does not matter for me or you, but, when you have multi million loc code bases, it adds up.

Sounds like your project is too big. Split it up into libraries.

>reading comprehension
Compile times matter to such an autistic level only for Google, Amazon, etc. with fuckhuge projects. The language was largely made to patch up Google's Python-C++ codebase.

>Only reason they did not add generics is because those would drive compile time too high.
Bullshit.
Other languages have generics and other metaprogramming things too and compile just as fast.
When implemented properly, stuff like type checking and tree expansion gets dwarfed by optimization passes anyway.

The only reason is that the lang devs are UNIX oldfarts that haven't looked at programming languages for the last three decades at all and therefore are incompetent.
It's just that simple, there is no more slightly diverse background story, no other side of the coin.
It's just like Oracle trying to make money every possible and impossible way they can to fund Larries yachts.

>google compiler is slow with basic language feature.

can google stop making compilers? literally all of them are complete shit in terms of speed. I'm still haunted by shit like gwt taking roughly half a fucking century for a nontirival project.

So they crippled a language forever just to keep their own compile times low? They could simply not have used generics in their own code.

So why does Google have a reputation for having great programmers? Seems to be they're all garbage tier people. Their products are always half-baked and poorly integrated. It's amazing they get anything done.

Microsoft is 900% superior when it comes to language implementation and research

How is the Dart compiler in terms of speed?
Some things indicate the few competent compiler devs are there and with V8.

Let's talk about that cute anime girl instead

Well I've read that V8's heritage and teams can be traced back to the JVM and Self VMs, literally man centuries of experience working on high quality execution environments there, these people weren't always Google employees.

Yes. Who is that cumslut and why is she displaying her lustful body for everyone to see like that? Does she want to get raped?

>Not as fast.
Easily as fast. dlang is faster, jai (while vaporware) does way more.
Some Pascal compilers (probably not FreePascal) were always faster, because they were designed to be faster.
>Go is retardedly fast at compiling.
It's not. It's mediocre, given how poor the resulting binaries are. And they just slowed it down when needlessly bootstrapping the compiler.

And that is just out of my head. There is probably way more stuff, if I was really interested into it.

because they probably are great, but they just half ass it and expect someone else to make it not slow.

I have never used dart because it feels like it's geared towards people who use nonfree IDEs and toolkits, so I don't bother. plus dart is almost completely deprecated by ES2017.

#
>Other languages have generics and other metaprogramming things too and compile just as fast.
Not as fast. Go is retardedly fast at compiling. It is generally too fast to be useful for anyone but big companies with giant codenases.
>stuff like type checking and tree expansion gets dwarfed by optimization passes anyway
That's the thing. Go does very little optimisation. For example, functions are almost never inlined. IIRC the inlining rules was "less than 20 expressions and no function calls inside".
If anything, the compile times are comparable to script interpreters in speed.
See above. It's designed to be fast to compile at the cost of stripping language features. This is only useful for very big codebases.
Yes. I agree it's kinda retarded.

We don't need any member functions.

>I have never used dart because it feels like it's geared towards people who use nonfree IDEs and toolkits, so I don't bother. plus dart is almost completely deprecated by ES2017.
Yeah, this too.

Also, they should have adopted Haxe instead.

Modern C++ is a sham.
Reject classes, inheritance, member functions, virtual functions, inheritance, constructors, destructors, RAII, operator new and exceptions.

Write C with namespaces and (where it makes life easier) templates and constexpr.

C++ is cute CUTE

see

no

>given how poor the resulting binaries are
That's the thing. Don't use Go, if you need optimised binaries. Use it for walls of CRUD and glue code.
See imgur.com/a/jQUav for a somewhat outdated comparison. People seem to consider Go a systems programming language. It's not. Think of it as a statically typed scripting language. Use case wise, it's just a better Python/Node.js/Ruby/PHP/whatever.

Give it generics and it would make a great glue language.

Go's compile time dropped like crazy when they reimplemented the compiler and runtime from Plan 9 C to Go. It was like 2-3x slowdown.

I'd love that, but Google is too autistic about 1M+ loc project compile times. Not having generics does not make sense for anyone but Google, Amazon and maybe a few others.

>C with namespaces

what the fuck? how? i thought the whole point of C was having easy, nonsensical calling conventions. I didn't even know they added name clobbering namespaces to C. wtf

>That's the thing. Don't use Go, if you need optimised binaries.

In the meantime, they could have archived the same with generics.

Do generics add that much to compile time? Particularly if they're just cast macros like Java rather than C++ style templates.

i would c those plusplus anytime

I'm describing a preferable style of writing C++. C does not have namespaces.

They didn't, relax. Nothing of that C++ cancer will ever infect C.

No they don't. Neither do templates in languages that are not C++. Generally checked replacements in the syntax tree are almost free unless you're doing something retarded.

A few C features have been backported from C++, like const.

Except const is useless in C so who cares.

beyond my brain

What? When? What the fuck are you talking about

Cross-library generics add plenty. IIRC their line of reasoning was "Java-like generics are too inefficient at runtime without a runtime JIT optimiser and C++-style generics compile too slow, so lets not have generics at all". I agree, it's dumb.

>Cross-library generics

Sorry, I meant cross-compilation-unit generics.

C89 lacks const, mixed declarations and code, the inline keyword, and probably a few other things.
C++98 has these features, because it's C++.
C99 introduced these features into C.
What's not to understand here?

>Java-like generics are too inefficient at runtime without a runtime JIT optimiser
lolwut? Type assertions in existing Go is slow because it needs to use type information that's only available at runtime, but inserting static casts at compile time should be free.

I thought you were talking about namespaces.

suspiciously weird specific case but nvm then

I'm merely saying that "C++ cancer" did infect C.

>std::string str(s.str());

well that's a shame. it would have been cool to see if C could be revolutionary and come up with some mechanism to clobber symbols and shit while still being mostly easy to drop shit in and it magically working.

oh well.

The things you cited aren't really cancer.
Name mangling is cancer.

Only if it's not standardized. It wasn't in the 90s, but for most any platform nowadays it is.

>Name mangling is cancer.
That isn't either. It being not properly standardized is. That said, most ABI is cancer. UNIX and influenced was a mistake.

Last time I checked C++ libraries are still horrible to work with and compilers still introduce subtle incompatibilities

>ABI is cancer

my sides

Consider this:
Your project uses generic types/functions from 5 libraries. Each of those libraries uses generic types/functions from 5 more and so on. Often the can not monomorphized before your projects uses generics from your dependency libraries, because the type parameter passed down is dependant on an upstream type parameter. That can be quite a lot of work for highly generic code, like the one in the standard library.

Maybe if you're a windows fag, MSVC and its blatant disregard for Intel ABi reigns over there.
Huge C++ libraries like Qt have no problems on Linux.

That's actually nice to hear. It's high time.

>RAII is for library dev.
Only if you assume that "applications" are only written from prior existing reusable components, which is never ever the case. You constantly have to write new classes just to manage minute pieces of data since the language lacks try-finally just because "we have RAII instead".

template
struct Defer {
F functor;

Defer(F const &functor): functor{functor} {};
Defer(F &&functor): functor{functor} {};
~Defer() { functor(); };
}

void foo()
{
Foo f;
f.open();
Defer d = [](){ f.close(); };

f.bar();
f.baz();
}

>Haskell is better than C++
Oh lord

C++ noob here, what does [](){/*something*/} mean?

It's a lambda expression. It creates a function object which can later be invoked with operator().
auto function = [](int x){ return x * 2; };
std::cout

lambda that captures nothing and has no input parameters

int main(int argc, char** argv)

Not the worst, but int main(int argc, char **argv) is better style.

std::auto str(s.auto());

Why? Isn't it better to associate pointers with the type rather than the variable?

It's a shame that namespaces are so broken in C++.
I seriously hope they fix this with modules.

* binds to the identifier, not the type, because C/C++ is retarded
char* s, t; // doesn't do what you think

That isn't how the grammar works, and you'll make incorrect assumptions if you think that way. For example
int* p1, p2; // does not declare two pointers
Putting the star on the identifier is more consistent when considering array and function pointer declarations too.

Broken how?

>return EXIT_SUCCESS;

I love the smell of POO in the morning!

>char* s, t; // doesn't do what you think
I never declare multiple variables on the same line for this very reason in C/C++.

That has nothing to do with POO. Declaring macros for every constant is a C thing.

it's the only standard compliant and portable way, dipshit

then don't do multiple variable declarations on the same line.

there. ambiguity destroyed.

0 is also standard for success.

I agree with this dude. Avoid side-effects.

It's still inconsistent with the rest of the language. Writing declarations like this is heinous.
int main(int argc, char* argv[])

C++? Nah, I'd give her a D