469,623 Members | 1,545 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,623 developers. It's quick & easy.

Clearing static std::vector fails

I'm having trouble clearing and resizing a static std::vector of
std::vectors (segmentation fault). Is it OK to call clear() and resize()
on a static attribute? My code is similar to the one posted below. The
code below works, though. My original code crashes on the second call to
X::f().

My question is: is this code valid, or is it just a coincidence that it
doesn't crash?

#include <iostream>
#include <vector>
using namespace std;

class X
{
private:
static vector< vector< int > > v;
public:
void f( unsigned x, unsigned y )
{
v.clear();
v.resize( x );
for (unsigned Y = 0; Y < x; ++Y)
v[Y].resize( y );
for (unsigned X = 0; X < x; ++X)
for (unsigned Y = 0; Y < y; ++Y)
v[X][Y] = 10*X + Y;
}

};

vector< vector< int > > X::v;

int main( )
{
X x;
x.f(10,10);
x.f(5,5);
x.f(15, 15);
return 0;
}
Jul 22 '05 #1
7 3358
Martin Magnusson wrote:
I'm having trouble clearing and resizing a static std::vector of
std::vectors (segmentation fault). Is it OK to call clear() and resize()
on a static attribute? My code is similar to the one posted below. The
code below works, though. My original code crashes on the second call to
X::f().
What's the damn point of posting working code when yours has a problem?
My question is: is this code valid, or is it just a coincidence that it
doesn't crash?
The class you store in the vectors (compared to the 'int' in the code
below) probably has some dynamic memory management ('new' in the c-tor
and 'delete' in the d-tor) which is screwed up (like not following the
"Rule of Three"). Without seeing the actual code it is impossible to
really help.
#include <iostream>
#include <vector>
using namespace std;

class X
{
private:
static vector< vector< int > > v;
public:
void f( unsigned x, unsigned y )
{
v.clear();
v.resize( x );
for (unsigned Y = 0; Y < x; ++Y)
v[Y].resize( y );
for (unsigned X = 0; X < x; ++X)
for (unsigned Y = 0; Y < y; ++Y)
v[X][Y] = 10*X + Y;
}

};

vector< vector< int > > X::v;

int main( )
{
X x;
x.f(10,10);
x.f(5,5);
x.f(15, 15);
return 0;
}


The code is valid. It doesn't make much sense to me that a non-static
member function of a class changes a static data member, but I guess
your particular design calls for it.

V
Jul 22 '05 #2
"Martin Magnusson" <martin@-xx-blecket-xx-.org> wrote in message
news:1102500815.13d5048dd8f2463266d8ef7e81655654@t eranews...
I'm having trouble clearing and resizing a static std::vector of
std::vectors (segmentation fault). Is it OK to call clear() and resize()
on a static attribute? My code is similar to the one posted below. The
code below works, though. My original code crashes on the second call to
X::f().

My question is: is this code valid, or is it just a coincidence that it
doesn't crash?

#include <iostream>
#include <vector>
using namespace std;

class X
{
private:
static vector< vector< int > > v;
public:
void f( unsigned x, unsigned y )
{
v.clear();
v.resize( x );
for (unsigned Y = 0; Y < x; ++Y)
v[Y].resize( y );
for (unsigned X = 0; X < x; ++X)
for (unsigned Y = 0; Y < y; ++Y)
v[X][Y] = 10*X + Y;
}

};

vector< vector< int > > X::v;

int main( )
{
X x;
x.f(10,10);
x.f(5,5);
x.f(15, 15);
return 0;
}


Calling clear() and resize() on a vector that happens to be a static member
is no different than calling it on some other vector.

I haven't explicitly tried, but I'm pretty sure the code you posted won't
compile. Is X a class name or a index variable in your for loops? Based on
this example, it's hard to know for sure what you intend your code to do.

-Matt
Jul 22 '05 #3
Matt Wharton wrote:
[...]
I haven't explicitly tried, but I'm pretty sure the code you posted won't
compile. Is X a class name or a index variable in your for loops? Based on
this example, it's hard to know for sure what you intend your code to do.


You should explicitly try before expressing such assuredness. The code
compiles just fine. The variable X and type X do not interfere with each
other. This:

class A {};
int main() {
A a;
int A;
}

is a perfectly valid C++ program.

