Fortran Garbage Collector

http://stackoverflow.com/questions/13966955/does-fortran-have-a-garbage-collectorgc/13967374#13967374

Modern Fortran has many ways of declaring variables. Items simply declared will exist for the duration of the scope of the entity. So "real, dimension (N) :: array" declared in a procedure will automatically disappear when that procedure returns. Naturally variables declared in the main program or module variables or common (outmoded) will persist for the duration of the program.

allocate -- dynamic allocate 

Variables can be dynamically allocated with "allocate" (to do so, they have to be declared with the allocatable attribute). Since Fortran 95 allocatable variables that are local to a procedure are automatically deallocated when the procedure returns! They will not leak memory! (Some programmers might consider it good practice to explicitly deallocate the variables anyway, even though it isn't strictly necessary.) (Of course, you can waste memory in the sense of not explicitly deallocating a variable that you know that you don't need anymore.)

t is possible to leak memory with pointers. You can allocate memory with a pointer, then assign the pointer to to another variable, losing the previous association. If you didn't deallocate that memory you have a leak. The need for pointers is less in Fortran than in some other languages ... many things can be done with allocatable variables, which are safer -- no memory leaks

http://stackoverflow.com/questions/2300199/allocatable-arrays-or-pointer-arrays
Allocatable arrays Vs Pointer arrays?

Allocatable arrays can result in more efficient code because the arrays will be contiguous. Particularly if the array is passed to a subroutine, being contiguous can prevent the need for the compiler creating a temporary copy. For local variables in subroutines (without the SAVE attribute) (for Fortran 95 and higher), allocatable arrays are automatically deallocated upon exit from the subroutine, avoiding a memory leak. Memory leaks aren't possible with allocatables, except in the sense of the programmer not deallocating an array that is no longer need. With pointers, you can reassign a pointer, leaving some memory inaccessible and lost -- one form of a leak. If an allocatable will do the job, I recommend using that method instead of a pointer. Some reasons to use pointers: taking a section of an array, or creating a data structure such as a linked list. For the purpose of creating an array of size determined at run time, I'd use an allocatable.

HDF5 undefined reference and can't find hdf5.h

-lhdf5
http://ubuntuforums.org/showthread.php?t=1246165

How to install Qt5 on Ubuntu

sudo apt-get install build-essential perl python "^libxcb.*" libx11-xcb-dev libglu1-mesa-dev libxrender-dev flex bison gperf libicu-dev libxslt-dev ruby libcups2-dev libgstreamer-plugins-base0.10-dev libssl-dev libpulse-dev libasound2-dev libgtk2.0-dev
wget http://releases.qt-project.org/qt5/5.0.0/single/qt-everywhere-opensource-src-5.0.0.tar.gz
tar -xf qt-everywhere-opensource-src-5.0.0.tar.gz
cd qt-everywhere-opensource-src-5.0.0




./configure -opensource -confirm-license -release -nomake tests -nomake examples -nomake demos

make -j3

sudo make install




http://2buntu.com/1267/how-to-install-qt-50-on-ubuntu-1210/

c++ terminate called without an active exception producer/consumer

std::thread - “terminate called without an active exception”, don't want to 'join' it

30.3.1.3 thread destructor [thread.thread.destr]

~thread();

If joinable() then terminate(), otherwise no effects. [ Note: Either implicitly detaching or joining ajoinable() thread in its destructor could result in difficult to debug correctness (for detach) or performance (for join) bugs encountered only when an exception is raised. Thus the programmer must ensure that the destructor is never executed while the thread is still joinable. — end note ]

What this means is that you should not let threads go out of scope without first calling either join() ordetatch().

Concept of producer/consumer
http://stackoverflow.com/questions/7381757/c-terminate-called-without-an-active-exception-producer-consumer

using valgrind to check memory leak

http://cs.ecs.baylor.edu/~donahoo/tools/valgrind/

valgrind --tool=memcheck --leak-check=yes --show-reachable=yes --num-callers=20 --track-fds=yes ./test

Unused parameter

You can cast function parameters to void to avoid "unused parameter" compile warnings.

iterator find(const Data& item) const {
 (void) item;
 return iterator(nullptr);
}

Assuming your question was asked given that everything already does compile, I would say code in an order that makes sense to you. Hint: think about incremental testability. The more pieces of functionality you can test along the way, the less time you will spend debugging.

nullptr Vs. NULL

1. We encourage you to use nullptr as we have C++11, the latest version;

2. Whenever a method receives a pointer as a parameter, it can check whether it is equal to nullptr and do the appropriate thing. This is part of good defensive programming. Don't assume other parts of your program are acting as they should. 

2) Are we going to assume that null data will never be inserted in the insert method in BST.hpp?

3. Note that we will not test for this corner case, as we didn't specify that you needed to handle the case in the writeup. 

(This is a general rule, we won't hold you responsible for details left unspecified)
However, testing this corner case could be helpful during code development, much as cassert can be useful

The reason you should use nullptr instead of NULL: http://www.devx.com/cplus/10MinuteSolution/35167

nullptr: A Type-safe and Clear-Cut Null Pointer

Whether you're using NULL or 0, your C++ apps are subjected to bugs and maintenance problems that are caused by the ambiguity of 0. Find out how to use the nullptr keyword instead of 0 to indicate a null pointer value.

‘cout’ was not declared in this scope

 ‘cout’ was not declared in this scope

if you forget to include iostream or to use the std namespace.

WRONG

 #include <iostream>  // no using namespace std;
 int main(void) 
 {
   cout << "A";
   return 0;
 }

ALSO WRONG

 using namespace std;   // no #include iostream
 int main(void) 
 {
   cout << "A";
   return 0;
 }

RIGHT

 #include <iostream>   // one of two
 using namespace std;    // two of two, yay!
 int main(void) 
 {
   cout << "A";
   return 0;
 }