C++17

>C++
Into the trash it goes

>>61016181
It's good. 17 years too late, but it's good.

Still using header files in the year of our lord two-thousand seventeen.

>>61016181
Only 6 more years until VC++ fully implements it. Can't wait!

I'd still have to deal with legacy code.

>>61016208
This.

>>61016207
u forgot /thread

When is Assembly 2 coming out?

>>61016181
>C++17
It doesn't matter anymore.

The language turned out to be one of the ugliest and unpleasant programming languages to deal with nowadays. It's a mess with everything mixed in with no regards to true standardization whatsoever.

Might as well use C# with an unsafe block wrapping everything.

>>61017313
New cpu extensions are being created all the time.

>>61016181
Garbage

>>61016181
What's even the point of using C++ these days? Maintaining legacy code? Name one reason to use C++ over C, you can't. Schools these days don't even teach C++ anymore, my school taught C and Java, c++ is just a clusterfuck dead end in the "evolution" of C.

>>61017502
>one reason to use C++ over C
It's impossible to write C that's guaranteed to be safe.

File: 1489904445277.gif (2MB, 250x187px) Image search: [Google]

2MB, 250x187px

>>61017528

>>61017528
M8 what.

Static analysis tools for C are way ahead of anything available for C++.

>>61017598
You don't need static analysis tools to write safe C++.
You don't need to litter your code with error checks and gotos to write safe C++.

>The final publication

Why?

>>61017502
>Name one reason to use C++ over C
I'll name six

1) STL containers -- no more reinventing the wheel or importing over-engineered third-party libraries to do stuff like storing things in a hash table

2) Exceptions -- write your code for the successful code path, allow the compiler to optimise for a successful code path, handle errors for what they really are: exceptions to the successful code path

3) RAII -- No more archaic concepts of ownership and initiator is responsible for cleaning up

4) Portable multithreading library (inb4 C11 threads, nobody implements them)

5) Regular expressions and sensible string manipulation, no more segmentation faults because you passed in a const char where a char was expected, or you forgot to free a strdup'd string, or you chopped your string into unusable garbage because you used strtok

6) Type inference

The seventh point would have been templates.

>Schools these days don't even teach C++ anymore
Wrong.

>my school taught C and Java
Your anecdote proves nothing. Your school might be absolute garbage for all we know.

>>61017528
Epic meme you got there pajeet

>>61017641
Because everyone now sees that C++ has turned out to be a bunch of shit frankensteined together just because it's maintainers are retarded boomers.

C++ is useless, use Rust instead.

>>61017764
/thread

>>61017700
Yet all of those points are just crutches for shit you can do in C in a way that actually makes sense

>>61017808
>Allowing compiler to easier optimise your code path because you no longer have to infest it with return code checking is "just crutches"

By all means, emulate C++ functions in C rather than just write C, if that somehow satisfies some severely autistic need you might have.

Also, I'm curious. How would you emulate type inference in C without relying on undefined behaviour?

>>61017808
But C is literally just crutches for shit you can do in assembly in a way that actually makes sense for the architecture you're running on.

>>61017502
Name one reason to use C over C++. 99% of the time C++ is a superset of C, and if you're not a retard, it's always better to have more tools.

Also, pretty much all C code is either garbage spaghetti, or a crude attempt at mimicking C++.

>>61017630
>> You don't need static analysis tools to write safe C++.

Yes. Yes you do. Any C++ project where safety is key uses static analyzers extensively, just take a look at the coding standards for any Nasa or DoD project. C (and historically Ada) is still preferred by many organizations for this task in many cases because it can often be proven to meet its specification with static analysis tools, while the equivalent level of static analysis for C++ is impossible in general.

>>61017844
>How would you emulate type inference in C
type inference is for retards, if you're doing any real programming you don't need that feature, just more bloated c++ shit
>>61017869
because I don't want retards like >>61017844 using auto variables and other frankenstein features

>>61016181
Professors will teach in C++98. If students use 14/17 features they will get a zero because the professor doesn't understand it.

>>61017502
It was used to program the f-22. that's more than enough reason.

>>61017963
>compile time type inference is "bloat"

You clearly don't know what the word bloat means.

Also
>he thinks type inference means slapping on "auto" everywhere
You're beyond retarded, see partial template specialisation, polymorphism, function overloading etc.

>>61018018
The F-22 was programmed in ADA actually.

You are probably thinking of the F-35, whose software development cost just happens to have gone way overbudget compared to all previous planes. ; )

>>61017355
>hurr no standardization

why the fuck would you need this in a language? it's not a program in of itself you fucking idiot. limiting type choices for the sake of doing so is the fidget spinner of program designs.

>people saying C is better than C++

this has to be bait. you can't even make classes in C.

>>61017963
>you don't need the feature
Not an argument. You don't need anything besides assembly language.

Auto variables are great when the type is obvious and the typename is long. But that's not really what he was talking about.

C++ is bit bloated, with this 17th iteration, they really need to replace it with something better and more streamlined with modern computers.

File: 1488834220699.png (279KB, 512x384px) Image search: [Google]

279KB, 512x384px

>>61018044
>>61018105
>M-MUH FRANKENSTEIN FEATURES
face it, people have seen through c++'s shit, it was a phase and now we're all over it

File: 1496143118183.png (17KB, 592x533px) Image search: [Google]

17KB, 592x533px

>>61018073
>why the fuck would you need standardization

>>61016181
>still no networking stack

At least they put in <filesystem>

>>61018169
>face it, people have seen through c++'s shit, it was a phase and now we're all over it
Then explain why C11 is adopting _Generic and why C99 basically copied C++'s minimal scoping idiom?

>>61018169
>doesn't understand what said idioms and features are
>"better call them frankenstein features, that will surely shut him up"

Quality reply, anon.

In other news, GCC Steering Committee green lights D support.

>>61017355
>angry rusthomo

>>61016207
>>61017272
>>61017355
>>61017373
>>61017502
>>61017598
>>61017592
>>61017780

>BRAINLETS

