dcgreen2k

If you want to do C/C++ development, I highly recommend using Visual Studio instead since it's an actual IDE. VSCode is primarily just a text editor.

My pick tends to be the best supported and easiest to use compiler for the system you're programming on. For Windows, that's MSVC which comes with Visual Studio (not VSCode). I do the majority of my programming on Linux and I use GCC. Making the compiler create an executable that runs faster or takes up less space on disk is as simple as enabling optimizations. All the popular compilers (MSVC, GCC, and Clang) are very good at that.

It lets us treat it as an array because an array is just a contiguous block of memory. Malloc gives you a contiguous block of memory with a pointer to the very start of it. On top of that, did you know that the [] arrays use is just syntax sugar? The square brackets are a short form of doing something called pointer arithmetic, which is how your computer actually works with arrays. Here's what I mean: #include <stdio.h> #include <stdlib.h> int main() { // Allocate memory that can hold an array of 10 ints int* array = malloc(sizeof(int) * 10); // Fill up the memory with values from 0 to 9 for (int i = 0; i < 10; i++) { array[i] = i; } // Get the value at index 5 with regular array syntax int value_regular = array[5]; printf("%d\n", value_regular); // That array syntax actually expands to this pointer arithmetic int value_arith = *(array + 5); printf("%d\n", value_arith); // That expansion is also why we can do this weird thing int value_weird = 5[array]; printf("%d\n", value_weird); // Don't forget to free the memory free(array); return 0; } In short, arrays are just something programming languages give us to make working with blocks of memory easier.

Maybe this will work? https://stackoverflow.com/questions/63134299/how-to-increase-max-stack-size-in-c-using-vscode Also, is there a reason you're trying to allocate that much memory on the stack? Typically, the stack is 1MB on Windows and 8MB on Linux. The heap is specifically made to store large amount of data like what you're doing here.

In C, you don't need to include the typecast because malloc's return value automatically gets cast to the type of the variable you assign it to. This means: int* array = (int*) malloc(sizeof(int) * 100); int* array = malloc(sizeof(int) * 100); do the same thing. Note that you do still need to include the variable type at the very start of the line, or else it won't work like you want it to as an array of ints. All you need to access the memory you allocate is the pointer that malloc returns. That pointer is the start of the array that got allocated, and no additional bookkeeping is required. Here's an example of using memory allocated with malloc: #include <stdio.h> #include <stdlib.h> int main() { // Allocate memory that can hold an array of 10 ints int* array = malloc(sizeof(int) * 10); // Fill up the memory with values from 0 to 9 for (int i = 0; i < 10; i++) { array[i] = i; } // Print out the values we just wrote for (int i = 0; i < 10; i++) { printf("%d\n", array[i]); } // Don't forget to free the memory free(array); return 0; } You can dynamically resize arrays. In C, you would use realloc to do this. #include <stdio.h> #include <stdlib.h> int main() { // Allocate memory that can hold an array of 10 ints int* array = malloc(sizeof(int) * 10); // Fill up the memory with values from 0 to 9 for (int i = 0; i < 10; i++) { array[i] = i; } // Expand the array to hold 100 ints array = realloc(array, sizeof(int) * 100); // The values we wrote earlier got copied into the new array for (int i = 0; i < 10; i++) { printf("%d\n", array[i]); } // But now we can write more values without causing a memory error // Here we're writing to the end of the array for (int i = 90; i < 100; i++) { array[i] = i; } // Check the new values we wrote for (int i = 90; i < 100; i++) { printf("%d\n", array[i]); } // Don't forget to free the memory free(array); return 0; } In C++: #include <iostream> int main() { // Allocate memory for an array of 10 ints int* array = new int[10]; // Write values in the array for (int i = 0; i < 10; i++) { array[i] = i; } // Expand the array to hold 100 ints // Note: we do this in C++ by creating an entirely new array! int* bigger_array = new int[100]; // Next, we copy all the old elements over for (int i = 0; i < 10; i++) { bigger_array[i] = array[i]; } // Last, delete the old array delete[] array; // Let's make sure the elements are present in the new array for (int i = 0; i < 10; i++) { std::cout << bigger_array[i] << std::endl; } // Free the new array delete[] bigger_array; return 0; } In Java: public class Main { public static void main(String[] args) { // Allocate memory for an array of 10 ints int[] array = new int[10]; // Write values to the array for (int i = 0; i < 10; i++) { array[i] = i; } // Expand the array to hold 100 ints int[] biggerArray = new int[100]; // Copy the old values System.arraycopy(array, 0, biggerArray, 0, 10); // Make sure the old elements are present for (int i = 0; i < 10; i++) { System.out.println(biggerArray[i]); } } } Or, you could use std::vector in C++ and ArrayList in Java to have a dynamic array without having to worry about allocating, deallocating, copying, etc.

