I Want Your Suggestions

[zb0S216C]

I'm creating a small class that's similar to a vector, but it's length doesn't dynamically change( a fixed-length array basically ). I want some of your feature suggestions that I could integrate into the project. So far, I have these features:

1) Automatic index validation
2) Automatic resource deallocation
3) A locking system to prevent accidental assignments( locks-down the entire array ).
4) Export. Exports the content of the array to a standard array, and a vector.
5) Import. Same as export, but vise-versa.

I want to expand this array class as much as possible.

<sub>Note: Could you please refrain from pitching features that're impossible to integrate. Any impossible features will be ignored.


Wazzak</sub>

[Athar]

Note that there is std::array (or std::tr1::array, for that matter).

[hamsterman]

You mean

template< typename T, int N >
class Array {
   T t[N];
};

?

[ultifinitus]

Oh hamsterman I can honestly say I lol'd at that post. However you forgot index validation =]

@Framework:
What do you mean about 3) ? The programmer can lock the array to prevent assignment?

4 && 5 FileIO as well?

[LB]

_{ultifinitus wrote:}

4 && 5 FileIO as well?

Haha, only true coders like us would use && instead of &

@Framework: so, an advanced std::array class? What's the automatic deallocation for...?

[Mathhead200]

Guys, think Java standard arrays. You can't do this with hamsterman's Array class:

Array<int> arr(10);
arr = Array<int>(5); //Whoops! 

Framework wrote:

I want some of your feature suggestions that I could integrate into the project.

Built in sort and search(es). Sub-array and concatenation methods also. Of course these would return a new array, not mutate the given array.

[zb0S216C]

ultifinitus wrote:

What do you mean about 3) ? The programmer can lock the array to prevent assignment?

This has recently been deprecated in my project( a gap in the design ). What it was meant to do was protect all elements of the array from modification. This is where the deprecation came into play. When I wrote the methods that access the elements of the array, I had no way of enforcing the locking system, so I deprecated it as it became redundant.

ultifinitus wrote:

4 && 5 FileIO as well?

There's no file I/O in this project. I don't plan on incorporating file I/O until a valid reason arises.

L B wrote:

so, an advanced std::array class? What's the automatic deallocation for...?

The automatic deallocation is used in two cases:
1) When the programmer/user attempts to rebuild the array without releasing the previous resources.
2) When the programmer/user forgets( or can't be bothered ) to release the resources allocated by the array.

_Wazzak

[zb0S216C]

Mathhead wrote:

Built in sort and search(es)

I can't see that working unless each element of the array had some sort of identifier or tag.

Mathhead, I'll take in consideration the last two suggestions( Sub-array, and concatenation ). Thanks for your input :)

_Wazzak

[LB]

Wait, if the array has a fixed size, why does it need to by dynamically allocated, reallocated, and deallocated?

[zb0S216C]

L B wrote:

Wait, if the array has a fixed size, why does it need to by dynamically allocated, reallocated, and deallocated?

If the programmer/user decides that they want the length of the array changing, they can do so by releasing the previously allocated resources, and allocate a new block of resources that holds the desired amount of elements. It's not a vector, so it's length can't dynamically change.

Are you concealing a better solution, L B?

_Wazzak

[hamsterman]

If the programmer/user decides that they want the length of the array changing <...> it's length can't dynamically change.

As for actual suggestions, make it mimic stl containers so that you can use <algorithm> smoothly.

[LB]

@Framework: No - I simply misunderstood, I hadn't realized it wasn't like hamsterman's templated array class. I guess I hadn't been thinking straight <_>

[hamsterman]

Framework, if you intend to use dynamic memory, you'll just be writing a vector, which is less comfortable to use. You loose any good things there are about a static array. Don't do that.

About 3). You could (should) have two operators []:

T& operator[](int);
const T& operator[](int) const;

Have a member boolean "locked" and then in the first one either assert(locked==false); or if( locked ) throw something;
Such feature would be somewhat useless though..

[zb0S216C]

hamsterman wrote:

if you intend to use dynamic memory, you'll just be writing a vector, which is less comfortable to use. You loose any good things there are about a static array. Don't do that.

To clarify, I'm not using a vector. The length of the array is fixed, and the only way the change that is by reallocating the array to a different size.

hamsterman wrote:

Have a member boolean "locked" and then in the first one either assert(locked==false); or if( locked ) throw something;

Allow me to quote myself.

Framework wrote:

This has recently been deprecated in my project( a gap in the design ). What it was meant to do was protect all elements of the array from modification. This is where the deprecation came into play. When I wrote the methods that access the elements of the array, I had no way of enforcing the locking system, so I deprecated it as it became redundant.

_Wazzak

[LB]

The length of the array is fixed, and the only way the change that is by reallocating the array to a different size.

Isn't that what a vector does when it needs more capacity?

[hamsterman]

Framework wrote:

To clarify, I'm not using a vector. The length of the array is fixed, and the only way the change that is by reallocating the array to a different size.

L B wrote:

Isn't that what a vector does when it needs more capacity?

Indeed it is.

Framework wrote:

Allow me to quote myself. <...>

I know you deprecated 3). I just wanted to point out that there is a simple way to enforce the locking.

[zb0S216C]

L B wrote:

Isn't that what a vector does when it needs more capacity?

OK, maybe it's similar to a vector. However, the resize doesn't happen automatically, so it's length is fixed until it's resized. But it definitely isn't designed to be dynamic.

Hamsterman wrote:

I know you deprecated 3). I just wanted to point out that there is a simple way to enforce the locking.

I read your solution and it already throws an exception depending on the active state( I appreciate your solution, though ). I have 3 methods which return references. The first returns a reference to the first element in the array. The second returns a reference to the last element in the array. Finally, the third returns a reference to the element at the given index. Since all three return references, I have to throw an OOR exception since returning temporary objects is out of the question.

_Wazzak

[Athar]

OK, maybe it's similar to a vector. However, the resize doesn't happen automatically, so it's length is fixed until it's resized. But it definitely isn't designed to be dynamic.

That still negates any advantage a fixed length array might have had (namely requiring no allocation and deallocation).

[zb0S216C]

Athar wrote:

requiring no allocation and deallocation

Every object allocates memory whether you use new/new[ ] or not. I get where you're coming from though.

_Wazzak