STL: copy vector of class ?

[sd2004]

could someone please show/help me to copy all element from "class dog"
to "class new_dog" ?
Note: "class new_dog" has new element "age" which should have value
"my_age"
/////////////////////////////// source code
///////////////////////////////
#include<iostre am>
#include <string>
#include<vector >
#include<sstrea m>
#include<fstrea m>
#include<numeri c>
using namespace std;

class dog
{
public:
string name;
int id;
int YearBorn;
string type;
};

class new_dog
{
public:
string name;
int id;
string age;
string type;
};

#define goldenretriever 11
#define Lab 33
#define Boxer 44
#define Terrier 55
int const CurrentYear =2006;

int dog_name (const string& name,const string& type ,const int age);
int main()
{
vector<dog> v;
vector<new_dog> v2;

new_dog dog_type;
dog dog_class;

ifstream in ("test5e.txt ");
string line;
while (!getline(in,li ne).eof()){
if (line.find("#") !=std::string:: npos)continue;
istringstream is(line);
if(is>>dog_clas s.name>>dog_cla ss.id>>dog_clas s.YearBorn>>dog _class.type)
{
v.push_back(dog _class);
}
}
vector<dog>::it erator search;
for (search=v.begin ();search!=v.en d();++search){
int my_age;
switch (search->id){
case goldenretriever :
my_age =dog_name(searc h->name,search->type,search->YearBorn);
//cout << "My dog is: "<<search->name<< " Age is :"<<
my_age<<endl;
break;
case Lab:
my_age=dog_name (search->name,search->type,search->YearBorn);
break;
case Boxer:
my_age=dog_name (search->name,search->type,search->YearBorn);
break;
case Terrier:
my_age=dog_name (search->name,search->type,search->YearBorn);
break;
default:
break;
} //switch

cout << "Dog name is: "<<search->name<< " ,Age is :"<<
my_age<<endl;
} // for loop

return 0;

}
int dog_name (const string& name,const string& type,int YearBorn){

return (CurrentYear-YearBorn);
}

/////////// input file "test5e.txt " //////////////////////////////

############### ############### ##########
#Name ID YearBorn Type
############### ############### ##########
Cricket 11 2000 GoldenRetriever
Nitro 11 1999 GoldenRetriever
Maxtor 33 2004 Lab
Arron 44 2001 Boxer
#Arron 44 2002 Boxer
Dora 55 2000 Terrier

[Daniel T.]

In article <dr**********@m urdoch.acc.Virg inia.EDU>,
Kai-Uwe Bux <jk********@gmx .net> wrote:

Daniel T. wrote:

Any algorithm that is used to determine the dog's age, should probably
also check for things like negative age, and probably also check to see
if the dog died before that year (and thus never reached that age.) In
other words, in a real program the algorithm would probably be much more
complicated that simply subtracting one number from another.
and:

da********@warp mail.net wrote:

The proposed function is

int dog::age_at( int 5year ) { return year - year_born; }

This is a utility function, and belongs in something like DogUtil:

struct DogUtil {
//...

static int ageAt(const Dog& dog, int year);
// Return the non-negative age of the specified 'dog' in the
// specified 'year'. Return a negative value is 'year < 0', or
// 'year' is less than the year of birth of 'dog'.
};

Will you agree with me that a dog's age is a piece of data that is
associated with the dog? If so, why is some other class providing that
data? And if not, why is it the *dog's* age?

Your proposal means to increase the number of members for the dog class
without sufficient cause. The proposed member yearOfBirth() provides all
necessary information and is a primitive, in terms of which other functions
can be defined. The proposed age() member lacks that property, in
particular if it would incorporate sanity checks like making sure the
result is non-negative.

Would you also opt for a member function

bool isOlderThan ( dog const & other );

or should that be a free standing function:

