Well, it's a little hard to debug.  A couple of observations, though:

   - You don't need linked lists at all; you're better off using narray.  If
   you want a list of things, just say something like this:

narray<int> list;
list.push(3);
list.push(9);
list.push(7);
for(int i=0;i<list.length();i++) printf("%d\n",list[i]);

Storage allocation is using exponential doubling, the data structure will
consume less memory even in the worst case, memory locality is better, and
you get full array bounds checking.

That is, narrays can be used both as one-dimensional lists and as
multidimensional arrays.


   - Generally, OCRopus code avoids the use of pointers altogether.  Have a
   look at the coding conventions here:

   http://docs.google.com/View?docid=dfxcv4vc_508vv9g6khd

   Instead of pointers, use autodel<T>, autoref<T> or oblist<T>

   - A Hough transform using narray classes should probably be less than 50
   lines of code if written carefully.

   - Although implementing a Hough transform is didactically useful, it's
   not a very accurate or efficient algorithm.  The RAST algorithm (used
   extensively in OCRopus already) is pretty much always a better choice.

   - If you're using Visual Studio, you need to look at the help files to
   tell you how to turn on the source level debugger.  Under Linux, just type
   (at the command line):

   $ gdb my_program
   (gdb) catch throw                         <- catches array bounds
   violations etc.
   (gdb) run arg1 arg2 arg3 whatever
   ... watch your program running ...


   If you're debugging something frequently, it's useful just to put the
   startup and arguments into a .gdbinit in the current directory; then you
   just type "gdb" to start debugging and go.

Cheers,
Thomas.

On Thu, Sep 11, 2008 at 17:18, Leo <[EMAIL PROTECTED]> wrote:

>
> Hi All
>
> I have upload one of the main function "hough.cc"
> I found out one of the main reason for slow speed is that when I add a
> item to the link list
> I add it to the end of the list, I already change the way to adding
> new items which is adding new item to the beginning of the link list.
> now the speed is much more faster, however there are many other
> segmentation fault in the code, I was wondering is there another other
> way for C debugging
> that I can use instead of just using fprintf(), it will be better if I
> can found out which line the segmentation fault has occur rather then
> just get an error message of
> "Segmentation fault (core dumped)".
>
> I didn't upload all the code, as I think no one will want to read them
> all lol
>
> Regards,
> Leo
>
>
>
> On Sep 10, 5:18 pm, Shag <[EMAIL 
> PROTECTED]<https://mail.google.com/mail?view=cm&tf=0&[EMAIL PROTECTED]>>
> wrote:
> > I think it will be easier to suggest something if you pasted some code
> > here .
> > Cheers,
> > Shantanu
> >
> > On Sep 8, 4:44 pm, Leo <[EMAIL 
> > PROTECTED]<https://mail.google.com/mail?view=cm&tf=0&[EMAIL PROTECTED]>>
> wrote:
> >
> > > Hi All
> >
> > > I just finish convert my hough transform code from Lua to C, and I try
> > > to call this new function from Lua
> > > however it seems it run even slower than when its implemented in Lua.
> > > I been using some fprintf() function in C for debugging segmentation
> > > fault, could the slow speed cause by this function? Other than that I
> > > have no clue why it perform slower than lua, as I convert the code
> > > from Lua into C and most procedure remain the same other than minor
> > > change in the data structure.
> > > any suggestion will be appreciated.
> >
> > > Cheers,
> > > Leo
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"ocropus" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/ocropus?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to