FROM : Dan Crevier
DATE : Thu Nov 07 23:04:22 2002
On 11/7/02 2:58 AM, "Andrew Demkin" <<email_removed>> wrote:
> At 11:02 PM 11/6/02, Dan Crevier wrote: On 11/6/02 7:38 PM, "James
> Montgomerie" <<email_removed>> wrote:
>
>>> Note, however, that though in all the implementations I know of,
>>> &myVector.front() does return an pointer to the Vector's internal array, I
>>> don't believe it's guaranteed to by the standard. I think that a Vector can
>>> use any O(1) storage, and if it did (or changed to in the future) use
>>> something other than a plain array, your code would break (because, for
>>> example, the second item is not guaranteed to be adjacent in memory to the
>>> first).
>>>
>> Actually, the standard does guarantee that it's contiguous in memory, but you
>> aren't guaranteed that the iterator is a simple pointer. For example,
>> Metrowerk's vector implementation does not use a simple pointer in the latest
>> version. That's you need to use &myVector[0]. See Scott Myer's More Effective
>> STL for more info. It's a great book.
>>
> <pedantically>
>
> The original standard did not make the guarantee of contiguous memory, but it
> has been ammended for the next version to make this guarantee and no common
> implementations are known to be in conflict.
>
> It's also true that the preferred syntax is &myVector[0], but this has nothing
> to do with iterators potentially being non-pointer types. Just as operator[]
> returns a reference, so does front(). Iterators do not enter the picture in
> either case. The real motivation for using operator[] is that there's greater
> likelihood of a compiler error for sequence types such as 'list' which do not
> make the contiguous memory guarantee.
>
> </pedantically>
You're right. I was reading myVector.begin() for some reason. A lot of
people have used &myVector.begin(), which will work if your STL
implementation uses raw pointers for vector iterators.
Dan
_______________________________________________
cocoa-dev mailing list | <email_removed>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
DATE : Thu Nov 07 23:04:22 2002
On 11/7/02 2:58 AM, "Andrew Demkin" <<email_removed>> wrote:
> At 11:02 PM 11/6/02, Dan Crevier wrote: On 11/6/02 7:38 PM, "James
> Montgomerie" <<email_removed>> wrote:
>
>>> Note, however, that though in all the implementations I know of,
>>> &myVector.front() does return an pointer to the Vector's internal array, I
>>> don't believe it's guaranteed to by the standard. I think that a Vector can
>>> use any O(1) storage, and if it did (or changed to in the future) use
>>> something other than a plain array, your code would break (because, for
>>> example, the second item is not guaranteed to be adjacent in memory to the
>>> first).
>>>
>> Actually, the standard does guarantee that it's contiguous in memory, but you
>> aren't guaranteed that the iterator is a simple pointer. For example,
>> Metrowerk's vector implementation does not use a simple pointer in the latest
>> version. That's you need to use &myVector[0]. See Scott Myer's More Effective
>> STL for more info. It's a great book.
>>
> <pedantically>
>
> The original standard did not make the guarantee of contiguous memory, but it
> has been ammended for the next version to make this guarantee and no common
> implementations are known to be in conflict.
>
> It's also true that the preferred syntax is &myVector[0], but this has nothing
> to do with iterators potentially being non-pointer types. Just as operator[]
> returns a reference, so does front(). Iterators do not enter the picture in
> either case. The real motivation for using operator[] is that there's greater
> likelihood of a compiler error for sequence types such as 'list' which do not
> make the contiguous memory guarantee.
>
> </pedantically>
You're right. I was reading myVector.begin() for some reason. A lot of
people have used &myVector.begin(), which will work if your STL
implementation uses raw pointers for vector iterators.
Dan
_______________________________________________
cocoa-dev mailing list | <email_removed>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
| Related mails | Author | Date |
|---|---|---|
| Arthur Clemens | Nov 6, 10:46 | |
| Clark S. Cox III | Nov 6, 14:14 | |
| Arthur Clemens | Nov 6, 23:42 | |
| James Montgomerie | Nov 7, 04:38 | |
| Dan Crevier | Nov 7, 06:50 | |
| Dan Crevier | Nov 7, 08:02 | |
| Andrew Demkin | Nov 7, 11:58 | |
| Clark S. Cox III | Nov 7, 14:15 | |
| Clark S. Cox III | Nov 7, 14:17 | |
| Clark S. Cox III | Nov 7, 14:20 | |
| Dan Crevier | Nov 7, 23:04 | |
| Chris Hanson | Nov 7, 23:14 | |
| Clark S. Cox III | Nov 8, 14:30 |






Cocoa mail archive

