Problems defining classes

Hello everyone!

I'm trying to do a program where you are supposed to simulate an automobile registry which stocks vehicles information(license number,model,brand,etc.) and their respective owners' information(name,address,id,etc.).
In the automobile registry I'll have the possiblities to insert vehicles and owners,erase,modify and search for vehicles and owners
I did a class for vehicles and their information and another class for owners and their information,but I'm not quite sure If I should make another class for the automobile registry or if that registry will only be the main interface with the options referred above.
Below are the classes(feel free to add comments or suggest modifications!):

Code:

---

class owners
{
private:

  string name;
  string address;
  long id;
  long phone;
  vehicles v;

public:

  owners(string o_name,string o_address, long o_id,long o_phone);//constructor
  void getname (void) const;
  string setname(string o_name);
  //etc,other gets and sets
}

class vehicles
 {
private:

  string model;
  string brand;
  string license;
  long nr_oldowners;
  owners o;

public:

  vehicles(string v_model,string v_brand,string v_license,long v_nr_oldowners)
  void getlicense (void) const;
  string setlicensestring o_name);
  o.setname(string o_name);
  //etc,other gets and sets
}

---

Does this make any sense at all?Any help appreciated!Thanks in advance!

Your question is not very clear. Does the code work fine for you?

Yeah, I'm not really following either, but you do need ;'s after your closing }'s

I think another class for the registry makes sense.

In your current code, an owners has vehicles and a vehicles has owners. The classes should be owner and vehicle singular, not plural. Each should represent a single owner or vehicle. Also, you shouldn't have each contain the other. This won't work as you have it anyway. If you want, you can have each contain references to the other, or you can just have your automobile registry class manage that.

DaveD makes a very good point. You can NOT have class A contain class B where class B contains class A - it would be infinitely large for one thing.

The second thing is that you can certainly have one person own more than one vehicle - so you need to take this into account [at least, you do if you want this to work in a REAL situation - if you're just doing this as a school excercise you may want to clarify if the requirements assume that there is at most one vehicle per owner].

There are several ways to do this. One of the simpler is to use a linked list of vehicles pointed to by the owner. You probably also want a pointer (or some other type of reference) to the owner for the vehicle, so that you can easily do a lookup of the owner from a registration number or other vehicle ID).

I take it this isn't supposed to be very realistic: In real life, vehicles are identified by a VIN (Vehicle Identification Number). This NEVER changes - but people can change registration number (in many countries at least).

In the real world, the previous owner is also kept on register (at least in England).

--
Mats

I've made the automobile registry class with their atributes and functions but I have a few questions...Why can't class a have class b and vice versa?If we were to make another class for the owner's birthday couldn't we include it on the owner's class since there's an association with both?
Also,I'm a bit confused,if the automobile registry manages both vehicles and cars(inserts,erases,updates,etc.) is there a need for a constructor on both vehicles and owners,since there are already constructors on autoreg that receive the owners' and vehicles' properties?
And answering someone who has asked,yes,a owner can have multiple vehicles but a vehicle has one owner only,but could have had before multiple owners.
Any help is appreciated and thakns for the help!

Code:

---

class owner
{
private:

  string name;
  string address;
  long id;
  long phone;

public:

  owner(string o_name,string o_address, long o_id,long o_phone);//constructor
  void getname (void) const;
  string setname(string o_name);
  //etc,other gets and sets
}

class vehicle
 {
private:

  string model;
  string brand;
  string license;
  long nr_oldowners;

public:

  vehicle(string v_model,string v_brand,string v_license,long v_nr_oldowner)
  void getlicense (void) const;
  string setlicensestring o_name);
  //etc,other gets and sets
}

class autoreg
{

private:

  vehicle v;
  owner o;

public:

    insert_v(string v_model,string v_brand,string v_license,long v_nr_oldowner);//is this okay??

    insert_o(string v_model,string v_brand,string v_license,long_nr_oldowner,string o_name,string o_address, long o_id,long o_phone););//is this okay??

    erase_o(string o_name,string o_address, long o_id,long o_phone););//is this okay??

    erase_v(string v_model,string v_brand,string v_license,long v_nr_oldowner););//is this okay??

    update(string v_model,string v_brand,string v_license,long_nr_oldowner,string o_name,string o_address, long o_id,long o_phone););//is this okay??
 
}

---

I don't think that's how I would do the class design.

