[pgrouting-dev] duplicate function names in core

[Daniel Kastl]

Hi Mario and Steve,

I like what Steve wrote. If there are reusable functions that can be used
from more than one algorithm, then we should do so.

I would like to add that the separation of "core" and "extra" was only
because of the CGAL and GAUL dependency. So someone, who didn't need
driving distance, shouldn't have to struggle with compiling CGAL as well.

Now as we don't need CGAL anymore since PostGIS 2.0, there is no need for
"core" and "extra" anymore. GAUL is GPL as pgRouting and it didn't change
for many years. So we could even compile it together with pgRouting.

Instead of "core" and "extra" I would prefer a directory for every new
pgRouting algorithm. It could then contain files like:

   - commons
      - sql
      - src
      - tests
      - docs_common.rst
   - <algorithm_name>
      - sql
         - <file_name>.sql
      - src
         - <file_name>.c
         - <file_name>.h
         - <file_name>.cpp
      - tests
      - README.txt
      - docs_<algorithm>.rst

For example we can then ask for each algorithm to contain tests and
documentation.

Daniel



On Wed, Jul 11, 2012 at 2:38 AM, Stephen Woodbridge <woodbri at swoodbridge.com
> wrote:

> On 7/10/2012 5:23 AM, Mario Basa wrote:
>
>> Hello,
>>
>> I am encountering problems placing the drivedist.c and
>> boost_drivedist.cpp into core (everything compiles, drivedist works
>> but astar searches dumps core. If I take out drivedist, astar works
>> like normal.), so I decided to poke around the source. I just found
>> out that there are so many duplicate functions (i.e.
>> finish(),text2char(),etc.) and struct names (edge_column,etc.) in each
>> of the C files.
>>
>> Since C does not have any namespace functionality nor function
>> overloading, I don't have any idea which one will be called whenever
>> there is a library call. Scary since this will be difficult to debug.
>>
>> Now that pgRouting is getting source contributions, I think this will
>> be a good time that we start discussing function naming conventions to
>> avoid duplicates as well as directory (core and extensions)
>> structures.
>>
>
> Mario,
>
> UGH! Ideally one of two things should happen:
>
> 1. common functions with compatible signatures should be extracted into a
> common.c common.h or utils.c utils.h and get shared by all algorithms that
> need them.
>
> 2. local functions should all be declares "static" which means they are
> not visible or callable from references outside the file they are declared
> in.
>
> So, if you have a C wrapper and it needs functions and no other files need
> to use these functions then they should be declared as static and placed in
> the C wrapper file.
>
> If you have some function that multiple C files need to call or you C++
> also needs to call, then it needs to go into a file like
> <namespace>_utils.c and all the functions in this file need to have a
> unique <namespace>_functionname() like signature.
>
> I think this will minimize the changes we need to make to the existing
> code using "static" declarations for most things, and then moving the
> others into some namespace'd set of files.
>
> How does this sound?
>
> I like the idea of having multiple library .so files rather than one huge
> file because it keeps things separated but more so because it makes it easy
> to rebuild one library without effecting any of the others. I would like to
> know that if I change TRSP that there is little to zero change that I can
> impact the other algorithms.
>
> Thank about a production environment where you have pgrouting running on
> lots of databases and in one database you want to add TRSP. By making it
> one big library you force a change on all the databases that did not need
> that change, but if TRSP is in a separate library then all the database
> that are not using it can be assured to be stable because they did not
> change. The worsted cases is that the new database with TRSP added to it
> might be unstable and if there is a collision of files like you describe
> the cases crashes, it only happens in the new database. Hmmm, maybe it
> doesn't work this way once the postgresql loads the library. But I don't
> remember having problems loading multiple libraries.
>
> Thoughts?
>
> -Steve
>
> ______________________________**_________________
> pgrouting-dev mailing list
> pgrouting-dev at lists.osgeo.org
> http://lists.osgeo.org/**mailman/listinfo/pgrouting-dev<http://lists.osgeo.org/mailman/listinfo/pgrouting-dev>
>



-- 
Georepublic UG & Georepublic Japan
eMail: daniel.kastl at georepublic.de
Web: http://georepublic.de
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pgrouting-dev/attachments/20120711/b19996ff/attachment.html>