Cheers -- thank you Mohammad! That's at the top of the wishlist, it will come to this channel :)

Not sure yet -- long term support for C, C++, and Dlang series will continue (as well as other series in game and graphics development). Rust is certainly a candidate language to go in-depth. The one constraint before I add another language series however, is that I have to use it for a project first to get a little experience 🙂

Some are available on my webpage

In some ways when learning programming, I think learning I/O in C first may actually be a big win. All languages seem to abstract on the C library. Understanding buffered/unbuffered I/O is somewhat clearer in C, and then folks can use and read other APIs in languages/libraries that may offer more convenience or otherwise speedup iteration time :)

They're certainly interesting to look at and learn some tricks from -- and over time they're very useful to study more to understand exactly how things work. The STL's goal is to be portable, performant, and generic, so that may impact readability of the code however :)

I would recommend first doing a little bit of C++ first. (Either this free playlist kzbin.info/aero/PLvv0ScY6vfd-R9N-vIDXdd4HO9IYATIxJ or this course: courses.mshah.io/courses/quick-start-introduction-to-modern-c-image-loader) Then as you said -- taking on a project to learn more. I highly would recommend the raytracingi n one weekend book, as it has the source as a fallback, and you can incrementally improve it as you learn more C++.

@@MikeShah thnx ❤

@@Hailfire2455 Cheers!

Can you show exactly what you tried to compile and the full error message?

In Home Simpson's voice 'D'oh'. You're correct, since it's a pointer it is going to just return 8 bytes on 64-bit systems. If I had an array of characters array allocated on the stack it would have done the right thing. Good catch!

Streams could be used in many contexts, so it's a complex topic, and a long answer, but I'll try to explain. One of the crucial benefits of streams is that they store data in a buffer before writing or reading. First I will go through the reasons for using streams, what they can do and some examples of where they might crop up in the computer world. In a second comment below I will discuss the actual mechanics of stream buffering and the structure of streams and their data buffers. You first learn about streams in C++ with std::cout used to print messages to the screen. But streams are much more versatile. They essentially offer an efficient way to send large amounts of data (can be any type of data) when it is split into many smaller chunks. For example, you may have heard of "streaming" data "packets" across the internet to watch a video. This relies on streams. Imagine you want to send a letter with 1 million characters. If you put each character in an envelope and send it, it is slow, and very messy as the words may come through jumbled and disordered since theres no guarantee the post will arrive in order. So it's much better if you write all your characters on one sheet of paper, then send it in one envelope! This is the same with computers, data is slow to send and receive and it can also be difficult to assemble many pieces into order. But if you group many bytes into "packets" you can "stream" them over more quickly and they are already partly assembled into order so it is also easier to read the data on the recieving end, where it would be a complete nightmare to get the job done if you were to do this byte for byte. This can also be the case for sending a file, maybe a picture or video, from one part of memory to another. If you send each pixel one by one, the order gets messy and each transfer takes a long time without actually moving very much. It's much better if we grab a group of pixels, or maybe a frame of a video, and send them over in one piece, the data gets there without being too disordered, and each time you send something, the "envelope" is filled out to its capacity with more data so it will be faster than using a transfer just for onr pixel, when it could have been grouped with others and sent as a full video frame in the same amount of time. Or, say you're messaging someone, it doesn't make sense to send data over every time you hit a keyboard letter, it's easier to wait for you to finish the message and then send it off all together. All of these tasks and MANY others are done by using streams. The idea is that writing data immediately to the computer's main memory drive EVERY time data is available, but maybe only sending a few bytes, is a huge waste of processing power! It's far more efficient, fast, and easier to manage, if you hold on to the data for a while, keeping it in a temporary buffer nearby while the program adds bits and pieces to it, which is quick since the buffer is nearby. When the buffer is full or there's no more data to add for a long time, then all that data can be packaged and sent off as a single coherent block of memory to be written over to a desired location. By sending data in large unified batches in this way, efficiency is HUGELY boosted compared to sending a few bytes here and there as they become available. This is not very noticeable when it comes to trivial tasks like printing the typical "hello world" to the screen because there isn't much data to write in the first place. Even if its done bit by bit, it's still very fast regardless of how you do it. But when it comes to larger data blocks, the efficiency gains become vital! Loading millions of pixels into a graphics card on a video or a 3d program would be all but impossible if you did pixel by pixel, but by batching up pixels into blocks of data to be "streamed" over to the GPU, the task becomes very manageable and it doesn't take the computer 10 days to work out how to put together a simple video, because most of the data already came packaged in a neat and predictable flow when it was being delivered from the main memory! That is the idea behind data streams and what makes them such a powerful and indispensable tool in the C++ language, and that is why they are well worth learning about in the long run when it comes to assembling increasingly complicated programs and projects!

