Perhaps you should check that the forward declaration of your read_files function matches the definition. If you can find no problem with that then post the smallest and simplest program that demonstrates this error.
By the way, you might as well make the fname parameter a const std::string&.
C + C++ Compiler: MinGW port of GCC
Build + Version Control System: SCons + Bazaar
as an aside, I erase that matrix when I have finished with it, and it is taking a real long time ... 600 seconds !
Did you time a fully optimized build (without iterator checking)?
What are the characteristics of your data? How many rows and columns, what type of strings are stored?
Cheers, D Drmmr
Please put [code][/code] tags around your code to preserve indentation and make it more readable.
As long as man ascribes to himself what is merely a posibility, he will not work for the attainment of it. - P. D. Ouspensky
Maestro, thanks, the forward reference was the culprit there!
as an aside, I erase that matrix when I have finished with it, and it is taking a real long time ... 600 seconds !
Unless your compiler implementation of std::string and std::vector is a bunch of crap, in no way should it take 600 seconds if you run an optimized build. Note the bold text.
If you're running an unoptimized, "debug" build, then you cannot use that as an indication of how fast or slow the erase will perform.
Also, exactly what compiler and version are you using?
is there a way to spped this erase operation?
There is nothing to do except to make sure you're running an optimized build. Again, no decent C++ compiler would have such a slow implementation, unless you're running an iterator-checked, unoptimized build, and not an optimized build.
The number of rows is slightly over 1million = 1,118,135 rows
The number of columns is 5
The release non-debug optimised build does see a significant performance improvement ie 13 seconds for my code , ..., and 225 seconds for the erase() of that matrix.
I wrote this code for a performance improvement to some open source software, and the debug version was marginal, but the release version is excellent; except for this nasty sting in the tail ... 225 seconds to erase that matrix is still too unpleasant.
I have tried looking at making the strings fixed size; in the hope that would have an improved performance, but have found no ideas there, the syntax of C strings of a pointer to the first element of an array almost ignores the possibility of a fixed string usage?
The number of rows is slightly over 1million = 1,118,135 rows
The number of columns is 5
The release non-debug optimised build does see a significant performance improvement ie 13 seconds for my code , ..., and 225 seconds for the erase() of that matrix.
Well, erase() can't do magic. If you have that many rows, then what routine(s) do you think exist that can make the deallocation any faster?
You're accessing the heap, and any massive amount of allocation would cause this issue, STL or no STL. You are eventually allocating 5 * sizeof(std::string) for each row. Multiply that by sizeof(std::vector<std::string>) * 1,118,135.
So the total number of bytes allocated just to maintain this data is very large and that is only for the matrix alone, without even allocating the data needed for the vector or string's contents. When the vector is destroyed, you have to deallocate the memory used by over 5 million strings. Now do you think anything you can think of can make those deallocations fast?
Simply stated, you need to rethink your design if you have this many strings.
Bookmarks