bool isOlder ( dog const & a, dog const & b ;

In this case, 'isOlder' should be a free standing function, because it
is not a property of any particular dog, but rather a comparison of two
different dogs.

Again, are you saying that a dog's age is not a property of the dog?
Of course, you could have both: a yearOfBirth() member and an age() member.
But where do you stop? Are you willing to add members to the dog class each
time some other piece of code would find those handy?

I add the member-function when there is some duplication (which tells us
that a function is a good idea) and the code is logically a property of
the class.

[Kai-Uwe Bux]

Daniel T. wrote:

In article <dr**********@m urdoch.acc.Virg inia.EDU>,
Kai-Uwe Bux <jk********@gmx .net> wrote:

Daniel T. wrote:

> Any algorithm that is used to determine the dog's age, should probably
> also check for things like negative age, and probably also check to see
> if the dog died before that year (and thus never reached that age.) In
> other words, in a real program the algorithm would probably be much
> more complicated that simply subtracting one number from another.

and:

> da********@warp mail.net wrote:
>
>> The proposed function is
>>
>> int dog::age_at( int 5year ) { return year - year_born; }
>>
>> This is a utility function, and belongs in something like DogUtil:
>>
>> struct DogUtil {
>> //...
>>
>> static int ageAt(const Dog& dog, int year);
>> // Return the non-negative age of the specified 'dog' in the
>> // specified 'year'. Return a negative value is 'year < 0',
>> or // 'year' is less than the year of birth of 'dog'.
>> };
>
> Will you agree with me that a dog's age is a piece of data that is
> associated with the dog? If so, why is some other class providing that
> data? And if not, why is it the *dog's* age?

Your proposal means to increase the number of members for the dog class
without sufficient cause. The proposed member yearOfBirth() provides all
necessary information and is a primitive, in terms of which other
functions can be defined. The proposed age() member lacks that property,
in particular if it would incorporate sanity checks like making sure the
result is non-negative.

Would you also opt for a member function

bool isOlderThan ( dog const & other );

or should that be a free standing function:

bool isOlder ( dog const & a, dog const & b ;

In this case, 'isOlder' should be a free standing function, because it
is not a property of any particular dog, but rather a comparison of two
different dogs.

Again, are you saying that a dog's age is not a property of the dog?

Well, I fail to see how you maintain that age is a property whereas isOlder
is a relation:

* isOlder is a relation between two dogs, i.e., a function that
maps ordered pairs of dogs to truth-values. A signature
representing that would read:

bool isOlder ( Dog const &, Dog const & );

* age() is a function that maps an ordered pair of a dog and a year
to a number. Here the corresponding signature reads:

int age_in_year ( Dog const &, int );

From this signature it is also clear that, if you consider age as a property
of the dog, you should also (by symmetry) consider it a property of the
year. Now, if you had a Year class, would you propose a member function:

class Year {
...

int age ( Dog const & );

};

BTW: since there is no year 0 in our calendar, a Year class is less silly
than one might think.

There really is no difference: being older than my puppy is of course a
property of dogs in the same way that being 8 years old in the year 2008 is
a property of dogs. And of course, being a year in which my puppy is 12, is
a property of years.

I cannot bring myself to take "is a property of" as a valid guideline for
class design.

Of course, you could have both: a yearOfBirth() member and an age()
member. But where do you stop? Are you willing to add members to the dog
class each time some other piece of code would find those handy?

I add the member-function when there is some duplication (which tells us
that a function is a good idea) and the code is logically a property of
the class.

Based on the demonstrated parallelism between isOlder() and age(), I would
maintain that being "logically property of the class" is not a good
guideline. Instead, I would try to go with free-standing functions as much
as possible. Within the class, I would put the bare minimum of primitives
needed to implement the free-standing functions as non-friends.

Of course, ultimately, I probably do not follow rules but gutt feelings
about what is most appropriate in a particular case. And, I guess, it is
those gutt feelings that tell me in this case, that age() should be
free-standing and the class should have a dateOfBirth() member instead.
Best

Kai-Uwe Bux

[davidrubin]

Kai-Uwe Bux wrote:

Daniel T. wrote:

Any algorithm that is used to determine the dog's age, should probably
also check for things like negative age, and probably also check to see
if the dog died before that year (and thus never reached that age.) In
other words, in a real program the algorithm would probably be much more
complicated that simply subtracting one number from another.

and:

da********@warp mail.net wrote:

The proposed function is

int dog::age_at( int 5year ) { return year - year_born; }

This is a utility function, and belongs in something like DogUtil:

struct DogUtil {
//...

static int ageAt(const Dog& dog, int year);
// Return the non-negative age of the specified 'dog' in the
// specified 'year'. Return a negative value is 'year < 0', or
// 'year' is less than the year of birth of 'dog'.
};

Will you agree with me that a dog's age is a piece of data that is
associated with the dog? If so, why is some other class providing that
data? And if not, why is it the *dog's* age?

Your proposal means to increase the number of members for the dog class
without sufficient cause. The proposed member yearOfBirth() provides all
necessary information and is a primitive, in terms of which other functions
can be defined. The proposed age() member lacks that property, in
particular if it would incorporate sanity checks like making sure the
result is non-negative.

Would you also opt for a member function

bool isOlderThan ( dog const & other );

or should that be a free standing function:

bool isOlder ( dog const & a, dog const & b ;

How would you implement it in terms of age() or in terms of yearOfBirth().
Note that there is a subtle difference between

bool isOlder( dog const & a, dog const & b ) {
return( a.yearOfBirth() < b.yearOfBirth() );
}

and

bool isOlderThan( dog const & a, dog const & b ) {
return( a.age( 0 ) > b.age( 0 ) );
}

namely that a.age(0) might throw since it is likely to yield a negative
result, at least for dogs born recently. Now, which year would you pick
instead of 0? If you have age also check whether the dog died already, you
are in even more trouble.

Of course, you could have both: a yearOfBirth() member and an age() member.
But where do you stop? Are you willing to add members to the dog class each
time some other piece of code would find those handy? Freestanding
functions can be added any time without the need to change the header
dog.h. That is, why I would opt for a primitive like yearOfBirth() instead
of an age() member function.

Just to clarify, Kai-Uwe is talking about 'int age_at(int year)', not
'const int age() const'. The names keep changing :-)

If you look at the two original class definitions, one has a 'YearBorn'
member, and the other has an 'age' member (although the type is
'string'). When your class represents a value, such as the dog classes
in this thread, good practice dictates that you have accessors an
manipulators (where appropriate) corresponding to the data members of
the class, and utilities that operate on class instances. You do not
typically add methods to the class to perform some random function,
like subtract the 'YearBorn' member from a random integer.

[Daniel T.]

In article <11************ **********@o13g 2000cwo.googleg roups.com>,
da********@warp mail.net wrote:

Just to clarify, Kai-Uwe is talking about 'int age_at(int year)', not
'const int age() const'. The names keep changing :-)
Not just the names, but the dependencies as well. 'age' has an implicit
dependency on whatever produces the current date, 'age_at' doesn't.
If you look at the two original class definitions, one has a 'YearBorn'
member, and the other has an 'age' member (although the type is
'string').
I have nothing against a 'yearBorn' member-function, by all means put it
in as well.
When your class represents a value, such as the dog classes
in this thread, good practice dictates that you have accessors an
manipulators (where appropriate) corresponding to the data members of
the class, and utilities that operate on class instances.
Where in the world did you get that from? The Dog class is a primary
abstraction of the problem space. I have no problem with the accessors
and manipulators, until you tell me they have to be removed/changed if
the member-variable is removed/changed. That breaks encapsulation in a
big way.
You do not
typically add methods to the class to perform some random function,
like subtract the 'YearBorn' member from a random integer.

The age of the dog is certainly not a "random function", it is important
to the problem space.

--
Magic depends on tradition and belief. It does not welcome observation,
nor does it profit by experiment. On the other hand, science is based
on experience; it is open to correction by observation and experiment.

[Daniel T.]

In article <dr*********@mu rdoch.acc.Virgi nia.EDU>,
Kai-Uwe Bux <jk********@gmx .net> wrote:

Again, are you saying that a dog's age is not a property of the dog?

Well, I fail to see how you maintain that age is a property whereas isOlder
is a relation:

* isOlder is a relation between two dogs, i.e., a function that
maps ordered pairs of dogs to truth-values. A signature
representing that would read:

bool isOlder ( Dog const &, Dog const & );

* age() is a function that maps an ordered pair of a dog and a year
to a number. Here the corresponding signature reads:

int age_in_year ( Dog const &, int );

From this signature it is also clear that, if you consider age as a property
of the dog, you should also (by symmetry) consider it a property of the
year. Now, if you had a Year class, would you propose a member function:

class Year {
...

int age ( Dog const & );

};

Do you really think that a dog's age is the property of the current
year? Does that make *any* sense? How often have you asked someone
which year his dog's age belongs to?

[Kai-Uwe Bux]

Daniel T. wrote:

In article <dr*********@mu rdoch.acc.Virgi nia.EDU>,
Kai-Uwe Bux <jk********@gmx .net> wrote:

> Again, are you saying that a dog's age is not a property of the dog?

Well, I fail to see how you maintain that age is a property whereas
isOlder is a relation:

* isOlder is a relation between two dogs, i.e., a function that
maps ordered pairs of dogs to truth-values. A signature
representing that would read:

bool isOlder ( Dog const &, Dog const & );

* age() is a function that maps an ordered pair of a dog and a year
to a number. Here the corresponding signature reads:

int age_in_year ( Dog const &, int );

From this signature it is also clear that, if you consider age as a
property of the dog, you should also (by symmetry) consider it a property
of the year. Now, if you had a Year class, would you propose a member
function:

class Year {
...

int age ( Dog const & );

};

Do you really think that a dog's age is the property of the current
year? Does that make *any* sense? [snip]

Well, a widely used calendar is apparently based on the assumption that the
age of Jesus Christ is a somehow significant property of a given year :-)
So, what about:

