CppCon 2017: Bryce Adelstein Lelbach “C++17 Features (part 1 of 2)”

[@michelecostantino]

My ophthalmologist uses these slides to check if one is shortsighted.

[@thomaskoppe343]

Re structured bindings: Other types that are bindable are the node handles from the new map splicing interface, and the return types of the new elementary numeric conversion functions.

[@DGDG0000000]

Thank you1/6 part of the screen is for code. 1/4 for you and title, and all the other for.... nothing. Difficult to see the code, but I see you and your title and the big blue perfectly.

[@timhaines3877]

Any news about a std::ignore equivalent for structured binding for C++20?

[@defense200x]

wait for c++23

[@stephenjames2951]

This presentation is evidence that you need to review your ‘slides’ in the environment that they are presented. The text is too small with way too much unused ‘white space’.

[@bogdansikach7709]

More over, the colors are just terrible, dark font on dark bg -- cool choice.

[@GeorgePapageorgakis]

I may not be a pro but the explanations given seem opaque, especially in the *constexpr* examples

[@ytsas45488]

Lots of cool features but the class template type deduction and other weirdness with type deduction is concerning and disheartening. We already have the auto keyword, so why is it not being reused? There is no need for this feature bloat, it adds more with barely any effect.

[@kamalabuhenamostafa]

Can anyone explain [logically] why sheet 19, left locked? why not explain here ?

[@Qazqi]

The mutex is still locked because the lock guard hasn't gone out of scope and unlocked the mutex in its destructor.

[@kamalabuhenamostafa]

hahaha....... i am not a programmer. so i need to locked that as long as i wish. this is correct answer.

[@fangjunkuang5061]

The font size is too small.

[@98luk45]

I want to see headers disappear by the next iteration.

[@DBZM1k3]

How would you see this being implemented? Headers provide a layer for the user to communicate to other areas of code while allowing the programmer to obfuscate the important stuff within the cpp. By removing the headers you take away this functionality. What would you replace it with?

[@98luk45]

+DBZM1k3, How many modern programming languages have you learned and practised with for more than a year for each? Your argument isn't a valid one if you compare c++ to other languages. C++ just has better support for hardware access and can achieve better performance, but that's about it. Headers and templates needs to seriously be reworked, and in the case of headers, developers should not have to deal with it;. compilers should handle that kind of work. We can start with eliminating the need of function prototypes. Compilers should be able to scan a file and map out the members. Private members should not be allowed inside headers.

[@DBZM1k3]

98luk45 I don't think we should be comparing C++ to other languages. Because different languages cater towards different things. They don't all offer the same thing. There is nothing inherently wrong with having header files. It allows you to separate interface from implementation. It's pretty much lost its original use which was to reduce compiling passes over the code. Because computers are much more powerful these days. But that doesn't mean we should take the functionality out. Small, less powerful, systems may make use of this. I recall a project to make a small probe which create new instructions and compile them into its instruction set via some machine learning. This was all done on the equivalent of a raspberry pie(possibly worse). So this functionality still has a significance in things like this.

[@98luk45]

It's perfectly reasonable to compare C++ to other languages. A lot of features that have been introduced in C++ in recent times have existed in other languages long before they were introduced to C++ (e.g. auto, lambdas, for_each, unordered_map/set, etc). Some of the things that were introduced in this video have also come from other languages (which is great to see they haven't given up yet), but I think there are other things that are more worthy of focusing on. At least for me, a rework on headers and templates would be more interesting than another 'using' from C# in mid 2000s. To counter your argument with the need of headers for weaker devices, headers actually introduce more compilation time due to IO (more characters and more files to process) and compilation speeds can be many times worse because of it. Its primary purpose was to be compatible with C - it's fine to be compatible and it has been successful at doing that, but there needs to be more than just compatibility to keep up with modern programming demands. The performance of C++ stems from the ability of having better management of resources, not in the syntax design of the language. Changing the syntax to be cleaner while providing the same low-level access would benefit all C++ developers ... except for those who've already given up hope on everything and are just waiting for retirement.

