"P.J. Plauger" <pjp@dinkumware.com> wrote in message news:<3c876099$0$17039$4c41069e@reader1.ash.ops.us.uu.net>...
> "Ralf Sinoradzki" <r_sinora@informatik.uni-kl.de> wrote in message news:3C86B668.5080807@informatik.uni-kl.de...
>
> > vector stores things in a contigous block of memory.
> > Why do you use begin() ?
> > I'd use something like old_c_function(&fred[0],fred.size());
> > This is guaranteed to work in my opinion.
>
> Uh, no it's not, unless fred is const. If the string is empty
> and non-const, fred[0] is an invalid expression.

But in this case, fred is a vector.  If fred.size() == 0, is &fred[0] valid?

Perhaps this should be written:

old_c_function(fred.size()?&fred[0]:0, fred.size());

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Matt Seitz" <mseitz@yahoo.com> wrote in message news:8e91e363.0203081349.25d6c5c0@posting.google.com...

> > > vector stores things in a contigous block of memory.
> > > Why do you use begin() ?
> > > I'd use something like old_c_function(&fred[0],fred.size());
> > > This is guaranteed to work in my opinion.
> >
> > Uh, no it's not, unless fred is const. If the string is empty
> > and non-const, fred[0] is an invalid expression.
>
> But in this case, fred is a vector.  If fred.size() == 0, is &fred[0] valid?

No.

> Perhaps this should be written:
>
> old_c_function(fred.size()?&fred[0]:0, fred.size());

Yup, that's the sort of thing you have to do.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Hi,

Eric Hopper wrote:
> I used to have code like this reasonably often:
>
> void old_c_function(int *array, size_t len);
>
> void cpp_function()
> {
>    vector<int> fred;
>
>    fred.push_back(5);
>    fred.push_back(12);
>    old_c_function(fred.begin(), fred.size());
> }

vector stores things in a contigous block of memory.
Why do you use begin() ?
I'd use something like old_c_function(&fred[0],fred.size());
This is guaranteed to work in my opinion.

regards, Ralf

P.S: A second valid solution may be:
old_c_function(&*fred.begin(),fred.size()); ...

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Ralf Sinoradzki" <r_sinora@informatik.uni-kl.de> wrote in message news:3C86B668.5080807@informatik.uni-kl.de...

> vector stores things in a contigous block of memory.
> Why do you use begin() ?
> I'd use something like old_c_function(&fred[0],fred.size());
> This is guaranteed to work in my opinion.

Uh, no it's not, unless fred is const. If the string is empty
and non-const, fred[0] is an invalid expression.

> P.S: A second valid solution may be:
> old_c_function(&*fred.begin(),fred.size()); ...

That's invalid for an empty string even if it's const.

I'm sensitive to these issues because we just finished doctoring
up our library for optional thorough iterator checking, and I had
to eliminate about a dozen expressions like this from our library.
The error checking was catching them even though they happen to
do the right thing with our version of basic_string.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

> > old_c_function(&*fred.begin(),fred.size()); ...
>
> That's invalid for an empty string even if it's const.

If it's const, it's also invalid for a non-empty string.

24p4:
"the result of the expression *i (for constant iterator i) cannot be
used in an expression where an lvalue is required."

--
Dag Henriksson


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

On Thu, 21 Feb 2002 10:04:19 CST, Nicola Musatti <objectway@divalsim.it>
wrote:

> Why does the standard allow
> calling non const member functions on rvalues? It appears a peculiar
> choice at best.

Maybe this will make sense.

Rvalue and const are orthoginal.  A udt rvalue is an object and member
functions may be called.  For udt we have

   non-const lvalue    can call any member
   const     lvalue    can call const members
   non-const rvalue    can call any member
   const     rvalue    can call const members

The builtins do not have members and do not have const rvalues.  We get

   non-const lvalue
   const     lvalue
             rvalue

Since references are lvalues, we may not bind an rvalue to a non-const
reference because it caused too many surprises when it was allowed.

HTH,
John

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

On Fri, 22 Feb 2002 01:47:09 GMT, jpotter@falcon.lhup.edu (John
Potter) wrote:

