Is this code correct?

[Christopher Benson-Manica]

#include <map>
#include <vector>
#include <iostream>

using namespace std;

class test
{
public:
unsigned int data;
vector<unsigned int> *v;
test() {data=0; v=new vector<unsigned int>();}
~test() {delete v;}
};

int main(void)
{
map< unsigned int, test > m;

cout << "I hate my implementation! \n";
m[0].data=3;
m[1].data=4;
cout << m[0].data << endl;
return 0;
}

This code hangs after printing the first line when compiled with
Borland 4. It works like a charm when compiled with g++ 3.3.1. Am I
doing something wrong here that invokes undefined behavior, or is
Borland 4 displaying its utter crappiness yet again? If it's the
implementation, can any one suggest a way to work around this?

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cybers pace.org | don't, I need to know. Flames welcome.

[Alf P. Steinbach]

Re: Is this code correct?

* Christopher Benson-Manica <ataru@nospam.c yberspace.org> schriebt:[color=blue]
> #include <map>
> #include <vector>
> #include <iostream>
>
> using namespace std;
>
> class test
> {
> public:
> unsigned int data;
> vector<unsigned int> *v;
> test() {data=0; v=new vector<unsigned int>();}
> ~test() {delete v;}
> };[/color]


Main _technical_ problem with above class is that it doesn't define
copy operations. So a pointer is copied. And hence multiply deleted by the
destructor, which is Undefined Behavior (crash, hang, e-mail to Bush).

You can see that by inserting


private:
test( test const& );
test& operator=( test const& );


at the top and compiling.

To fix it define these operations yourself, or let v simply be a vector
instead of a pointer to a vector.

There are other problems relating to the lack of design, but ask about that
separately.

[color=blue]
> int main(void)[/color]

void is a C'ism.

[color=blue]
> {
> map< unsigned int, test > m;
>
> cout << "I hate my implementation! \n";[/color]

You have Undefined Behavior; the C++ implementation is not to blame.

[color=blue]
> m[0].data=3;
> m[1].data=4;
> cout << m[0].data << endl;
> return 0;
> }[/color]

--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Karl Heinz Buchegger]

Re: Is this code correct?

Christopher Benson-Manica wrote:[color=blue]
>
> #include <map>
> #include <vector>
> #include <iostream>
>
> using namespace std;
>
> class test
> {
> public:
> unsigned int data;
> vector<unsigned int> *v;
> test() {data=0; v=new vector<unsigned int>();}
> ~test() {delete v;}
> };[/color]

To answer your question:
No it is not correct.
This class lacks a correct copy constructor and assignment operator.
[color=blue]
> This code hangs after printing the first line when compiled with
> Borland 4. It works like a charm when compiled with g++ 3.3.1. Am I
> doing something wrong here that invokes undefined behavior, or is
> Borland 4 displaying its utter crappiness yet again? If it's the
> implementation, can any one suggest a way to work around this?[/color]

2 possibilities:

* Why is v a pointer to a vector?
As far as I can see, there is no need for it to be so. So drop
the pointer and make it a plain vanilla vector

class test
{
public:
unsigned int data;
vector<unsigned int> v;
test() {data=0}
};

and everything should be fine

* implement a copy constructor and assignment operator


--
Karl Heinz Buchegger
kbuchegg@gascad .at

[Christopher Benson-Manica]

Re: Is this code correct?

Alf P. Steinbach <alfps@start.no > spoke thus:
[color=blue]
> Main _technical_ problem with above class is that it doesn't define
> copy operations. So a pointer is copied. And hence multiply deleted by the
> destructor, which is Undefined Behavior (crash, hang, e-mail to Bush).[/color]

I figured it was me...
[color=blue]
> You have Undefined Behavior; the C++ implementation is not to blame.[/color]

....which is why I asked. Lord knows it *has* been the implementation
plenty of times. Thanks.
[color=blue]
> void is a C'ism.[/color]

Sorry.
[color=blue]
> There are other problems relating to the lack of design, but ask about that
> separately.[/color]

Well, considering it was just a minimum compilable example, I'm not
sure how it could demonstrate design at all, but I'm listening all the
same.

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cybers pace.org | don't, I need to know. Flames welcome.