C++17 Is Now Official

[Zan Lynx]

That's what the filter method is for:

for value in vector.iter().filter(|x| x == this) { }
vector = vector.into_iter().filter(|x| x == this).collect::<Vec<_>>();

This code is neat and compact but programmers should realize it is creating an entirely new copy of vector, then replacing the old vector with the new copy.

That's not the same as using C++'s erase-remove or erase-partition idioms to modify a vector in-place.

[Hi-Angel]

Not sure what you're talking about here.

I am simply saying that there's no need to be explicit about the return type, because it is clear anyway.

Not necessarily. Say you had a private field that stored the ID of the thread, and this ID was taken from a global atomic integer, so that the user doesn't have to specify the thread ID manually when initializing every thread. The point of using a constructor method is so that you can have private fields that are automatically initialized behind the scenes without the user having to manually specify every field by hand.

Ah, well. It works with a constructor too, see, quick'n'dirty example:

struct MyJITThread {
    int fd;
    const char* name;

    MyJITThread(int fdArg, const char* nameArg, int pidArg):
        pid(pidArg), fd(fdArg), name(nameArg) {}
    MyJITThread(int fdArg, const char* nameArg, MyJITThread& thr):
        pid(thr.pid), fd(fdArg), name(nameArg) {}
private:
    int pid;
};

int main() {
    MyJITThread thr1 = {fd: 1, name: "thread1", pid: 2};
    MyJITThread thr2 = {fd: 1, name: "thread2", thread: thr1};
}

[hoohoo]

Actually this doesn't really resemble the truth. What is speaking here is you feeling overwhelmed by the options C++ offers. But this is fine. You can accept it. And in fact, C++ is underspecified. There are some blind spots and this is why you will observe different behaviour when compiled with different compilers under certain circumstances. And no - this is not a real big deal in most scenarios ;-)

Not so much overwhelmed as irritated.

Underspecified: ANSI C and original C++/C++98 were IMHO specified just enough. I just don't think everything needs to be nailed down. I do not think we need a pre-baked one liner for every possible requirement - thus my crack about VB.

Different behaviour: certainly, and it's a problem. Not a huge problem. The solution ought to be fix the edge cases.

