Re:The danger of "language" in programming (2009)
by stonemetal on Friday December 27, 2013 @02:40PM
(#6972226)
Pointers can be null references can not, therefore if you use a reference then you are communicating nulls not allowed. You can't new or delete with a reference, so you are saying something about the lifetime of the object referenced(That this code absolutely refuses to manage it).
[ Parent
| on HN ]
Re:The danger of "language" in programming (2009)
by catnaroek on Friday December 27, 2013 @02:42PM
(#6972238)
This is only partially true. A C++ reference can outlive the object it references. A better argument would be Rust's borrowed pointers, which are statically checked to never point to an invalid object throughout their entire lifetimes.
To talk about lifetimes, you need linear logic in the core language. Merely having destructors is not enough.
Re:The danger of "language" in programming (2009)
by stonemetal on Friday December 27, 2013 @04:10PM
(#6972629)
This is only partially true. A C++ reference can outlive the object it references.
I didn't mean to imply that it couldn't, just that by using a reference instead of a pointer you are disclaiming responsibility for lifetime management of the referenced item since you can not delete a reference.
C++ being what it is, one can ref = *(new object());, delete &ref;, but the intention you are expressing by using a reference is more hands off in nature. It isn't retargetable, no built-in ability to new\delete, etc.
Re:The danger of "language" in programming (2009)
by catnaroek on Friday December 27, 2013 @04:36PM
(#6972729)
Manually making sure a reference does not outlive the referenced object (or, at least, that a reference is not used after the object has been destroyed) looks pretty much like "lifetime management" to me. What C++ affords you is merely ownership management.
Re:The danger of "language" in programming (2009)
by sixthloginorso on Friday December 27, 2013 @02:54PM
(#6972299)
You are also indicating that the reference is not meant to be "reseated", i.e. that you aren't going to swap the object at the end of it for another, like you could do with a pointer.