Assuming we have two vehicles owned by the same person, that SHOULD be THE SAME OBJECT - not two independent copies [say you change the address for example, you don't want to have to change the address twice, do you?]

Let's explain why class A can't have class B inside it when you have class A in class B. If we write it out, you'll see:

Code:

---

class A {
  class B {
      ...
      class A {
        class B {
          ...
          class A {
            class B  {
            ...
              class A  ...
              // This continues forever and ever.
            }
        }
      }
    }
  }
};

---

Essentially, that is an infinite recursion problem, and it can not be solved with a finite number of recursions or iterations - the structure itself would take an infinite amount of memory.

What you can do is have mutual pointers:

Code:

---

class B;  // We need to tell the compiler that THERE IS a class B.
class A {
  ...
  B *b;
};

class B {
  ...
  A *a;
};

---

Since the compiler doesn't have to infinitely recurse to build the data structure, we are fine.

--
Mats

But is it wrong to have the class autoreg like I defined (containg vehicle v and owner o)?

Quote:

---

Originally Posted by esmeco

But is it wrong to have the class autoreg like I defined (containg vehicle v and owner o)?

---

You mean aside from the fact that if you have two vehicles by the same owner, you need to keep two copies of the same owner, which I think is the wrong solution.

--
Mats

So,if I understood you correctly,since a owner can have multiple vehicles we should have a pointer in both classes?Something like this?:

Code:

---


class owner
{
private:

  string name;
  string address;
  long id;
  long phone;

public:

  owner(string o_name,string o_address, long o_id,long o_phone);//constructor
  void getname (void) const;
  string setname(string o_name);
  //etc,other gets and sets
}

class vehicle
 {
private:

  string model;
  string brand;
  string license;
  long nr_oldowners;

public:

  vehicle(string v_model,string v_brand,string v_license,long v_nr_oldowner)
  void getlicense (void) const;
  string setlicensestring o_name);
  //etc,other gets and sets
}

class autoreg
{

private:

  vehicle *v;
  owner  *o;

public:

    insert_v(string v_model,string v_brand,string v_license,long v_nr_oldowner);//is this okay??

    insert_o(string v_model,string v_brand,string v_license,long_nr_oldowner,string o_name,string o_address, long o_id,long o_phone););//is this okay??

    erase_o(string o_name,string o_address, long o_id,long o_phone););//is this okay??

    erase_v(string v_model,string v_brand,string v_license,long v_nr_oldowner););//is this okay??

    update(string v_model,string v_brand,string v_license,long_nr_oldowner,string o_name,string o_address, long o_id,long o_phone););//is this okay??
 
}

---

Yes, that would make more sense.

Technically, vehicle could be constant part of the registry - there's no registration without a vehicle, only the owner may be shared between multiple vehicles.

--
Mats

You mean the

Code:

---

insert_v(string v_model,string v_brand,string v_license,long v_nr_oldowner)

---

method,making it constant?

Quote:

---

Originally Posted by esmeco

You mean the

Code:

---

insert_v(string v_model,string v_brand,string v_license,long v_nr_oldowner)

---

method,making it constant?

---

Not quite: just replace vehicle *v with vehicle v; this means that the vehicls is part of the registry, raher than something pointed to by the registry.

Each registration concerns exactly and always one unique vehicle. The owner may or may not be unique, so you need a way to refer to an owner from more than one registration. This means that it has to be a pointer or some other type of reference [you could keep all owners in an array and keep the index of the owner in the registry, for example - but I think a pointer is better].

[Edit]Also, I would probably just make functions to get and set things, rather than functions that take a lot of parameters and do lots of things.

If you maintain the existing model with a pointer to a vehicle, you could even us a method "setVehicle(vehicle *av);" and "setOwner(owner *ao);". [/edit]

--
Mats

Could this class also be done like this with array,instead of pointer(to use later with linked lists)?

Code:

---


class autoreg
{

private:

  vector <vehicle> v;
  vector <owner>  o;

public:

    insert_v(string v_model,string v_brand,string v_license,long v_nr_oldowner);//is this okay??

    insert_o(string v_model,string v_brand,string v_license,long_nr_oldowner,string o_name,string o_address, long o_id,long o_phone););//is this okay??

    erase_o(string o_name,string o_address, long o_id,long o_phone););//is this okay??

    erase_v(string v_model,string v_brand,string v_license,long v_nr_oldowner););//is this okay??

    update(string v_model,string v_brand,string v_license,long_nr_oldowner,string o_name,string o_address, long o_id,long o_phone););//is this okay??
 
}

---

Well, you need a way to connect a vehicle to an owner. Your current class will be able to hold a number of owners and a number of cars - but there's no direct connection [of course, if you insert them together, they would be at the same index both of them - but hardly a practical arrangement to connect them].

But a lot of it depends on how you are actually going to use the data.

My approach is mostly based on the fundamental principles in database design - and I don't think that's a bad thing, because what you are doing is essentialy a database. In database design, the principle is that you only hold something in one place, and then use an ID to refer to it someplace else. So in these terms, the owner would have an ID, and then the registry would refer to the owner by the ID, and the vehicle would have another ID, and a the ID would be stored in the registry.

But in C/C++, you may use a pointer as a more direct way to access the owner - it's still the same principle - one owner stored somewhere, referenced by the connection to the vehicle in the registry. If you hold the vehicle itself in the registry or not is a different matter.

Does this make sense to you?

--
Mats

Well it makes sense,but how would it be in terms of classes the connection between the vehicles and owners?

An owner is a data member of a vehicle.

Code:

---

class Owner { ... }

class Vehicle {
    public:
        Owner GetOwner() { return owner_; }
    private:
        Owner owner_;
}

