generic class issue

[paradoxajd]

Hello cpp forum, it's my first post here.
I was writing generic class Array (based on counting access to elements)and i got compiling error I cannot even understand (in vs2012). Sorry my code being on my mother tongue, but it was due university specifications. I'll post both my code and entire vs outup.
code: http://pastebin.com/07zqbHbh
error: http://pastebin.com/eJygK05a
Thanks in advance. :D

[MiiNiPaa]

Line 93: You have missed & in output iterator passing.
copy(&elementi[indexTrenutnog+1], &elementi[brojElemenata()], &noviEl[indexTrenutnog+1]);

[ne555]

blergh at your indent style.

1>          c:\program files (x86)\microsoft visual studio 11.0\vc\include\xutility(2110) : 
   see reference to function template instantiation 
   '_OutIt std::_Copy_impl<_Iter,_OutIt(_InIt,_InIt,_OutIt,std::_Nonscalar_ptr_iterator_tag)' 
   being compiled
1>          with
1>          [
1>              _OutIt=int *,
1>              _Iter=int **,
1>              _InIt=int **
1>          ]

referring to copy(&elementi[indexTrenutnog+1], &elementi[brojElemenata()], noviEl[indexTrenutnog+1]); //line 93
As you can see, the types don't match.

Also, ¿why are you using T** for an array?

[paradoxajd]

Works, thanks guys.
About my indent, I'm aware that many might hate it, but I find it very easy to read and intuitive. Since i'm working on solo projects I'm not that concerted about indent, but I'll definitely work out on that.

About T**. It's MUCH MUCH more efficient:
1) as you can see I always have few places spare in my array, and pointers take much less memory space than some object that T might become.
2) sorting, coping and moving pointers is much more efficient than doing some with object that T might become
3) if T is some object that hasn't constructor without parameters, making a array in ways i do wouldn't work
4) using T** is essential in efficient way for making arrays based on counting access to element (avoiding extra copies, etc).

[ne555]

> sorting, coping and moving pointers is much more efficient than doing some with object that T might become
copying a pointer is not equivalent to copying to object it points to.
you may design your "big" object with a handler (pointer) to the data, so swapping becomes cheap. Consider Niz<std::vector<int> >

> if T is some object that hasn't constructor without parameters, making a array in ways i do wouldn't work
then change your faulty ways.
Check out placement new.

> using T** is essential in efficient way for making arrays based on counting access to element
I'm not familiar with the term, ¿mind to explain?

[paradoxajd]

My task was about creating efficient array class, which doesn't depend on how other objects are designed.
And, from what see, Niz<std::vector<int> > would make matrix (array of vectors), so i don't understand what is there to consider.

Again, this class doesn't care about how objects are designed. I'm not sure what exactly that "placement new" is, and I will look into it. Thanks for information.

About "access counting" thing. This is literal translation from my language, so I'm not sure about professional term. Basically, it doesn't make deep copies of elements every time I want to copy that object. Instead, copy constructor and operator = just copy addresses of that objects and increase counter of access to that element. Basically, it leaves shallow copy on purpose. I only make deep copies when there is chance that element might be changed, in this case, only operator[] does that. So, it makes deep copy of element operator[] wants to access, reduces counter of access to that elements for one (and deletes both element and it's counter if counter == 0). I tired to explain that, hope u understood. However, if you haven't feel free to ask about it again. If i find time these days, i translate names to English, so it makes it more clear. Tell me if you would like that.

[ne555]

> `Niz<std::vector<int> >' would make matrix (array of vectors), so i don't understand what is there to consider.
sizeof(std::vector<int>) is not big. Swapping vectors is quite efficient, however you require yet another dereference to access the elements.
Test if it is actually better.

> Basically, it leaves shallow copy on purpose.
> I only make deep copies when there is chance that element might be changed
copy on write (cow), I guess
However you make a copy in operator[] always, even if you are the only one that is referencing that element.


By the way, you have memory leaks in operator= and operator[]

[paradoxajd]

Even with vector it's smarter to use vector<T*> rather than vector<T> (if some big objects), but again, my task was to recreate vector as best as I can. (I'm well aware that using vector instead of my class is way more efficient).

Lot completely always. As you can see, I have version of operator[] for constant variables which partially solves problem. On the other hand, there is no way (known to me at least) that I can know when will operator[] be used as right value and when as left value. If I knew that, i could only deep copy when it's used as l- value.

Yes, i know I had leaks in that version, however, he's final one. I'd tried to find leaks, but seems like everything is good now. If you have time, please check if I missed anything.
http://pastebin.com/bKgE6xMw
lines which contain comment

mem leak check!

is actually handy function in visual studio(2012) to check memory leaks.

[Disch]

Even with vector it's smarter to use vector<T*> rather than vector<T> (if some big objects)

Ehhh.

I was going to make a big reply to counter this point... but instead I will just say you are oversimplifying a complex topic.