03.12.2012 Views

C++ for Scientists - Technische Universität Dresden

C++ for Scientists - Technische Universität Dresden

C++ for Scientists - Technische Universität Dresden

SHOW MORE
SHOW LESS

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:

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!