---

Who owns the vehicle? call Vehicle::GetOwner() to know.

Quote:

---

Originally Posted by Mario F.

An owner is a data member of a vehicle.

Code:

---

class Owner { ... }

class Vehicle {
    public:
        Owner GetOwner() { return owner_; }
    private:
        Owner owner_;
}

---

Who owns the vehicle? call Vehicle::GetOwner() to know.

---

Yes, but I still think it should be a pointer so that THE SAME owner can be connected to multiple vehicles, and for example an address update will be affecting ALL vehicles owned by that owner, and not need to be updated multiple times for multiple vehicles [which by the way is not how the UK's DVLA works - if you own two vehicles registered to you as a person, you need to send in both registration documents to change the address].

--
Mats

So,if the owner is referred on the vehicle class (owner owner_;) shouldn't the vehicle be referenced in the owner class?

You don't necessarily have to keep a reference to the vehicle from the owner - but it helps if you want to find "what vehicles are owned by John Smith". The reverse holds if you want to find "who owns registration ABC123" - then you are best of having a reference in the vehicle to the owner, so that when you locate the vehicle, you don't have to traverse all the owners to find who owns that vehicle.

You could of coruse have a separate table to hold this informaton, where you have a pointer to the owner and a pointer to the vehicle, and neither the vehicle nor the owner contains any links to each other directly [this is sort of a cleaner approach].

--
Mats

An object must own all the owners and all the vehicles. The automobile registry is an ok place to do that in this simple setup (ideally something else would own each group and the automobile registry would be restricted to the relationship between the two).

So the autoreg class could have two containers. One that holds vehicles and one that holds owners. These containers should allow fast lookup of their contents. One option is a map. You can have one that maps the owner id to the owner and another that maps the vehicle license to the vehicle.

Once you have the objects contained, then you have to store the relationship between them. This should be a container pairing the keys of each owner/vehicle pair that has a relationship. So you could have a map of owner ids to vehicle licenses. If you need to look up a vehicles owner from its license you could have a map of the vehicles license to the owner id. If you need to lookup in both directions you can have two maps. (There is actually a container from boost that allows you to make both values keys for easy lookups on either in one container if you're interested.)


I don't like the idea of Vehicle containing Owner. What if a vehicle has joint owners? What if you want to have a separate database of information on owners. What if an "owner" doesn't actually own a vehicle? If none of these issues will ever arise, then it might be ok. Otherwise they should be separate.

Quote:

---

An object must own all the owners and all the vehicles. The automobile registry is an ok place to do that in this simple setup (ideally something else would own each group and the automobile registry would be restricted to the relationship between the two).

So the autoreg class could have two containers. One that holds vehicles and one that holds owners. These containers should allow fast lookup of their contents. One option is a map. You can have one that maps the owner id to the owner and another that maps the vehicle license to the vehicle.

Once you have the objects contained, then you have to store the relationship between them. This should be a container pairing the keys of each owner/vehicle pair that has a relationship. So you could have a map of owner ids to vehicle licenses. If you need to look up a vehicles owner from its license you could have a map of the vehicles license to the owner id. If you need to lookup in both directions you can have two maps. (There is actually a container from boost that allows you to make both values keys for easy lookups on either in one container if you're interested.)


I don't like the idea of Vehicle containing Owner. What if a vehicle has joint owners? What if you want to have a separate database of information on owners. What if an "owner" doesn't actually own a vehicle? If none of these issues will ever arise, then it might be ok. Otherwise they should be separate.

---

Could you possibly demonstrate what you said in a few code lines,because I'm a bit confused...

Quote:

---

Originally Posted by Daved

An object must own all the owners and all the vehicles.

---

Why? I own two cars. There is no other object that owns my cars or myself. Hence it is possible to construct a world view in which there is no need for an object to own my cars, other than (objectively) myself.

In general, the relationship between a car and an owner if best described as an association. That might be a many to many association (eg I own more than one car, some cars might be co-owned by several people or organisations).

One way of representing an association between objects is with a pointer. Many to many associations might be represented with an array of pointers, in the definition of each class of object.

>> Could you possibly demonstrate what you said in a few code lines,because I'm a bit confused.

Code:

---

std::map<std::string, Vehicle> vehicles; // map unique license to Vehicle
std::map<long, Owner> owners; // map unique ownerId to Owner

typedef std::multimap<long, std::string> OwnedVehicleMap;
OwnedVehicleMap owned_vehicles;  // map owner to his vehicles

// owner #3 buys new vehicle with license ABC123

// add vehicle
Vehicle new_car("330i", "BMW", "ABC123");
vehicles.insert(std::make_pair("ABC123", new_car));

// add association of vehicle to owner
owned_vehicles.insert(std::make_pair(3, new_car.getlicense()));


// What make/model cars does owner #3 have?
std::pair<OwnedVehicleMap::const_iterator, OwnedVehicleMap::const_iterator> vehicle_range
      = owned_vehicles.equal_range(3);

Owner& the_owner = owners[3];
std::cout << the_owner.getName() << " owns:\n";

while (vehicle_range.first != vehicle_range.second)
{
    std::string license = vehicle_range.first->second;
    Vehicle& current_car = vehicles[license];

    std::cout << current_car.getbrand() << ' ' << current_car.getmodel() << '\n';

    ++vehicle_range.first;
}

---

It's not the most perfect solution, but the idea is to keep track of the vehicles and owners separately, and then keep track of the associations.

If you have an owner, you can look up the information about the car by getting the license from the association and using the license to find the car. If you wanted to go the other direction, you would want to add another multimap to map vehicles to their owner.



>> Why? I own two cars. There is no other object that owns my cars or myself. Hence it is
>> possible to construct a world view in which there is no need for an object to own my cars,
>> other than (objectively) myself.

In your program, who will manage the lifetime of the vehicles and who will manage the lifetime of the owners? By "own" I meant "manage the lifetime of". I also didn't mean they had to be "owned" by the same thing. So if you want a one-to-many association, then you can have the owner manage the vehicles and something else manage the owner.

But is it possible to do with the vector container instead of the map container the association between the elements?And how does a vector container works?Does it work like an array where you access it like this [i] and in each position we can only store a character (ex: "s") or integer (1111)?

A vector is a dynamic array, and it can be defined as you like:

Code:

---

vector<int> intv;
vector<char *> charv;
vector<owner> ownerv;

---

You can access the vector just like an array, but you can also use some other functions that are defined here:
http://www.cplusplus.com/reference/stl/vector/

You can't have a vector of owner directly connect with a vector of vehicle, so you still need some way to connect the two together.

--
Mats

Code:

---


You can't have a vector of owner directly connect with a vector of vehicle, so you still need some way to connect the two together.

---

And that way to connect could still be maps,or what other options there are?

maps would be one of the options. Another option is a vector of a pair of objects (owner and vehicle).

A lot of the decisions here depend on exactly what you are doing with your data and how you plan to organise the data in other respects.

For example, are you planning to keep a register of "previous owners" or just the count of them?

Note that a map is essentially a vector where the "index" is a non-numerical value. So you can for example have a map of vehicles that index on the registration number. Or a vector of owners that index on (for example) a string combination of the first and last name.

--
Mats

I'm planning to just count them...So,would the vector be like this ?:

vector<owner,vehicle> ownerv;

There are two distinctly different ways to handle this. One is to have each owner and each vehicle contain the references to the objects it is associated with. So the owner might have a vector<vehicle*> and vehicle might have vector<owner*>. For that to work, you have to make sure some other object controls the lifetimes of the owners and vehicles. You also have to make sure that if you ever delete an owner or vehicle, that you update the associations.

A similar approach would be to have owners contain a vector<string> where the string is the vehicle license. Vechicles could have a vector<long> where the long was the ownerid. This works the same, except you have to lookup the vehicle or owner if you want to access it. It has the benefit of not crashing if you accidentally forget to clean something up- you will just have an invalid id instead of a bad pointer that causes a crash.

The other solution is the one I proposed earlier. Keep the associations in the autoreg class.

>> So,would the vector be like this ?: vector<owner,vehicle> ownerv;
You can use a vector, although it would be more complicated than a map. A vector of pairs would be like this:

Code:

---

vector<pair<owner, vehicle> > ownerv;

---

A better solution might be to make a owner/vehicle association class, and store those in the vector if you really wanted to use vector. The problem is that sorting is done automatically in the map, and you have to do extra work if youuse the vector.

No matter what, you have to include code that keeps track of the associations, so that if you remove one it will be changed in other places.

So if I understood correctly it would be something like:

Code:

---


class Owner
{

private:
...
vector<vehicle*>

public
...
}

class Vehicle

 {
    public:
        ...

    private:
        ...
    vector<owner*>

}

class cra
{
private:
...
vector<vehicle*>
vector<owner*>

public:
...
}

---

Is this right?

Not how I would do it.

If you have some form of "association" class (cra in your case), it should be the only place where you connect the owner and the vehicle.

You almost certainly don't need a "vector<owner *>" in your vehicle class - that would cover the case where you have multiple owners of a vehicle, which I don't even think is possible [at least not in the UK, you have a "registered keeper", which is the "owner", even if the actual owner is for example a company].

--
Mats

That is one way to do it, yes. You just have to take extra care to clean up all pointers to things that are deleted. In that scenario the cra class would manage the lifetimes of the vehicle and owner objects.

My wife and I jointly own one of our cars, and it is certainly allowed for use to have separate cars in our own names individually, so multiple owners might be allowed. Of course, it all depends on the problem space whether that is a requirement or not.

Quote:

---

Originally Posted by Daved

My wife and I jointly own one of our cars, and it is certainly allowed for use to have separate cars in our own names individually, so multiple owners might be allowed. Of course, it all depends on the problem space whether that is a requirement or not.

---

Just goes to show that what applies in one country doesn't necessarily apply in another country.

--
Mats

Quote:

---

Not how I would do it.

If you have some form of "association" class (cra in your case), it should be the only place where you connect the owner and the vehicle.

You almost certainly don't need a "vector<owner *>" in your vehicle class - that would cover the case where you have multiple owners of a vehicle, which I don't even think is possible [at least not in the UK, you have a "registered keeper", which is the "owner", even if the actual owner is for example a company].

---

Well,the problem explicitaly says that a car just have one owner...So,regarding to what you've said you could have the association defined by vectors like this:

Code:

---


class Owner { ... }

class Vehicle{ ... }

class cra
{
private:
...
vector < pair <vehicle*,owner* > > ownerv;


public:
...
}

---

Or by maps like this:

Code:

---


class Owner { ... }

class Vehicle{ ... }

class cra
{
private:
...

map<string, Vehicle> vehicles;
map<long, Owner> owners;
multimap<long, string> OwnedVehicleMap;

public:
...
}

---

Does this look ok?And thanks for all the help!:D

Also, if I wanted to,after storing the vehicles' and owners' information, list the owners' information and their owned vehicles how would I do it in terms of coding?

Just one more question that has been aching my head: why would I want to use maps instead of vectors in this case?What are the differences?

>> the problem explicitaly says that a car just have one owner.
I guess I missed that. Remember my comments were based on the assumption that a car can have multiple owners.


About your entire design. First understand the difference between referencing and management of an object (normally I would say ownership but because the problem includes something called an "owner" I don't want to use that term). A reference is a way for one object to refer to another. This can be a pointer. It can also be a key. For example, if the vehicle stored the ownerId of its owner, then it would be referencing the owner.

Management in this case means keeping track of the lifetime of the object in the program. It means having control of the actual instance and being able to create or destroy instances. Any object can only be managed by one other object. For example, if you have an owner contain a vector<Vehicle>, then it has a vector of objects (not pointers). That means it is containing and managing the actual Vehicle objects. If the Owner object is destroyed it's vehicle is destroyed. If it contained a vector<string> that was a list of the licenses of the owned vehicles, then it would be referencing them instead of "managing" them.

So if you understand that difference, here are the things you need to do in this program.

1. You need to manage all the Owner objects in the application. Something has to control when an Owner instance is created and when they are destroyed.
2. You need to manage the Vehicle objects somehow. You can do this by having each owner hold its own vehicles, or have a container that holds all vehicles in the application.
3. You need to be able to find the vehicle from the owner. You need this because you want to "list the owners' information and their owned vehicles". This means two things. One is that the Vehicle should not manage the Owner, it can only reference it. Since multiple Vehicles can be owned by the same Owner, and an object can only be "managed" by one other object, it won't work to have Vehicles manage Owners. The other thing it means is that Owners need to reference or manage their vehicles. You have to quickly and easily get from an Owner to its Vehicles.
4. You probably need to be able to find an owner from a vehicle. In that case, the Vehicle needs to reference the Owner, because as we just said the Vehicle cannot manage the Owner.

So, for #1, who should manage the Owners? It can't be the Vehicles, and the Owners can't manage themselves, so I'd say the autoreg class should manage the Owners. To do this there are several options, which is best depends on other decisions:

1. You can have a simple list (e.g. vector<Owner>). But assuming you need to be able to have the Vehicle reference the Owner (#4 above), that might be difficult. A pointer wouldn't work because a pointer doesn't always remain valid when an object is in a vector. An index might work, but then an Owner should never move around or get deleted from the vector.
   
2. You can have a list of dynamically allocated Owners (e.g. vector<Owner*>). This has the benefit of ensuring the pointers are never changed by the vector. The Vehicle can reference the Owner via a pointer and be confident that as long as the Owner is valid the pointer will point to it. The disadvantage is that you have to handle the memory management yourself and cleanup the Owners when they are removed.
   
3. You can have a map of Owners with their unique ids as the key (e.g. map<long, Owner>). One benefit here is that you don't have to do memory management. Another benefit is that the Vehicle can reference its Owner by keeping track of its ownerId. To look up the Owner, it just looks up the OwnerId in the map. The Id will never point to dangling memory, if the Owner is deleted then no entry will exist in the map. This means its safer. You can implement this solution with a vector as well. A simple vector<Owner> could work if the ownerId was sequential and starting at 0 (or 1) like an index. You could also sort the vector based on the OwnerId for fast access, and then look up via binary_search. Finally, if your application doesn't care about speed, you can just use a vector<Owner> and lookup the ownerId with a linear search.

If you don't need #4, then use a vector<Owner> inside the autoreg class. Otherwise, use whichever option above is most comfortable for you. I'd pick option C because it scales nicely and doesn't require memory management.

Now, what about for #2? Who manages the Vehicles, and how? As I said earlier, you could let the autoreg class manage the Vehicles, or you could let the Owner manage the Vehicles it owns.

1. If you let the autoreg class manage the Vehicles, it would mean that you would need a reference from the Owner to its Vehicles (for #3). The options here are similar to the options for referencing the Owner from the Vehicle. The first is a vector<Vehicle>. Negative is that referencing via pointer is bad, and referencing via index only works if you are strict about moving and/or deleting the Vehicles in the vector.
   
2. The second option is to contain a vector<Vehicle*> in the autoreg class. As above, the benefit is that an Owner can reference its vehicles with a vector<Owner*> of its own without worrying too much about the pointers changing randomly. The drawback is that you have to do the memory management and messing that up is more dangerous.
   
3. The third option is a map in the autoreg class. Again, a map<string, Vehicle> would work, since it would map the Vehicle based on its unique license. You could also use a vector<Vehicle> sorted by license, or you could use a vector<Vehicle> with a linear search. The Owner would then contain a vector<string> which is a list of the licenses of all Vehicles owned by that Owner.
   
4. You don't have to have the autoreg class manage the Vehicles. You can have each Owner manager the Vehicles it owns. The simplest way to do this is a vector<Vehicle> inside each Owner. The downside is that you don't have easy access to all the Vehicles. If you need to print out each Vehicle or look up a Vehicle by its license, then you need to search through all the Owners to find it. If you manage Vehicles in the autoreg class then they are all stored right there and it is not as difficult.

So for this problem, I would use either option C or D. Use D only if you don't need much access to the Vehicles and they are only there as part of an Owner's data. I would use option C if you want to be able to access Vehicle data separately from the Owner.


Finally, what about #3 and #4, I already mentioned ideas above on how to do those, but you have the option of storing the references in the objects themselves or in the autoreg class. My earlier example used the autoreg class to do that.

1. For option A it depends. As I said getting the references to work is difficult for this option.
2. For option B, have the Owner store a vector<Vehicle*> (#3) and have the Vehicle store an Owner* (#4). Or have the autoreg class hold a multimap<Owner*, Vehicle*> for #3 and a map<Vehicle*, Owner*> for #4.
3. For option C, you can have the Owner store a vector<string> to hold the Vehicle licenses for #3 and have the Vehicle store an ownerId for its Owner to handle #4. Or you can have the autoreg class contain a multimap<long, string> to map the ownerId to Vehicle license for #3 and a map<string, long> to map the Vehicle license to its Owner's Id for #4.
4. For option D, you don't need to have the Owner reference it's Vehicles, since it manages them, so #3 is already solved. For #4 you can use many techniques, but a simple Owner* in the Vehicle class or a map<Vehicle*, Owner*> in the autoreg class would work.

Whether you store the references in the Owner and Vehicle classes or in the autoreg class is up to you. The suggestion I had earlier was option C with the multimap/map in the autoreg class, but I think Option C with the objects containing the references is just as good.


There are still many more ways to do this than the above. For example, you might want to have a class other than autoreg manage the Owners and/or Vehicles. Hopefully this gives you an idea of different things you need to be concerned about, and ways you can implement solutions to those things. Identify who will "manage" the Owners and the Vehicles, and how each will be able to reference each other.

I've read all this and I must say it will give me a giant leap ahead on my work!Very very insightful,thank you so much for all the work!Later tonight,I'll post my code so that you,if possible,give me some help and suggestions!Thanks again!:)

This's my actual code...I'm having a bit of difficulty about some coding: in class autoreg defined de <map> as public...Should I put them has private instead?Another thing,once I have in autoreg a method in_ov(...) whose arguments are the objects of vehicle and owner(since that way it's easier to be,instead of sending all the attribute parameters ' of the classes like name,address,etc.),I have created a autoreg.cpp so that I can call that function from main .
In main I want to call that function,since user introduced data before,I would like to send them to the method in autoreg.cpp so that it could keep the data in the variables created created within the classes vehicle and owner and,later on,in that same function,create pair between the vehicles and owners association...I just don't have a clue how will I send all these data on the function since what I have there are the objects of both classes(owner and vehicle).
Could someone please help me out a bit with my code?
Just one last question: Is it necessary for constructors to exist in clas owner and vehicle given that who will manage that is the autoreg class throught their own add,clear methods?

Code:

---


#include<iostream>
#include <string>

using namespace std;

class vehicle
{
private:
        string license;
        string brand;
        string color;
        string model;
        long cil;
        long ccv;
        long nowner;
       

public:

        vehicle();
        vehicle(string str_ license,string str_brand,string str_color,string str_model,long n_cil,long n_ccv,long n_nowner);
        string get license(void) const;
        void set license(string str_ license);
        string getbrand(void) const;
        void setbrand(string str_brand);
        string getcolor(void) const;
        void setcolor(string str_color);
        string getmodel(void) const;
        void setmodel(string str_model);
        long getcil(void) const;
        void setcil(unsigned long n_cil);
        long getccv(void) const;
        void setccv(long n_ccv);
        long getnowner(void) const;
        void setnowner(long n_nowner);
   
};

---

Code:

---


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

class owner
{
private:
        string name;
        long id;
        string address;
        long phone;
       
public:
        owner();
        owner(string str_name,long sid,string str_address,long sphone);
        string getname(void) const;
        void setname(string str_name);
        string getaddress(void) const;
        void setaddress(string str_address);
        long getid(void) const;
        void setid(long sid);
        long getphone(void) const;
        void setphone(long sphone);

       
};

---

Code:

---


#include <iostream>
#include <map>
#include <string>
#include "vehicle.h"
#include "owner.h"

using namespace std;

class autoreg
{

public:
       
        map<string,vehicle>;
        map<long, owner>;
        multimap<long, string>;
        map<string, long>;

        void in_ov(vehicle v,owner p);
        void er_vehicle(vehicle v);
        void er_ov(vehicle v,owner p);
        search(vehicle v,owner p);

}

---

autoreg.cpp

Code:

---


#include "autoreg.h"
using namespace std;

cra::void in_ov(vehicle v,owner p)
{

   
 }

cra::er_vehicle(vehicle v);
 {

       
 }

 cra::er_ov(vehicle v,owner p);
 {

 }

cra::search(vehicle v,owner p);
{
}

---

Code:

---


#include <stdlib.h>
#include <iostream>
#include <string>
#include "autoreg.h"
#include "vehicle.h"
#include "owner.h"


void main()
{

  char input;
  string name,add,brand,model,color,lic;
  long id,ph,cil,ccv,nrowner;
  vehicle v;
  owner p;
  cra r;

  cout << "AutoREG" "\n"<< endl;
  while( 1 )
  {
          cout << "Add client and vehicle(a):""\n"<< endl;
          cout << "Remove owner(r):""\n"<< endl;
          cout <<        "Remove vehicle(x):""\n"<<endl ;
          cout <<        "Refresh owners and vehicles(z):""\n"<<endl ;
          cout <<        "List vehicles(v):" "\n"<<endl;
          cout <<        "List owners(o):""\n"<< endl;
          cout <<        "Exit(e): ""\n"<< endl;
      cin >> input;

    switch( input )
    {
    case 'a':
      {   
        cout <<"Name: " <<endl;
        cin>>name;
        cout<<"ID: "<<endl;
        cin >>id;
        cout<<"Address: "<<endl;
        cin>>add;
        cout<<"Phone: "<<endl;
        cin >>ph;
        cout <<"Brand: "<<endl;
        cin >>brand;
        cout << "License: "<<endl;
        cin >>lic;
        cout << "Color: "<<endl;
        cin >>colorr;
        cout << "Model: "<<endl;
        cin >>model;
        cout << "Cil: "<<endl;
        cin >>cil;
      cout<<"ccv: "<<endl;
      cin >>pot;
      cout<<"Nr de old owners: "<<endl;
        cin >>nrowner;
        r.in_ov(v,p);

          }
      continue;
        case 's':
                exit(0);
        default:
      cout << "Error: Input valid char " << input << '\n';
      break;
 }
  }

 
}

---

[B]Owner.cppB]

Code:

---


#include <iostream>
#include <string>
#include "owner.h"

owner::owner(string str_name,long sid,string str_address,long sphone)
{
                name = str_name;
        id=sid;
        phone=sphone;
        adress = str_adress;
}
string owner::getname() const
{
  return name;
};

void owner::setname(string str_name)
{
        name=str_name;
};

string owner::getadress() const
{
        return adress;
};

void owner::setadress(string str_adress)
{
        adress=str_adress;       
};

long owner::getid() const
{
        return id;
};

void owner::setid(long sbi)
{
        id=sid;
};

long owner::getphone() const
{
        return phone;
};

void owner::setphone(long sphone)
{
        phone=sphone;
};

---

Code:

---


#include<iostream>
#include<string>
#include "vehicle.h"

vehicle::vehicle(string str_ license,string str_brand,string str_color,string str_model,long n_cil,long n_ccv,long n_nowner)

{
license=str_license;
brand=str_brand;
color=str_color;
model=str_model;
cil=n_cil;
ccv=n_ccv;
nowner=n_nowner;

}

---

PS:Feel free to give suggestions or point out if there's code which isn't necessary,or even suggest corrections!:)

Could anyone help me on this?

>> Should I put them has private instead?
Yes. Keep them private and provide public access to the data they hold. I would have functions like GetVehicleOwner that looks up a vehicle's owner by using the maps.

>> I just don't have a clue how will I send all these data on the function
I would create an owner object and a vehicle object with the values input by the user, then pass those to your functions:

Code:

---

owner new_owner(name, id, add, ph);
vehicle new_vehicle(lic, brand, colorr, model, cil, pot, nowner);
r.in_ov(new_vehicle, new_owner);

---

In reality, I might separate the add owner and add vehicle functions in the cra class and add them separately. What if the user wants to add a new vehicle to an existing owner?

>> Is it necessary for constructors to exist in clas owner and vehicle given that who will manage that is the autoreg class throught their own add,clear methods?
Not necessary, but you should still do it. The vehicle and owner classes shouldn't rely on auto_reg, they should be valid classes in their own right. It is also better to construct them with all their data from the beginning rather than create one and call set for each data item.

>> Feel free to give suggestions
I would add header include guards to your header files. This is important for proper compilation.
I would use int main instead of void main, void main is not proper C++.
I would give longer, more descriptive variable names to make the code easier to read and follow.
I would use an initializer list in your constructors, although you might want to wait until your other coding is finished and working before worrying about this since how you have it now works too.

Thank you very much for the explanation and help!Here I've changed a bit the main function and class autoreg taking into account what you've said.
When compiling I get 2 errors of linkage saying the following:

autoreg.obj : error LNK2019: unresolved external symbol "public: __thiscall..."

Also,I have a warning that says: "warning C4715: 'autoreg::getownersvehicles' : not all control paths return a value

Do you have any idea,based on the code I've provided what may be causing this?

Code:

---


class autoreg
{

private:

       
        typedef map<string,vehicle> vehicles;
        typedef map<long, owner> owners;
        typedef multimap<long, string> ovmap;
        typedef map<string, long> ids;

public:
                string getownersvehicles() const;
        void in_ov(vehicle v,owner p);
        void er_vehicle(vehicle v);
        void er_ov(vehicle v,owner p);
        search(vehicle v,owner p);

}

---

Code:

---


void autoreg::in_ov(vehicle v,owner p)
{ 
  vehicles vh;
  ovmap ovm;
  owners odata;
  long id=p.getid();
  string lic=vh.getlicense(); 

  odata.insert(make_pair(id,p)); 
  vh.insert(make_pair(lic,v)); 
  ovm.insert(make_pair(id,lic));
}


string autoreg::getownersvehicles() const
{
 owner p;
 long id=p.getid();
 ovmap ovm;
  vehicles vh;
  owners odata;

pair<ovmap::const_iterator, ovmap::const_iterator> list_vehicles
      = ovm.equal_range(id);

owner& owns = data[id];
cout << owns.getname() << " has:\n";

while (list_vehicles.first != list_vehicles.second)
{
    string license = list_vehicles.first->second;
    vehicle& current_car = vh[license];

    return current_car.getbrand();
    return current_car.getmodel();

    ++list_vehicles.first;
}
}

---

Code:

---

int main
{
...
owner new_owner(name, id, add, ph);
vehicle new_vehicle(lic, brand, colorr, model, cil, pot, nowner);
r.in_ov(new_vehicle, new_owner);
...

case 'n':
      { 
                  autoreg auto;
                  auto.getownersvehicles();
               
  }
...

---

>> autoreg.obj : error LNK2019: unresolved external symbol "public: __thiscall..."
The part of the error message that was snipped off is important. What's the rest of the error message?

>> warning C4715: 'autoreg::getownersvehicles' : not all control paths return a value
This seems pretty self-explanatory. The function autoreg::getownersvehicles promises to return something, but there are ways the code can go that don't return anything. Of course, you are trying to return a string, but what you seem to want to do is return all vehicles owned by that owner, is that right? If so, you want to return a list of vehicles (maybe a vector<vehicle>) so that you can return all the vehicles and display there brand, model, etc.

As to your code, hopefully you've realized this by now but your member variables for the autoreg class aren't member variables. You created typedefs, then created local variables in the functions. That's not good, because the local maps you create in the function go out of scope and are destroyed when the function ends, so your autoreg class will never remember any data you give it. If you want typedefs, you need to also add member variables to the autoreg class, or if you didn't mean to do the typedef (or didn't know what you were doing), then remove the typedef word from those private variables.

Thank you for the tips!
It does work now...But,just one question,why do they get out of scope?

Why or when do they go out of scope?

This was the code for your in_ov function:

Code:

---

void autoreg::in_ov(vehicle v,owner p)
{ 
  vehicles vh;
  ovmap ovm;
  owners odata;
  long id=p.getid();
  string lic=vh.getlicense(); 

  odata.insert(make_pair(id,p)); 
  vh.insert(make_pair(lic,v)); 
  ovm.insert(make_pair(id,lic));
}

---

The bold parts are the variable declarations. You are declaring the variables inside this function. It is the same as doing:

Code:

---

void print_one_to_ten()
{
  int number = 1;
  while (number < 10)
    std::cout << number << ", ";
  std::cout << number << '\n';
}

---

The variable number in that code is local to the function, so when the function ends it goes away. If you call the function again it creates a new variable and runs the function, it doesn't use the previous one. Variables declared inside a block of code are local to that block, and they are destroyed when that block of code ends.

In your case, you want the maps to stick around as long as your class object sticks around. For example, let's say you have a car class that has a headlight member. You want the headlights to stick around for as long as the car sticks around. If somebody turns the headlights on, then you want to remember that the headlights are on. If you create headlights local to the function and turn those on, then when the function ends the headlights will be destroyed. If somebody checks the headlights they will be off because the headlights that were on were destroyed.

If you make the variables member variables, then they live as long as the class itself, and anything you change about them is remembered. So when you add a new vehicle to the map when it is a member variable, the vehicle will still be there later when you call another function to get or change that data.

This thread sparked off another discussion that may be worth reading: Pointers and Efficiency.