>Since references are lvalues, we may not bind an rvalue to a non-const
>reference because it caused too many surprises when it was allowed.

Still current rules are surprising enough... for example
to clear a vector reclaiming all its memory you can do

  std::vector<int>().swap(v);

but you can't do

  v.swap(std::vector<int>());

because in the latter a non-const reference would
be associated to a temporary.

As a first impression I think that I would have
preferred more relaxed rules (not forbidding those
bindings)... they let you do strange things but
the whole language is designed thinking that the
programmer knows very very well what's doing.

I suppose most of the problems came in because of
implicit conversions, when binding to a temporary
surely can bite you for distraction... (I think
it's harder to *inadvertitely* call a member or to
*inadvertitely* pass an object to a function that
modifies it).

Andrea

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Thomas Maeder <maeder@glue.ch> wrote in message news:<3c602210$1@news.swissonline.ch>...

> Does &fred[0] not work?

Or, for that matter, &fred.front().

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Matthew Austern wrote:
[...]
> > Is there any good reason for allowing the iterator of a standard
> > container to be a typedef to a pointer?
>
> I think it's mostly an artifact: we've said that std::vector<T> is an
> implementation defined type.  Changing that to something more
> complicated, like "implementation defined, except that it can't be a
> pointer", has never seemed worth the trouble.

I'd say that the only problematic area is the existence of expressions
which are valid if vector<T>::iterator is a UDT, but not if it's a
pointer. I'm thinking of

vector<int> v;
// fill it somehow
vector<int>::iterator last = --v.end();

(I know this specific example can be easily worked around, but the issue
is still there).

Cheers,
Nicola Musatti

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

On Wed, 20 Feb 2002 15:11:57 GMT, Nicola Musatti <objectway@divalsim.it>
wrote:

> I'd say that the only problematic area is the existence of expressions
> which are valid if vector<T>::iterator is a UDT, but not if it's a
> pointer. I'm thinking of

> vector<int> v;
> // fill it somehow
> vector<int>::iterator last = --v.end();

This expression is not valid for all udt anymore than it is for a
pointer.  For example MyIter& operator-- (MyIter&).  You assume
that operator-- is a member and mine is not.  It does not require
a pointer to show that the code is broken.

There is a workaround expression which will be valid for a udt but
not for a pointer, but you do not want to write it.

John

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

John Potter wrote:
>
> On Wed, 20 Feb 2002 15:11:57 GMT, Nicola Musatti <objectway@divalsim.it>
> wrote:
>
> > I'd say that the only problematic area is the existence of expressions
> > which are valid if vector<T>::iterator is a UDT, but not if it's a
> > pointer. I'm thinking of
>
> > vector<int> v;
> > // fill it somehow
> > vector<int>::iterator last = --v.end();
>
> This expression is not valid for all udt anymore than it is for a
> pointer.  For example MyIter& operator-- (MyIter&).  You assume
> that operator-- is a member and mine is not.  It does not require
> a pointer to show that the code is broken.

You're right, I hadn't thought of this. Why does the standard allow
calling non const member functions on rvalues? It appears a peculiar
choice at best.

Cheers,
Nicola Musatti

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Ron Natalie <ron@sensor.com> wrote:
>> I wonder whether  std::vector could have methods 'T * c_array()' and '=
T
>> * const c_array() const' much as std::string has a 'c_str()'.
>> Implementation should be straight forward and it might help to reduce =
the
>> strain on the eyes ;-)
>=20
> How about just calling it data().=20

data() is fine with me.

Andre'

--=20
Andr=E9 P=F6nitz .............................................. poenitz@g=
mx.de

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Andr    P   nitz" <poenitz@gmx.de> wrote in message
news:a3tu5p$aq$3@narses.hrz.tu-chemnitz.de...
> Ron Natalie <ron@sensor.com> wrote:
> >> I wonder whether  std::vector could have methods 'T * c_array()' and 'T
> >> * const c_array() const' much as std::string has a 'c_str()'.
> >> Implementation should be straight forward and it might help to reduce
the
> >> strain on the eyes ;-)
> >
> > How about just calling it data().
>
> data() is fine with me.

