Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » U++ Library support » U++ Core » why not "T & Add(const T & x)" in all containers
Re: why not "T & Add(const T & x)" in all containers [message #28605 is a reply to message #28588] Wed, 08 September 2010 10:24 Go to previous messageGo to previous message
rylek is currently offline  rylek
Messages: 79
Registered: November 2005
Member
Hi there!

It is a pleasure to play the third party, though the semantics of the term are highly disputable here. I think it's possible Mirek originally didn't include the return reference in Vector::Add to emphasize the fact that such references into Vectors are volatile in principle (specifically they are periodically invalidated by the Add function itself while reallocating the physical Vector data). But, of course, the same argument holds for Add() which does return the reference. Moreover, Array::Add(T *newobj) also returns the reference, albeit for different reasons.

U++ also decidedly avoids returning references in pick assignment operators, which is natural because a "chain" assignment (a = b = c) in such cases exhibits undesirable behaviour (by destroying b). But Vector::Add(const T&) doesn't have this problem; the only thing that has to be avoided is rather artificial constructs of the form

vector.Add(vector.Add(obj))


exactly because of the periodical Vector reference invalidation. But then again you can run into exactly the same problems by writing, e.g.

vector.Add(vector[5]);


so that this is no specific of Vector::Add(const T&) either. To sum it all up, I currently see no practical reasons against modifying Vector::Add to include the return reference. I would rather say that it's like updating old code to match interface standards adopted / developed later on, in fact I believe Vector is one of the very oldest things in U++ (although it's been rewritten quite a few times since its inception).

Regards

Tomas
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: InitCaps() proposal
Next Topic: Incorrect implementation of INITBLOCK (and similar macros) in case when flagBLITZ is not defined.
Goto Forum:
  


Current Time: Mon Aug 25 02:46:08 CEST 2025

Total time taken to generate the page: 0.05976 seconds