[@seditt5146]

Headers still greatly reduce Compile times even on small projects, Try implementing your code inside of the classes even on a small project then attempt to make a single change on a commonly used class. It will take many minutes to recompile the entire project when all that was needed was a single line of code yet it now has to update that everywhere it is included. Package management is ugly and a pain in the ass overall. I do understand that much of the functionality of C++ has come from other languages but at the same time many of those other languages existence in general is because of C++ and almost surely they have borrowed more from C++ than C++ has from them. Programming languages are like that and should be, ever morphing interfaces for us to communicate with our computer. Take the good leave the bad and continue to the future in search of the perfect programming language. The C++ committee puts ALOT of thought into what they do and do not do, you are not even close to the first person to suggest the removal of Headers yet every single time they come back to the fact there is just really no better way. Just like Macros in C++. The Committee and Bjorn personally has been wanting to remove macros for decades yet there really just is not a better way and there is nothing they can do that performs the functionality they provide.

[@nottellinganyoneanything]

what if I do not want to use auto for MultipleReturnValues?

[@rfdangel001]

If you know the number of arguments, you can use std::tie there's a great video on this channel named "CppCon 2017: Kate Gregory “10 Core Guidelines You Need to Start Using Now” " the part about returning multiple values starts at 28:55.

[@davidyang7852]

It is "incredible" to see C++ still heading to a wrong direction after 2017. People want a standard build system and a compressive library (networking, HTTP, etc) or library management system like pip for python If standardizing a compressive library is difficult.

[@rebase]

Miracle Yang what the heck is a “compressive” library? Did you mean “comprehensive”? Also, there are plenty of existing build systems and library/package managers out there. Feel free to use them, but they have nothing to do with the C++ language itself.

[@DrMcCoy]

There *is* a standard build system. It's called autotools :P

[@seditt5146]

@@rebase People seem confused as to what C++ is and isn't. They come from C#, Java, Javascript and Python and seem to think C++ has anything in common with those. It does not. While all are considered Higher Level languages C++ is more like a middle level. It is not here to hold your hand, provide you with all sorts of packages and to make your life peaches and cream. C++ is just above barebones as they could possibly get while still having higherlevel language functionality. They struggle to KEEP C++ as low a level as possible and to not waste their time with all the package management bullshit everyone is crying about. It is not about that. That is your job not the Language. If one wants that functionality as already stated, get a manager to do it but it's not up to C++. I am currently using SDL2 on a project and almost always use Raw OpenGL on all my other projects. Because that is what I almost always do, is it up to C++ to implement Graphics programming? Provide me with a Standard library for Graphics programming so that I can just include Graphics.h and it deals with porting to all systems and does everything I need to do so I do not have to worry? Absolutely not because graphics.h has NEVER been part of the standard library. On the other hand you know what C++ will allow you to do, Write Graphics, Threading, Audio and any code you can think of for every single platform out there damn near if that is what your goal is however it is not up to it to determine what can and cant work on them systems and change for you. Remember to put what C++ is simply, C++ is ... "You Don't Pay, For what You Don't Use"

[@nottellinganyoneanything]

Otherwise they are still destroying the language, only a few good features in the ocean or useless overcomplicated hacks.

[@broken_abi6973]

auto is not an overcomplicated hack. Most of the fears ppl had regarding it ended up being unfounded.

[@nottellinganyoneanything]

I'm not talking about auto. Auto is fine it has some use cases.

[@ikk9000]

that all the templates ends up being header-only code bothers me, exponentially increasing compilation times, and its supposed to be turned into precompiled headers mechanism... what about header-source mechanism instead, that existed since much earlier... and excuse is that on a mainframe you have all the processing power you need. well, I'm not on a mainframe.

[@broken_abi6973]

oops. misunderstood you then

[@Moriadin]

This talk has just reinforced how garbage C++ is.