class Year {

int age_of ( Entity const & default = Static_Humans:: Jesus_Christ );

}
Best

Kai-Uwe Bux

[davidrubin]

Daniel T. wrote:

In article <11************ **********@o13g 2000cwo.googleg roups.com>,
da********@warp mail.net wrote:

Just to clarify, Kai-Uwe is talking about 'int age_at(int year)', not
'const int age() const'. The names keep changing :-)
Not just the names, but the dependencies as well. 'age' has an implicit
dependency on whatever produces the current date, 'age_at' doesn't.

'age' depends on standard library functions (e.g. 'std::time', etc).
This is a perfectly reasonable dependency. However, I am not
recommending that 'age' be in the interface of 'Dog', except that if
you wanted to return the dog's age in addition to the year of birth,
returning the current age is a much more reasonable method than one
which returns the age based on a random input: current age is a
"derived" property of 'YearBorn', and requires none of the range
checking 'age_at' does.

If you look at the two original class definitions, one has a 'YearBorn'
member, and the other has an 'age' member (although the type is
'string').

I have nothing against a 'yearBorn' member-function, by all means put it
in as well.

When your class represents a value, such as the dog classes
in this thread, good practice dictates that you have accessors an
manipulators (where appropriate) corresponding to the data members of
the class, and utilities that operate on class instances.

