I don't know if it's standardized in C++, but yes, a __vtable pointer that maintain a pointer to the original parent classes function pointer would remain preserved.

I believe it was still C, but I forget if Sylven said for sure. Delphi was winning against VB during that time for application development -- so there was lots of Pascal out in the world! See the interview here! kzbin.info/www/bejne/lZvLgYV7itJ7gJY

@@MikeShah Thanks man! I'll watch it. Worked a little with Erlang before. Pascal was "the language" schools used to teach before Java got popular. BOS was written in it, which ran just about all HIS (hospital information) sytems in the Netherlands. I never got into Delphi however a colleague wrote our ticketing system in it. VB was about as popular for applications as php is for websites today. Most of wat i did was just bash & C. Later some CFEngine i guess.

Cheers, thank you for the kind words!

@@MikeShah no no, thank YOU for your very generous gfx inclined cross platform lessons oh great teacher !! 干杯

Indeed! New SDL3 playlist is coming soon!

std::map is ordered, and std::unordered_map is not. The guarantees of the operations run-time thus are different (i.e. Log2(n) vs O(1) on average).

@@MikeShah Thanks for the reply Mike, appreciate you!

It seems like you are wanting to add using bitwise operations on the top and bottom set of bits. The bitwise operations are atomic for integral types (en.cppreference.com/w/cpp/atomic/atomic). I suppose you could use a high resolution timer to see how fast they are. I'm curious what problem is this solving, or is this an interview question?

Indeed! At some point I'll show more with extern(C) and how to interface with C (and even C++) libraries on this series :) It's pretty painless -- so many excellent quality of life features in D :)

The principle of 'least surprise' is not always followed in C++ 😅

Indeed, on the way!

@@pschneider1968 I'm sorry you felt that way. The purpose of this series is indeed to look at a new environment for ~1 hour without any preparation. It's an honest livestream (almost a user study) for language and tool creators to see what it's like exploring something new.

@@MirrorsEdgeGamer01 Yes, always good to try the features in context of a project and then see where they best fit in solving problems.

@ Yeah, I agree. I love metaprogramming in general. I first heard about D again. I want to talk about the reflection API coming to C++.

@@MirrorsEdgeGamer01 awesome!

@@huiz.5107 cheers, thank you for the kind words!

Good news, you're right on it! kzbin.info/aero/PLvv0ScY6vfd8j-tlhYVPYgiIyXduu6m-L otherwise see courses.mshah.io for the same playlist

Cheers! I have some videos on serialization and deserializarion on my channel in the C++ series

I think recreating effects from games and otherwise building small games is a good idea

@@MikeShah thankyou mike, I'll give my 100 percent to learn direct X 12 and make those effects

Cheers!

Sounds like you're on the right track. I've always felt roles in game (especially engine programming) and graphics programming translate well to basically any software role. Folks know these are challenging positions and graphics programmers have good skills, so I think lots of companies (especially in the semiconductor space) would want to scoop up folks with your skill set. Industry as a whole seems to be going through a big cycle though, so I cannot predict the future -- just keep challenging yourself to learn good skills.

@@joeblandd6425 Cheers! Programming in D has always felt like the right tool to get real engineering done. I am so productive in getting up a prototype when solving problems in D, that often times with D the right abstraction just emerges 🙂 D provides performance and it also has a good safety story -- I always encourage folks to give it a try 😁

@

What's that struct as globals "trick"? I mean, how would you use it? These are not static members, and an object must exist to get their values... This makes it semantically hard to grasp.

