Видео

\(@^0^@)/ Reflection looks like kaomoji! LOL

There are a lot of invalid suggestions and recommendation in this video.

I hope one day we’ll get a package manager for C++ or something similar that’s still backwards compatible.

This guy gave me a career... C++ forever.

@45:20 Of course -march or -mtune will degrade latency performance, they are designed to maximise throughput. SIMD instructions will of course have higher latency than their scalar counterparts.

That name space is one piece of work

I lined it up real good but it all went side ways during staging

This is an awesome talk! Very useful for C++ developers on embedded projects.

Wow this is easily one of the most underrated C++ talks I've ever watched! This was so well-explained that a lot of things about the typical way you find done in Big Corp code (e.g. with inheritance) can feel so much like "instant legacy code".

at least you can add english subtitles ?

35:00 shouldn't CRTPMixin be inherited from virtually if it wants to be reused by multiple mixins (to get the self() for "free")? Maybe it doesn't make a difference because it's a bunch of consteval functions.

I don't know why nobody ever mentions what languages those "memory safe languages" were written in: C/C++ If they were not written in C/C++, they depend at one point on C/C++. Even the "memory safe" language Rust uses LLVM to compile its code, which was written in… C++. How can anybody create a "memory safe" language depending on an "unsafe language" or on something that was created in an "unsafe language". That doesn't make any sense. It either means that everything is unsafe or that C/C++ are not as bad as (almost) everybody says.

The language is beyond ridiculous at this point, if I would be Bjarne I would just "delete" c++ and start again and reduce the language to be smaller, simpler and still be the same low lvl efficiency.

After years of "trying to learn" C++, I can finally safely say that it's okay if sometimes I say I seriously cannot understand C++. Though, I still love to program with C++. So, here I am moving to the next video on my C++ watch list! This talk seems to introduce cool new features though.

it would be good if there's an English version.

in the world where everything is going towards simplicity and ease of use, we have C++ which bravely goes against the stream 🙃 I can't comprehend how somebody could look at such syntax and think "yeah... that looks good"

The reflection syntax makes C++ look like brainfuck. I can't imagine how someone is supposed to learn this?

Great talk! On the topic of virtual functions, I hope the committee will consider the “Liskov Substitution Principle” when deciding (post MVP) how to define pre/post conditions of virtual functions

Do not write an English title, or an English description for a zionist genocidal language to be spoken in the talk.

Interesting

I have put my presentation at Core C++ 2019 in Israel, while answering a Quora question: Why is C++ considered a bad first language to learn? My answer began with a short text: * The most important word in that question is _considered_! * The answer is: - Because too many programmers use C++ without understanding the real basics of C++, and some of them even dare to teach C++. Then the link to this video followed. Enjoy 🌷

That was great, never thought about parallelizing via something like lambda vs. threads.

Thank you for all what you did, Walter!

Started from nowhere, super bad audio quality, has no structure.

Please can you clean up the audio. Thanks.

24:01 Great talk. To clearly state Alex’s point in this slide - of someone would call the decode() function with a negative size it will result in buffer overflow, because ‘line 45’ doesn’t catch negative cases, and (surprisingly) the condition “i < size” will be evaluated to true (!) converted to a number larger than INT_MAX (and thus definitely larger than 254)

6:18 David Sankel’s talk from C++Now 2023: ruclips.net/video/7xwjjolDnwg/видео.html

Audio quality is trash. makes the video unwatchable.

Best tutorial so far I have ever seen. Thanks!

after all these years, i can't believe that they haven't been able to come up with a standard library build module in c++. i mean, they have no problem bloating the language with every obfuscated idea that comes out of CS, but a build module? no way! the simplest thing would be to have the build scripts written in c++, (see zig as example). that way you don't have to learn some archaic scripting language, or rely on 3rd party tooling.

I recommend CPM for dependency management. It's a thin wrapper around CMake's FetchContent module so theres no need to learn an additional tool...

Nice to see two clang-tidy checks I wrote appear on screen :)

Promo-SM 🤦

24:47 After the talk I learned that there’s also paper P2760 with the plan for ranges in C++26

14:10 Link to Stepanov’s talk: ruclips.net/video/1-CmNNp5eag/видео.html. Another version of the talk with better audio: ruclips.net/video/YlVUzJwN_Xc/видео.html

Direct link to slides: docs.google.com/presentation/d/115iU6rA6gAUNErenmBIPqdl_HHlcYp9_YoYLOFSUNho/present

what the hell is going on with C++ this is all getting way too confusing lmao, it feels like 30 different people with 30 different beliefs push shit into C++ and now you have 3000 different ways of doing 1 thing.

So what's the fixed version of the original Euler problem code?

I accept Mr Stroustrup fights for his invention. That's commendable. Nevertheless, he has not fully analyzed the problem. Here is why: sappeur.ddnss.de/WhyCandCppCannotBeMemorySafe.html

Ada doesn't have implication, but it has nice if expressions which achieve the same thing. You can say "if condition1 then condition2" and if conition1 is false, the expression evaluates to true.

Poor Christina. Now the world knows she is arithmetically challenged.

@40:00 You meant "for (int i=0; i<=7; i++)", right?

@23:00 This version is cleaner, but requires a memory allocation. Imagine a case where a, b and c are huge and can be pre-allocated and reused for each call. The former version of arr_add would be more appropriate.

I'd save the arrow operator => for short syntax lambdas, so that we can use ranges and pipe operators more effectively, making things like "std::views::filter(x=>x>2)" vs "std::views::filter([](const auto& x) { return x > 2; }). In my mind, this is more useful and saves much more typing than the implication operator.

The language and std library should only provide the most basic tools necessary to write a program because it's not feasible to expect developers to dedicate their entire lives to learning a single language (which C++ already kind of does). Adding a new core language features that provide no new functionality just complicates the implementations and surface area for bugs and weird interactions to pop up. It's also less readable than a simple ternary operator.

"!p || q" is just a single character longer than "p => q", and (in my opinion) just as readable. Sorry, but I don't buy the "professional toolbox" argument, I want the exact amount of tools I need to be as efficient as possible, too many similar/duplicate tools just add extra weight to carry around. I respect the well presented and thought out arguments and effort put into this though.

If there are 2^4 different truth tables, which other simple operators are we "missing" and being forced to make complex multioperational predicates from?

I'm waiting for it so long. I loved to use it when i programmed in Eiffel. It is so usefull when you write lots of "assert" statements (as anyone should).

C++ is made, document and accesibile as "magic show". This mean you can see it if you somehow get to one show but nothing more or less. You need search lot to got some magic revealed. But C++ is one best programing leanguage we have and is better every day. my noob opinion.

Seems like little to no benefit to add an esoteric feature that just tempts people into writing inscrutable expressions. In the example given it is a much better idea to leave it as a conditional with three branches. If you really like the idea, you can just define and use a macro.