I prefer c_arr() or c_array() because it discourages use outside of C
interop and because calling it data() would undoubtably lead to more common
misuse of basic_string::data(), which is already a very common problem among
non-experts.  I think the asymmetry between c_arr and c_str with respect to
null termination isn't a major issue, because it's commonly known that C
idiom strings are null terminated and C idiom arrays are not.

Ken


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

> Technically, that's not guaranteed to work under the current version of
> the standard. It guarantees neither the contiguity, nor the order in
> memory, of the elements of a vector. This seems to have been an
> oversight, and there are plans to change it in the next revision.

The standard has already been updated so now elements in a vector should be
placed in the same way as a c-array.

Sorry I don't got a internet reference but it stands in "effective stl" page
74.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Renato Mancuso wrote:
>
> Hi Eric,
>
> there is an easy and portable way to achieve what you want:
>
> void old_c_function(int *array, size_t len);
>
> void cpp_function()
> {
>    vector<int> fred;
>
>    fred.push_back(5);
>    fred.push_back(12);
>    old_c_function(&fred[0], fred.size());
> }

Technically, that's not guaranteed to work under the current version of
the standard. It guarantees neither the contiguity, nor the order in
memory, of the elements of a vector. This seems to have been an
oversight, and there are plans to change it in the next revision.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Eric Hopper <eric.hopper@tiecommerce.com> wrote:
>> Does &fred[0] not work?
>=20
> I suppose it does.  I didn't really think of it because I have blindspo=
ts
> with regards to certain code.  I abhor seeing the whole &array[x] thing.

I wonder whether  std::vector could have methods 'T * c_array()' and 'T
* const c_array() const' much as std::string has a 'c_str()'.
Implementation should be straight forward and it might help to reduce the
strain on the eyes ;-)

Andre'

--=20
Andr=E9 P=F6nitz .............................................. poenitz@g=
mx.de

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

John Nagle <nagle@animats.com> wrote:
> That's what "valarray" is for.

But valarray's push_back is terribly inconvenient ;^)

Andre'

--=20
Andr=E9 P=F6nitz .............................................. poenitz@g=
mx.de

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Andr=E9 P=F6nitz wrote:
>=20
> Eric Hopper <eric.hopper@tiecommerce.com> wrote:
> >> Does &fred[0] not work?
> >
> > I suppose it does.  I didn't really think of it because I have blinds=
pots
> > with regards to certain code.  I abhor seeing the whole &array[x] thi=
ng.
>=20
> I wonder whether  std::vector could have methods 'T * c_array()' and 'T
> * const c_array() const' much as std::string has a 'c_str()'.
> Implementation should be straight forward and it might help to reduce t=
he
> strain on the eyes ;-)

How about just calling it data().  c_str() forces a null at the end of
a string, a feature of dubious use for vector.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <3C61570F.1F56BC2C@sensor.com>, Ron Natalie  <ron@sensor.com> wrote:
>How about just calling it data().  c_str() forces a null at the end of
>a string, a feature of dubious use for vector.

That's because in C, a "string" is by convention a null-terminated
array of chars.  An "array" has no terminator, and so c_array()
wouldn't add any overhead, and I agree would be easier to read.
--
Mark Ping
emarkp@soda.CSUA.Berkeley.EDU

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Matthew Austern <austern@research.att.com> wrote in message
news:<dil7kpren4u.fsf@isolde.research.att.com>...

> Well, there is a little more to it than that.  The C++ Standard says
> that std::vector<T>::iterator is an implementation defined random
> access iterator type.  Some standard library implementations use T*
> as that type, others use a class.  The old GNU standard library did
> the former, the new does the latter.  Both choices are conforming.
> From an implementors point of view there are arguments either way.
> Users who care about portability, of course, should make sure that
> their code doesn't depend on implementation-defined details.  (The
> exact type of std::vector<T>::iterator, the sizeof int, whether char
> is signed, etc.)

So what do you do when you need a function which can handle iterators
from either std::vector or a C style array?  You can't portably
overload on the type, since you might end up with two copies of the
same function, and you cannot portably count on just the T* version
doing the trick.  I know that the official answer is a template, but I
don't particularly want all of my functions to end up in the header
files, and support for export is still a bit weak, to put it mildly.

