boost::array<char,7> buf = {'a','b','c','d','e','f','g'};
...
...
std::cout << buf.data() + 5;
It's display: fg
How to understand it?
buf.data() + 5
Thanks
buf.data() seems to return a pointer to the internal array buffer in question.
From there, standard pointer arithmetic applies, and you see the 6th character onwards in the std::cout.operator<< call.
buf.data() is defined to return a pointer to the first element of the array, and the elements in a Boost.Array are defined to be contiguous.
So buf.data() + 5 will be a pointer to the element (in this case, character) of the array.
You could also write &buf[5] and get the same pointer.
Note that in the code above:
std::cout << buf.data() + 5;
you are attempting to print the value of the pointer, not the character it points to.
Related
So i have a class in which there is a shared_ptr declared as following
std :: shared_ptr< T > dyn_arr{ new T[ dyn_arr_max_size ], std :: default_delete< T[] >() };
This points to the dynamic array of some size.
I also implemented an iterator for it. Inside this iterator there is a ++ overloaded operator. Now when i get
shared_ptr<T> ptr_iter= dyn_arr;
for example it will work for the first one or two elements. After that it does not iterate properly. Also i notices the following:
For example my ptr_iter is address ABDC0 for ptr_iter.get() in the beginning
After doing
ptr_iter = std :: make_shared<T>( *(ptr.get() + 1 ) );
or
ptr_iter = std :: make_shared<T>( ptr.get()[1] );
ptr_iter.get() will point to some other address now like SDBC instead of pointing to ABDC4 for integers for example. Can someone please explain me why is this happening???
I need to be able to do ptr_iter = make_shared( ptr_iter.get() + 1 ); somehow instead of ptr_iter = make_shared( *(ptr_iter.get() + 1) );
std::make_shared allocates new memory, which you don't want. To solve this problem just use the constructor of std::shared_ptr and pass the adress of the element in the array. However, std::shared_ptr attempts to deallocate as soon as the reference count falls to zero, and you will call delete on an element of the array. That's why you'll need to pass a custom delete which does nothing:
std::shared_ptr<int> ptr_iter{dyn_arr.get() + 1, [](int* pi) {}};
// ^-- Custom deleter does nothing
Example in a loop:
for (int i = 0; i < 9; ++i) {
std::shared_ptr<int> ptr_iter{dyn_arr.get() + i, [](int* pi) {}};
std::cout << *ptr_iter.get() << std::endl;
}
However, I strongly recommend to not do this in other cases than in your assignment!
i have declared a map below using stl and inserted some values in it.
#include<bits/stdc++.h>
int main()
{
map<int,int> m;
m[1]=1;
m[2]=1;
m[3]=1;
m[4]=1;
m[5]=1;
m[6]=1;
for(auto it=m.begin();it!=m.end();)
{
cout<<it->first<<" "<<it->second<<endl;
it=it++;
}
return 0;
}
When i executed the above written code it ended up in an infinite loop. Can someone tell me why it does so?
I am incrementing the value of iterator it and then it gets stored in it which should get incremented next time the loop is executed and eventually it should terminate normally.Am i wrong?
The bad line is it = it++;. It is undefined behavior! Because it is not defined, when it is increased, in your case it is increased before the assingment to itsself again, that the value of it before it is increased is assigned to it again and so it keeps at the first position. The correct line would be it = ++it; or only ++it;/it++;, because it changes itsself.
Edit
That is only undefined with the builtin types, but in here that is defined by the source-code of the map in the stl.
If you try doing something similar with an int, you'll get a warning:
int nums[] = { 1, 2, 3, 4, 5 };
for (int i = 0; i < sizeof nums / sizeof *nums; ) {
cout << nums[i] << '\n';
i = i++;
}
warning: operation on 'i' may be undefined [-Wsequence-point]
However, when you're using a class (std::map::iterator) which has operator overloading, the compiler probably isn't smart enought to detect this.
In other words, what you're doing is a sequence point violation, so the behavior is undefined behavior.
The post-increment operation would behave like this:
iterator operator ++ (int) {
auto copy = *this;
++*this;
return copy;
}
So, what happens to your increment step is that iterator it would get overwritten by the copy of its original value. If the map isn't empty, your loop would remain stuck on the first element.
The program below is outputting unexpected use_count() value when shared pointer is printed using iterator de-reference of std::vector:
#include<iostream>
#include<memory>
#include<vector>
class A;
typedef std::shared_ptr<A> sharedPtr;
typedef std::vector<sharedPtr> sharedPtrVect;
typedef sharedPtrVect::const_iterator vectItr;
class A
{
public:
A(int inp): m_Val(inp) { /*std::cout << "*** A ctor called: " << m_Val << " ***" <<std::endl;*/ }
~A() { /*std::cout << "### A dtor called: " << m_Val << " ###" <<std::endl; */}
int getVal() const { return m_Val; }
private:
int m_Val;
};
int main()
{
sharedPtrVect myVect1, myVect2;
vectItr myVectItr;
std::shared_ptr<A> tmpPtr;
for(int i = 1 ; i <= 5 ; i++ ) {
std::cout << "Pushed back: " << i << std::endl;
tmpPtr = std::make_shared<A>(i);
myVect1.push_back(tmpPtr);
}
myVectItr = myVect1.begin();
for( ; myVectItr != myVect1.end() ; ++myVectItr) {
std::cout << "-----------------------------" << std::endl;
std::cout << "Element number: " << (*myVectItr).get()->getVal() << std::endl;
std::cout << "Element use count: " << (*myVectItr).use_count() << std::endl;
std::cout << "-----------------------------" << std::endl;
}
return 0;
}
The output of the above code is:
Pushed back: 1
Pushed back: 2
Pushed back: 3
Pushed back: 4
Pushed back: 5
-----------------------------
Element number: 1
Element use count: 1
-----------------------------
-----------------------------
Element number: 2
Element use count: 1
-----------------------------
-----------------------------
Element number: 3
Element use count: 1
-----------------------------
-----------------------------
Element number: 4
Element use count: 1
-----------------------------
-----------------------------
Element number: 5
Element use count: 2 //I am not sure why or how this is 2?
-----------------------------
I don't understand how the use_count() for the last vector element is 2. Shouldn't it be 1 like others? I am not creating any copies of the shared pointer stored in the last element of the vector.
What am I missing here?
EDIT: I have good experience in C++98, but less experience in C++11.
Shouldn't it be 1 like others? I am not creating any copies of the shared pointer stored in the last element of the vector. What am I missing here?
But you are creating a copy. You push_back() from tmpPtr. push_back() puts a copy of its argument into the vector, unless you tell it to move instead. (More on that later!)
Therefore, what happens for all but the last element is this:
tmpPtr holds the only reference to the shared resource
You push_back() a copy, so the copy-constructor of shared_ptr increments the use count to 2
You then assign the next element to tmpPtr, releasing the reference to, and thereby decrementing the use count of, the previous element's resource.
But, of course, there is no subsequent assignment on the last iteration of the loop. So, at the point of printing, tmpPtr is still in scope, and it retains a reference to the last resource that was allocated. Hence the 1-higher refcount on the last element. This seems perfectly expected to me. ;)
To see the results you expected, you need to either destroy tmpPtr after you copy it but before you print, or simply avoid the copy from it in the first place. The former could be done by moving its declaration into the for loop, as SirGuy pointed out in the comments.
However, clearly, the latter is superior. How do we do that? Well, C++11 lets us move instead. So, you could emplace_back( std::move(tmpPtr) ), in which the move will cast to an rvalue and thus invoke the move-constructor of the vector element. This will cause tmpPtr to release its reference upon being moved into the vector, effectively ensuring the use count is always 1. This leaves tmpPtr (like any moved-from object) in a valid-but-unspecified state, i.e. useful only to be reassigned-to.
(Note: push_back() will achieve the same thing, but I generally prefer using emplace_back() wherever possible, as it's more efficient in other situations, so it's a better default.)
Of course, you can then combine both of these: declare tmpPtr within the scope of the for loop, and move from it. However... you don't even need tmpPtr at all! It does not appear to serve any useful purpose. So, you could just not use it, and instead directly emplace_back() the result of make_shared(). Because the return value thereof will be an rvalue, it will implicitly be moved into the vector; no cast by std::move is needed.
Is it possible to walk a std::forward_list, incrementing an iterator, until said interator is null? The old-fashioned way...
In the following example, I create a print() function.
#include <iostream>
#include <forward_list>
void print(std::forward_list<int>::iterator fl_it, std::forward_list<int>::iterator e) {
while (fl_it != e) {
std::cout << *fl_it << ' ';
++fl_it;
}
std::cout << std::endl; //-> 1 2 3
}
int main() {
std::forward_list<int> fl = {1, 2, 3};
print(fl.begin(), fl.end());
std::cout << std::endl;
return 0;
}
Notice how passing an iterator pointing to the end of the list is necessary, so that we know when to stop walking.
What I want to do is simply pass an iterator to the head of the list, and step along until there are no more elements, like so:
void print(std::forward_list<int>::iterator fl_it) {
while (fl_it != nullptr) {
std::cout << *fl_it << ' ';
++fl_it;
}
std::cout << std::endl;
}
My compiler doesn't like this fl_it != nullptr business.
My first inclination was to look for a method to check if the iterator is null, and references the end of the list. Sadly, such a method does not exist.
Any ideas?
You don't.
std::forward_list is a standard library container. Like all containers, it goes from begin to end. There are no "null" iterators. Operations therefore are on a range of iterators.
Note that the Range TS proposal intends to allow "sentinel" types instead of requiring end iterators. A single sentinel could compare equal to the end iterator of any range. So forward_list could indeed be updated to have such a value.
But it still wouldn't be a "null" iterator.
You should realise that the iterator object is not exactly a pointer. It is an object and it represents the position of an item in a datastructure.
Also incrementing the end iterator does not result in a null iterator. It is undefined behavior. Look at Can an STL map iterator go out of bounds through incrementing?
The iterator is not null when at the end of the list, instead it is equal to the list's end iterator fl.end(). So both iterators need to be passed to the function.
The internal implementation of the iterator depends on the STL library used, for std::forward_list its interface is such that it fulfills the ForwardIterator concept: http://en.cppreference.com/w/cpp/concept/ForwardIterator .
In visual studio 2013, I created a std::vector and has store some strings in it. Then I want to make a copy of some string in the vector and append them to the end (suppose to move them to the end, after insert will do erase), but using insert method, I saw only empty strings at the end, very strange. I reproduced it with some simple test code,
std::vector<std::string> v;
std::string s = "0";
for (int i = 0; i < 7; ++i)
{
s[0] = '0' + i;
v.push_back(s);
}
v.insert(v.end(), v.begin(), v.begin() + 3);
for (std::string& s : v)
std::cout << "\"" << s.c_str() << "\" ";
What I get there is
"0" "1" "2" "3" "4" "5" "6" "" "" ""
I debugged into insert method, inside _Insert(..) method of vector class, it did some reallocating of memory, memory move/move and so on.
The first _Umove call move all 7 strings to new allocated memory, I think the std::move is invoked, the old memory has some empty string left.
Then the _Ucopy method try copy 3 items, but from old memory, as a result 3 empty string is attached.
There is another _Umove call, I am not sure what's that for. After all thes, the old memory is freed and new memory attached to the vector.
Using a scalar type like int does not make wrong output, because the memory is copied, no std::move is invoked.
Am I doing something wrong here, or is it a MS Visual Studio's STL bug?
From this std::vector::insert reference:
Causes reallocation if the new size() is greater than the old capacity(). If the new size() is greater than capacity(), all iterators and references are invalidated
[Emphasis mine]
You are adding elements to the vector while iterating the vector using iterators. Since this can cause the vector to be reallocated your iterators will be invalidated. That will lead to undefined behavior.