Hi Mario,<div><br></div><div>I am not familiar with c/c++ specification,</div><div>but I had encountered the same problem before.</div><div>See my experimental "msvc" branch commit diff. <a href="https://github.com/sanak/pgrouting/commit/9ef417078eadad8554e1d7cd3ccd7592266b2912">https://github.com/sanak/pgrouting/commit/9ef417078eadad8554e1d7cd3ccd7592266b2912</a></div>
<div>(NOTICE: Don't mind my temporary fix(symbol naming, .etc),</div><div> because my "msvc" branch is "only" experimental.)</div><div><br></div><div>And I agree that different symbol name using.</div>
<div><br></div><div>Regards,</div><div><br><div class="gmail_quote">2012/7/11 Mario Basa <span dir="ltr"><<a href="mailto:mario.basa@gmail.com" target="_blank">mario.basa@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello Steve,<br>
<br>
With the problem I am encountering when I brought the driving_distance<br>
into core, both boost_drivedist.cpp and astar_boost_wrapper.cpp have<br>
graph_add_edge() function and Edge and Vertex structs.<br>
<br>
The offending components here are the structs I think since they have<br>
different values even if they have the same name in the c++ files. So,<br>
whichever you compile first (astar or drivedist) in the CMAKE file<br>
will work while the other will core dump. For fun, I made a different<br>
library in the CMAKE for drivedist, and it still dumped core.<br>
<br>
It was only after I renamed everything (Edge_dd,Vertex_dd, etc.) did<br>
it work. Again, this is so difficult to debug, well time consuming<br>
anyway. I am not so familiar with the recent gcc compiler, but I'll<br>
try look if there is a compile time option to give out warnings for<br>
similar function names.<br>
<br>
I'll move the common functions into a pgr_utils.h file to take out<br>
redundancy in core.<br>
<span><font color="#888888"><br>
Mario.<br>
</font></span><div><br>
<br>
On Wed, Jul 11, 2012 at 8:38 AM, Stephen Woodbridge<br>
<<a href="mailto:woodbri@swoodbridge.com" target="_blank">woodbri@swoodbridge.com</a>> wrote:<br>
</div><div><div>> On 7/10/2012 5:23 AM, Mario Basa wrote:<br>
>><br>
>> Hello,<br>
>><br>
>> I am encountering problems placing the drivedist.c and<br>
>> boost_drivedist.cpp into core (everything compiles, drivedist works<br>
>> but astar searches dumps core. If I take out drivedist, astar works<br>
>> like normal.), so I decided to poke around the source. I just found<br>
>> out that there are so many duplicate functions (i.e.<br>
>> finish(),text2char(),etc.) and struct names (edge_column,etc.) in each<br>
>> of the C files.<br>
>><br>
>> Since C does not have any namespace functionality nor function<br>
>> overloading, I don't have any idea which one will be called whenever<br>
>> there is a library call. Scary since this will be difficult to debug.<br>
>><br>
>> Now that pgRouting is getting source contributions, I think this will<br>
>> be a good time that we start discussing function naming conventions to<br>
>> avoid duplicates as well as directory (core and extensions)<br>
>> structures.<br>
><br>
><br>
> Mario,<br>
><br>
> UGH! Ideally one of two things should happen:<br>
><br>
> 1. common functions with compatible signatures should be extracted into a<br>
> common.c common.h or utils.c utils.h and get shared by all algorithms that<br>
> need them.<br>
><br>
> 2. local functions should all be declares "static" which means they are not<br>
> visible or callable from references outside the file they are declared in.<br>
><br>
> So, if you have a C wrapper and it needs functions and no other files need<br>
> to use these functions then they should be declared as static and placed in<br>
> the C wrapper file.<br>
><br>
> If you have some function that multiple C files need to call or you C++ also<br>
> needs to call, then it needs to go into a file like <namespace>_utils.c and<br>
> all the functions in this file need to have a unique<br>
> <namespace>_functionname() like signature.<br>
><br>
> I think this will minimize the changes we need to make to the existing code<br>
> using "static" declarations for most things, and then moving the others into<br>
> some namespace'd set of files.<br>
><br>
> How does this sound?<br>
><br>
> I like the idea of having multiple library .so files rather than one huge<br>
> file because it keeps things separated but more so because it makes it easy<br>
> to rebuild one library without effecting any of the others. I would like to<br>
> know that if I change TRSP that there is little to zero change that I can<br>
> impact the other algorithms.<br>
><br>
> Thank about a production environment where you have pgrouting running on<br>
> lots of databases and in one database you want to add TRSP. By making it one<br>
> big library you force a change on all the databases that did not need that<br>
> change, but if TRSP is in a separate library then all the database that are<br>
> not using it can be assured to be stable because they did not change. The<br>
> worsted cases is that the new database with TRSP added to it might be<br>
> unstable and if there is a collision of files like you describe the cases<br>
> crashes, it only happens in the new database. Hmmm, maybe it doesn't work<br>
> this way once the postgresql loads the library. But I don't remember having<br>
> problems loading multiple libraries.<br>
><br>
> Thoughts?<br>
><br>
> -Steve<br>
> _______________________________________________<br>
> pgrouting-dev mailing list<br>
> <a href="mailto:pgrouting-dev@lists.osgeo.org" target="_blank">pgrouting-dev@lists.osgeo.org</a><br>
> <a href="http://lists.osgeo.org/mailman/listinfo/pgrouting-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/pgrouting-dev</a><br>
_______________________________________________<br>
pgrouting-dev mailing list<br>
<a href="mailto:pgrouting-dev@lists.osgeo.org" target="_blank">pgrouting-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/pgrouting-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/pgrouting-dev</a><br>
</div></div></blockquote></div><br></div>