STL question - why does this code crash?

#include <vector>
#include <set>

using namespace std;
class c
{
public:
c() {};
virtual ~c() {};
};

class h : public vector<c>
{
public:
h();
virtual ~h() {};
};

int _tmain(int argc, _TCHAR* argv[])
{
set<h> myset;

return 0;
}



it crashes when trying to construct the set, citing 'Stack around the
variable _Hk was corrupted' on line 456 of xtree.

Any idea what's wrong?

Ben
Wed Feb 28 10:49:15 CST 2007

oh... it also crashes in exactly the same way if I just do:

int _tmain(int argc, _TCHAR* argv[])
{
set<int> myset; //crashes here
return 0;
}


must be something simple I'm missing...I'm using VC++ express 2005 (and it's
an unmanaged project.).


"Ben" wrote:

> #include <vector>
> #include <set>
>
> using namespace std;
> class c
> {
> public:
> c() {};
> virtual ~c() {};
> };
>
> class h : public vector<c>
> {
> public:
> h();
> virtual ~h() {};
> };
>
> int _tmain(int argc, _TCHAR* argv[])
> {
> set<h> myset;
>
> return 0;
> }
>
>
>
> it crashes when trying to construct the set, citing 'Stack around the
> variable _Hk was corrupted' on line 456 of xtree.
>
> Any idea what's wrong?
>

Alex
Wed Feb 28 10:58:41 CST 2007

"Ben" wrote:
> oh... it also crashes in exactly the same way if I just
> do:
>
> int _tmain(int argc, _TCHAR* argv[])
> {
> set<int> myset; //crashes here
> return 0;
> }
>
>
> must be something simple I'm missing...I'm using VC++
> express 2005 (and it's
> an unmanaged project.).


The problem should be elsewhere. It's quite innocent code.
It doesn't crash with my VC++2005 SP1.

Alex

Ben
Wed Feb 28 11:06:20 CST 2007


i thought so, but that's all the code i've got...

"Alex Blekhman" wrote:

> "Ben" wrote:
> > oh... it also crashes in exactly the same way if I just
> > do:
> >
> > int _tmain(int argc, _TCHAR* argv[])
> > {
> > set<int> myset; //crashes here
> > return 0;
> > }
> >
> >
> > must be something simple I'm missing...I'm using VC++
> > express 2005 (and it's
> > an unmanaged project.).
>
>
> The problem should be elsewhere. It's quite innocent code.
> It doesn't crash with my VC++2005 SP1.
>
> Alex
>
>
>

Alex
Wed Feb 28 11:52:47 CST 2007

"Ben" wrote:
>
> i thought so, but that's all the code i've got...


Create new project and then add the code to it step by step.
You'll see where it starts to be broken.

Alex

Larry
Wed Feb 28 13:29:18 CST 2007

> #include <vector>
> #include <set>
>
> using namespace std;
> class c
> {
> public:
> c() {};
> virtual ~c() {};
> };
>
> class h : public vector<c>
> {
> public:
> h();
> virtual ~h() {};
> };
>
> int _tmain(int argc, _TCHAR* argv[])
> {
> set<h> myset;
>
> return 0;
> }
>
>
>
> it crashes when trying to construct the set, citing 'Stack around the
> variable _Hk was corrupted' on line 456 of xtree.
>
> Any idea what's wrong?

Nothing wrong with it that I can see and Alex has confirmed it. In any case,
you shouldn't be publicly inheriting from "vector" anyway. As has (probably)
been pointed out many times, it has no virtual destructor and it's not
generally intended for derivation anyway (though I personally disagree with
this philosophy). Note that most classes in the standard library have the
same issue.

Ben
Thu Mar 01 03:47:10 CST 2007

That's exactly what I did do, hence the difference between the OP and mmy
first reply to it.


"Alex Blekhman" wrote:

> "Ben" wrote:
> >
> > i thought so, but that's all the code i've got...
>
>
> Create new project and then add the code to it step by step.
> You'll see where it starts to be broken.
>
> Alex
>
>
>

Ben
Thu Mar 01 08:55:08 CST 2007

