Dependency Loop seems unavoidable

[Tim]

Dear All,

Dependency should be not looped. However, I think it unavoidable. For
example, I have two classes: Bank and People as follows

class Bank
{
private:
Set<people*m_clients; //all clients
};

class People
{
private:
Bank* m_bank; // in which an account is opened.
};

Any way to avoid the dependency loop?

Thanks,

Tim

[meagar]

On Aug 22, 12:42 am, Tim <[e-mail]:

Dear All,

Dependency should be not looped. However, I think it unavoidable. For
example, I have two classes: Bank and People as follows

class Bank
{
private:
Set<people*m_clients; //all clients

};

class People
{
private:
Bank* m_bank; // in which an account is opened.

};

Any way to avoid the dependency loop?

Thanks,

Tim

You could try rethinking your mapping of real-world objects to
classes; all banks have clients, but not all people have banks?

class Person {
// name, address, etc
};

class Bank {
public:
class Client : public Person {
Bank* m_bank;
// A set of bank account numbers, other client-specific
things that not all people have
};

std::set<Client*m_clients;
};

[Ian Collins]

Tim wrote:

Dear All,

Dependency should be not looped. However, I think it unavoidable. For
example, I have two classes: Bank and People as follows

class People;

class Bank
{
private:
Set<people*m_clients; //all clients

Set<People*m_clients; //all clients

};

class People
{
private:
Bank* m_bank; // in which an account is opened.
};

Any way to avoid the dependency loop?

There isn't one, provided you don't attempt to dereference a People*
before the full class declaration.

--
Ian Collins.

[Jim Langston]

"Tim" <Ti************@gmail.comwrote in message
news:11**********************@r23g2000prd.googlegr oups.com...

Dear All,

Dependency should be not looped. However, I think it unavoidable. For
example, I have two classes: Bank and People as follows

class Bank
{
private:
Set<people*m_clients; //all clients
};

class People
{
private:
Bank* m_bank; // in which an account is opened.
};

Any way to avoid the dependency loop?

Well, since Bank* inside People is a pointer, the only thing it needs to
compile is a
class Bank;
declaration. It does not need to see the interworkings of Bank unless you
attempt to derefernce it inside of the People class. If People simply
returns the pointer to something, then you have no problem.

Consider, also, that some people use more than one Bank. It depends on what
you are attempting to do.

[Ian Collins]

Jim Langston wrote:

"Tim" <Ti************@gmail.comwrote in message
news:11**********************@r23g2000prd.googlegr oups.com...

>Dear All,

Dependency should be not looped. However, I think it unavoidable. For
example, I have two classes: Bank and People as follows

class Bank
{
private:
Set<people*m_clients; //all clients
};

class People
{
private:
Bank* m_bank; // in which an account is opened.
};

Any way to avoid the dependency loop?

Well, since Bank* inside People is a pointer, the only thing it needs to
compile is a
class Bank;
declaration. It does not need to see the interworkings of Bank unless you
attempt to derefernce it inside of the People class. If People simply
returns the pointer to something, then you have no problem.

I think you have that the wrong way round, it is People that requires a
forward declarations.

--
Ian Collins.

[Tim]

On Aug 22, 1:42 am, "Jim Langston" <[e-mail]:

"Tim" <[e-mail] in message

news:11**********************@r23g2000prd.googlegr oups.com...

Dear All,

Dependency should be not looped. However, I think it unavoidable. For
example, I have two classes: Bank and People as follows

class Bank
{
private:
Set<people*m_clients; //all clients
};

class People
{
private:
Bank* m_bank; // in which an account is opened.
};

Any way to avoid the dependency loop?

Well, since Bank* inside People is a pointer, the only thing it needs to
compile is a
class Bank;
declaration. It does not need to see the interworkings of Bank unless you
attempt to derefernce it inside of the People class. If People simply
returns the pointer to something, then you have no problem.

Consider, also, that some people use more than one Bank. It depends on what
you are attempting to do.- Hide quoted text -

- Show quoted text -

It is easy to avoid the compilation loop. I am talking about the
design, the acyclic design.

Thanks.

[Juha Nieminen]

Tim wrote:

It is easy to avoid the compilation loop. I am talking about the
design, the acyclic design.

Why do you want to avoid the dependency loop?

There are cases where a class even has a dependency loop with
itself. A list element is a typical example.

[Jim Langston]

"Tim" <Ti************@gmail.comwrote in message
news:11**********************@r23g2000prd.googlegr oups.com...

On Aug 22, 1:42 am, "Jim Langston" <[e-mail]:

>"Tim" <[e-mail] in message

news:11**********************@r23g2000prd.googleg roups.com...

Dear All,

Dependency should be not looped. However, I think it unavoidable. For
example, I have two classes: Bank and People as follows