I've gone through the broad ideas behind WHY streams are helpful and the kind of things they are used to do, so now I will explain in greater detail HOW they actually achieve their goal and the mechanics and functionality behind streams and data buffering! Accessing hard drive memory is very slow and inefficient. Streams add small blocks of data to a larger data buffer, then they can save or load the whole block in one go, so access to main memory (usually a file) is done less often, in bulk. Storing small chunks of data to a buffer and transferring it in one block is MUCH more efficient than regulary transferring many small blocks of data every time. "Output" streams store "write" data in a local buffer and then "flush" to a file when the buffer is full. Now the buffer is empty and ready for more "writes". "Input" streams work the other way: a block of data is loaded from a file to the stream's buffer, then data can be "read" from the buffer when needed. When empty, the buffer loads another data batch from the file so more "reads" can be done from the buffer. This is very useful for adding together small chunks of data to be transferred as a single larger block to or from the main computer memory. This reduces the number of slow memory accesses, because a local buffer works MUCH faster than accessing main memory. The buffer only needs to access memory in bulk. Without a buffer, this would be done EVERY time you read or write data to a file. It should be noted, stream "buffering" is done internally. When you read or write, the buffer is loaded and flushed automatically; it is rarely accessed directly. If desired, a buffer CAN be manually assigned right after creating a stream, but the system will do it for you. You can also manually flush the buffer when you like, but the buffer is automatically managed by the stream, so flushing is usually not needed. The buffer is not often used manually, but knowing how it works is VERY helpful for understanding how streams behave! Streams use pointers to track position (eg file position for file streams). tellp/tellg return the number of bytes from the start of a file (or string) while seekp/seekg are used to move the position pointer. tellp and seekp work with the "put" pointer, which is where to write into a file; tellg/seekg are for the "get" pointer, the position to read data from. I like to use separate ostream and istream objects to access a file (or string) to keep write and read operations separated. That covers most of the basics of what streams do and why they are useful! Different types, like string streams or file streams have some extra functions, but the underlying concepts are the same for all streams! Hope this helps you to understand what streams are all about! Best of luck learning this stuff, it's a challenge but well worth knowing about!

@@sephirapple7317 thanks mate for you time. ❣️

@@sephirapple7317 Mate, thanks for your time, that was a great explanation!

@@sephirapple7317 Better than I could have explained -- thanks for taking the time!

Cheers!

Good catch! Generally speaking, it is compiler dependent on the size of the 'int' type. There exist 'fixed-width types' that may be better for portability that otherwise are consistent -- you can learn about them here :) kzbin.info/www/bejne/joOZoJmLpc-ZeJY

Cheers -- thank you for the kind words. Next video added more to streams :) I have some ideas in the gaming space for doing more talking about buffering. The problems start getting really interesting (i.e. tradeoff of encoding/decoding to save time) when you also compress the data for speed purposes in gaming :)

So vectors for instance use 'new' to allocate memory. 'new' is a memory allocator so it has its own data structures to manage where memory is. If we need a bigger chunk, then we'll free that 0x0000 - 0x1000 block, and allocate whatever block is big enough and not previously occuppied. This can indeed present some interesting challenges of 'how to find the bigger chunk' (Well operating system hands it to us effectively), or what type of 'fragmentation' (little free bits in between) may occur. These are all great topics of studies in 'systems programming' that further go into these details. Note -- Again, there's another level of abstraction, as from a processes perspective, we just assume we have a bunch of memory in a linear array -- the operating system has its own allocation of 'heap' memory.

