If an index supplied is invalid, what's wrong with throwing std::out_of_range?The idea is that an index is not an integer. 1 or 5 may not be valid indexes. Only an iterator is a valid index. That was the idea anyway.
If an index supplied is invalid, what's wrong with throwing std::out_of_range?The idea is that an index is not an integer. 1 or 5 may not be valid indexes. Only an iterator is a valid index. That was the idea anyway.
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
Oh, I will be doing that alright.
You are putting the burden of constant correctness on the wrong code! You can't protect the contents of an object by making it merely difficult, and you can't make it impossible.
Also, returning an integer versus returning an object is irrelevant to your 'const' concerns if you are going to provide a 'difference' function and an ability to convert an 'iterator' to an 'const_iterator'.
Soma
I realized.
But I never claimed to make any difference function to convert between const_iterator/iterator.Also, returning an integer versus returning an object is irrelevant to your 'const' concerns if you are going to provide a 'difference' function and an ability to convert an 'iterator' to an 'const_iterator'.
I was admitting I was planning one to convert to a STL iterator.
A 'difference' function to obtain the mathematic distance between two instances could be written--unless you also have changed the meaning of '+' and '==', and if I can't obtain an 'const_iterator' from an 'iterator' your interface is useless and horribly broken because I couldn't call 'const_iterator' code from any 'iterator' code.But I never claimed to make any difference function to convert between const_iterator/iterator. I was admitting I was planning one to convert to a STL iterator.
Soma
Your fears are, fortunately, unfounded.
A const_iterator can be built from an iterator.
Initially, I HAD a Difference function that returned the distance between the two iterators. It was a friend function and subtracted the pointers directly.
But I've changed the behaviour now, more to STL like.
Alright, the first test is a success! I have successfully implemented a custom iterator and re-written a stand-alone Replace function to use iterators and std::copy_backward and std::copy.
More tests to be done, of course.
Last edited by Elysia; 05-15-2008 at 10:54 AM.
So I imagined.Your fears are, fortunately, unfounded.
Now if we could just break you of the habit of sticking a 'C' in front of things...But I've changed the behaviour now, more to STL like.
Congratulations! Admit it: now that your coding with it, the STL, you love it. ^_^Alright, the first test is a success! I have successfully implemented a custom iterator and re-written a stand-alone Replace function to use iterators and std::copy_backward and std::copy.
More tests to be done, of course.
Soma
Now way
Classes are classes and therefore must begin with C
Sure, it's good to be able to use STL, but I'm still going to provide interfaces around them in my classes!Congratulations! Admit it: now that your coding with it, the STL, you love it. ^_^
Now I'm going to have to overload the std::backward_copy and std::copy, and that probably means the second stage of the plan, because the current implementation only works if the buffer does not need to be resized...
Last edited by Elysia; 05-15-2008 at 11:04 AM.
That is how they should work! I don't know about you, but if I swapped the bits around I would want it to warn/crash/raise an exception by default, not just push additional data onto the string. I might make a programming mistake. Just grab a 'back_insert_iterator<your_string<?>>' with 'back_inserter(instance)'. (Assuming you have the relevant 'push_back()' method.)Now I'm going to have to overload the std::backward_copy and std::copy, and that probably means the second stage of the plan, because the current implementation only works if the buffer does not need to be resized...
Soma
But... it should work with std::copy even if there's no space! It calls the overloaded class operators! Darn!
More debugging needed -_-
Or maybe it really doesn't work... I'll just have to find out.
EDIT: Duh, of course it doesn't!
It does the work via iterators, not the string class's operators!
Last edited by Elysia; 05-15-2008 at 11:12 AM.
Er... what? O_oBut... it should work with std::copy even if there's no space!
Soma
Still unused to iterators and std::XXX family...
Of course it's an error.
I need to allocate proper space first or forward operator * calls to the string class!
At least read how std::copy is supposed to work, and realize that you are doing something that nobody expects. In the standard algorithm nothing is supposed to be resized; it's stated in one of the preconditions.
So correct copying would be:There is enough space to hold all of the elements being copied. More formally, the requirement is that [result, result + (last - first)) is a valid range. [1]
I assume they do it this way so as to allow the containers to manage their own memory, or if we apply Occam's razor, std::copy does little more than perform assignments in a loop. It shouldn't be allocating buffers for anything because that makes copying more work than it needs to be. Do you want to throw exceptions when you copy?Code:vector<o> foo; // ... use foo ... list<o> bar( foo.size( ) ); copy( foo.begin( ), foo.end( ), bar.begin( ) );
So do it this way, yes?
Yes. I have to make sure to resize the string to proper size. Only, it invalidates all iterators, which can be pretty annoying. I'll have to manually fix that until I can fix the new implementation.
BTW, the TYPE_FRIENDLY macro only seems to work for VS (at least I think it does - I get no compile error). But for GCC, it does not.
But there is a special iterator, that is produced by back_inserter. So copy could also ask the receiver to make more room:
So, perhaps Elysia needs something akin to the back_inserter?Code:vector<o> foo; //.. use foo ... //list<o> bar( foo.size( ) ); //not necessary copy( foo.begin( ), foo.end( ), back_inserter(bar) );
I might be wrong.
Quoted more than 1000 times (I hope).Thank you, anon. You sure know how to recognize different types of trees from quite a long way away.