V
Jul 22 '05 #4
"Victor Bazarov" <v.********@comAcast.net> wrote in message
news:2Y*****************@newsread1.dllstx09.us.to. verio.net...
Matt Wharton wrote:
[...]
I haven't explicitly tried, but I'm pretty sure the code you posted won't
compile. Is X a class name or a index variable in your for loops? Based
on this example, it's hard to know for sure what you intend your code to
do.


You should explicitly try before expressing such assuredness. The code
compiles just fine. The variable X and type X do not interfere with each
other. This:

class A {};
int main() {
A a;
int A;
}

is a perfectly valid C++ program.


Ok, you got me--fair enough :). I'll still contend however that, even
though this is technically a "valid C++ program", this kind of a coding
practice (using a type name as a variable name) doesn't make for readable
code and it doesn't provide any tangible benefit (that I can see). If I
were on the standards committee, I would have voted against this, but what
do I know? :p

-M
Jul 22 '05 #5
Victor Bazarov <v.********@comAcast.net> writes:
You should explicitly try before expressing such assuredness. The code
compiles just fine. The variable X and type X do not interfere with each
other. This:

class A {};
int main() {
A a;
int A;
}

is a perfectly valid C++ program.


I see that this is true, but could you explain why the following
is not valid C++:

----
struct foo {};

struct bar {
foo foo;
};

int main()
{
bar bar;
foo foo;
}
----

Rename or remove the foo member from bar and the compiler is
happy, otherwise I get (using g++ 3.2):

t.cc:4: declaration of `foo bar::foo'
t.cc:1: changes meaning of `foo' from `struct foo'

....which I don't quite understand.

Josh
Jul 22 '05 #6
Josh wrote:
Victor Bazarov <v.********@comAcast.net> writes:

You should explicitly try before expressing such assuredness. The code
compiles just fine. The variable X and type X do not interfere with each
other. This:

class A {};
int main() {
A a;
int A;
}

is a perfectly valid C++ program.

I see that this is true, but could you explain why the following
is not valid C++:

----
struct foo {};

struct bar {
foo foo;
};

int main()
{
bar bar;
foo foo;
}
----

Rename or remove the foo member from bar and the compiler is
happy, otherwise I get (using g++ 3.2):

t.cc:4: declaration of `foo bar::foo'
t.cc:1: changes meaning of `foo' from `struct foo'


Is that a warning or an error message?
...which I don't quite understand.


If it is in fact an error message, the only explanation to that is that
g++ 3.2 has a bug in that area. The code is valid.

If it is in fact a warning, what do you not understand? It warns you that
inside the class 'bar' the use of 'foo' after that declaration is
different than before that declaration or outside the class. So, if you
later write something that uses 'foo' you will get bar's member instead of
the global type-id.

V
Jul 22 '05 #7
Victor Bazarov <v.********@comAcast.net> writes:
Josh wrote:

I see that this is true, but could you explain why the
following is not valid C++:

----
struct foo {};
struct bar {
foo foo;
};
int main()
{
bar bar;
foo foo;
}
----
Rename or remove the foo member from bar and the compiler is
happy, otherwise I get (using g++ 3.2):
t.cc:4: declaration of `foo bar::foo'
t.cc:1: changes meaning of `foo' from `struct foo'


Is that a warning or an error message?


An error message. Interesting, the only difference in output
between g++ 3.2 and 3.4 is the addition of "error: ":

t.cc:4: error: declaration of `foo bar::foo'
t.cc:1: error: changes meaning of `foo' from `struct foo'
...which I don't quite understand.


If it is in fact an error message, the only explanation to that
is that g++ 3.2 has a bug in that area. The code is valid.

If it is in fact a warning, what do you not understand? It
warns you that inside the class 'bar' the use of 'foo' after
that declaration is different than before that declaration or
outside the class. So, if you later write something that uses
'foo' you will get bar's member instead of the global type-id.


Ah, okay. The error text makes sense now. What I don't
understand is why the complier can clearly distinguish the two
inside the scope of main, but not inside the class definition.

The reason I'm bringing this up is that we ran into this issue at
work when a header including a similar structure definition was
included into a c++ source file. Previously, it had only been
built with gcc which does not seem to have a problem with the
syntax.

Josh
Jul 22 '05 #8

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

5 posts views Thread by canned.net | last post: by
8 posts views Thread by Ross A. Finlayson | last post: by
6 posts views Thread by zl2k | last post: by
6 posts views Thread by Jia | last post: by
2 posts views Thread by Rockair | last post: by
23 posts views Thread by Mike -- Email Ignored | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.