C++17

The final publication on the new standard is coming soon. What are your thoughts on it?

Other urls found in this thread:

quinn.echidna.id.au/quinn/C -Critique-3ed.pdf
en.cppreference.com/w/cpp/language/operator_precedence,
twitter.com/NSFWRedditImage

>C++
Into the trash it goes

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

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

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

I'd still have to deal with legacy code.

This.

u forgot /thread

When is Assembly 2 coming out?

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

New cpu extensions are being created all the time.

Garbage

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.

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

...

M8 what.

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

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?

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

Epic meme you got there pajeet

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.

/thread

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

>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?

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.

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

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

>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
because I don't want retards like using auto variables and other frankenstein features

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

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

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

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. ; )

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

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

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

>why the fuck would you need standardization

>still no networking stack

At least they put in

>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?

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

Quality reply, user.

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

>angry rusthomo

>BRAINLETS

>Brainlet C++ajeet

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++

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

t. Nodejs web artisan

>What are your thoughts on it?

This.
The C user is just a retard.

>t. std:: pajeet

>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

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

>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?

Okay, Mozilla JUST evangelist

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

>C++
Belongs to

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

Name 1 (one) reason

...

M O D U L E S
O
D
U
L
E
S

Unreadable code

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

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 a() {
typename std::vector::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::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.

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

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

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

quinn.echidna.id.au/quinn/C -Critique-3ed.pdf

>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

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

>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

/thread

I'll make that my wallpaper.

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

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

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

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

horrible

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.

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

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

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.