-- GDCM_VTK When this option is on VTK_DIR might require manual
configuration
-- GDCM_WRAP_PYTHON
+ -- CMAKE_CXX_FLAGS (when working with gcc of course) should be set to
+ -g -O0 -Wall -W -Wshadow -Wunused-variable -Wunused-parameter
+ -Wunused-function -Wunused -Wno-system-headers -Wno-deprecated
+ -Woverloaded-virtual
+ (this is to avoid spurious problems with overloading)
* Configure cmake: hit c
* Generate the makefiles (or dsw): hit g
- Compile gdcm
across multiple lines as necessary.
- Methods and functions should keep a reasonable number of lines when
possible (a typical editor displays 50 lines). Avoid code duplication.
- Allways prefer creating a new method or function to duplication.
+ Always prefer creating a new method or function to duplication.
A high indentation level generally suggests the need for a new
method or function.
- All the code should be properly indented. The appropriate indentation
uppercase as in LUT or RGBA.]
While this does result in long names, it self-documents the code.
- Naming Files:
- Files should have the same name as the class, with an "gdcm" prepended.
+ Files should have the same name as the class, with a "gdcm" prepended.
Header files are named .h, while implementation files are named either
.cxx or .txx, depending on whether they are implementations of templated
classes. For example, the class gdcm::Document is declared and defined
named beginning with a capital letter, as in GetImageDataSize().
- Naming Local Variables:
Local variables begin in lowercase. There is more flexibility in the
- naming of local variables allthough they still should convey some
+ naming of local variables although they still should convey some
semantics.
* Classes:
T* foo = 0;
and not
T *foo = 0;
- - Allways define a typedef for a new type and be consistent in usage.
+ - Always define a typedef for a new type and be consistent in usage.
Use
typedef Header* HeaderPointer;
HeaderPointer MyHeaderPointer;
- One notorious counter example for non using C style inclusion concerns
- exact-width intergers (since there seem to be no equivalent for C++).
+ exact-width integers (since there seem to be no equivalent for C++).
When using exact-width integers use the typedef names defined by
the Basic ISO C99: 7.18 Integer types i.e.
int8_t int16_t int32_t int64_t (signed integers)
and
uint8_t uint16_t uint32_t uint64_t (unsigned integers).
+ Conversion table is then:
+ unsigned char -> uint8_t;
+ unsigned short -> uint16_t;
+ unsigned int -> uint32_t;
+ unsigned long -> uint32_t;
+ unsigned long long -> uint64_t;
+ (signed) char -> int8_t;
+ short -> int16_t;
+ int -> int32_t;
+ long -> int32_t;
+ long long -> int64_t;
Hence do not use declarations like "unsigned int".
With g++, accessing those typedef is achieved by the following
#include <stdint.h>
* All the commits should be atomic. They must preserve the compilation
in order to prevent checkouts with broken code.
* All the commits must correspond to a stade of the code where ctest
- runs and has no failing subtest. Allways run ctest before commiting.
- Note: * you can launch ctest in verbose mode through the command
+ runs and has no failing subtest. Always run ctest before commiting.
+ Note: * you can start ctest in verbose mode through the command
ctest -V >& log
- * you can launch a single test through ctest with
+ * you can start a single test through ctest with
ctest -R FailingTestName -V >& log
------------------------------------------------
+Compiler flags policy:
+ When working with gcc please use the flags specified in DEVELOPPER file
+ (in order to avoid difficult overloading problems).
+------------------------------------------------
git://git.creatis.insa-lyon.fr / gdcm.git / blobdiff