Re: noobs and pointers
On Apr 17, 5:52 am, Salt_Peter <pj_h...@yahoo.com> wrote:
On Apr 16, 4:12 am, "James Kanze" <james.ka...@gmail.com> wrote:
On Apr 16, 3:30 am, "Salt_Peter" <pj_h...@yahoo.com> wrote:
ie:
std::set<Student> or std::map<int/*id*/, Student>
Lets face it, using pointers and uncopyable Students will not satisfy
the requirement of unique objects in any way.
It means that the identity of an object cannot be lost.
Thats not neccessarily what you want.
example:
Student enrolls in a class, gets a record in a central school
district's repository/database.
Student takes new studies in summer school,
then enrolls in a different school in same district the next year.
Should a new identifiable record be generated each time the student
enrolls?
Its the source or repository that should be identifiable,
the Student should be copyable to facilitate processing.
I don't think I follow you. Your example seems to suggest just
the opposite. Student enrols in summer school. A copy is made,
and credited with his courses. The original student object
isn't. Result, the student looses credit.
This is precisely the case where copying is NOT wanted. There
is one, and only one, object which represents the student, and
all course credits are enregistered in that object. So there's
no risk of some of them getting lost.
[...]
Why should a program be forced to depend on unsafe, raw pointers only?
Have you stopped beating your wife? Raw pointers are neither
more nor less safe than anything else. Used correctly, they
work well. Used incorrectly, they don't.
Its my wife that beats me, she does so often, and i can't get enough.
read the original post from the OP. He's having issues with dangling
pointers.
So pointers are unsafe, because one person is having trouble
with them. So it is better to replace pointers with multiple
copies, where updates are done to a random copy. An expression
like "depend on unsafe, raw pointers only" reflects a
preconceived notion---the question is loaded.
If "student" has an identity, and is not just a value, then
supporting copy and assignment is a guaranteed recepe for
errors. (In general, but there are a lot of exceptions, an
object which supports modification other than through assignment
probably has identity, and should not support copy or
assignment.) And most of the time, if an object has identity,
it also has an explicit lifetime, which must be managed; you
can't foster such management off to a container.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34