Is there any good reason for allowing the iterator of a standard
container to be a typedef to a pointer?

--
James Kanze                                   mailto:kanze@gabi-soft.de
Beratung in objektorientierer Datenverarbeitung --
                             -- Conseils en informatique orient   e objet
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany, T   l.: +49 (0)69 19 86 27

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

kanze@gabi-soft.de (James Kanze) writes:

> Matthew Austern <austern@research.att.com> wrote in message
> news:<dil7kpren4u.fsf@isolde.research.att.com>...
>
> > Well, there is a little more to it than that.  The C++ Standard says
> > that std::vector<T>::iterator is an implementation defined random
> > access iterator type.  Some standard library implementations use T*
> > as that type, others use a class.  The old GNU standard library did
> > the former, the new does the latter.  Both choices are conforming.
> > From an implementors point of view there are arguments either way.
> > Users who care about portability, of course, should make sure that
> > their code doesn't depend on implementation-defined details.  (The
> > exact type of std::vector<T>::iterator, the sizeof int, whether char
> > is signed, etc.)
>
> So what do you do when you need a function which can handle iterators
> from either std::vector or a C style array?  You can't portably
> overload on the type, since you might end up with two copies of the
> same function, and you cannot portably count on just the T* version
> doing the trick.  I know that the official answer is a template, but I
> don't particularly want all of my functions to end up in the header
> files, and support for export is still a bit weak, to put it mildly.

Have you ever had a situation when you had a function that
 (a) could be called for std::vector<T>::iterator
 (b) could be called for T*
 (c) couldn't be called for any other container's iterators; and
 (d) couldn't be a template?

I haven't. I don't have a particularly convenient way to deal with
that situation, but it doesn't strike me as a very common case.

> Is there any good reason for allowing the iterator of a standard
> container to be a typedef to a pointer?

I think it's mostly an artifact: we've said that std::vector<T> is an
implementation defined type.  Changing that to something more
complicated, like "implementation defined, except that it can't be a
pointer", has never seemed worth the trouble.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

I used to have code like this reasonably often:

void old_c_function(int *array, size_t len);

void cpp_function()
{
   vector<int> fred;

   fred.push_back(5);
   fred.push_back(12);
   old_c_function(fred.begin(), fred.size());
}

I considered it kind of a cheat, but I thought the standard would always
preserve some way of getting to a vector and treating it as a C style
array for certain purposes.  I discover that a recent release of libstdc++
for g++ 3 removes this ability completely. The underlying pointer type of
the iterator is wrapped up in a template class and hidden, and there are
no methods for getting the array out of the vector.

Now this is horrible.  It means that vector has become useless to me in a
wide variety of situations, and I'll end up having to write my own memory
management code for a C style array where before I could've used a vector.
 The worst aspect of this is creating a growing array of things.

The standard trusts people with string::c_str() so you can use old C code
with the new string.  Why not let you use a vector as a C array in some
circumstances?

Of course, perhaps the g++ libstdc++ is being more strict than the
standard demands.  The standards document is thick and expensive, and I
don't have the ability to examine it in minute detail to discover this.
Given the nature of the change, I suspect libstdc++ is trying harder to
conform to the standard rather than being more strict than the standard
requires.

*sigh*,
--
Eric Hopper

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Eric Hopper wrote:
> The underlying pointer type of
> the iterator is wrapped up in a template class and hidden, and there are
> no methods for getting the array out of the vector.

Sure there is:
 &fred[0]
or
 &*fred.begin();

Nobody said iterators were liternally pointers, they just sort of
behave like them.

While it's not explicitly stated that vectors are internally
contiguous, everybody agrees that they should be so (and will
be corrected in the standard), so it's safe to treat them like
they are.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

On Tue, 05 Feb 2002 18:45:23 +0100, Eric Hopper wrote:

> The underlying
> pointer type of the iterator is wrapped up in a template class and
> hidden, and there are no methods for getting the array out of the
> vector.