it's something to do with the way it's compiling it.
It works fine if I copy the exact same command line
cl /Od /D "WIN32" /D "_DEBUG" /D "_CONSOLE" /D "_UNICODE" /D "UNICODE" /Gm
/EHsc /RTC1 /MDd /Fo"Debug\\" /Fd"Debug\vc80.pdb" /W3 /c /Wp64 /ZI /TP
".\settest.cpp"
from the buildlog.htm and paste it into a command window and compile it from
the command line, then it works fine (regardless of whether I let VC++ link
it or whether it's linked from the command line).
The compiler version is the same in each case, "Microsoft (R) 32-bit C/C++
Optimizing Compiler Version 14.00.50727.42 for 80x86".

any thoughts in the light of this?


"Larry Smith" wrote:

> > #include <vector>
> > #include <set>
> >
> > using namespace std;
> > class c
> > {
> > public:
> > c() {};
> > virtual ~c() {};
> > };
> >
> > class h : public vector<c>
> > {
> > public:
> > h();
> > virtual ~h() {};
> > };
> >
> > int _tmain(int argc, _TCHAR* argv[])
> > {
> > set<h> myset;
> >
> > return 0;
> > }
> >
> >
> >
> > it crashes when trying to construct the set, citing 'Stack around the
> > variable _Hk was corrupted' on line 456 of xtree.
> >
> > Any idea what's wrong?
>
> Nothing wrong with it that I can see and Alex has confirmed it. In any case,
> you shouldn't be publicly inheriting from "vector" anyway. As has (probably)
> been pointed out many times, it has no virtual destructor and it's not
> generally intended for derivation anyway (though I personally disagree with
> this philosophy). Note that most classes in the standard library have the
> same issue.
>
>
>

Ben
Thu Mar 01 08:56:43 CST 2007

oh and by the way it's not a debugger issue as if I let VC++ compile and link
it, but then run the resulting executable from the command line, then it
still asserts.


"Larry Smith" wrote:

> > #include <vector>
> > #include <set>
> >
> > using namespace std;
> > class c
> > {
> > public:
> > c() {};
> > virtual ~c() {};
> > };
> >
> > class h : public vector<c>
> > {
> > public:
> > h();
> > virtual ~h() {};
> > };
> >
> > int _tmain(int argc, _TCHAR* argv[])
> > {
> > set<h> myset;
> >
> > return 0;
> > }
> >
> >
> >
> > it crashes when trying to construct the set, citing 'Stack around the
> > variable _Hk was corrupted' on line 456 of xtree.
> >
> > Any idea what's wrong?
>
> Nothing wrong with it that I can see and Alex has confirmed it. In any case,
> you shouldn't be publicly inheriting from "vector" anyway. As has (probably)
> been pointed out many times, it has no virtual destructor and it's not
> generally intended for derivation anyway (though I personally disagree with
> this philosophy). Note that most classes in the standard library have the
> same issue.
>
>
>

Ben
Thu Mar 01 09:03:40 CST 2007

in addition, when i compile it from the command line, the resulting
settest.obj file is 109,160 bytes long, whereas from VC++, it's 52,276 bytes
long - i.e. much smaller from within the IDE.
could any of you who have got the same compiler be so kind as to compile the
following with the same switches as I've put below and tell me how big the
obj file is? different from within the IDE as in the command line?
the exact code for settest.cpp is

#include <tchar.h>
#include <set>

using namespace std;
int _tmain(int argc, _TCHAR* argv[])
{
set<int> s;

return 0;
}






"Ben" wrote:

> it's something to do with the way it's compiling it.
> It works fine if I copy the exact same command line
> cl /Od /D "WIN32" /D "_DEBUG" /D "_CONSOLE" /D "_UNICODE" /D "UNICODE" /Gm
> /EHsc /RTC1 /MDd /Fo"Debug\\" /Fd"Debug\vc80.pdb" /W3 /c /Wp64 /ZI /TP
> ".\settest.cpp"
> from the buildlog.htm and paste it into a command window and compile it from
> the command line, then it works fine (regardless of whether I let VC++ link
> it or whether it's linked from the command line).
> The compiler version is the same in each case, "Microsoft (R) 32-bit C/C++
> Optimizing Compiler Version 14.00.50727.42 for 80x86".
>
> any thoughts in the light of this?
>
>
> "Larry Smith" wrote:
>
> > > #include <vector>
> > > #include <set>
> > >
> > > using namespace std;
> > > class c
> > > {
> > > public:
> > > c() {};
> > > virtual ~c() {};
> > > };
> > >
> > > class h : public vector<c>
> > > {
> > > public:
> > > h();
> > > virtual ~h() {};
> > > };
> > >
> > > int _tmain(int argc, _TCHAR* argv[])
> > > {
> > > set<h> myset;
> > >
> > > return 0;
> > > }
> > >
> > >
> > >
> > > it crashes when trying to construct the set, citing 'Stack around the
> > > variable _Hk was corrupted' on line 456 of xtree.
> > >
> > > Any idea what's wrong?
> >
> > Nothing wrong with it that I can see and Alex has confirmed it. In any case,
> > you shouldn't be publicly inheriting from "vector" anyway. As has (probably)
> > been pointed out many times, it has no virtual destructor and it's not
> > generally intended for derivation anyway (though I personally disagree with
> > this philosophy). Note that most classes in the standard library have the
> > same issue.
> >
> >
> >

Alex
Thu Mar 01 09:31:40 CST 2007

"Ben" wrote:
> it's something to do with the way it's compiling it.
> It works fine if I copy the exact same command line
> cl /Od /D "WIN32" /D "_DEBUG" /D "_CONSOLE" /D "_UNICODE"
> /D "UNICODE" /Gm
> /EHsc /RTC1 /MDd /Fo"Debug\\" /Fd"Debug\vc80.pdb" /W3 /c
> /Wp64 /ZI /TP
> ".\settest.cpp"
> from the buildlog.htm and paste it into a command window
> and compile it from
> the command line, then it works fine (regardless of
> whether I let VC++ link
> it or whether it's linked from the command line).
> The compiler version is the same in each case, "Microsoft
> (R) 32-bit C/C++
> Optimizing Compiler Version 14.00.50727.42 for 80x86".
>
> any thoughts in the light of this?


It seems that something in IDE settings went wrong. Check
that directories are set correctly. There are chances that
you build the project with wrong SDK and/or CRT. In settings
go to "Projects and Solutions" -> "VC++ Directories". Also,
from Visual Studio Command Prompt run `set' command. Ensure
that VC environment variables are set properly.

HTH
Alex

Ben
Thu Mar 01 10:02:08 CST 2007

Yes, that's solved it, thanks.
When I installed it I followed the instructions in 'Using VC++ express 2005
with the Platform SDK" and some of the include files must be duplicated in
the IDE and the SDK, and the IDE needs to use its own rather than the SDK's.
I moved the SDK include directories to below the IDE's own ones and it
worked fine.

Just out of interest though, isn't there a switch to make it verbosely print
the paths of the include files it's using as it compiles... I can't seem to
find it, do you know where that switch is / what its command line is?

"Alex Blekhman" wrote:

> "Ben" wrote:
> > it's something to do with the way it's compiling it.
> > It works fine if I copy the exact same command line
> > cl /Od /D "WIN32" /D "_DEBUG" /D "_CONSOLE" /D "_UNICODE"
> > /D "UNICODE" /Gm
> > /EHsc /RTC1 /MDd /Fo"Debug\\" /Fd"Debug\vc80.pdb" /W3 /c
> > /Wp64 /ZI /TP
> > ".\settest.cpp"
> > from the buildlog.htm and paste it into a command window
> > and compile it from
> > the command line, then it works fine (regardless of
> > whether I let VC++ link
> > it or whether it's linked from the command line).
> > The compiler version is the same in each case, "Microsoft
> > (R) 32-bit C/C++
> > Optimizing Compiler Version 14.00.50727.42 for 80x86".
> >
> > any thoughts in the light of this?
>
>
> It seems that something in IDE settings went wrong. Check
> that directories are set correctly. There are chances that
> you build the project with wrong SDK and/or CRT. In settings
> go to "Projects and Solutions" -> "VC++ Directories". Also,
> from Visual Studio Command Prompt run `set' command. Ensure
> that VC environment variables are set properly.
>
> HTH
> Alex
>
>
>

Alex
Thu Mar 01 10:49:08 CST 2007

"Ben" wrote:
> Yes, that's solved it, thanks.
> When I installed it I followed the instructions in 'Using
> VC++ express 2005
> with the Platform SDK" and some of the include files must
> be duplicated in
> the IDE and the SDK, and the IDE needs to use its own
> rather than the SDK's.
> I moved the SDK include directories to below the IDE's own
> ones and it
> worked fine.

Actually, there is nothing wrong in using SDK's files before
Visual Studio files. As long as SDK's files are used
consistently for all categories (Include Files, Lib Files
etc.) there shouldn't be any problem. I think that in your
case headers were taken from one SDK while lib files from
another. When you upgrade Platform SDK, then usually you put
its folders before original ones supplied with Visual
Studio.

> Just out of interest though, isn't there a switch to make
> it verbosely print
> the paths of the include files it's using as it
> compiles... I can't seem to
> find it, do you know where that switch is / what its
> command line is?

I'm not aware of such switch. The best you can get is
preprocessor output dump (look for /E, /P, or /EP option).

Alex

Arnaud
Thu Mar 01 14:14:38 CST 2007


"Ben" <Ben@discussions.microsoft.com> a écrit dans le message de news:
A04A71C4-1121-4D75-B04C-07A574BDDEBC@microsoft.com...

>
> Just out of interest though, isn't there a switch to make it verbosely
> print
> the paths of the include files it's using as it compiles... I can't seem
> to
> find it, do you know where that switch is / what its command line is?

/showIncludes

Arnaud
MVP - VC

Alex
Thu Mar 01 16:59:14 CST 2007

"Arnaud Debaene" wrote:
>> Just out of interest though, isn't there a switch to make
>> it verbosely print
>> the paths of the include files it's using as it
>> compiles... I can't seem to
>> find it, do you know where that switch is / what its
>> command line is?
>
> /showIncludes


I knew there must be something like that! Can't believe I
missed it. Thanks.