class Bank
{
private:
Set<people*m_clients; //all clients
};

class People
{
private:
Bank* m_bank; // in which an account is opened.
};

Any way to avoid the dependency loop?

Well, since Bank* inside People is a pointer, the only thing it needs to
compile is a
class Bank;
declaration. It does not need to see the interworkings of Bank unless
you
attempt to derefernce it inside of the People class. If People simply
returns the pointer to something, then you have no problem.

Consider, also, that some people use more than one Bank. It depends on
what
you are attempting to do.- Hide quoted text -

- Show quoted text -

It is easy to avoid the compilation loop. I am talking about the
design, the acyclic design.

Again, it depends on what you are trying to do. Are you writing code for a
bank, for people, or for the IRS?

If you are writing code for a bank, then it shouldn't be your concern what
other banks that person uses.

If you are writing code for a person, then it shouldn't be your concern what
other people that bank uses.

If you are writing code for the IRS, it would most likely be in differnet
applicatoins.

What are you trying to accomplish? What is your program intended to do? If
this is just a learning experience, then imo most times you don't need to do
such things except in experimentation.

[BobR]

Tim <Ti************@gmail.comwrote in message...

Dear All,
Dependency should be not looped. However, I think it unavoidable. For
example, I have two classes: Bank and People as follows

class Bank{
private:
Set<people*m_clients; file://all clients
};

class People{
private:
Bank* m_bank; // in which an account is opened.
};

Any way to avoid the dependency loop?
Thanks,
Tim

<G>
Why on earth would you want to put people in a bank?
(after you get their money, you don't want them in the bank! <G>).

class Account{
std::string bankname;
std::string username;
std::string accountnumber;
long long balance; // in pennies
};

class People{
Account account;
};

class Bank{
Set<Accountclients;
public:
Account NewAccount( std::string const &name, long amount );
};

--
Bob R
POVrookie

[Victor Bazarov]

BobR wrote:

Tim <Ti************@gmail.comwrote in message...

>Dear All,
Dependency should be not looped. However, I think it unavoidable. For
example, I have two classes: Bank and People as follows

class Bank{
private:
Set<people*m_clients; file://all clients
};

class People{
private:
Bank* m_bank; // in which an account is opened.
};

Any way to avoid the dependency loop?
Thanks,
Tim

<G>
Why on earth would you want to put people in a bank?
(after you get their money, you don't want them in the bank! <G>).

He didn't put people in the bank, he put *pointers to people* in it.
You know, like an address book stored in the vault... :-)

[..]

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[BobR]

Victor Bazarov <v.********@comAcast.netwrote in message...

BobR wrote:

<G>
Why on earth would you want to put people in a bank?
(after you get their money, you don't want them in the bank! <G>).

He didn't put people in the bank, he put *pointers to people* in it.
You know, like an address book stored in the vault... :-)

Or a bunch of bank employees standing around pointing at the customers. :-}
( it's not polite to point! <G>)

Hate to jump back to 'serious', but,

Set<people*m_clients; file://all clients

.... if the 'Set' was std::set, we both know there's a missing 'comparator'
in the instantiation.
IMHO, a std::vector would be a better choice for pointers. You'd still need
to write some kind of 'unique' to sort it out.

[ caution: I have not finished my first cup of coffee yet! My
single-brain-cell is only about 20% active. <G>]
--
Bob R
POVrookie

[Victor Bazarov]

BobR wrote:

Victor Bazarov <v.********@comAcast.netwrote in message...

>BobR wrote:

>>[..]
Set<people*m_clients; file://all clients

... if the 'Set' was std::set, we both know there's a missing
'comparator' in the instantiation.

Why do you say that it's missing? There is the default compare
functor, std::less...

IMHO, a std::vector would be a better choice for pointers. You'd
still need to write some kind of 'unique' to sort it out.

8-O why bother with the vector and making it unique and sorting,
when there is std::set for it?

[ caution: I have not finished my first cup of coffee yet! My
single-brain-cell is only about 20% active. <G>]

Figures...

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[BobR]

Victor Bazarov <v.********@comAcast.netwrote in message...

BobR wrote:

Victor Bazarov <v.********@comAcast.netwrote in message...

BobR wrote:
[..]
Set<people*m_clients; file://all clients

... if the 'Set' was std::set, we both know there's a missing
'comparator' in the instantiation.

Why do you say that it's missing? There is the default compare
functor, std::less...

Ah, I wasn't aware that (default) std::less was smart enough to dereference
the pointer.
I'll have to read-up on that.

Person joe("Joe Smith");
Person smith("Joe Smith");
std::set<Person*clients;
clients.insert( &joe );
clients.insert( &smith );
assert( 1 == clients.size() );

?

--
Bob R
POVrookie