McBopomofo
McBopomofo - 需要重新修改熱鍵
4/07/2014
3/27/2014
3/17/2014
7. Memory : Stack vs Heap
Stack vs Heap So far we have seen how to declare basic type variables such as int, double, etc, and complex types such as arrays and structs. The way we have been declaring them so far, with a syntax that is like other languages such as MATLAB, Python, etc, puts these variables on the stack in C. The Stack What is the stack? It's a special region of your computer's memory that stores temporary variables created by each function (including the main() function). The stack is a "FILO" (first in, last out) data structure, that is managed and optimized by the CPU quite closely. Every time a function declares a new variable, it is "pushed" onto the stack. Then every time a function exits, all of the variables pushed onto the stack by that function, are freed (that is to say, they are deleted). Once a stack variable is freed, that region of memory becomes available for other stack variables. The advantage of using the stack to store variables, is that memory is managed for you. You don't have to allocate memory by hand, or free it once you don't need it any more. What's more, because the CPU organizes stack memory so efficiently, reading from and writing to stack variables is very fast. A key to understanding the stack is the notion that when a function exits, all of its variables are popped off of the stack (and hence lost forever). Thus stack variables are local in nature. This is related to a concept we saw earlier known as variable scope, or local vs global variables. A common bug in C programming is attempting to access a variable that was created on the stack inside some function, from a place in your program outside of that function (i.e. after that function has exited). Another feature of the stack to keep in mind, is that there is a limit (varies with OS) on the size of variables that can be store on the stack. This is not the case for variables allocated on the heap. To summarize the stack: the stack grows and shrinks as functions push and pop local variables there is no need to manage the memory yourself, variables are allocated and freed automatically the stack has size limits stack variables only exist while the function that created them, is running The Heap The heap is a region of your computer's memory that is not managed automatically for you, and is not as tightly managed by the CPU. It is a more free-floating region of memory (and is larger). To allocate memory on the heap, you must use malloc() or calloc(), which are built-in C functions. Once you have allocated memory on the heap, you are responsible for using free() to deallocate that memory once you don't need it any more. If you fail to do this, your program will have what is known as a memory leak. That is, memory on the heap will still be set aside (and won't be available to other processes). As we will see in the debugging section, there is a tool called valgrind that can help you detect memory leaks. Unlike the stack, the heap does not have size restrictions on variable size (apart from the obvious physical limitations of your computer). Heap memory is slightly slower to be read from and written to, because one has to use pointers to access memory on the heap. We will talk about pointers shortly. Unlike the stack, variables created on the heap are accessible by any function, anywhere in your program. Heap variables are essentially global in scope. Stack vs Heap Pros and Cons Stack very fast access don't have to explicitly de-allocate variables space is managed efficiently by CPU, memory will not become fragmented local variables only limit on stack size (OS-dependent) variables cannot be resized Heap variables can be accessed globally no limit on memory size (relatively) slower access no guaranteed efficient use of space, memory may become fragmented over time as blocks of memory are allocated, then freed you must manage memory (you're in charge of allocating and freeing variables) variables can be resized using realloc()
3/16/2014
.bash_profile vs .bashrc
.bash_profile vs .bashrc - .bash_profile 只有在 login 的時候執行一次, .bash_rc 每開一個 new terminal 都會執行一次
WHEN working with Linux, Unix, and Mac OS X, I always forget which bash config file to edit when I want to set my PATH and other environmental variables for my shell. Should you edit .bash_profile or .bashrc in your home directory? You can put configurations in either file, and you can create either if it doesn’t exist. But why two different files? What is the difference? According to the bash man page, .bash_profile is executed for login shells, while .bashrc is executed for interactive non-login shells. What is a login or non-login shell? When you login (type username and password) via console, either sitting at the machine, or remotely via ssh: .bash_profile is executed to configure your shell before the initial command prompt. But, if you’ve already logged into your machine and open a new terminal window (xterm) inside Gnome or KDE, then .bashrc is executed before the window command prompt. .bashrc is also run when you start a new bash instance by typing /bin/bash in a terminal. Why two different files? Say, you’d like to print some lengthy diagnostic information about your machine each time you login (load average, memory usage, current users, etc). You only want to see it on login, so you only want to place this in your .bash_profile. If you put it in your .bashrc, you’d see it every time you open a new terminal window. Mac OS X — an exception An exception to the terminal window guidelines is Mac OS X’s Terminal.app, which runs a login shell by default for each new terminal window, calling .bash_profile instead of .bashrc. Other GUI terminal emulators may do the same, but most tend not to. Recommendation Most of the time you don’t want to maintain two separate config files for login and non-login shells — when you set a PATH, you want it to apply to both. You can fix this by sourcing .bashrc from your .bash_profile file, then putting PATH and common settings in .bashrc. To do this, add the following lines to .bash_profile: if [ -f ~/.bashrc ]; then source ~/.bashrc fi Now when you login to your machine from a console .bashrc will be called.
http://stackoverflow.com/questions/1158091/defining-a-variable-with-or-without-export
http://stackoverflow.com/questions/1158091/defining-a-variable-with-or-without-export
export makes the variable available to sub-processes. That is, export name=value means that the variable name is available to any process you run from that shell process. If you want a process to make use of this variable, use export, and run the process from that shell. name=value means the variable scope is restricted to the shell, and is not available to any other process. You would use this for (say) loop variables, temporary variables etc. It's important to note that exporting a variable doesn't make it available to parent processes. That is, specifying and exporting a variable in a spawned process doesn't make it available in the process that launched it.
To illustrate what the other answers are saying:al$ foo="Hello, World" al$ echo $foo Hello, World al$ bar="Goodbye" al$ export foo al$ bash bash-3.2$ echo $foo Hello, World bash-3.2$ echo $bar bash-3.2$
node environment
add to ~/.profile
export NODE_ENV=production
then in node
> process.env.NODE_ENV 'production'
then in express
> app.get('env') //will be 'production'
or:
> NODE_ENV=production node server.js
訂閱：
文章 (Atom)
