Hi, thanks for the replies,
well, good catch, I feel a little bit dump having commite exactly that stupid error. The division by 0. Almost the first thing you read in every text about programming errors ...
The reason why I wanted to chang this is that the update of the wxProgressDialog, as it is now, at least on my project with has about 30 files (so it is rather small), slows down the whole thing. If I comment out all the updating of that wxProgressDialog, the plugin parses my project in about one second. Whith the wxProgressDialog as is it takes about 10 seconds. I wanted to speed this dialog up having it been called less and updating each time a greater chunk of the gauge, not having it update by one step for every line of data that gets parsed ...
The idea of using all that (not very bright) division by zero code was to update the gauge in equal steps in relation to the number of lines that get parsed, that is to say, no matter what the size of the wxArrayString containing the data it will always update the wxProgressDialog in a fixed number of steps (like 30 updates or 20, or what so ever ) which would be calculated by the part
const size_t STEP = maxcount/RATIO;
I guess I just realized that the modulo is still a division. But I still think that updating the gauge for every line parsed is not a good idea, serious ...
That -m option : is it right that it refers to the non standard c and c++ extension of basic-blocks ?? I'm not sure, but I seem to remember that gcc does not produce any basic-block profiling information when profiling ... but I'm surly wrong there, and besides I don't know about other compilers.
Well, these were my motives. Thanks for the punch on the nose
I will think it over and try something better. What do you say of the rest of my changes ?
Regards
nausea