You can allocate way more memory than your system actually has. This video shows off what happens really well: Yes, that's one way to fill the memory. If you want to learn different ways to use the memory you allocate, I highly recommend you find a data structures tutorial. On top of that, I think you'd love videos from Jacob Sorber and Low Level Learning. They make a lot of videos related to these questions you're asking.

The program doesn't print anything because it throws a stack overflow exception before it can reach the call to printf. Adding this code right after the call to SetThreadStackGuarantee shows the error code 87. DWORD err = GetLastError(); printf("%d\n", err); Error code 87 corresponds to "ERROR_INVALID_PARAMETER" according to https://learn.microsoft.com/en-us/windows/win32/debug/system-error-codes--0-499- In addition, the documentation for SetThreadStackGuarantee states that the value you pass into it cannot be larger than the reserved stack size. https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-setthreadstackguarantee This means that using SetThreadStackGuarantee in this way isn't the right way to increase the stack size. This thread seems useful for doing that: https://social.msdn.microsoft.com/Forums/en-US/2a5b32b6-683b-4729-92d3-45ed7a89ef3f/stack-overflow-and-how-to-increase-the-stack-size?forum=Vsexpressvc

In my experience, it comes from when you're trying to solve a problem and you get stuck. Or, you've already solved it and want to optimize your code. To fix that, you Google a question related to the problem you're having and see what other people have done. Simple as that. At some point you'll come across solutions that use smart pointers, the template lib, etc, and try them out for yourself. Learning to code by doing doesn't just mean sitting down and writing code, because it's impossible to get anywhere by just doing that. You need external resources to learn from to get better and that doesn't have to be from a textbook.

You don't need to use polymorphism or any other fancy OOP features when using C++. In fact, you could write C++ code just like how you would write in C and have it work just the same. Why might someone prefer to write in C++ instead of C, if they aren't making use of OOP? For one, C++ has the standard template library. It's a set of generic data structures and algorithms, among other things, that I find to be very useful. C++ also has additions to help manage memory, like using smart pointers instead of raw pointers.

Correct, embedded systems (at least the ones I work with) usually have entirely separate memory for the program code.

Once the functions get turned into machine code and made into an executable, the compiler can't do any more optimization. We know that instructions must be loaded into memory before they're executed, so any possibility that instructions could be removed from memory would need to be supported by both the CPU and operating system. Let's see how much space a program's instructions actually take up. Here's a large program I wrote a while back. It's an IDE for MIPS assembly with a built-in interpreter and debugger. The executable file takes up 288.4kB of space on disk while it's source code takes up 194.3kB. Using the readelf -S command, I can see how much space each of the executable's sections take up. The .text section is where the actual instructions reside, and they will be placed into memory when the program starts. hex 27dde equals decimal 163294, which means the instructions take up just over 163kB. Keeping that in mind, let's see how much RAM this program uses, shown in the RES column below. Ah. The program takes up 113MB in RAM while its instructions take up only 163kB. To conclude, it would simply be a waste of time to optimize how much memory the instructions use.

It's because there's no way to know for sure that previous instructions won't be executed again. As a simple example, here's how a loop is written in assembly: Close to the bottom of the function, we can the instruction jg .L3. This means that the CPU will jump back to previously-executed instructions if the correct conditions are met. There is no way for the CPU to know this until it executes the cmp instruction, so those earlier instructions must stay in memory.