WRT my being irritated...
I've been writing a lot of C++ code the past couple weeks. I keep running into these sorts of things and they are really irritating me:
- C++11 added lambda expressions... now I regularly find open source software (and sometimes closed source in the work place) where an entire program is implemented in essentially one function using lambdas to differentiate execution paths. Many dozens, to hundreds, of lines in each lambda, it's incredibly hard to read, and neither Slickedit nor Notepad++ can auto-format this kind of code well. It's worse than spaghetti code implemented with goto. In fact lambdas seem to encourage this Javascript style code. Lambdas are intrinsically antithetical to the idea of structured code.
- libraries: leave the purpose specific libs in Boost! Boost is wonderful, and Boost is all in the boost namespace. Std:: is getting so huge it's silly.
- auto: I see people using auto instead of std::string, or int! Even worse I see auto being used where actually complicated types are returned, and then when I want to dig into the returned object, it is frequently not clear what the type is. I have to get out GDB to examine the object, or start reading code to figure it out (but then they've used auto everywhere). This is silly, and it makes for hard to read code.

These ^^^ things may be fine for "experienced" programmers. I don't dispute that. But if this kind of stuff keeps on for two more revisions we will have a language which learning curve is so steep that it will simply die along with the "experienced" users as they age.

[hoohoo]

why do you refer to yourself in plural? or is it voices in your head?

"We" being C++ programmers.

seeing what isn't there is symptom of drug abuse
c++ has core language spec of similar size to its competitors(no, not to brainfuck) and orders of magnitude smaller library spec

I don't use drugs.

C++ core language spec is getting bigger every time they release a new spec. The standard library is growing even faster. These things bother me. If they don't bother you, well, OK they don't bother you.

[hoohoo]

<snip>
Whereas in C++03 I had to do return MyJITThread(1, 2, "thread1");, in C++11 and later I can do return { pid: 1, fd: 2, p_name: "thread1"};, now guess which one is more readable??

Well, speaking as someone who might have to read your code, and the more so if you are given to using auto a lot, I like return MyJITThread(1, 2, "thread1"); more because I can see what you are returning!

return { pid: 1, fd: 2, p_name: "thread1"}; on the face of it, could be quite literally anything.

[Hi-Angel]

Well, speaking as someone who might have to read your code, and the more so if you are given to using auto a lot, I like return MyJITThread(1, 2, "thread1"); more because I can see what you are returning!

return { pid: 1, fd: 2, p_name: "thread1"}; on the face of it, could be quite literally anything.

I already wrote about it, why do you need the type if you can peek at return type of the function? That said, you can also write return MyJITThread{ pid: 1, fd: 2, p_name: "thread1"};

[Kemosabe]

Not so much overwhelmed as irritated.

Underspecified: ANSI C and original C++/C++98 were IMHO specified just enough. I just don't think everything needs to be nailed down. I do not think we need a pre-baked one liner for every possible requirement - thus my crack about VB.

Different behaviour: certainly, and it's a problem. Not a huge problem. The solution ought to be fix the edge cases.

WRT my being irritated...
I've been writing a lot of C++ code the past couple weeks. I keep running into these sorts of things and they are really irritating me:
- C++11 added lambda expressions... now I regularly find open source software (and sometimes closed source in the work place) where an entire program is implemented in essentially one function using lambdas to differentiate execution paths. Many dozens, to hundreds, of lines in each lambda, it's incredibly hard to read, and neither Slickedit nor Notepad++ can auto-format this kind of code well. It's worse than spaghetti code implemented with goto. In fact lambdas seem to encourage this Javascript style code. Lambdas are intrinsically antithetical to the idea of structured code.
- libraries: leave the purpose specific libs in Boost! Boost is wonderful, and Boost is all in the boost namespace. Std:: is getting so huge it's silly.
- auto: I see people using auto instead of std::string, or int! Even worse I see auto being used where actually complicated types are returned, and then when I want to dig into the returned object, it is frequently not clear what the type is. I have to get out GDB to examine the object, or start reading code to figure it out (but then they've used auto everywhere). This is silly, and it makes for hard to read code.

These ^^^ things may be fine for "experienced" programmers. I don't dispute that. But if this kind of stuff keeps on for two more revisions we will have a language which learning curve is so steep that it will simply die along with the "experienced" users as they age.

I don't really understand. Why is it better to "put everything" into the boost namespace instead of std. I mean it's even longer. And yes everything lives in there because everything the standard offers is by name separated from your shit. That's the only purpose of this namespace.
And lambdas are just a more convenient way to formulate what has ever been possible with the language. There is no mechanism in the standard which prevents editor programmers from not implementing the syntax correctly. There is no mechnism in the standard which prevents from "devs" writing ugly code. Lambdas don't really change a shit IMHO. Can you show me a code example with hundres of lambdas in a row? Why don't I expect an answer? :-P

[hoohoo]

...

Can you show me a code example with hundres of lambdas in a row? Why don't I expect an answer? :-P

I've been making use of this lately. It is a good example of what I call abuse of lambdas:

https://github.com/eidheim/Simple-We...s_examples.cpp

I've tried pasting the verbatim code, but I can't seem to get the forum to display it nicely.

[hoohoo]

I already wrote about it, why do you need the type if you can peek at return type of the function? That said, you can also write return MyJITThread{ pid: 1, fd: 2, p_name: "thread1"};

Many years ago I choose C and C++ as my main languages because they were quite explicit. The code could document itself, and largely because types were explicit. Now apparently we don't need to say what we mean... we can specify return type "auto" and the return keyword can be followed by an unnamed type. It's a step backward.

[Hi-Angel]

Many years ago I choose C and C++ as my main languages because they were quite explicit. The code could document itself, and largely because types were explicit. Now apparently we don't need to say what we mean... we can specify return type "auto" and the return keyword can be followed by an unnamed type. It's a step backward.

Well, in this particular case it does make sense to use explicit return value. That said, I would generally refrain of using "auto" as a return type in favor of templates, because templates are imposing constraints on what exactly one wanted to return. And in case of templates you'd get again return T(1, 2, "thread1"); which doesn't tell you much.