STL collection to wrap a raw pointer?

[314ccc]

I have some old code that uses very large c style arrays extensively.
I am to the point where I need to write some new methods that access
this data. Instead of passing this data as a pointer and a count, I'd
like to pass it as a const collection reference. The problem is that I
can't seem to figure out how to intiialize any of the STL collections
with the data without making a copy of the data. Is this
possible?...perhaps with a custom allocator??

Thanks in advance!!

 

[roberts.noah]

I have some old code that uses very large c style arrays extensively.
I am to the point where I need to write some new methods that access
this data. Instead of passing this data as a pointer and a count, I'd
like to pass it as a const collection reference. The problem is that I
can't seem to figure out how to intiialize any of the STL collections
with the data without making a copy of the data. Is this
possible?...perhaps with a custom allocator??

Thanks in advance!!

I would just implement a "raw collection" class that acts like an STL
container.

 

[Ben Pope]

I have some old code that uses very large c style arrays extensively.
I am to the point where I need to write some new methods that access
this data. Instead of passing this data as a pointer and a count, I'd
like to pass it as a const collection reference. The problem is that I
can't seem to figure out how to intiialize any of the STL collections
with the data without making a copy of the data. Is this
possible?...perhaps with a custom allocator??

The most STL-like way of doing it would be a pair of iterators. This
will work with arrays:


int myArray[ARRAY_SIZE];
// initialise or whatever

// Call function that takes iterators
myFunction(myArray, myArray+ARRAY_SIZE);


Then, if you do decide to "upgrade" your arrays to vectors, the
iterators semantics remain valid.

Take a look at just about anything in <algorithm>.

Ben Pope

 

[Kai-Uwe Bux]

I have some old code that uses very large c style arrays extensively.
I am to the point where I need to write some new methods that access
this data. Instead of passing this data as a pointer and a count, I'd
like to pass it as a const collection reference. The problem is that I
can't seem to figure out how to intiialize any of the STL collections
with the data without making a copy of the data. Is this
possible?...perhaps with a custom allocator??

A custom allocator won't do: the standard container classes require that
your objects support default construction, copy construction, and
assignment.

What I would do is: wrap the large c style arrays within a "smart array"
class (analogous to a smart pointer): the class (a) pretends to be an array
by overloading operator[] appropriately, (b) uses a reference count and COW
optimization internally, and (c) takes care of automatic lifetime
management. If you need this to be thread safe, be sure to have operator[]
return a proxy (otherwise the possibility of aliasing will mess things up).
This way, you can pretend that your arrays have copy semantics throughout
your code, physical copies will only be made when a logical copy is
modified, and when the last logical copy dies, the underlying c style array
gets killed. I am pretty sure something like this is already available as a
templated library. You might want to check whether boost has something like
this.


Best

Kai-Uwe Bux

 

[Kai-Uwe Bux]

I have some old code that uses very large c style arrays extensively.
I am to the point where I need to write some new methods that access
this data. Instead of passing this data as a pointer and a count, I'd
like to pass it as a const collection reference. The problem is that I
can't seem to figure out how to intiialize any of the STL collections
with the data without making a copy of the data. Is this
possible?...perhaps with a custom allocator??

A custom allocator won't do: the standard container classes require that
your objects support default construction, copy construction, and
assignment.

What I would do is: wrap the large c style arrays within a "smart array"
class (analogous to a smart pointer): the class (a) pretends to be an
array by overloading operator[] appropriately, (b) uses a reference count
and COW optimization internally, and (c) takes care of automatic lifetime
management. If you need this to be thread safe, be sure to have operator[]
return a proxy (otherwise the possibility of aliasing will mess things
up). This way, you can pretend that your arrays have copy semantics
throughout your code, physical copies will only be made when a logical
copy is modified, and when the last logical copy dies, the underlying c
style array gets killed. I am pretty sure something like this is already
available as a templated library. You might want to check whether boost
has something like this.

Oops, I misunderstood: you do not want to put various c style arrays as
elements in a vector, but you want to access the c style array as though it
was a vector. Well, you can do that already since the STL algorithms
operate on iterators. Just use pointers into the array (and past it) as
range indicators for the algorithms from the STL, and you do not need to
actually turn your array into a vector.


Best

Kai-Uwe Bux

 

[Neelesh Bodas]

(e-mail address removed) wrote:

A custom allocator won't do: the standard container classes require that
your objects support default construction, copy construction, and
assignment.

I guess not. The standard container requires that the object is
Copy-constructable (which means Copy construction and destruction) and
assignable (which means assignment). There is no requirement of
default-construction.

Eg:
class X {
X() { }
public:
X(int x) { }
X(const X&) { }
};

int main()
{
X p(7);
std::vector<X> a;
a.push_back(p);
}

The above code will work well. Observe that zero-arg constructor is
private.

 

[Kai-Uwe Bux]

I guess not. The standard container requires that the object is
Copy-constructable (which means Copy construction and destruction) and
assignable (which means assignment). There is no requirement of
default-construction.

You are right. There is no such general requirement. My memory
oversimplified the matter: what I was thinking of is covered by [20.1.4]:

The default constructor is not required. Certain container class member
function signatures specify the default constructor as a default argument.
T() shall be a well-defined expression (8.5) if one of those signatures
is called using the default argument (8.3.6).



Best

Kai-Uwe Bux