Where in the world did you get that from?

Lakos '96.
The Dog class is a primary
abstraction of the problem space. I have no problem with the accessors
and manipulators, until you tell me they have to be removed/changed if
the member-variable is removed/changed. That breaks encapsulation in a
big way.

You do not
typically add methods to the class to perform some random function,
like subtract the 'YearBorn' member from a random integer.

The age of the dog is certainly not a "random function", it is important
to the problem space.

There is a difference between 'age' taking no arguments, and 'age_at',
which takes a year as input. "Current age" is a property of Dog. "Age
at year X" is not; it is a function of Dog and year.

[Daniel T.]

In article <dr**********@m urdoch.acc.Virg inia.EDU>,
Kai-Uwe Bux <jk********@gmx .net> wrote:

Daniel T. wrote:

In article <dr*********@mu rdoch.acc.Virgi nia.EDU>,
Kai-Uwe Bux <jk********@gmx .net> wrote:

> Again, are you saying that a dog's age is not a property of the dog?

Well, I fail to see how you maintain that age is a property whereas
isOlder is a relation:

* isOlder is a relation between two dogs, i.e., a function that
maps ordered pairs of dogs to truth-values. A signature
representing that would read:

bool isOlder ( Dog const &, Dog const & );

* age() is a function that maps an ordered pair of a dog and a year
to a number. Here the corresponding signature reads:

