closed_account::vector_ptr, closed_account::unique_vector_ptr code review

[Naughty Albatross]

Hello,
I have finished a smart pointer named closed_account::vector_ptr. I have also finished a smart pointer named closed_account::unique_vector_ptr. The smart pointer cannot be invalidated in any situation.

Additionally, when you try to access a vector element via this smart pointer that is outside the main vector array, the pointer will tell the vector to adjust the size of the vector so that the element you are accessing becomes valid.

For example (std::vector_ptr) :

std::vector<int> first;
for(size_t i = 0; i <= 5; i++) first.push_back(i);

closed_account::vector_ptr<int> p(first);

p[5] = 5; // Ok

p[6] = 6; // The pointer p tells "first" to adjust so that p[6] becomes valid. Try removing this line

first.at(6) = 60; // Oops, the assert message is here

p[10] = 10; // The pointer p tells "first" to adjust so that p[10] becomes valid

p += 3;

p[-2] = 20; // Ok

p[-5] = -2; // The pointer p tells "first" to adjust so that p[-5] becomes valid

p[100000] = 999999; // This is crazy, but the program is surprisingly fine!!! No undefined behavior here

p[-100000] = 999999; // This is also crazy too, but the program is surprisingly fine!!! No undefined behavior here

p.getvector().push_back(199);

Does it sound smart?
Is it a good idea that a pointer to a vector element can be never invalidated?

:D

[cire]

Does it sound smart?

Not solving a non-problem? Not so much.

What's the relationship between "int3264_t" and std::size_t, std::vector::size_type and the range of valid indexes for a std::vector?

When t+i overflows on line 34, is that really a sensible thing to do?

Doesn't work for contained types without a default constructor.
Doesn't work for constant vectors.
Is not const correct.
Undefined behavior. (You cannot insert your type into the std namespace.)
What happens when it outlives the vector it refers to?

[Z e r e o]

Free advice of the day, use the edit button. That is all.

[1vD3vCM9]

Z e r e o meant that you can edit a single post and put all your questions, rather than posting question per post

[lockandstrike]

I would say to try to understand Z e r e o's tip and then I'd suggest moving this post to the C++ General Programming sections since it feels more adequate there.

About the code itself, I haven't got the chance to properly look at it and try to understand it but firstly I don't see the neccessity of creating what you're saying, seems redundant; secondly, I'm not sure about this part, but defining one of your own classes in the std namespace sounds like bad practice.

[cire]

std::size_t and std::vector::size_type are unsigned. I am looking for the signed one.

You failed to address the relevant portion of the question:

cire wrote:

What's the relationship between "int3264_t" and std::size_t, std::vector::size_type and the range of valid indexes for a std::vector?

It also tied into the question that followed about overflow.

I now know what you mean. Changing std::vector<T> &v to std::vector<T> *v now.

That doesn't begin to address the issue, so apparently you didn't get the meaning.

[edit: It does not allow the following to compile, but it is trivial to reproduce the problem illustrated.]
Your code allows the following to compile without complaint (assuming one makes the necessary changes to allow it to compile at all.)

int main() {
    std::vector_ptr<int> vp((std::vector<int>)(10));
    *vp = 34;
}

Is my class not qualified (good) and standard enough to be able to live in this very standard "namespace"?