@@bsdooby @MikeShah Hey Mike, could you verify if this GenAI bot response is accurate? Thx a bunch! 🤖 The comment refers to a practice mentioned in the video where Mike Shah suggests using a `struct` to group "globals" or variables in a module. The viewer's concern arises from the fact that in D, struct members are not inherently static, so accessing their values typically requires an instance of the struct. This approach might seem counterintuitive for managing global state or constants. ### **What the Viewer is Asking** The viewer is questioning the semantics of using a `struct` for "global" variables because: 1. **Non-static Members**: By default, a `struct` in D has instance members, meaning you need to create an object to access these values. 2. **Global Context Misalignment**: The term "global" suggests shared state accessible without creating instances, which aligns more naturally with `static` variables in a module or a class. ### **What Mike Shah Suggested** Mike Shah likely proposed this technique to encapsulate related "global-like" variables or constants under a common structure. This approach could help organize variables logically, but it doesn't make them true globals in the traditional sense unless they are explicitly made `static`. ### **Clarifying the Confusion** The confusion stems from the difference between: - **Instance members**: Require an object of the struct to access their values. - **Static members**: Belong to the type itself, accessible without creating an instance. If you define a `struct` like this: ```d struct Globals { int someValue; double anotherValue; } ``` You need to create an instance: ```d Globals globalsInstance; globalsInstance.someValue = 42; ``` However, if the intent is to have "global" variables, you'd need to use `static`: ```d struct Globals { static int someValue; static double anotherValue; } ``` Now you can access them as: ```d Globals.someValue = 42; ``` ### **Better Alternatives for "Global" State** Instead of using a `struct` with `static` members, D's module system provides a more natural way to define and organize globals: 1. **Direct Module-Level Variables**: ```d module myglobals; int someValue; double anotherValue; ``` Access them after importing the module: ```d import myglobals; someValue = 42; ``` 2. **Static Class or Struct**: If grouping is essential, you might prefer using a `static` class or a struct with static members for clarity: ```d struct Globals { static int someValue; static double anotherValue; } ``` ### **Why the Viewer Finds This "Hard to Grasp"** - The viewer likely finds it "semantically hard to grasp" because a `struct`'s primary use case is to define instances, not shared global state. - Using a `struct` without `static` for globals introduces unnecessary complexity, as you need to instantiate it to access its members. - The approach might mix two paradigms-structs for encapsulation and module-level variables for global state-which can lead to confusion. ### **Conclusion** The comment reflects the viewer's concern about the mismatch between the proposed technique and its apparent use case. While the struct-as-globals approach can work with `static` members, D’s module system is typically a more straightforward and semantically clear way to manage globals.

@@GaryChike The bot summarizes and enhances my concerns pretty accurately. Still impressed what these LLMs are capable of. But let's wait for @MikeShah to respond on my initial, not AI enhanced question. This is to keep humans in the loop...

Cheers!

Happy New Year!

microsoft broke visual studio. use vscode.

Have you tried recently? VisualD is not a prerequisite for the language. Many folks otherwise use VS Code with the code-d plugin for completion

@@MikeShah I rarely if ever use Visual Studio for Dlang myself. Because I'm platform agnostic, it's a pleasure working in VS Code (or VS Codium) with the "D Programming Language (code-d)" extension.

@@GaryChike I've heard a lot of the game dev folks like visual studio, and that's what I used in industry, but I like living in VIM and having no need for an IDE as well 🙂

🎶"Came for the low" (ZHU, partywithray) - low level that it is!

I'm not super familiar with module-info, but indeed I could imagine a private function that logged using traits what modules are being used.

@@MikeShah Ah yes, that would be a feature ;) let me test this ...

I suspect it's perfectly fine

Indeed, mike is 'nullptr' . So you'll have to check against null (or otherwise if(mike.get()==nullptr){ // handle case... }) before accessing the pointer in that scope.

@@MikeShah Excellent! Thanks!

@@shanemcleod5500 Cheers!

I can see swapping single elements in arrays being handy, I'm glad you included that example because I can't think of a single case where using std::swap on whole objects would have any logically functional purpose. Maybe as a work around to wire together some terrible spaghetti code strewn across multiple files with excess macros, defines, and use of extern/static? In fresh code, using std::swap version has at best more compile time overhead as the optimizer figures out that the remainder of the file is simply opposite-day and removes all the swapping internally (Essentially converting it into version one.), and I suppose the worst case it will do an an actual runtime swap in memory. E even if it is only swapping memory addresses using spare registers, it's two reads and two writes. As non-hot-path code an address swap is a trivial inefficiency, but the point is that it is any non-zero work for absolutely no change to the result.

