C++ for Scientists - Technische Universität Dresden
C++ for Scientists - Technische Universität Dresden
C++ for Scientists - Technische Universität Dresden
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
2.8. STRUCTURING SOFTWARE PROJECTS 47<br />
#include <br />
#include <br />
int main () {<br />
std::ofstream myfile(”example.txt”);<br />
myfile ≪ ”Writing this to a file. ” ≪ std::endl;<br />
return 0;<br />
}<br />
2.8 Structuring Software Projects<br />
2.8.1 Namespaces<br />
In the last section we mentioned that equal names in different scopes hides the variables (or<br />
functions, types, . . . ) of the outer scopes while defining the same name in one scope is an error.<br />
Common function names like min, max or abs already exists and if you write a function with<br />
the same name (and same argument types) the compiler will tell you that the name already<br />
exists. But this does not only concern common names; you must be sure that every name you<br />
use is not already used in some other library. This really can be a hustle because you might<br />
add more libraries later and there is new potential <strong>for</strong> conflicts. Then you have to rename some<br />
of your functions and in<strong>for</strong>m everybody who uses your software. Or one of your software users<br />
is including a library that you do not know and has a name conflict. This can grow to a serious<br />
problem and it happens in C all the time.<br />
One possibility to deal with this is using different names like max , my abs, or library name abs.<br />
This in fact what is done in C. Main libraries have short function names, user-libraries longer<br />
names, and OS-related internals typically start with . This decreases the probability of conflicts<br />
but does not eliminate it entirely.<br />
Remark: Particularly annoying are macros. This is an old technique of code reuse by expanding<br />
macro names to their text definition, potentially with arguments. This gives a lot of possibilities<br />
to empower your program but much more <strong>for</strong> ruin it. Macros are resistent against namespaces<br />
because they are reckless text substitution without any notion of types, scopes or any other<br />
language feature. Un<strong>for</strong>tunately, some libraries define macros with common names like major.<br />
We uncompromisingly undefine such macros, e.g. #undef major, without merci <strong>for</strong> people that<br />
might want use those macros. Visual Studio defines — till today!!! — min and max as macros<br />
and we advise you to disable this by compiling with /DNO MIN MAX. Almost all macros can be<br />
replaced by other techniques (constants, templates, inline functions). But if you really do not<br />
find another way of implementing it use LONG AND UGLY NAMES IN CAPITALS like the library<br />
collection Boost does.<br />
2.8.2 Header and implementation<br />
It is usual to split class (Chapter 3) and function definition and implementation into different<br />
files. Classes and functions are typically defined in a header file (.hpp), and implemented in a<br />
cpp file, which is then compiled and added to a library. For example, the header file foo.hpp<br />
could be:<br />
foo.hpp: