[GRASS-dev] Re: [GRASS GIS] #197: sfd support for r.terraflow

[GRASS GIS]

#197: sfd support for r.terraflow
--------------------------+-------------------------------------------------
  Reporter:  adanner      |       Owner:  grass-dev at lists.osgeo.org
      Type:  defect       |      Status:  new                      
  Priority:  major        |   Milestone:  6.4.0                    
 Component:  Raster       |     Version:  svn-develbranch6         
Resolution:               |    Keywords:  terraflow r.terraflow    
  Platform:  Unspecified  |         Cpu:  Unspecified              
--------------------------+-------------------------------------------------
Comment (by adanner):

 Replying to [comment:2 glynn]:
 > Replying to [comment:1 adanner]:
 > > Can someone double check the Makefile? I wasn't sure about this
 BROKEN_MAKE flag. The modifications to the Makefile are just to build the
 new C source for tflowopts.c, so if the BROKEN_MAKE flag is
 C++/r.terraflow specific, I don't think there is a problem.
 >
 > BROKEN_MAKE is only required for rules with order-only dependencies
 (some versions of make don't handle these correctly).
 >
 > However: is it really necessary for the new file to be in C instead of
 C++? It would simplify matters to keep everything in the same language.

 Yes, the new file must be in C and not C++. The g++-4.2 throws a warning
 if you try to assign a string constant to a char *. E.g.,

 cat test.c
 int main(){
         char * example = "hello";
 }

 gcc test.c -o test  //ok

 mv test.c test.cc; g++ test.c -o test
 test.cc: In function ‘int main()’:
 test.cc:2: warning: deprecated conversion from string constant to ‘char*’

 In C++, the following are preferred and do not give a warning

 std::string example="hello";
 const char * example2="hello";

 However, as the code in question is initializing a bunch of GRASS structs
 which cannot use const or std::string, it is best to do this in C and link
 the rest of terraflow to this C code.

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/197#comment:3>
GRASS GIS <http://grass.osgeo.org>