int age_in_year ( Dog const &, int );

From this signature it is also clear that, if you consider age as a
property of the dog, you should also (by symmetry) consider it a property
of the year. Now, if you had a Year class, would you propose a member
function:

class Year {
...

int age ( Dog const & );

};

Do you really think that a dog's age is the property of the current
year? Does that make *any* sense? [snip]

Well, a widely used calendar is apparently based on the assumption that the
age of Jesus Christ is a somehow significant property of a given year :-)
So, what about:

class Year {

int age_of ( Entity const & default = Static_Humans:: Jesus_Christ );

}

We are talking about a program where 'dog' is a primary abstraction,
perhaps a vet's patient database, do *you* think that
"year::age_of_J esus_Christ" is an appropriate function of such a program?

[Kai-Uwe Bux]

Daniel T. wrote:

In article <dr**********@m urdoch.acc.Virg inia.EDU>,
Kai-Uwe Bux <jk********@gmx .net> wrote:

Daniel T. wrote:

> In article <dr*********@mu rdoch.acc.Virgi nia.EDU>,
> Kai-Uwe Bux <jk********@gmx .net> wrote:
>
>> > Again, are you saying that a dog's age is not a property of the dog?
>>
>> Well, I fail to see how you maintain that age is a property whereas
>> isOlder is a relation:
>>
>> * isOlder is a relation between two dogs, i.e., a function that
>> maps ordered pairs of dogs to truth-values. A signature
>> representing that would read:
>>
>> bool isOlder ( Dog const &, Dog const & );
>>
>> * age() is a function that maps an ordered pair of a dog and a year
>> to a number. Here the corresponding signature reads:
>>
>> int age_in_year ( Dog const &, int );
>>
>> From this signature it is also clear that, if you consider age as a
>> property of the dog, you should also (by symmetry) consider it a
>> property of the year. Now, if you had a Year class, would you propose
>> a member function:
>>
>> class Year {
>> ...
>>
>> int age ( Dog const & );
>>
>> };
>
> Do you really think that a dog's age is the property of the current
> year? Does that make *any* sense? [snip]

Well, a widely used calendar is apparently based on the assumption that
the age of Jesus Christ is a somehow significant property of a given year
:-) So, what about:

class Year {

int age_of ( Entity const & default = Static_Humans:: Jesus_Christ );

}

We are talking about a program where 'dog' is a primary abstraction,
perhaps a vet's patient database, do *you* think that
"year::age_of_J esus_Christ" is an appropriate function of such a program?

a) Please, lighten up. Did you, by any chance, miss the "this is a joke
flag"?

b) I just gave reasons why I would prefer a free standing function

int age_of_in_year ( Dog const & dog, int year );

to a member function

class Dog {

int age_in_year ( int year );

}

In that part of the argument where I tried to refute your reasoning, I
applied your criterion (namely the phrase "is a property of") in ways that
you did not forsee just to demonstrate why I would not consider it a good
guideline for class design. That's all.

DISCLAIMER: That counter-argument, of course, does not apply to any other
reasons that you may or may not have to prefer a member function to a free
standing function in this particular case.

However, the way you iterate the question

"Again, are you saying that a dog's age is not a property of the dog?"

indicates that this seems to be a very important point to you. In direct
response: I agree that age is a property of the dog; but that is completely
inconsequential for whether it should be a member function or a free
standing function.
Best

Kai-Uwe