[smart-ptr][containers] type of the operator[] index
Hi, which is the correct type used as index of operator[]. scoped_array uses std::ptrdiff_t. Others containers use std::size_t. The standard uses also std::size_t, but in 13.6 Built-in operators 13 For every cv-qualified or cv-unqualified object type T there exist candidate operator functions of the form T* operator+(T*, std::ptrdiff_t); T& operator[](T*, std::ptrdiff_t); T* operator-(T*, std::ptrdiff_t); T* operator+(std::ptrdiff_t, T*); T& operator[](std::ptrdiff_t, T*); we see again std::ptrdiff_t. When using an index to move from a scoped_array to another container which should be the type if the index? Best, Vicente
On Sunday, December 04, 2011 17:46:02 Vicente J. Botet Escriba wrote:
Hi,
which is the correct type used as index of operator[]. scoped_array uses std::ptrdiff_t. Others containers use std::size_t.
The standard uses also std::size_t, but in
13.6 Built-in operators 13 For every cv-qualified or cv-unqualified object type T there exist candidate operator functions of the form T* operator+(T*, std::ptrdiff_t); T& operator[](T*, std::ptrdiff_t); T* operator-(T*, std::ptrdiff_t); T* operator+(std::ptrdiff_t, T*); T& operator[](std::ptrdiff_t, T*);
we see again std::ptrdiff_t.
When using an index to move from a scoped_array to another container which should be the type if the index?
In containers, there isn't any sense in negative indices since they are always relative to the beginning of the container (and there isn't any elements before the beginning). This is not true for pointers or iterators since a pointer may refer to an element in the midst of a valid range. Smart pointers might depart from raw pointers in this regard because they also tend to point to the beginning of the range. But as I see it, they also accept ptrdiff_t to be as close to raw pointers as possible.
Le 04/12/11 18:02, Andrey Semashev a écrit :
Hi,
which is the correct type used as index of operator[]. scoped_array uses std::ptrdiff_t. Others containers use std::size_t.
When using an index to move from a scoped_array to another container which should be the type if the index? In containers, there isn't any sense in negative indices since they are always relative to the beginning of the container (and there isn't any elements before the beginning). This is not true for pointers or iterators since a
On Sunday, December 04, 2011 17:46:02 Vicente J. Botet Escriba wrote: pointer may refer to an element in the midst of a valid range.
Smart pointers might depart from raw pointers in this regard because they also tend to point to the beginning of the range. But as I see it, they also accept ptrdiff_t to be as close to raw pointers as possible.
Scoped_array can not take a pointer in the middle of the allocated array as its role is to delete it. Vicente
On Sunday, December 04, 2011 19:17:46 Vicente J. Botet Escriba wrote:
Le 04/12/11 18:02, Andrey Semashev a écrit :
On Sunday, December 04, 2011 17:46:02 Vicente J. Botet Escriba wrote:
Hi,
which is the correct type used as index of operator[]. scoped_array uses std::ptrdiff_t. Others containers use std::size_t.
When using an index to move from a scoped_array to another container which should be the type if the index?
In containers, there isn't any sense in negative indices since they are always relative to the beginning of the container (and there isn't any elements before the beginning). This is not true for pointers or iterators since a pointer may refer to an element in the midst of a valid range.
Smart pointers might depart from raw pointers in this regard because they also tend to point to the beginning of the range. But as I see it, they also accept ptrdiff_t to be as close to raw pointers as possible.
Scoped_array can not take a pointer in the middle of the allocated array as its role is to delete it.
Exactly.
Scoped_array can not take a pointer in the middle of the allocated array as its role is to delete it.
Exactly.
True for scoped_array. As Olaf pointed out, it would be possible to have a custom deleter for shared_array that would allow shared_array to point to the middle of an allocation. Then it seems reasonable to have shared_array::operator[] take a ptrdiff_t. It'd be weird to have shared_array and scoped_array take different types for operator[]. ptrdiff_t for both seems fine to me and size_t is demonstrably wrong for shared_array in at least one (very goofy) use case. - Rhys
On Sun, Dec 4, 2011 at 7:17 PM, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
Scoped_array can not take a pointer in the middle of the allocated array as its role is to delete it.
Let's consider shared_array then. The current implementation doesn't support sub arrays (unfortunately), but conceptually it could. -- Olaf
On Sun, Dec 4, 2011 at 5:46 PM, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
which is the correct type used as index of operator[]. scoped_array uses std::ptrdiff_t. Others containers use std::size_t.
If [-1] might be valid, ptrdiff_t makes sense. Otherwise, I'd opt for size_t.
Olaf van der Spek wrote:
On Sun, Dec 4, 2011 at 5:46 PM, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
which is the correct type used as index of operator[]. scoped_array uses std::ptrdiff_t. Others containers use std::size_t.
If [-1] might be valid, ptrdiff_t makes sense. Otherwise, I'd opt for size_t.
-1 doesn't make sense for scoped_array. It uses ptrdiff_t in order to assert that the index is nonnegative. Other containers, knowing its size, need not use ptrdiff_t because assert( index < size ) will fire when the index is (size_t)-1.
Le 04/12/11 18:14, Peter Dimov a écrit :
Olaf van der Spek wrote:
On Sun, Dec 4, 2011 at 5:46 PM, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
which is the correct type used as index of operator[]. scoped_array uses std::ptrdiff_t. Others containers use std::size_t.
If [-1] might be valid, ptrdiff_t makes sense. Otherwise, I'd opt for size_t.
-1 doesn't make sense for scoped_array. It uses ptrdiff_t in order to assert that the index is nonnegative. Other containers, knowing its size, need not use ptrdiff_t because assert( index < size ) will fire when the index is (size_t)-1.
So which will be the type used to to move from a scoped_array to another container? Vicente
Le 04/12/11 19:25, Peter Dimov a écrit :
Vicente J. Botet Escriba wrote:
So which will be the type used to to move from a scoped_array to another container?
I have no idea what you mean, sorry.
No problem. I'm analyzing this ticket https://svn.boost.org/trac/boost/ticket/5040 future.hpp in boost::thread does not compile with /clr The concerned code is typedef std::vector<registered_waiter>::size_type count_type; count_type count; // ... for(count_type i=0;i<count;++i) { locks[i]=boost::unique_lock<boost::mutex>(futures[i].future->mutex); } The question is how count_type must be defined so that we don't have portable issues. Best, Vicente
Le 04/12/11 23:37, Vicente J. Botet Escriba a écrit :
Le 04/12/11 19:25, Peter Dimov a écrit :
Vicente J. Botet Escriba wrote:
So which will be the type used to to move from a scoped_array to another container?
I have no idea what you mean, sorry.
No problem. I'm analyzing this ticket https://svn.boost.org/trac/boost/ticket/5040 future.hpp in boost::thread does not compile with /clr
With some missing declarations
The concerned code is
typedef std::vector<registered_waiter>::size_type count_type; count_type count; boost::scoped_array<boost::unique_lock<boost::mutex> > locks; std::vector<registered_waiter> futures; // ... for(count_type i=0;i<count;++i) {
locks[i]=boost::unique_lock<boost::mutex>(futures[i].future->mutex); }
The question is how count_type must be defined so that we don't have portable issues.
Best, Vicente
On Sun, Dec 4, 2011 at 2:40 PM, Vicente J. Botet Escriba < vicente.botet@wanadoo.fr> wrote:
Le 04/12/11 23:37, Vicente J. Botet Escriba a écrit :
Le 04/12/11 19:25, Peter Dimov a écrit :
Vicente J. Botet Escriba wrote:
So which will be the type used to to move from a scoped_array to another container?
I have no idea what you mean, sorry.
No problem. I'm analyzing this ticket https://svn.boost.org/trac/** boost/ticket/5040 <https://svn.boost.org/trac/boost/ticket/5040>future.hpp in boost::thread does not compile with /clr
With some missing declarations
The concerned code is
typedef std::vector<registered_waiter>**::size_type count_type; count_type count; boost::scoped_array<boost::**unique_lock<boost::mutex> > locks; std::vector<registered_waiter> futures; // ... for(count_type i=0;i<count;++i) { locks[i]=boost::unique_lock<**boost::mutex>(futures[i].** future->mutex); }
The question is how count_type must be defined so that we don't have portable issues.
I would do the narrower of the make_unsigned versions of the respective index types. In this case, I'd guess that would be std::size_t? And, maybe, cast it to std::ptrdiff_t when indexing into locks? - Jeff
On Sun, Dec 4, 2011 at 11:40 PM, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
typedef std::vector<registered_waiter>::size_type count_type; count_type count; boost::scoped_array<boost::unique_lock<boost::mutex> > locks; std::vector<registered_waiter> futures;
// ... for(count_type i=0;i<count;++i) {
locks[i]=boost::unique_lock<boost::mutex>(futures[i].future->mutex); }
The question is how count_type must be defined so that we don't have portable issues.
Is this still an issue with 1.48? Can't reproduce. Olaf
Le 05/12/11 00:48, Olaf van der Spek a écrit :
On Sun, Dec 4, 2011 at 11:40 PM, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
typedef std::vector<registered_waiter>::size_type count_type; count_type count; boost::scoped_array<boost::unique_lock<boost::mutex> > locks; std::vector<registered_waiter> futures;
// ... for(count_type i=0;i<count;++i) {
locks[i]=boost::unique_lock<boost::mutex>(futures[i].future->mutex); }
The question is how count_type must be defined so that we don't have portable issues.
Is this still an issue with 1.48? Can't reproduce.
No body said that the error has been corrected or disappeared before. Could you try to reproduce it with version 1.45 so that we are sure the error is no more present? I don't know which compiler version was used :( Best, Vicente
On Mon, Dec 5, 2011 at 1:24 AM, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
No body said that the error has been corrected or disappeared before. Could you try to reproduce it with version 1.45 so that we are sure the error is no more present? I don't know which compiler version was used :(
I'd just ask the bug reporter. Olaf
Vicente J. Botet Escriba wrote:
Le 05/12/11 00:48, Olaf van der Spek a écrit :
Is this still an issue with 1.48? Can't reproduce.
No body said that the error has been corrected or disappeared before.
The following simple program gives me an error with VS 2005 /clr and the SVN trunk, so I'd expect the issue to be valid at least for this version. #include <boost/scoped_array.hpp> int main() { boost::scoped_array< char > a; size_t i = 0; a[ i ]; }
Vicente J. Botet Escriba wrote:
No problem. I'm analyzing this ticket https://svn.boost.org/trac/boost/ticket/5040 future.hpp in boost::thread does not compile with /clr
The problem here is that the "unspecified bool type" is not a member pointer under /clr because it doesn't work. I see that I used a function pointer to avoid this problem, but apparently, function pointers can be indexed with operator[] (even though it makes no sense to do so), which results in the ambiguity being reported. This is technically a scoped_array issue, but I have no idea how to fix it, so the easiest approach is to make count_type ptrdiff_t under /clr (#ifdef _MANAGED).
Le 05/12/11 00:48, Peter Dimov a écrit :
Vicente J. Botet Escriba wrote:
No problem. I'm analyzing this ticket https://svn.boost.org/trac/boost/ticket/5040 future.hpp in boost::thread does not compile with /clr
The problem here is that the "unspecified bool type" is not a member pointer under /clr because it doesn't work. I see that I used a function pointer to avoid this problem, but apparently, function pointers can be indexed with operator[] (even though it makes no sense to do so), which results in the ambiguity being reported.
This is technically a scoped_array issue, but I have no idea how to fix it, so the easiest approach is to make count_type ptrdiff_t under /clr (#ifdef _MANAGED).
Thanks for clarifications. I will use a specific code for _MANAGEG as you suggest). Do you want I transfer the ticket to SmartPointer? Vicente
participants (6)
-
Andrey Semashev -
Jeffrey Lee Hellrung, Jr. -
Olaf van der Spek -
Peter Dimov -
Rhys Ulerich -
Vicente J. Botet Escriba