I think this ideal case for pick(), as you pick up content of return value (leaving it empty), which is discarded anyway right away.

In programming you always should be sort of aware how you use the computer memory.
In C++ you have great control over it, actually just by reading source you can tell quite exactly, how the memory is used.

Vector is built of two parts, the Vector container data like size, capacity and pointer to the data itself; this part is of constant memory size, and is cheap to allocate/copy/destroy, so it's often instantiated on the actual scope stack.
And then there're the data itself, which are allocated on the heap memory, as there may be lot of them, and the pointer to the heap is stored inside the container inner structure.

pick() is sort of "copy constructor", which will copy the size/capacity/pointer from one Vector to the other Vector container, and it will disconnect and invalidate the old container's data pointer. Effectively "moving" the Vector without copying millions of data, only the small constant size Vector container inner structure is copied.

clone() is full copy constructor, which will allocate another (second) block of heap memory for the actual data inside the new Vector instance, and then will copy the actual data from one block of heap memory to the new one.
The old instance of Vector remains fully operational. This is performance expensive operation, and you don't want to do it, unless you actually need a second copy of data.

So when you have a cheap way to move the Vector data around with "pick", you can instantiate Vector inside function, fill it up with data, return the temporary function instantiated Vector (to be released on the very next line after return from function), and pick the data payload to caller's Vector instance, saving them from release, but not copying them one by one.

If you are still confused, which of those two used, use always "pick" in debug mode. In case you mess it up, and access the picked container after, it will crash with some assertion, that you tried to access data from picked Vector, then you can decide if you need a copy, or you accidentally access old Vector instead of the new one.

In case of function returning Vector there's no reason for "clone()", as the source instance is destroyed right away in the function call clean up.

It's simple: your new compiler is C++11 compiler. And thus U++ is compiled in C++11 mode. It means, among other things, that you must now specify whether you use Pick or Clone operation.
For example, this code is valid for U++ in 'old' mode:

Vector<int> a,b; a = b;

But it fails to compile in U++11 mode because you should use pick/clone and call it explicitly:

Vector<int> a,b; a = pick(b);

Of course, you may use clone() only if your object supports it.
Please refer to the updated Help documentation for details.

Hi,

I would rather recommend fixing the code. Could you please show me the example of code that is causing the problem?

class ReadExcelDlg : public WithReadExcel<TopWindow> {
	typedef ReadExcelDlg CLASSNAME;
	OfficeSheet sheet;
	void MakeList();
	void SaveDetailRecord(int count, int idteam, Vector<String> p);
	int  SaveMasterRecord(Vector<String> t);
public:
	bool updated;
	void SetTournamentDir( String dir);
	void ReadSheetDetail();
	ReadExcelDlg();
};
// code snippet

		Vector<String> t;
                //...
		int idteam = SaveMasterRecord( t); <--- error C2280

class Pair : Moveable<Pair> {
public:
	int idw, idb;
	String ToString() const { return AsString(idw) + ' ' + AsString(idb); }
	Pair(int idw, int idb) : idw(idw), idb(idb) {}
	Pair() {}
};

class SortPairing { 
	Vector<Pair> pairs;
	int comppair(int j1, int j2);
 public:
	Vector<Pair> SortPairs(Vector<Pair> pairing);
	SortPairing() {}
	~SortPairing(){;}
};

 	//code snippet
        SortPairing S, pairs;
        //...
  	Vector<Pair> sortedPairing;   
        sortedPairing = S.SortPairs(pairs);  <--- error C2280

Do you really want to pass full copy?

mr_ped wrote on Wed, 27 January 2016 22:42

Do you really want to pass full copy?

Hi,

thanks for the answer. That code was a bit old. It never gave problem and I forgot it. You are right of course.
After your observation I cleaned it and used Vector<...>& everywhere.

Now it compiles but fail to link with error: