X-Git-Url: https://git.creatis.insa-lyon.fr/pubgit/?a=blobdiff_plain;ds=sidebyside;f=DEVELOPPER;h=37af3d44ff705aba8fcbae223ecf9599344bb49b;hb=5794c0f534c2d5dbf871766f3c7a7a0cc6c6118f;hp=3f01c29ec3bcf2148c890f6e42edba9ad36d1156;hpb=d71e2e62b38383d9b960760f6d81c4d545d59fba;p=gdcm.git

diff --git a/DEVELOPPER b/DEVELOPPER
index 3f01c29e..37af3d44 100644
--- a/DEVELOPPER
+++ b/DEVELOPPER
@@ -20,6 +20,11 @@ The following comments are intended for core gdcm developpers.
         -- 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
@@ -128,7 +133,7 @@ gdcm coding style and religious/agnostic beliefs (proposition)
    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
@@ -151,7 +156,7 @@ gdcm coding style and religious/agnostic beliefs (proposition)
     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
@@ -163,7 +168,7 @@ gdcm coding style and religious/agnostic beliefs (proposition)
    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:
@@ -338,17 +343,28 @@ gdcm coding style and religious/agnostic beliefs (proposition)
       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>
@@ -357,9 +373,13 @@ CVS policy
 * 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).
+------------------------------------------------