Does &fred[0] not work?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <3c602210$1@news.swissonline.ch>, "Thomas Maeder"
<maeder@glue.ch> wrote:

> On Tue, 05 Feb 2002 18:45:23 +0100, Eric Hopper wrote:
>
>> The underlying
>> pointer type of the iterator is wrapped up in a template class and
>> hidden, and there are no methods for getting the array out of the
>> vector.
>
> Does &fred[0] not work?

I suppose it does.  I didn't really think of it because I have blindspots
with regards to certain code.  I abhor seeing the whole &array[x] thing.
*sigh*  I guess I could do that.  :-P

I actually especially hate doing that because when I have a member
function that returns a reference to something, I usually have explicit
documentation declaring that you are not, under any circumstances, to take
the addrress of the reference.  It seems sneaky and underhanded to me to
take the address of some private thing a class returns to you.

I would've felt nervous without assurances that this was supposed to work
in the future anyway.

Thanks,
--
Eric Hopper

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Hi Eric,

there is an easy and portable way to achieve what you want:

void old_c_function(int *array, size_t len);

void cpp_function()
{
   vector<int> fred;

   fred.push_back(5);
   fred.push_back(12);
   old_c_function(&fred[0], fred.size());
}

you may find useful to give a look at:
http://www.awl.com/cseng/titles/0-201-74962-9/item16-2.pdf

cheers

Renato Mancuso



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Eric Hopper wrote:

> I actually especially hate doing that because when I have a member
> function that returns a reference to something, I usually have explicit
> documentation declaring that you are not, under any circumstances, to take
> the addrress of the reference.

What explicit documentation?

> It seems sneaky and underhanded to me to
> take the address of some private thing a class returns to you.

No more sneaky tha assigning into it.  (Which is why it gave you
a reference anyhow).

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Ron Natalie <ron@sensor.com> writes:

> Eric Hopper wrote:
> > The underlying pointer type of
> > the iterator is wrapped up in a template class and hidden, and there are
> > no methods for getting the array out of the vector.
>
> Sure there is:
>  &fred[0]
> or
>  &*fred.begin();
>
> Nobody said iterators were liternally pointers, they just sort of
> behave like them.

Well, there is a little more to it than that.  The C++ Standard says
that std::vector<T>::iterator is an implementation defined random
access iterator type.  Some standard library implementations use T* as
that type, others use a class.  The old GNU standard library did the
former, the new does the latter.  Both choices are conforming.  From
an implementors point of view there are arguments either way.  Users
who care about portability, of course, should make sure that their
code doesn't depend on implementation-defined details.  (The exact
type of std::vector<T>::iterator, the sizeof int, whether char is
signed, etc.)

> While it's not explicitly stated that vectors are internally
> contiguous, everybody agrees that they should be so (and will
> be corrected in the standard), so it's safe to treat them like
> they are.

Especially since the forthcoming technical corrigendum will say that
vectors are internally contiguous. See
http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#69

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <NIV78.20822$Wf1.5141446@ruti.visi.com>,
Eric Hopper <eric.hopper@tiecommerce.com> wrote:
>In article <3c602210$1@news.swissonline.ch>, "Thomas Maeder"
><maeder@glue.ch> wrote:
>> Does &fred[0] not work?
>
>I suppose it does.  I didn't really think of it because I have blindspots
>with regards to certain code.  I abhor seeing the whole &array[x] thing.
>*sigh*  I guess I could do that.  :-P
>
>I actually especially hate doing that because when I have a member
>function that returns a reference to something, I usually have explicit
>documentation declaring that you are not, under any circumstances, to take
>the addrress of the reference.  It seems sneaky and underhanded to me to
>take the address of some private thing a class returns to you.

Considering that you felt that your original way was a cheat and yet
still did it, I know you can't hate it all that much :)
--
Greg Comeau  GA BETA:4+ New Windows Backends  PLUS 'export' beta online!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Eric Hopper wrote:


> I considered it kind of a cheat, but I thought the standard would always
> preserve some way of getting to a vector and treating it as a C style
> array for certain purposes.


    That's what "valarray" is for.

     John Nagle
     Animats

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]