//some basic operators removed to workaround YT hashtags, angle brackets and some curly braces. Hashtags seem esp problematic. Just tested with godbolt. GCC 14 in -O0 does indeed add the 4 instructions for swapping addresses, and -O1[+] produces identical assembly down to the letter. …include iostream …include utility void myfunc(long A) long fu {4l} ; long bar {5l} ; /*... non-swapping version*/ fu *= A ; bar += -A ; std::cout << bar << std::endl; } /*... end v1*/ /**... swapping version **/ std::swap(fu,bar) ; bar *= A ; fu += -A ; std::cout << fu << std::endl; } /**...end v2**/ int main(){ myfunc(3l); return 0

//basic operators removed to workaround YT. hashtags, angle brackets and curly braces and semicolons also changed multiply to "×" and old style initialize/assignment. Hashtags seem esp problematic. Just tested with godbolt. GCC 14 in -O0 does indeed add the 4 instructions for swapping addresses, and -O1[+] produces identical assembly down to the letter. include iostream include utility void myfunc(long A) long fu = 4l long bar = 5l /*... non-swapping version*/ fu = fu × A bar = bar - A std::cout << bar << std::endl /*... end v1*/ /**... swapping version **/ std::swap(fu,bar) bar = bar × A fu = fu - A std::cout << fu << std::endl /**...end v2**/ int main() myfunc(3l) return 0

So my second reply is still there but hidden unless you sort comments by newest. So frustrating.

Welcome!

Perfectly fine to learn a programming language and then dive into graphics -- I'd recommend doing a few simple projects (e.g. build a small card game, tetris, etc.) and then come back and visit OpenGL. From Java the OpenGL function calls and API will effectively be the same.

@@MikeShah Thanks a lot for your response. As I was searching for learning resources, I found also a huge amount of content to learn physics and gamedev with JS. I have some intermediate experience with the language. How good it would be to learn with JS and then move to C# or C++ (which seem to be much more used in graphics and games thatn Java?

@@eduardabramovich1216 I think hitting the ground running using any language (e.g. JS with something like three.js) would be great. You can always transition or change languages later, but it's important to otherwise learn the concepts, and otherwise get some practice and exposure to the idea of graphics/game programming.

@@MikeShah thanks a lot Mike!

That's probably right. I suspect there's an overload for std::list and std::forward_list but I cannot look at the moment.

Maybe you could use std::swap on those within a range based for? Ah! I just found std::swap_ranges and std::ranges::swap

Would need to look at implementation but cppreference states: "Internally, the elements are not sorted in any particular order, but organized into buckets." en.cppreference.com/w/cpp/container/unordered_set -- so that sounds like a contiguous table that can be resized and reshashed on once load_factor exceeds some threshold.

In graphics we have a separate (extrinsic) 'transform' that transforms each vertex. So locally the geometry of an object (e.g. a box with dimensions 1m x 1m x 1m), but we can 'move' or 'transform each point'. Thus the savings is in not having to duplicate the geometry, and only store a transform (e.g. a vector of floats telling us to move each vertex 1m in the x dimension, 2m in the y dimension, 3m in the z dimension).

Coming from C++ I initially missed namespaces. However, as soon as I started reading other peoples code (e.g. various dub libraries), I really liked the structure that packages provided.

I should have been more specific -- they are similar, and you can use a binary semaphore in a 'mutex-like fashion to guard a resource' but the mechanism of a 'lock' (mutex) and a signal (a binary semaphore that increments/decrements) are indeed different :)

Cheers, enjoy!

There are some more recent editions and it's worth reading. I'd read an applied book alongside it if you're just starting, but the more math-y books will start to make sense why the graphics apis are as they are 🙂

Absolutely -- thank you for your support Gary! Let us know what you're coding these days otherwise!

@@MikeShah I still reside in tutorial hell ❤‍🔥but I'm luvin' it

@@GaryChike Not a bad place to be -- I'm right next to you writing more tutorials as we speak 😄

That is indeed the idea to split the work between CPU and GPU for what each are good at :)

someone on discoed noted that the current gl context is a per thread global that you usually init just once per app runtime. and you'd typically have just one rendering thread.

@@ניריבןלולו Indeed, that is correct. This is one of the things that Vulkan tries to improve upon in regards to the concurrency aspect. That said, usually only one rendering thread is used anyways (or at least historically has been true).

You are most welcome!

That's fair -- in a larger project this should be divided into further systems.