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 » Wrong(?) ASSERT in Vector<>::Insert()
Wrong(?) ASSERT in Vector<>::Insert() [message #27807] Wed, 04 August 2010 23:33 Go to next message
dolik.rce is currently offline  dolik.rce
Messages: 1789
Registered: August 2008
Location: Czech Republic
Ultimate Contributor

Hello,
I just hit a problem in Vector code and I feel a need for explanation Smile . Have a look at this code
#include <Core/Core.h>
using namespace Upp;

CONSOLE_APP_MAIN{
	Vector<int> v;
	v.Add(123);
	v.Insert(0,v[0]);
}

I would expect it to insert a deep copy of the first element of the Vector and place it before the original. The actual result is that the code hits an assert in the Insert function:
template <class T>
void Vector<T>::Insert(int q, const T& x, int count) {
	if(!count) return;
	ASSERT(&x < vector || &x > vector + items);
	RawInsert(q, count);
	DeepCopyConstructFill(vector + q, vector + q + count, x);
}

As you can see, it check if the inserted data are part of the object itself. And of course, in the example above, they are.

Now, can someone explain me the reason for this assert? I fail to see how it could be harmful to make a deep copy of one of the elements inside...

If there is no real reason for this, I would like to see that assertion removed. There are also the same or similar assertions in the other variations of Insert which can be probably removed.

In my actual code I had to work around this by first making a deep copy of the copied element in temporary object and than inserting that. But I use quite big objects, not just int, so this workaround introduces is not only ugly, but also slow.

Best regards,
Honza

Re: Wrong(?) ASSERT in Vector<>::Insert() [message #27857 is a reply to message #27807] Fri, 06 August 2010 20:51 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
maybe because the adding of another element could lead to destroying (remember Moveable<>) the underlying vector space, (of which your first element is part of and render your reference to the first element invalid) and you would use an invalid source element reference for making the deep copy.

array flavor shouldnt have this problem i think.

correct me if i'm wrong..

[Updated on: Fri, 06 August 2010 20:55]

Report message to a moderator

Re: Wrong(?) ASSERT in Vector<>::Insert() [message #27997 is a reply to message #27807] Fri, 13 August 2010 09:34 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
dolik.rce wrote on Wed, 04 August 2010 17:33

Hello,
I just hit a problem in Vector code and I feel a need for explanation Smile . Have a look at this code
#include <Core/Core.h>
using namespace Upp;

CONSOLE_APP_MAIN{
	Vector<int> v;
	v.Add(123);
	v.Insert(0,v[0]);
}




It is classical and nasty bug.

Insert expects a reference, but at the same time invalidates references to v.

Not that in this particular case, we could workaround it in Vector code, but there are other similar cases where this is not quite possible:

http://www.ultimatepp.org/srcdoc$Core$Caveats$en-us.html

so I decided to forbid them all.

(And thanks kohait, you are 100% right).

And yes, I am not happy about this, but I guess ASSERT is best we can get here....
Re: Wrong(?) ASSERT in Vector<>::Insert() [message #28054 is a reply to message #27997] Fri, 13 August 2010 20:25 Go to previous message
dolik.rce is currently offline  dolik.rce
Messages: 1789
Registered: August 2008
Location: Czech Republic
Ultimate Contributor

Thank for explanation Mirek.

I guess one additional deep copy from time to time won't kill me Smile

Honza
Previous Topic: better Stream manual....more info needed
Next Topic: NEW: BufferStream
Goto Forum:
  


Current Time: Sun Apr 28 07:17:52 CEST 2024

Total time taken to generate the page: 0.02779 seconds