| re: vector of stringstream*
mlm wrote:[color=blue]
> I believe that it should not be legal to create a vector (and array)
> of stringstream since the copy constructor and assignment operators
> are declared private. However, I don't understand why it shouldn't be
> legal to create a vector (or array) or stringstream pointers. The
> following code compiles and runs on g++, but seg faults while using
> the Intel c++ compiler. Is this standard code?[/color]
Yes, it's fine.
[color=blue]
> Which newsgroup
> (intel or g++) needs to be consulted?[/color]
I don't know of Intel newsgroup, but I'd contact their tech support.
[color=blue]
> ================================================== ===========
> g++ -v
> Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.2/specs
> Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
> --infodir=/usr/share/info --enable-shared --enable-threads=posix
> --disable-checking --with-system-zlib --enable-__cxa_atexit
> --disable-libunwind-exceptions --enable-java-awt=gtk
> --host=i386-redhat-linux
> Thread model: posix
> gcc version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)
> ================================================== ============
>
> Intel C++ compiler version 8.1
> ================================================== ============
>
> #include <vector>
> #include <sstream>
> #include <iostream>
>
> using namespace std;
>
> int main()
> {
> int test1 = 100;
> int test2 = 200;
>
> vector<stringstream*> ssv;
>
> for(int i=0; i<10; i++)
> ssv.push_back(new stringstream);
>
> cout << "test1: " << test1 << endl;
> cout << "test2: " << test2 << endl;
>
> for(int i=0; i<10; i++) {
> *ssv[i] << "testing 1 2 3" << endl;
> }
>
> cout << "test1: " << test1 << endl;
> cout << "test2: " << test2 << endl;
>
> for(int i=0; i<10; i++) {
> cout << ssv[i]->str() << endl;
> cout << "test1: " << test1 << endl;
> cout << "test2: " << test2 << endl;
> }
>
> return 0;
> }
>
> [ btw - while debugging this problem I noticed that local variables
> declared at the top of method are being overwritten. If you use the
> Intel compiler, you'll start to see that test1 and test2 will contain
> garabage after a few iterations through the last for loop.[/color]
"After a few"? What does that mean? Are you saying it's arbitrary and
changes from one run to another? Pin-point the moment, then look where
it happens. Step into the library code if you can (should be able to).
[color=blue]
> And this
> is another question - why would anything that is happening in the
> last for loop cause _anything_ to be overwritten? ][/color]
The code is fine. What you need to try is a different implemenation
of the Standard library than the one you already have (with Intel C++).
I just tried your code on Visual C++ v8 and it was fine.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
| 