I see what you're asking now. Yes, the instructions themselves require memory. Those instructions stay in memory until the program stops. At a simplified level, this is what the memory layout of a C program looks like: The text section is where the program's instructions are placed, and they get read from the .exe file when the program starts. Why do the instructions get placed in memory instead of just being read from disk whenever they're needed? Put simply, getting them from disk would be way too slow. In fact, the instructions are often copied from memory into the CPU's instruction cache so that they can be accessed fast enough to keep the CPU fed. RAM is surprisingly slow compared to cache that's very close to the CPU.

Simply calling the function requires 8 bytes of memory on the stack, assuming the compiler has not inlined it. If you create any variables inside that function, the memory usage will increase. If you're asking whether the instructions themselves take up space in memory - yes, they do. They will be loaded into memory when the program starts, but this space is generally negligible compared to how much space data takes up.

Since you asked about specifically the function itself and not the variables inside it, we can check that pretty easily using godbolt.org. Here's an empty function and the assembly code it compiles to without optimization: The only instructions here that deal with memory are push and pop. Specifically, the push instruction pushes the value of the base pointer register onto the stack which uses 64 bits or 8 bytes on a 64-bit machine. Thus, a function call requires 8 bytes of memory on the stack at a minimum.

Everything @igormp said is correct - if the program uses shared libraries (.dll files on Windows and .so files on Linux), then the machine you want it to run on must have those libraries installed. In addition to that, there are library functions that Windows has while Linux doesn't and vice versa. Some examples of this would be the Win32 API on Windows and mmap() on POSIX compliant systems, although there are ways to get around those incompatibilities. Lastly, different operating systems will use different executable file formats that aren't interchangeable for the most part. For example, Linux uses ELF files and Windows uses PE32+ files. The compiler you use will have to target one of these file formats to have its output be able to run on your system.

The GUI is nowhere near as polished as the Windows version, but it works. It also uses redshift as its backend instead of the original xflux, which explains why it still works today. I'm using it on PopOS 22.04 with the default Cosmic DE.

I have an 80GB IDE drive from 2002 and two 160GB SATA drives from 2006, all still working. The last time I checked, both of those SATA drives had around 50k hours on them. Funnily enough, the only drive I've ever had fail was a 120GB SATA SSD.

Yes, it's f.lux. I've been using it since 2012 and it's been great for reducing blue light as you mentioned. The main problem I have with my monitors is that they're incredibly bright at night, even at their minimum supported brightness. The dim command I use has been very helpful in alleviating that issue.

This was exactly my experience during undergrad for my computer engineering degree. For both myself and my girlfriend, who was in computer science, there were multiple times when the cost of textbooks for a semester was more than we had in our savings accounts. Furthermore, only a few of those textbooks were available at the university library. Many of the professors I've talked to have acknowledged that this is an issue for students. On multiple occasions, my professors figured out a way for students to get the required textbooks for free or at a discount, usually by getting an electronic copy directly from the author or by determining when older versions of the textbook were sufficient. Interestingly, every time I was able to get an electronic copy of a textbook from the author, it was completely free. I wish that was an option. Unfortunately, a college degree is required for many of those who want to pursue a career in a skilled labor field. Not everyone who goes to college will be able to pay the full cost of textbooks, as I know through personal experience. That being said, I believe piracy is wrong in general. More specifically, one should not pirate media if they are able to pay for it instead.

It's pretty basic, but here's what I've added to my .bashrc. I use Linux as my daily driver and I mostly do programming on this machine, for both university and my research job. The only really interesting thing I have here is my "dim" command, which I can use to set my monitor to a lower brightness than is normally possible. Entering "dim 0.5" will set it to half brightness for example. Good for night owls like me.

Good to hear you figured it out. In general, to get data into an object from the outside, you'll need to pass the data as an argument. This can be done either in the constructor or in a method you call on that object. To get data out of an object, you'll almost always use the return value of one of that object's methods. To use methods inside a class, you will need to create an object unless that method is declared as being static.

Java imports by class, not by file. Furthermore, if both classes are in the same package, then you shouldn't need to import anything to have them work together. Could you please post your code, so we can figure out what's going wrong?