>>61019138
>>61019658
>Brainlet C++ajeet

>>61016181
C++ is a fucking piece of garbage

>ITT: People who are too dumb to program modern C++ and understood it's power bash on C++

>>61021113
Your post would sound a lot more convincing it if wasn't written in pajeenglish.

>>61019679
t. Nodejs web artisan

File: C++.jpg (343KB, 1200x487px) Image search: [Google]

343KB, 1200x487px

>>61016181
>What are your thoughts on it?

>>61017866
This.
The C anon is just a retard.

>>61021248
>t. std::<<<POOst>>> pajeet

>>61017502
>Name one reason to use C++ over C
higher order functions in C (like qsort with a nontrivial comparator) discard type safety and take a large function pointer overhead. std::sort crushes qsort

>>61021275
t. Mozilla JUST evangelist (non cis) pronouns are tho thom thoms thomselves

>>61017808
>Yet all of those points are just crutches for shit you can do in C in a way that actually makes sense
it makes sense to write giant string interpolation macros to generate the code for basic fucking data structures?

>>61021297
Okay, Mozilla JUST evangelist

>>61021275
Error at line 2, column 10: Expected an identifier, found <

>>61016181
>C++
Belongs to >>>/trash/

>>61017355
elegance is a buzzword, like "disruptive" or "innovation." hell, you might as well talk about "beautiful code"

>>61021344
>>61021250
Name 1 (one) reason

File: 1495641113909.png (72KB, 1016x98px) Image search: [Google]

72KB, 1016x98px

>>61021353

>>61021360
M O D U L E S
O
D
U
L
E
S

File: 1497827764994.png (537KB, 1920x1080px) Image search: [Google]

537KB, 1920x1080px

>>61021360
Unreadable code

>>61021360
The split between source and headers, which makes project management quite slow. If you make all header libraries you’ll have a lot of copied code – the binaries will be larger. You’ll have to recompile that code every time you want to use it. And the split between the two is always troublesome – you can’t add a new field to your class without a few CTRL-TABs until you find where to write the proper definition.
You still can’t write template code in .cpp files. You have to write code in the headers. If you mix that with some #ifdef & friends, it becomes a mess quite fast. Not to mention that you include content that is really implementation dependent.
C++ still uses the C preprocessor. That is the first feature that should’ve gone from the language. If you think about it, the header should represent the features that your object offers and not a letter more. However, people ended up delivering these huge files that can be used everywhere even if they will be used in one place and one place alone.
Namespaces are useless and make the code way too verbose. Instead of making your code cleaner and clearer, the programmers will end up doing a using namespace xxx. If you don’t believe me, look at how the code for using the duration_cast looks without some usings (auto only hides the dirt under the rug).
Lack of ABI makes it impossible to deliver C++ components without a C interface. If you don’t, you’ll crash quite fast when you use the flag -fsuper-duper-new-feature because you should’ve used the flag -fsuper-duper-extra-cool-newer-feature

Theoretically you write stuff in one place and you should be ready for… wait a minute. Did you really use <unistd.h>? And did you dare use the std::to_string call? You’re stupid, that doesn’t work under the C++14 compiler under Windows except for Microsoft’s. Why? Well, why not? We love to be arbitrary like that.

Portability is a hard thing in C++. You have to work for it, you have to make sure that you’re doing special stuff for it. C++ is amazing, don’t get me wrong, but in the past 15 years the only non-portable code I’ve seen was written in C++, or was caused by the interaction with a C++ native layer. C++ is mostly portable except when it’s not.

I think it’s easier to achieve true portability under C# or Java, because there’s an “all or nothing” feeling about them – either they have the whole core system ported, or they don’t work at all. That said, you still end up using C/C++ layers, and I love C++ for that, but remember, I offer a look at the bad part.

I like to call myself stupid. It’s obvious that I am, that’s why I became a programmer – to make computers do the work for me, because I’m not to be trusted. That’s the case for my instant crush for C# – they have one simple model to refer resources – pointers, hidden by the lack of special notation – moron friendly, so it was a natural match.

I wanted to start a Breakout clone in C++. I had an array of widgets. Those widgets had textures. Those textures were copied over and over and over again, because containers can do that, so I had to go back to rethinking the storage class for the widgets.

I explained about the productivity hit I have when I have to search for a header file and add a few bits there, then go to the constructor (another file) to initialize it, then implement its usage in the header file (because templates) then go back in the other file to make sure another function makes proper use of it. If you put this in the context of IDEs unable to add a field to a class or rename a field of a class…

You can’t just take a DLL and use it as such. You need to have a “development package” which consists of pre-built binaries and huge header files that you need to compile with certain flags.

>>61017502
My university teaches machine learning courses in C++

C++ has a bool type. It is the most idiotic boolean type you will ever see. Firstly, you can use any integral type in a place where you need a boolean value. This leads of course to programming errors like if (i = 2). But if you actually decide to use the bool type, you run into funny stuff, for example: An uninitialized bool variable may be neither true nor false - depending on your compiler, if you define bool a;, both a and !a may evaluate to true.

Enums are really dumb. Take for example:

enum traffic_lights {
    RED     = 1,
    YELLOW  = 2,
    GREEN   = 4
};

