> I have a number of issues with this proposal.
> 
> (1) You need to explicitly justify moving from C to C++.  In particular,
> renaming all existing C sources to C++.  What does the project gain from this?
> What are the possible repercussions (ie. what new problems are introduced and
> what new potential for error is obtained)?  The renaming introduces a lot of
> noise that makes it difficult to evaluate the rest of the change.
> 
> (2) This merge marks most sources as executable.  That is undesirable.
> 
> (3) What is the .directory file?  It does not appear to be necessary to build
> the project.
> 
> (4) Please do not use ///-style or //!-style comments, use Javadoc-style (/**)
> comments for consistency with the style of other uTouch projects.
> 
> (5) The various classes implement their own containers.  Is there a good
> reason not to use the (tested, dependable) standard library instead?  One of
> the main advantages to porting to C++ is the ability to use the C++ library.
> 
> (6) None of this code is exception safe.  When errors are encountered,
> resources are leaked or undefined behaviour is encountered.
> 
> (7) There is no cleanup:  objects are created using new but never deleted.
> 
> (8) Class constructors are assigning initial values to members in the
> constructor body instead of using initializer lists.  Most of the classes are
> C structs that rely on external code to maintain their invariants:  what is
> the point of converting to C++ if the code is just non-OO style C?  See
> http://en.wikipedia.org/wiki/Class_invariant.
> 
> (9) Why add a capital G or D to classes and function names?  This does not
> contribute to readability in a positive way.  If this is to represent words
> like "device" or "gesture", use those words.  We are not experiencing a
> shortage of ASCII.
> 
> (10) Some variable names could reflect their purpose better:  for example,
> what is "local" used for?
> 
> (11) "header.h" is not an acceptable header file name.  Also, please do not
> create a single header file to include all other header files any source file
> might need.  Headers should pull in only the minimal subset of headers they
> need to compile on their own.  Never put a "using namespace" directive in a
> header file.
> 
> (12) GINN::Dadded catches an exception of type error_t, but there is no code
> inside the try-block that can throw such a type.  The only exception possible
> from the try-block is std::bad_alloc.
> 
> (13) Please leave at least one blank line between function definitions for
> readability.


1: if you think renaming is getting you to trouble so i must do what to port to c++
2: No why you think so
3: i remove it if the code accepted
4: the comment is not part of code! please review the code not comment!
5: can you make instance in my code
6: can you make instance in my code
7: it's the c++ advantage unlike C it delete them automatically
8: it's only on some classes and it is because if we change it need to recreate a code fuly again!!
9: if you use a very long function name you made the developer get to pitfall it's the best way to simple the develop process and have various advantage 
10: it use to create a local copy of ginn object that is load for device .it's show the duty fully
11: i like this way;also adding header not make your software slow!
12: it's an static error ,add error_t is for just through of the compiler error. also use  error_t for dynamic error.
13: the comment is not part of code! please review the code not comment!