@@NSA-n8n cheers!

😁

You are most welcome!

Cheers!

This is indeed a good question -- because now we effectively have 'two' ways to refer to the same object. Generally speaking, the lifetime of the reference will not effect the original variable unless we explicitly do something -- 'ref' otherwise just goes out of scope in our example. It so happens that 'ref' is in the same scope as 'x' that it doesn't matter here. If the 'reference' takes over ownership of the object, then it can be deleted however through that reference in the case of an object allocated with 'new'. In C++11 we have 'move semantics' which allows ownership to be taken over (more important for dynamically allocated objects with 'new' for instance -- see kzbin.info/www/bejne/aJi4oqyqaq-Hqq8& for an introduction to move).

Cheers -- thank you Damon!

@@wrymeanders8382 cheers, you are most welcome!

Excellent!

Indeed -- I think tooling could be nicely built for a dashboard for larger projects. DMD as a library project will certainly make some of this tooling more easy. over time as well!

Will pin a post to otherwise get all of the unit tests properly named.

Cheers!

The meta programming for pipeline based APIs could indeed be very powerful!

Cheers!

Indeed -- copy & paste error without actually testing (just in the 'discussion' or 'sketch' portion of the video). I'd need to think a bit about a use case for a parameter in a destructor -- perhaps for control flow on how you'd like to perform deletion for instance -- but the mechanism may not work as well as 'defer' or 'scope(exit)' in other languages.

Cheers!

Using it for regular variables probably is -- useful for local scope and generic programming however

Cheers! Nice analogy :)

static asserts should not have any runtime cost for the final product, as they are just executed at compile-time and otherwise stop the program from compiling if they do not pass. static asserts otherwise I would encourage folks to have, and you don't necessarily need to hide them in your implementation. Some folks do hide the test suite however, if that gives away critical information for some reason.

@@MikeShah Got it. Thanks Mike 😀

If you make global 'const' or 'immutable' this is fine. The reason we cannot allow 'int global=3' otherwise to be used in pure functions is because if we have multiple threads then global data could be modified elsewhere, and thus the function would not be pure.

See more with pure here: kzbin.info/www/bejne/hnK7eYJ7qsuJfK8

I watched this episode again; why isn't the compileStatic function not called twice? ah, I see: you did not execute the actual program 😅

@@bastiaan9127 cheers!

Cheers, thanks for the kind words! Perhaps your laptop and PC have different graphics cards? Bindless textures as I understand are an extension, and not part of core OpenGL 4.5 or 4.6

My laptop has a 3050 ti while my PC has a 7800xt

@@JumpercraftYT Might be an issue of updating drivers then. What version of OpenGL is supported on each?

Version 4.6 on both. Also, i tried adding texture arrays instead of bind less but it only worked on my amd gpu instead of my nvidia, which is weird.

@@JumpercraftYT Strange -- I've had the misfortune of having the integrated GPU being the default selected GPU on my machine and that also has caused differences.

Since the value of the move that is being written is not what is being output(i.e. c.x and c.y), x and y still need to be negated.

Cheers!

Excellent!

Me neither (?)

Not aure why the notification did not go out -- maybe a big from KZbin ​@@bsdooby

Generally speaking, I prefer 'constexpr int' versus #define, as the defines are just a textural replacement, and you get the advantage of typecheck. Constexpr also sort of 'forces' a constant propogation or other evaluation for more complicated magic values alongside the stronger typechecking. Depending on your debugger as well, #define's may not expand well (unless you use -ggdb for gdb for instance) either, as the 'magic' value gets lost.

@@MikeShah thank you! your channel is a great resource

I could probably agree with that. Given enough tutorials and some fun graphics/game themes perhaps it could be over time if folks wanted to learn it as a first language. Generally speaking, I still recommend python as a first language -- or even D 🙂

@@marks209 I think for sdl3 that might be the case. There may be a mirror to the sdl2 docs elsewhere otherwise

Welcome! size_t is an 'unsigned integer', usually an unsigned long or some type that can otherwise hold lots of integer values. By convention we use it to ensure we don't access a negative index, as well as to indicate a 'count' or 'index' of something