Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   C++ (http://www.velocityreviews.com/forums/f39-c.html)
-   -   Pointer arithmetic (http://www.velocityreviews.com/forums/t455050-pointer-arithmetic.html)

flopbucket 06-30-2006 01:00 PM

Pointer arithmetic
 
Hi,

Quick question regarding pointer math. I have a simple container class
- something like std::vector<> - that I am implementing.

My iterators are implemented as pointers:

template<class T> class myContainer
{
typedef T * iterator;
typedef const T* const_iterator;

......
};

My question is, for implementing something like distance(), I have
somthing like:

unsigned long distance(myContainer<T>::iterator& a,
myContainer<T>::iterator& b)
{
return static_cast<unsigned long>(b-a);
}

This works, and I think it must always work, but I wanted to check here
with some of the experts.

Also, do you see a better way of doing this?

Thanks


Bo Persson 06-30-2006 01:30 PM

Re: Pointer arithmetic
 

"flopbucket" <flopbucket@hotmail.com> skrev i meddelandet
news:1151672446.315712.236870@m73g2000cwd.googlegr oups.com...
> Hi,
>
> Quick question regarding pointer math. I have a simple container
> class
> - something like std::vector<> - that I am implementing.
>
> My iterators are implemented as pointers:
>
> template<class T> class myContainer
> {
> typedef T * iterator;
> typedef const T* const_iterator;
>
> .....
> };
>
> My question is, for implementing something like distance(), I have
> somthing like:
>
> unsigned long distance(myContainer<T>::iterator& a,
> myContainer<T>::iterator& b)
> {
> return static_cast<unsigned long>(b-a);
> }
>
> This works, and I think it must always work, but I wanted to check
> here
> with some of the experts.


It seems pretty ok, except that you don't (portably) know the size of
unsigned long. Also, if you want to compute distance(b, a) you need a
signed type. Perhaps std::ptrdiff_t ?

>
> Also, do you see a better way of doing this?


The std::distance is already there, and works well for pointers.


Bo Persson



flopbucket 06-30-2006 01:43 PM

Re: Pointer arithmetic
 

Bo Persson wrote:
> >
> > Also, do you see a better way of doing this?

>
> The std::distance is already there, and works well for pointers.
>
>


Yes, that's true. The thing here is that we are developing for an
embedded platform. We have a C++ compiler but the vendor supplies no
C++ libraries, and a highly stripped version of the standard C lib. So
we are trying to implement just a few basic containers and such.

Thanks for the reply.


Michiel.Salters@tomtom.com 06-30-2006 02:57 PM

Re: Pointer arithmetic
 

flopbucket wrote:

> The thing here is that we are developing for an
> embedded platform. We have a C++ compiler but the vendor supplies no
> C++ libraries, and a highly stripped version of the standard C lib.


Probably stating the obvious for quite a few people here, but why not
buy
such a library? IIRC, Dinkumware has such a lib.

HTH,
Michiel Salters


flopbucket 06-30-2006 03:55 PM

Re: Pointer arithmetic
 

Michiel.Salters@tomtom.com wrote:
> flopbucket wrote:
>
> Probably stating the obvious for quite a few people here, but why not
> buy
> such a library? IIRC, Dinkumware has such a lib.


Yes, that certainly was an option. We looked at a few freely available
ones, such as STLport, but they were too large, needed a more complete
C library then the platform provides, etc. We discussed possibly
purchasing one - we found at least one "mini" STL product for embedded
environments, but in the end, the decision was to roll our own minimal
implementation for the time being (part of this had to do with special
memory constraints, non-standard platform API for allocation, etc.,
although I suppose we could have made a custom allocator to solve most
of this).

The group decided they just wanted a few containers (vector, string,
list) so that's how I ended up doing this work. For the parts
implemented, it matches the standard so hopefully in the future the
custom code can be switched out if our platform vendor ever ships a
more complete library. And while I was outside the decision loop, I
must admit I have enjoyed this work as I got a chance to dig into some
implementation details and get a better understanding of the STL.

I have not looked too closely at the Dinkumware library, perhaps it
could have fit our needs. However, we really needed pretty much
standalone containers. We didn't want to have to pull in lots of other
code and dependencies or modify the supplied 3rd party code. For
example, having operator<< defined for std::string would require us to
remove it since that would depend on iostreams, and there is no way we
could build that given our very limited C library (nor would we want
to, there is no display or anything on our device).



All times are GMT. The time now is 06:12 PM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.