1:17:57 Mike’s C++ playlist: kzbin.info/aero/PLvv0ScY6vfd8j-tlhYVPYgiIyXduu6m-L

1:17:56 Mike’s D-lang playlist: kzbin.info/aero/PLvv0ScY6vfd9Fso-3cB4CGnSlW0E4btJV

11:54 Mike’s “first impressions” playlist: kzbin.info/aero/PLvv0ScY6vfd-5hJ47DNAOKKLLIHjz1Tzq

just adopt Circle as c++2x

If your argument for not switching technologies is that you need to learn another programming language, then you've just admitted to be a bad programmer.

30:47

Very thought provoking talk. There is much to be said for frugal :-)

I think Walter is a really bright guy, and his C++ compiler, even if he's not still maintaining it, is the absolute best in existence. I do think simplifying things from how C++ does them is a good idea, but perhaps not quite as much as he has done for D. For instance, I don't agree with his choice for the template syntax nor for scope resolution. I also don't like how his standard library is organized, but I also don't think that most languages get that right. One thing this talk has exposed for me is that writeln and all of those associated functions can't be used with @nogc functions, but especially with an @nogc main(). As far as I can tell looking at the source there's no reason for that because at first glance they don't appear to allocate anything. I feel like that's something that needs to be remedied by making them all @nogc, which would still render them usable from everywhere else even in GC enabled code. I'm sure most will disagree with all of my complaints about D, but I don't like the lambda syntax. Although, the post return syntax is better than C++'s because -> in C++ is a member pointer operator and thus it further confuses context for no gain. I dislike UFCS and method chaining in general. The contrived examples always suck, but when you add on two unnecessary calls to strip() to make a point about convoluted code, that only undermines the point. At least pull a real-world example, because even if I disagree with it, at least it'll be valid. Also, the point about mixins is really disappointing as a preprocessor doesn't have to mean a lack of type checking. A simple addition could be `#macro int foo( int arg )` and give it an almost proper function styling, yet it could still act as a text replacement mechanism if you don't use a function style macro or have type annotations at all. There's no reason to not have both #import and #include as a preprocessor is an incredibly powerful thing. One thing I really like about D is the concept of CTFE and I try to do as much of that in my own language as I can having made my compiler into an interpreter as well and like other languages just calling it directly opens a REPL, and I hate constexpr and consteval in C++. However, I still don't understand the point of most uses of type annotations and especially typeof(). I feel more languages should aim for more type inference as I have in my own language. For instance, that other contrived example would in my language look more like this `v := [7, 5, 8, 2, 4, 1, 3]; min := *v; for i in v: if i < min: min = i;` but if we take the example seriously, then it would ideally be `v := #{ 7, 5, 8, 2, 4, 1, 3 }; min := *v;` because #{} denotes a built-in tree type and thus the first element would denote the minimum. Since I strive for CTFE too, if `v` isn't used other than to acquire the minimum of that set, then assuming the answer is printed out it would generate code that just prints the constant value. While I do take some inspiration from Python, I take more from C and its child C++, and whitespace isn't significant for scoping and default types can literally be changed by aliasing whatever you want to the int and float "generic" types. So if you want 32-bit floats to be default then you can simply do `alias float32 as float;` at the top. Though, I opted for RAII over GC and the user can configure the default allocator per module if desired for cases when objects have a runtime representation. Ultimately, I would suggest learning more languages, whether side-by-side or not, because it can improve your programming skills regardless of which language you end up using and there are certain big projects that everyone should take on at least once, such as writing a compiler, even if it's only for a subset of functionality present in other languages. I fully expect that no one will read this long-winded post, but I tend to ramble on as a means of catharsis, so it doesn't matter anyway.

Ja!

This presentation misses entaierly elephant in the room...data centers in details presentation although they are mostly responsible for summary precentages.

verry respect u ! Nico u are the best!

Circle is without a doubt the most promising development for C++. Too many people unfortunately can't set their egos aside to give it the attention it really deserves.

Mike's YT channel on D (and C++) is excellent

I like the whole idea of views, but I'm concerned about the performance of this stuff. I'm pretty sure, although I don't have any evidence for this, that it would be faster to do what you're getting with a view yourself. Maybe it would be more readable as a view, I don't know, it would certainly be more concise, but that doesn't always equate to readability. Having views might be more confusing to junior programmers than something you've done yourself. This sort of thing with views and stuff has existed in C# for ages with Linq and it preformed pretty badly there. So as a concept, views seem okay, but outside the odd case or two, I've got no real need for them. In my opinion, a lot of these things they're cramming into the standard are like things to include just for the sake of inclusion, not for any real worldly benefit. Sure, they're nice to have but are they going to change the way that most C++ developers write code, probably not. Well, not unless you're one of those annoying bleeding edge coders who likes to shoehorn a spaceship operator in their code whenever they can.

Great talk! In many ways D seems to answer an early aughts question - how can you combine the productivity and safety of Java with at least most of the performance of C++? I really love how D makes many things that are hard or ugly in C++ seem simple. Mixins is a very simple way to get powerful metaprogramming. Automated marshalling of structs to JSON, yes please! Less undefined behavior and UFS, hell yeah! However I think the reliance on a GC and built in safety checks disqualified it from the high performance domains occupied by C++ early on. Recently even Herb Sutter acknowledges that we should be safe by default (paying a small runtime tax for that) with the option to opt out of we really need to. This makes D relevant today, but unfortunately I think the boat of D has sailed due to Rust which manages to provide safety with most of the checks done at compile time. If you really value productivity and still want decent performance then I think a lot of people will look into Go instead.