As you may expect, this is just an int with some named constants. You can declare multiple values with the same value, you can assign int value to it. And if you do YELLOW++, you don't end up with GREEN, but with a value that isn't defined in the enum (but doesn't raise an exception either). You also cannot iterate over existing enum values. At this point, this is just useless syntax sugar for

#define RED    1
#define YELLOW 2
#define GREEN  4

Oh, did you know, C++11 does introduce enum class. It fixes none of the issues described above, but makes you prefix the enum values with the name of the enum. Well done.

You have to put the complete implementation into the header. This slows down compilation considerably, because all the fucking implementation of the fucking template is parsed every fucking time it is fucking used. Oh, you can of course try to use precompiled headers and open the door to hell.
You can use the keywords typename and class for template parameters, and they do exactly the same. You can put a class into a typename parameter, and you can put a non-class into a class parameter. So what's the point?

If you use a template parameter for defining a type within the template implementation, you often have to put typename in front of it. Example:

template<typename T> a() {
       typename std::vector<T>::iterator t;
    }

It wouldn't compile without the typename. And if you miss it, the compiler will probably give you an error that is extremely hard to understand. If you get some huge error message when compiling a template implementation, add more typename.

You cannot constrain type parameters. For example, you cannot declare that a type parameter has to be a child class of some other class. You just assume random things about the template type, and if someone else uses in a way you didn't plan for, he may get error messages pointing to the implementation of your template. There was a feature called Concepts that was planned for C++11, but it was dropped (and may come in C++14).

Support for value parameters is very limited. For example, you cannot declare a template taking a parameter of type std::string. You can declare a template parameter of type char*, but you cannot directly pass a string literal to it. You have to define a char* constant with external linkage somewhere and use that as template parameter.

The smart pointers (std::unique_ptr et. al.) are a sorry excuse for a missing language feature. A class usually has no idea about whether it is accessed with a smart pointer or not, but when it passes a reference to itself somewhere, it needs to know. So you suddenly have to derive from std::enable_shared_from_this to be able to convert this to a smart pointer.
Iterators are simply a huge mess. To implement a custom iterator, you kind of need the iterator module from the Boost library if you want to have it done till the end of the year, and even that is really complicated to use.

C++ is so bad that makes Java look good. I don’t like Java. I think it’s too verbose and lacks several features I expect from a high level language, most of its advanced techniques (design patterns, reflection, xml frameworks) being just patches for those absences. But all in all, Java is a language that makes sense. C++ is not.

It’s backwards compatible with C. Seriously Stroustrup? What on earth were you thinking?

The compiler never helps. The error messages never make sense, and in most cases ignoring them is the healthier choice.

C++ Strings suck. They suck so hard that they’re not a built-in type, they’re not even used in the libraries, so you have to use stuff like c_str().

Streams suck. The syntax is weird, they’re just too many of them, I seem to recall there was some diamond inheritance weirdness going on over here… I’d rather stick to C files.

STL sucks. The iterators are error-prone and tedious to use. You have to write a lot to use most of the methods of the containers, even for basic stuff, ending up with code like:

for (map<string, string>::iterator it = myMap.begin(); it
        != myMap.end(); it++) {
    string key = it->first;
    string value = it->second;
    //...
}

Don’t even get me started on templates.

Whether you use them or not, namespaces are a pain in the ass. If you do use them, the code gets confusing and annoying to write (and it’s easier to get compiler errors when you forget to specify the namespace). If you don’t use them in your code you still need to add the using namespace std bit everywhere or you get syntax errors that as usual don’t point the problem.

Why are there references? One can’t consistently use either references or pointers, you are forced to mix them in certain contexts

The language is not consistent. An example: you instantiate classes in the stack like:
MyClass myObject(arg1, arg2);

But what if your class has a constructor that takes no arguments? You might expect it to work like this:
MyClass myObject();

But no, the correct way is omitting the parenthesis:
MyClass myObject;

You might find yourself wondering for half an hour why your program won’t compile for things like this.

Methods are not virtual by default. Premature optimization is the root of all evil.

It’s copy-paste oriented. Code duplication is trouble. In C++, the standard way to code a class is to copy all the method prototypes from the .h to the .cpp file, adding the MyClass:: bit. Even with just a couple of getters and setters, theres a whole lot of typing and copying. This is not only tedious, but one of the places where more errors occur. And remember, the compiler speaks its own language.

You can’t refactor. Unit testing frameworks are awkward to use and setup. Creating a class and making it compile is so hard that most of the time you stick to add an if.

>>61021418
I know a lot of the stupid bool issues were fixed in C++ 2017, but I don't know anything about enums.

>>61017502
My school taught Java, C++, and some C for basic OS shit. The new classes are learning Python, Java, C/C++.

>>61017355
brainlet detected.

It is backward compatible with C. See above.
But still with subtle differences that make some C code unable to compile in a C++ compiler.
The standard libraries offer very poor functionalities compared to other languages' runtimes and frameworks.
C++ doesn't enforce a single paradigm. Neither procedural nor object-oriented paradigms are enforced, resulting in unnecessary complication. [Some people consider this as an advantage.]
Too hard to implement and to learn: the specification has grown to over 1000 pages.
Everybody thus uses a different subset of the language, making it harder to understand others' code.
Not suitable for low level system development and quickly becomes a mess for user level applications.
The standard does not define exception handling and name mangling. This makes cross-compiler object code incompatible.
No widely used OS supports the C++ ABI for syscalls.
What is 's', a function or a variable?

std::string s();

Answer: it's actually a function; for a variable, you have to omit the parentheses; but this is confusing since you use usually the parentheses to pass arguments to the constructor.
The value-initialized variable 's' would have to be:

std::string s; /* or */ std::string s{};

There is try but no finally.

Considered a "feature" because RAII is supposed to be the main means of resource disposal in C++. Except a lot of libraries don't use RAII.

Horrid Unicode support.
Operators can be overloaded only if there's at least one class parameter.

This also makes impossible concatenating character array strings, sometimes leading programmers to use horrible C functions such as strcat.

catch (...) doesn't let you know the type of exception.
throw in function signatures is perfectly useless.
The exception system is not integrated with the platform: dereferencing a NULL pointer will not throw a C++ exception. [Some people consider this as an advantage.]
mutable is hard to use reasonably and, since it fucks up const and thus thread safety, it can easily bring to subtle concurrency bugs.
Closures have to be expressed explicitly in lambda expressions (never heard about anything like that in any functional language).

You can use [=] and enclose everything, but that still adds verbosity.

The nature of C++ has led developers to write compiler dependent code, creating incompatibility between different compilers and even different versions of the same compiler.
An std::string::c_str() call is required to convert an std::string to a char*. From the most powerful language ever we would have all appreciated a overloaded operator const char* () const.
Developers may have to worry about optimization matters such as whether declaring a function inline or not; and, once they've decided to do it, it is only a suggestion: the compiler may decide that was an incorrect suggestion and not follow it. What's the point? Shouldn't developers worry about optimization matters?

To rectify this nonsense many compilers implement __forceinline or similar.

Templates are Turing-complete, hence compilers have to solve the halting problem (undecidable) to figure out whether a program will even compile.
Unused global symbols do not generate any warnings or errors, they are compiled and simply increase the size of the generated object file.
Changes that could actually standardise key functionality or substantially improve language usability often take a TS detour to nowhere. Technical Specifications seem to be where good ideas go to die, often for political reasons, or some country didn't like it.
The fact export was never supported means you have to include the entirety of a template in your library header. Traditional C (and most other C++ code) separates implementation and prototypes.
Every problem with the language is resolved by adding a new feature.

I started programming back in the early 1970's with Basic. I am not a great programmer but in Basic I can pretty much kind of get the job done. I am aware of modern programming ideas (years ago I did a little home programming in Pascal) like subroutines, reusable code, etc. but C++ seems terrible limiting in its structure for doing the programing easily . There are no subroutine calls. Labels seem to be not doable (no real goto statement... I know that is a no-no). And the Ardunio compiler is very poorly documented as to the required structure.

I got my program to compile but I am not ready for testing as some of the hardware is still in the mail to me. What is missing is a cookbook on the structure of C++ with complete programming templates. Examples don't do it! A list of variable types, functions, etc, is not a guide to making a program. Most of the examples vary in implementation enough to lead to confusion (at least for me). So here was my approach, right or wrong, you tell me.

The main program is in a loop looking for a start switch closure. It then calls a custom function (I guess that is a C++ subroutine??) that looks for one of four detector triggers or a stop switch closure, in a loop. Each detector trigger calls one of two different custom functions to energize and de-enrgize some relays. It then returns to the detection process. It only returns to the startup loop if it finds a stop switch closure in the detection process.

Utterly BTFO

Ok fine c++ sucks. Give me an alternative language that
>compiles to machine code
>has portable threading
>has no GC
>isn't C

http://www.quinn.echidna.id.au/quinn/C++-Critique-3ed.pdf

>>61018164
>replace it
Every company has their flavor of C++, yet none will ever replace it. Go, Rust, D, Spec#, you name it.
Either Stroustrup or Sutter had it right--you could build another language that does things better than C++, but no one will adopt it. So you just add onto C++ to make it better.

Going the Python route would just make everything worse. That would literally be the worst possible choice.
>fragmenting your userland to the nth degree because you were too brainlet to design your language properly from the beginning

>>61021510
C++ has GC and is going to include GC, it's a work in progress

>>61021384
>You still can’t write template code in .cpp files. You have to write code in the header
you can write template code in .cpp files. you can also expose it to other compilation units if you declare the explicit type in the header

the only thing you can't do is expose the uncompiled template from within a compiled unit, which should be fucking obvious. the correct place to put uncompiled library code is in the library header. then you complain about bloat in the header and "larger binaries," but this is literally the trade off of shipping uncompiled template code. if you don't like it then build your library around some other form of polymorphism? you're complaining about the drawbacks of different choices without identifying any of the benefits

>Namespaces are useless
man

TLDR: C++ is so bad it makes Java look good

>>61021537
/thread

>>61021537
I'll make that my wallpaper.

Fuck C++ and Fuck Bjarne. Bjarne is a Microsoft shill

>>61021510
Threading? sorry what? oh yeah use PThreads or boost..What is boost? some other day man..long story

>>61021487
>Machine languages are Turing-complete, hence exec has to solve the halting problem (undecidable) to figure out whether a binary will even run.

>>61021569
>.What is boost?
std::beta

First, pop quiz: What is the value of this C++ expression:

10.0f + true ? 1.0f : 2.0f;

If you answered 11.f, you're wrong. The actual answer is 1.0f.

The ternary conditional operator (?:) has very low precedence (See http://en.cppreference.com/w/cpp/language/operator_precedence, it's right down in box 15). The plus operator has higher precedence, so the expression gets evaluated as

(10.0f + true) ? 1.0f : 2.0f;

This code, which is a gross violation of any reasonable type system, compiles without warning! You can add 10.0f to a boolean value apparently and it's just fine! Of course the reason is that true gets converted to the integer 1, for historical C reasons presumably. And then the resulting value of 11.f effectively gets converted back to a boolean! (to evaluate the condition)

The thing that sucks about C++ in this case is the automatic conversion of true to 1, which allows 10.0f + true to pass the type checker. Automatic conversion/casting of types in a language is very dangerous. Each case should be closely considered by the designer(s). And in this case it's just a bad idea. Fuck you C++.

>>61021589
horrible

>>61021589
The result of that expression is obvious though

Unlike C or D, C++ and Rust were written by illiterate people. There are some design flaws here and there.

>>61021418
You are basically complaining that C++ isn't C#.
There are good performance reasons for those design choices.

>>61021752
That has N O T H I N G to do with performance optimization. Bjarne is uneducated in compiler engineering

>>61017988
go to a real school retard

There are only two kinds of languages: the ones people complain about and the ones nobody uses.

This guy is basically too retarded to use C++ properly.

>>61016181
Still no modules. Just give me modules and I'll be happy. That's all I want.

>>61021826
>C++
>Monads
haha

>>61021833
>>61021797
Fucking idiot, you can't even read and now desperately controlling damage.

>>61016181
>C++
No, thanks.

>>61021522
Python's main fragmentation is 2.7 and 3.0. And with the current day, many of the third party scripts are updated to use the latest python 3.X, so compatibility shouldn't be too much of an issue.

>>61016208
>17 years too late
Didn't you like c++11 and c++14 or what?

>>61021856
I read all of it.
1. It's an outdated rant, some of those "issues" have since been fixed.
2. I've never seemed to have experienced the problems you have, maybe it's just because I write non shit code, and I actually well understand the language I program in.

>>61021936
>it was fixed I swear
STILL NO MODULES

>>61017929
>a subset of C
FTFY

C++ has two standard libraries and both of them suck

This thread shows that modern C++ is too complex for /g/ autists to comprehend.

Just compare C's qsort with std::sort. The latter is way faster because C++ can actually infer the comparison function, whereas C has to call it each time.
>http://www.martin-ueding.de/en/articles/qsort-vs-std-sort/

The nice thing about C++ is that it actually doesn't FORCE you to use all the features it has. You can still do well without all the seemingly unneccessary features.
>But why not just use C :(((
Because that's retarded. Everything that can be done in C can be done in C++ but easier and faster. Why are you autists fuzzing about some idealistic "pure" language?

>>61017808
If you mean macros then fuck you.

>>61021962
>modern C++
Shit is still shit. The feces that came out of people back in 1500 is still the same feces that came out in C++17

>>61021962
>infer
You mean inline?
Infer doesn't make sense in that context.

kill it with fire

>>61021988
C++ajeets are not good at English

>>61021962
>Just compare C's qsort with std::sort. The latter is way faster because C++ can actually infer the comparison function,
Visible cringe. Average C++ faggot

>>61021962
Complexity is not a desirable language trait.

>>61021962
>Just compare C's qsort with std::sort. The latter is way faster because C++ can actually infer the comparison function, whereas C has to call it each time.
False, nobody stops the compiler from optimising that.

>>61021373
>first two points
Well no shit, this is called a "calleable".

Also Scott Meyers both likes C++ and constructively criticizes it.

>>61021418
>enum class don't fix it.
Except it does and makes it type safe and less prone to name collisions?

File: tmp_636-1486093100989-830327797.jpg (23KB, 464x434px) Image search: [Google]

23KB, 464x434px

>>61021450
or do it the less verbose way

for (pair<string, string> p: myMap) {
    string key =p->first;
    string value = p->second;
    //...
}

>>61022057
or just for(auto p: myMap)

>>61022011

Compilers are shit at inlining bare function pointers. They're much better with lambdas, which you can only do with std::sort.

>>61022072
It's just as trivial.

>>61021510
While I like C++, Rust tries to be exactly that.

>>61021589
You can write horrible code in every language.

>>61022096
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.

>>61022087
Rust changes a bunch of shit for no reason. Some of it works well like enums but the rest is just ugly. A lot of the ugliness is due to the restrictions of the borrow checker which often isn't worth it.

>>61022118
I don't know Rust, never tried it. Anyway, it matches the criteria.

>>61022111
>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.
Rekt and burried

>>61022011
>>61022085
Then why is qsort slower than std::sort?
http://www.martin-ueding.de/en/articles/qsort-vs-std-sort/

>>61022148
Because the implementation that this article uses does not optimise both of them the same way, duh.

>>61016213
each compiler will implement its own version of modules, and then once its been use enough the standard will pick one to choose (probably microsofts version)

>>61022161
Hence qsort is slower, because it's harder to optimize.
The implementation used is both GCC and LLVM. qsort loses in both implementations.

>>61022189
>Hence qsort is slower
In that specific implementation.

>because it's harder to optimize
This is wrong.

>The implementation used is both GCC and LLVM. qsort loses in both implementations.
Okay?

>>61022197
Lmao retard.
Go be braindead somewhere else, you clearly don't have the IQ points to participate in this thread.

>>61022212
Is this how you try to argue once you have lost the argument?

>>61021363
That is completely fine and if you don't understand it it's your problem.

>>61022197
>>61022161
>>61022085

>cfag in denial

>>61022228
Just stating facts, man.

>>61022227

Understanding it isn't even necessary. You never have to write code like that and equivalent code in C is impossible to write.

>>61022222
You are honestly completely braindead if you thought >>61022197 was a good argument.
GCC and LLVM are the two best and most optimized implementations of C and C++ we have.
In both implementations, qsort loses.

Why does qsort lose if C is supposed to be faster than C++?

>>61022250
>are the two best
No, not really but whatever.

>In both implementations, qsort loses.
I am unsure what you try to prove with that.

>Why does qsort lose if C is supposed to be faster than C++?
Both C and C++ are languages, languages do not have speed, implementations do.

>>61022235
"Facts" you stated:
>NUH UHH, C IS FASTER WAAAAHHHH

Facts I stated:
Real benchmark showing qsort losing to std::sort in both GCC and LLVM.

>>61022270
>>NUH UHH, C IS FASTER WAAAAHHHH
Whom are you quoting? I never stated that.

>Real benchmark showing qsort losing to std::sort in both GCC and LLVM.
Which was not really relevant to the discussion?

>>61022265
>No, not really but whatever.
Yes, really. We have no better compiler than GCC and LLVM.

>I am unsure what you try to prove with that.
C is slower here.

>Both C and C++ are languages, languages do not have speed, implementations do.
The design of the language greatly influences the implementations ability to optimize.

A language being faster than another means the language is easier to optimize than the other.
C is often stated to be faster because it's easier to optimize, but this is being shown to be incorrect in the qsort vs std::sort benchmark, due to the way C++ is designed.

But anyway, there's not much point in arguing with retards. As a former C programmer, I thought C programmers were more intelligent than this, but I guess not.
Even my respect for Rust is higher than C at this point.

>>61022279
>Which was not really relevant to the discussion?
You are literally retarded.

>>61022310
>Yes, really. We have no better compiler than GCC and LLVM.
This is factually false.

>C is slower here.
Sure, that specific example of C is slower in that specific implementation, so what?

>The design of the language greatly influences the implementations ability to optimize.
The easiness I would say.

>A language being faster than another means the language is easier to optimize than the other.
False, it might also mean that more effort was spend on the other language.

>due to the way C++ is designed
The design of C++ is irrelevant to that.

>But anyway, there's not much point in arguing with retards. As a former C programmer, I thought C programmers were more intelligent than this, but I guess not.
Not a C programmer but whatever, keep trying to insult me. It won't make you correct magically.

>You are literally retarded.
It's still not relevant to the discussion.

>>61021418
>if (i = 2)
dont do stupid things like this
>An uninitialized bool variable
or this
>You can declare multiple values with the same value
not an issue
> this is just useless syntax sugar for
its scoped which is useful.
>enum class. It fixes none of the issues
its type safe, and if you want operators implement them yourself.

>>61016181
C++ was a mistake, C is superior

>>61022332
>this discussion

>>61022265
>languages do not have speed, implementations do

This type of thinking gave us a few decades of delusional promises that Java would one day be faster than C or C++.

>>61022265
>languages do not have speed, implementations do.
Putting aside the fact that this is an irrelevance since you can't point to a single implementation where qsort is faster, it's also misleading.
Languages and low level languages especially do not live in isolation from their hardware. The features they offer exist to meet the designs of the platforms they're targeting. The features they implement are responsible for the techniques the implementations are able to use. In this case, the inherently static nature of C++ templates is responsible for all existing implementations of C++ being able to reason more effectively about whether function parameters may be inlined to increase speed.

>>61022368
>n-not an issue
Is your ass in pain too?

>huh huh C++ is not like my C#
The programmer's stupidity is not the language's fault.

>>61022423
Java programmers are unable to make proper implementations, did you expect anything better of them?

>>61022424
>Putting aside the fact that this is an irrelevance since you can't point to a single implementation where qsort is faster
I am unsure how me not posting an implementation where qsort is faster than std::sort makes my point irrelevant.

>being able to reason more effectively
And this is wrong, there is no significant reason on why the implementations would be inherently able to reason more efficiently in the case of the C++ example.

>>61022469
>Java programmers are unable to make proper implementations, did you expect anything better of them?

The JVM is written in C++.

>>61022469
>Java programmers are unable to make proper implementations
The JVM is written in C++, by C++ programmers, retard.

>>61022455
This. Only stupid substandard programmers use C++

>>61022504
>>61022524
1: The JVM is not the only part of a Java implementation, but surely you knew that already.
2: Just because they also knew C++ doesn't mean that this makes them somehow smarter you turd.

>>61022469
>there is no significant reason on why the implementations would be inherently able to reason more efficiently in the case of the C++ example.
Templates are a compile time feature by design. Function pointers are a runtime feature by design.
You could make a C++ compiler that generates templates at runtime and a C compiler that resolves function pointers at compile time. But the languages aren't designed to accommodate this and that's why no implementations do this.

>>61022534
>Only stupid substandard programmers use C++
And yet this thread only shows that C programmers are absolute fucking retarded with an IQ below 80.

See: every post made by >>61022469

>>61022545
Your comment was stupid to begin with because optimization is a CS problem.

>>61022564
If C programmers are retard, C++ programmers are considered subhumans.

>>61022562
>Function pointers are a runtime feature by design
And this is false.

>>61022564
There is absolutely no need to be upset just because you lost an argument.

>>61022576
What?

C programmers are literally braindead idiots. They have no ability to understand anything.
This thread proves it.

>>61022586
Techniques like escape analysis are algorithmic in nature.

>>61022620
Okay but I am unsure how this is relevant.

>>61022606
Did you forget a ++?

>>61022629
>Okay but I am unsure how this is relevant.

Because you originally made a comment about it being somehow related to the programming language, and then tried to back it up.

>>61022629
>C is shown to be slower in a situation, due to it's design.
>Goes into full damage control, denies everything, plays dumb.
Just admit your loss. C++ and even Rust has a greater ability to optimize than C does.

>>61022606
C++ is for braindead programmers that want to get into real programming

>>61022659
>C is shown to be slower in a situation
>That must mean C is slower
While C++ is written in C

>>61022656
>Because you originally made a comment about it being somehow related to the programming language
Nope, I made a comment concerning the intelligence of Java programmers.

>>61022659
>C is shown to be slower in a situation, due to it's design.
Wrong, a specific implementation of C is shown to be slower in a situation due to its lack of optimisation in that specific case.

>Goes into full damage control, denies everything, plays dumb.
I just continued the discussion normally.

>>61022674
>While C++ is written in C

GCC recently switched to C++, if that's what you were referring to.

>>61016213
>>61021837
how are modules better than header files?

>>61018181
you can write crossplatform win32-*nix code with a few defines really easily since winsock has the BSD socket API, just with different names

>>61022395
>>61021879
>>61021344
>>61021250
>>61019679
>>61017502
>>61017373
show me some of your projects
I'm genuinely curious

>>61022695
>GCC recently switched to C++,
Deluded C++ pajeet. There are more Ada in GCC than C++

>>61022695
Since 4.8

>>61022669
I've done plenty of real programming, and I still do.
I used to use C a lot, I use C++ now.
I do kernel programming in my free time. That's as "real programming" as you can get.
Get fucked.

>>61022674
Both LLVM (full) and GCC (g++) are written in C++.

>>61022685
>due to its lack of optimisation
Which in turn is due to the lack of the languages ability to be optimized.
The SAME implementation implementing the SAME algorithm in two different languages, and one of them ends up being faster than the other.
Think about it.

>>61022698
My work is closed source, NEET trash

>>61022705
Check again

File: Screenshot.png (56KB, 1401x420px) Image search: [Google]

56KB, 1401x420px

>>61022713
>Both LLVM (full) and GCC (g++) are written in C++.

>>61022705
you're the only pajeet here

>>61022713
>Which in turn is due to the lack of the languages ability to be optimized.
I will disagree, just because an implementation does not optimise well a specific case does not mean that it's "due to the lack of the languages ability to be optimized".

>>61022727
github randomly considers .h files as C++ leading to many C-only projects having 10% or so C++.

>>61022716
of course
it's not that you don't have a single presentable project at all

>>61022756
Probably you are upset that I'm on salary. No biggie.

>>61022695
>>61022727

File: 1489243106285.png (30KB, 1011x251px) Image search: [Google]

30KB, 1011x251px

>>61022727
Yes, can you read? I explicitly said (g++) referring to the fact that it's only the g++ part of GCC that's written in C++, supporting my point that C++ is not written in C.
GCC is huge, and supports many languages.

Pic related is LLVM, what's not written in LLVM (not sure why there's so much) is entirely written in C++ and assembly, the others are tiny and irrelevant.

Thanks for proving my point, though.

>>61022773
https://lwn.net/Articles/542457/

>>61022778
BWAH WOW C++ compiler written in C++ woooah

Dumb C++ pajeet. GCC is and always was written in C. Take your M$ tier misinfo to plebbit.

>>61022737
>does not mean that it's "due to the lack of the languages ability to be optimized".
It does when the same implementation could perform better optimizations in another language.

You are in massive damage control right now.

>>61022800
That article was a lie, I've given you live, fresh proof from a few seconds ago

Cfags are getting pretty desperate, lmao.

>>61022816
Obviously the existing code wasn't rewritten from scratch. But now that C code is being utilised as just being a subset of C++.

>>61022825
C++ is a historical failure.

>>61022807
>It does when the same implementation could perform better optimizations in another language.
I fear that this does not make sense as it is not the same implementation.

>You are in massive damage control right now.
Just because you disagree with something it does not mean that it is not correct.

>>61022838
So much for """switching""" to C++.

>>61022804
>GCC is and always was written in C.
Until it moved it's g++ portion to C++.

>>61022839
How so?

>>61022849
>it's g++ portion to C++
So just like many other language?

>>61022859
Bjarne created C++ to replace C.

>>61022825
>Cfags
Rustyfags are also in the midst make no mistake.

C++ should be euthanized nonetheless.

>>61022865
And it has, for me. So it's succeeded in that regard.
But of course, most people are retarded, and will stubbornly refuse to move onto better languages.

>>61022845
You can write valid C++ using only C features, but it's just a bit of a stupid thing to do out of choice.

>>61022882
>, for me.
C++ has been replaced by JS by webdevs a long time ago as well.

>>61022765
of course
it's not that you don't have a single presentable project at all :^)

>>61022756
>>61022957
>Ass flustered C++ pajeet

>>61021934
C++11 was a major overhaul, but all the features in C++17 was already discussed when they proposed C++11. And a majority of these things were also discussed for C++03. So yeah, they should have pushed for more earlier.

>>61022965
Where do you work?
What language do you use?

>>61023012
Telenor. I use C at work, they use other languages as well. Why?

>>61023016
Why do they use C over C++?

>>61023016
Telenor bruker masse C++ din jævla dust.

t. tidligere telenor ansatt som skrev C++

>>61023030
They don't, anon is lying his ass off.

>>61022965
>C++ pajeet
How is this even possible?
C++ is a superset of C.
You still need to know C to use C++; in fact, C++ is a lot more complex than C

>>61023030
They do use C++, but not as much. C++ programmers unmaintainable garbage.

Heck, there is a team that uses Rust for experimental case.

>>61023051
De bruker mer C++ enn C, slutt å lyve.

>>61023062
>>61023042
How would you know, you don't even work any more

>>61023044
>C++ is a superset of C.
t. pajeet

>>61023072
I quit 6 months ago for fuck's sake. It's not like they suddenly decided to rewrite their entire stack and over 500k lines of code in some meme language in six months.

Only /g/ would be so retarded that they believed this.

>>61023093
The entire stack is NOT written in C++, wtf are you on about?

>>61023103
They have multiple stacks, as they have multiple softwares and libraries. Stop pretending to be retarded, I never said EVERYTHING was written in C++.

It's not like Telenor only has one piece of software, you flaming retard. I was clearly referring to the project I worked on.

>>61023118
>>61023103
And yes, they also have loads of stuff written in Java. They have more Java code than C++ and C combined. Same for Python.

>>61023126
>>61023118
Then you should also know why we went through the lay-off

>>61023157
The layoff was several years ago, dude. Also, Telenor employed ~150 fucking Indians last year (and expanded their outsourcing teams in India). This is partially why I quit, even though most on my team were Norwegian (and some few from other places in Europe), I don't want to work for a company that's run by a bunch of blåruss with no idea what they're doing.

>>61023078

Pretty much is, with the minor exception of making doing stupid shit explicit.

>>61016181
>What are your thoughts on it?
no modules or reflection / 10

Fuck the committee.

In the third world war it's c vs c++

>>61023501
>reflection / 10
#include <type_traits>

>>61021687
D is a million times worse than C++
>dude gc, lmao

RAII is literally one of the best things about C++ and they just ax it making a shitty standard library that fails if you turn of gc. Fuck D.

>>61022057
>>61022071
>C++17 thread

for (auto [key, value]: myMap) {
    //...
}

>>61016181
more boost shenanigans based on template gymnastics like chrono?

>>61023626

This.
D is not a C++ killer. It's C# with some metaprogramming and no VM.

>>61023626
>RAII is literally one of the best things about C++
Which D has

>standard library that fails if you turn of gc
You can still use stdlib without GC. D doesn't try to do the stupid mental gymnastics stunt like trying to replace C, which C++ failed to do. C++ is create by an uneducated person, D wasn't

>>61023540
Not real reflection. I want to get a function pointer to a function and associate it with a string at compile time.

>>61023662

>C++ sucks because it can't replace C
D has replaced nothing and is used by nobody.

>>61022674
>While C++ is written in C
Nope, all major compilers are written in C++. Even MSVC's standard C library (you read it well: C library) was reimplemented in C++ some time ago to make the code cleaner and faster.
http://blogs.msdn.com/b/vcblog/archive/2014/06/10/the-great-crt-refactoring.aspx

File: 1491081808903.jpg (56KB, 945x482px) Image search: [Google]

56KB, 945x482px

>>61023686
>C++ sucks because it can't replace C
Of course. The illiterate retard that created C++ claims so.

>>61023697
>all major compilers are written in C++.
GCC is C. The fucking kernels are in C. C++ is a failure. FAILURE

>>61017502
It's actually feasible to write a large program that human beings can read and do so pretty quickly.

>>61023697
>MSVC's C library is implemented in C++
Fucking lol.

>>61023686
C++ is a mediocre language. D, by design, is simply better since it was created by actual compiler engineers, not a salty codemonkey

>>61023717
C++ is anything but readable. The language has had to wait 16 (SIXTEEN) years to get a barely functional refactoring tool. It should give you an idea.

>>61017272
>/threading your own post

How new are you?

>In May 2010, the GCC steering committee decided to allow use of a C++ compiler to compile GCC.[3] The compiler was intended to be written in C plus a subset of features from C++. In particular, this was decided so that GCC's developers could use the destructors and generics features of C++.

LOL, so much for those FRANKENSTEIN features, amirite?

>>61021424
>You cannot constrain type parameters. For example, you cannot declare that a type parameter has to be a child class of some other class.
This is actually in most compilers now as Concepts TS.

>>61016181
Another 19 years till vector<bool> fix

>>61023790
Now they should include C++'s native garbage collection support

>>61021453
>Methods are not virtual by default.
Do you have any idea what that would do to performance? There's a very good fucking reason they're not virtual by default.

>>61023814
Are you slow or something? That's exactly what they mean when they use C++ destructors. It literally means that they are relying on RAII.

>>61023626
>>dude gc, lmao
http://en.cppreference.com/w/cpp/memory#Garbage_collector_support

>>61023884
>reference counting is the same as a non-deterministic thread halting execution at random points in order to do a costly breadth first search of memory references

/g/ doesn't know shit, apparently

File: 1498117439710.png (9KB, 637x130px) Image search: [Google]

9KB, 637x130px

>>61023912
>Reference counting
See picture

>>61023929
>implying C programmers doesn't implement reference counting all the time
Why else would the Linux kernel be full of get_* and put_* functions?

Refcounting is a sensible trade-off between unmanaged memory and a BFS-style garbage collector.

>>61023951
C programmers don't use brain dead ref counters like C++

>>61023980
>implying that the Linux kernel isn't full of reference counting

>>61024021
>>61023980

>>61024029
>>61024021

>>61023813
It's a feature. Since bool is just a byte, you could just use std::int8_t.

>>61023929
Reference counting is objectively superior to gc. Circular memory leaks are not a problem in practice.

>>61024141

reference counting is shit for concurrency

>>61024129

kys yourself

>>61024239
>reference counting is shit for concurrency

All architectures have some form of atomic compare and swap or even atomic increment and decrement, you're fucking retarded.

>>61022844
>all this pointless discussion
qsort and std::sort are not the same algorithm. qsort is slower than std::sort because it tries to be generic at runtime with the comparison function pointer argument, which causes winding and unwinding call stack at every turn. std::sort is a templated function, so its performance is dependent on the compiler inlining the comparison or not. You could get the same theoretically best performance between optimized std::sort<double> and a hand-written quick sort with inlined double comparison.

The only thing you can reasonably judge in that case is convenience. And even then, YMMV.

>>61023667

#include <typeinfo>
// kinda

>>61021389
You are so fucking dumb of you think c# is portable. Any validity you had is in the shitter

>>61018103
Notice how cfags completely ignore the fact there's no oop. Inb4 oop is garbage but java and c# are cool

>>61025341
>>61018103
>>>>>>>>>>>/i/ndia

File: 1496497524747.jpg (6KB, 226x226px) Image search: [Google]

6KB, 226x226px

i like how nobody has made an actual argument against C++. it's either "lol it's shit" or "lol it still uses ___", neither of which are arguments, just baseless criticisms to trigger (You)s.

>>61025818
Why not play the devil's advocate then?

Oh that's right, C++ worshipers are unable to self-critique their language and always feel the need to proselytize even when they're invited to non-sheeples-related conferences.

>>61026651
>C++ worshipers are unable to self-critique their language
not true at all, that's why we've been begging for modules for so long

File: 1498117439711.png (753KB, 1338x5868px) Image search: [Google]

753KB, 1338x5868px

>>61025818

>>61025818
>Close your years
>Close your eyes
>Ignore all the previous comments
>Ignore Linus
>"No one has actually arguments guyzz!!1!1!!"

>>61016181
They should have included modules a long time ago.
Apart from that, it's probably the best one can expect from something descending C compability.

>>61022698
>how are modules better than header files?
are you kidding

>>61026876
>Ignore Linus
Not that guy, but like some hardware faggot that knows shit about programming languages should be a measure for it.

>>61026807

It's funny, just about all the stuff in this is either legacy C stuff or a consequence of it. I for one would love a huge breaking change that threw out the preprocessor, header/impl separation, mvp/function prototypes etc. And also replace some of the old niggling mistakes in stl like streams, vector<bool> and old non-RAII classes.

>>61026938
Here is another example of how C++ appeals to uneducated people and substandard programmers

File: 1498108612020.webm (924KB, 600x336px) Image search: [Google]

924KB, 600x336px

why wouldn,t all anons in dis thread convert to python? oh deer celestia

>>61017528
I'm not even a C fag, but what you said is true for C++ as well.

>>61016181
How long until this becomes unmasked in ~arch so I can keyword and emerge this?

>>61021396
>Those textures were copied over and over and over again, because containers can do that, so I had to go back to rethinking the storage class for the widgets.
>what are pointers
>what is std::move

Other people have already pointed other stupid things you've said but based on this alone you seem to lack basic understanding of new C++ features and you're probably stuck in C++03.

Has C++ gone too far?

template<typename...Args>
constexpr auto folder(Args&&... args) {
    return [=](){ return (args && ... && true); };
}

int main() 
{
    auto f = folder(true, 1 == true, 0 == false);
    return f();
}

main:
        mov     eax, 1
        ret

For each(retard in thread){
<< "Poo goes in the loo /n " << retard.display();
}

>>61026974
Here is another example of how C appeals to uneducated people and substandard programmers. So is Linux and most of GNU.

File: 1495641426051.png (60KB, 645x968px) Image search: [Google]

60KB, 645x968px

>>61016230
>unironically a wincuck

>>61029491
>For each in
>output stream operator without a stream
You obviously don't know C++, get out