Your class evokes undefined behavior (as I believe I've already mentioned) by being in the standard namespace. That should be enough reason to avoid it.

[NoXzema]

To be honest, I'm not really sure what you mean.

std::size_t is used as a means of saying, "This type can hold the size of any valid object". It's not necessarily 32-bit on x86 systems and it's not necessarily 64-bit on x86_64 systems. If it's less, then no problem. If it's more, you have a problem. The point is to keep it abstract and let the compiler handle that size for you.

p[-5] = -2;

Oh my noodliness, it's hideous. This is blasphemous to C/++ users who would expect this to mean you're looking 5 elements behind the beginning of the array, not adjusting the entirety of the array which is a optimization and logistic nightmare. I would *prefer* my program to crash if I were to ever do something like this in an invalid way since it means I'm doing something wrong and more than likely stupid.

Is my class not qualified (good) and standard enough to be able to live in this very standard "namespace"?

Not even in the ballpark. Not sure what you mean by "standard enough" when you have no standard. Your class is a wrapper over a standard object that muddies the standard namespace for a nonsensical reason. This seems like a lopsided version of std::vector<T>::iterator which you ironically use in your class.

Does it sound smart? Is it a good idea that a pointer to a vector element can be never invalidated?

No. Validity is defined as something that is valid. Something being invalid means something is wrong and needs to be fixed. Ignoring the implementation, the concept of this is completely broken in that it only covers up problems and will lead to horrible design and implementation if used.

In a "safe" implementation of the standard, it might work around logical errors in order to prevent the program from going down, while logging such occurrences so the programmer can know where to look. That doesn't make those logical errors correct. They need to be fixed regardless of whether or not the implementation can handle it.

[Thomas1965]

It is undefined behavior to add declarations or definitions to namespace std or to any namespace nested within std, with a few exceptions noted below

http://en.cppreference.com/w/cpp/language/extending_std

[E0p9LyTq]

What do you think?

ANYONE who even thinks about using your garbage is looking for trouble.

[E0p9LyTq]

Seek professional mental health help.

[NoXzema]

Your smart pointers aren't smart. They have literally no purpose. It's just a iterator wannabe that does some ridiculously hideous behind-the-scene allocations that an underlying vector actually does, breaking it off into even smaller more ridiculous fragmented allocations, in a conceptually broken attempt to prevent invalid references to an element. You're not solving anything.

Is there anyway to rewrite my smart pointers in a more standard way?

That could mean literally anything. In any situation, you shouldn't populate the std namespace in the way you are unless it's part of the C++ standard library, if that's what you're getting at. There's zero point in doing it, it does nothing but complicate things.

EDIT: Noticed you moved it out of the std namespace.

[coder777]

Your 'smart pointer' is not a smart pointer. Instead it is a weird extension of the vector which is basically unusable due to the member t.

If you want something that shows the behavior of your example above use a std::map.

[Z e r e o]

Why? With closed_account::vector_ptr and with closed_account::unique_vector_ptr, one can literally safely access any vector element (even though it may be out of bounds) with no range limit.

That is exactly what he is saying has no purpose. I personally can't think of a single reason why you would want that as a "feature" (Access any element even out of bounds). All you are doing is covering up a run-time error and allowing the application to fail silently in the background instead of crashing.

This is not something you want to do...

You are probably going to ask why so I will try to explain it to you, though bear with me it has been a long night ;). When all you are doing is hiding the run-time exception and then continuing on with execution of the program the programmer has no idea that he/she made a logical error in the code (Trying to access an element out-of-ranges).

Instead they will think that the code is working as it should be, that is until something in their code breaks because of that normally out-of-range element. And that will happen trust me because they are not accessing the element they thought they would be. Instead they are doing whatever they wanted to do on a new permanent element that they don't even know about which will just cause even more errors down the line(Not to mention all the other new elements in the vector you added between the end of "real" vector and the out-of-range element).

Now in the case of a normal std::vector the programmer would know pretty quickly they made the logical error because of the out-of-bounds exception, but in your solution that logical error gets hidden and will be harder to notice and find.

Seriously just think about the main "problem" you are trying to solve (Make it so that it doesn't matter what element you try and access on a vector) for a little bit. Can you name a single instance where accessing an element that is out-of-range on a std::vector is not a logical error?

You can't because you never should want or need to access an element that you know is out-of-range, other than that there is only the obvious error where you didn't know it was out-of-range which is even worse (As I described above).

All in all that is what NoXzema means when he says that it has no point to it. In fact I would go even further and say that not only does it try and solve a problem that isn't there, it also introduces new problems like silently squashing run-time exceptions and continuing execution in a bad state.

Hope I didn't do to bad of a job trying to explain this, if you didn't understand anything (Sorry been a long day so not sure if I worded things correctly) just let me know and I will try and explain better.

[BHX]

That is exactly what he is saying has no purpose. I personally can't think of a single reason why you would want that as a "feature" (Access any element even out of bounds).

This is why he is viewed as trolling because whether he is a 1 year beginner or a 8 year experienced programmer; the concept of out of bounds is basic. That is ran into the ground when you are learning arrays and vectors and why it is bad to access something that isn't there. I just can't figure how the admin hasn't stepped in by now over all these ridiculous posts.