DLang might have a small ecosystem, but you can still be very productive with it.

D seems pretty cool language!

I write in C++ over 5 years, but nothing came close to C even now. Its a legendary language.

Very well presented and explained, thanks!

The only people who think this is great are Rust fanatics that will never write a line of C in their lives so why is the committee trying to appease them?

29:55 No, std::less has no extra stuff for doubles. If a range contains nan, sorting it with std::sort results in undefined behaviour.

16:15 JF Bastien’s talk from CppNow 2023: kzbin.info/www/bejne/fZmaaqqZfK-Xisk

Great talk as always! Question: With so many copyright holders, will you be able to change the license of Cppfront to a free license?

I hate putting the ampersand and asterisk signs left-aligned. I teach newbies by asking this: int* a, b; and then I ask the type of variables. Most of them say they are both pointers. No, they are not.

Really enjoyed this Herb, thank you!

This talk is highly interesting, very good points

Does this professor have some book, site, or course related to him?

We’ll put together 👏 Can someone please recommend books that go in-depth through each step of the design and creation process for a complete noob 😅

one big question is, why is C++ default regexp so slow compared to perl ?...

Adding auto with the same meaning as in C++ is a strange choice - I thing its generally a bad feature in C++ but at least has some utility due to long typenames, iterators, namespaces- but in C? Why?

you can use c++ modern without the classes and templates and still can get the modern features that it provide

I really liked the low-hanging fruits part. Great content, thanks

If you look at it, the humble 6502 was the first RISC CPU. It had competition (6800, Z80, 6809, 8008/8080), but its minimized register count and minimized instruction set made it very simple to implement efficiently, and it could do everything that any other 8-bit CPU could do, and often just as quickly.

As mathematician I see Design Patterns as tricks language.

Why we can't execute ADD, SUB instructions in one clock cycle

45:21 Assuming sz can get very big, the argument to malloc can overflow and create a smaller allocation than expected. There's calloc for this purpose. Thought this was common knowledge.

16:30 Unfortunately this is also wrong, if it compiles, then only under C23. auto buffer = (char[42]){}; 1) the compound literal has an empty initializer list, which is not allowed according to ISO C (until C23 it was available as a gcc feature) 2) auto buffer : default type to int results in at least a warning (-Wall or -pedantic). 3) auto buffer : if the default type would be int (with warning) the type does not match, because the compound literal (char array of size 42) gives the address of the first element (char *) This would be a conversion from char* to int.

18:30 Unfortunately, this is not correct. The idea is to check whether the passed address belongs to an array that has AT LEAST (and not exactly) this many elements. void foo(char p[static 5]); char array[4]; foo(array); In this example, you would receive a compile warning. Both under clang and under gcc. The whole thing has its limits, of course. And of course the function cannot check whether a null pointer was passed if it was not already known as a constant value at compile time. foo(NULL) leads to a warning because a constant value was passed here. In the following example, the compiler has no way of determining at compile time whether NULL was passed. int x = 1; char const * p = "Hello"; if(x) p = NULL; foo(p); // No warning, even if p should be NULL The whole thing is not intended for this, but for cases in which a "real" array (as the address of the first element) is passed - and not a pointer. void accept(char const str[static 4]); char const a[] = "Hi"; char const * p = "Hi"; accept(a); // Warning with clang and gcc accept(p); // Warning with gcc (not with clang) Clang and gcc also do different things here to determine whether the limits of the array have been observed. For example, clang no longer warns at all if a pointer is passed. gcc tries - as far as it is possible at compile time. Unfortunately, the way it is presented in the video is not correct.

Long life to C

Thank You so much Filipp Gelman. This talk is really insightful.

Herb has great talks, but does anything he talks about happen?

Great talk!

1:22:34 I was unsure if the double cast was needed, but now I know.

ranges/view were one of the main things why i tried making our codebase ready for C++20. Even just the small things like splitting strings. And then we saw that while you could split strings there was no way of concatenating them back together in a similar style - ok, so we have to create our own compatible functionalities for that (the committee "forgot" about that and it was later added to C++23). Still not too bad - so lets test it... wait, why is everything broken? oooohhhh views are caching... and the code would need extensive reworking due to changes to enum, bool, volatile etc.... Yup, and back to C++17.

22:38 - "Do you think cheap is expensive?" - i sure hope nobody does.

Every time he says, "It's like in C++", I say, "Oh no"; "Oh no, they will make C look like that".

Something about static rules of the system that will always be there... The emulator would always be limited in outputs for exploits, at least then. He was asked to put in signal limitations and how factors effect this but he didnt like that idea and said it would be tedious and it is already in. "get a scrub to do it..someone who can burn time.""i will have to burn through physical chips to do it and even then i would be better at working on ai or exploits."

Best programming language that human kind invented.

I don't know if I love or hate the fact that the only people using C nowadays are Python devs

1:15:00 When functions are pure, then I'd say you extend them via pre- and post-composition with other functions. And I guess with generic arguments; (as said) with functions as arguments; and maybe by application of Functors ... fns in Lists, fns in Exception blocks, fns with Logging, Optional fns, a fn in an Either, fns in Futures, ... and maybe by replacement by an Interface(?)