 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
chris.dearlove@baesystems
Guest
|
 Posted: Wed Sep 28, 2005 11:07 am Post subject: Reentrancy and std::equal |
 |
|
I was writing an operator== for a class which contains a vector of
objects. Simple implementation, including using std::equal (after
checking equal length vectors of course). But then I realised that I'd
written the operator== for the objects in the vector (which themselves
each contain a vector) in the same way. So I'm calling std::equal
within a call of std::equal. Just to be on the safe side however I
thought I'd check in the standard. But there I found 17.4.4.5 which
just states "Which of the functions in the C++ Standard Library are not
reentrant subroutines is implementation defined.". Not good.
So my question is, do I, realistically, have to rewrite my functions if
I'm to remain practically portable, or are in practice implementations
of std:equal (and other STL algorithms)
actually going to be reentrant (certainly the naive implementation is)?
Of course I plan to check the implementation definition for the systems
of critical interest to me (at the moment MS VC++ 6.0
and g++ 3.x) - once I find them, if they exist.
Any plans to improve this state of affairs in C++0X - or better still
have I missed something in the existing standard? Without it,
std::equal is a bit dead on arrival for class usage (in general who
knows whether the compared class used it?).
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
 |
kanze
Guest
|
| Posted: Thu Sep 29, 2005 8:18 pm Post subject: Re: Reentrancy and std::equal |
|
|
[email]chris.dearlove (AT) baesystems (DOT) com[/email] wrote:
| Quote: | I was writing an operator== for a class which contains a
vector of objects. Simple implementation, including using
std::equal (after checking equal length vectors of
course). But then I realised that I'd written the operator==
for the objects in the vector (which themselves each contain a
vector) in the same way. So I'm calling std::equal within a
call of std::equal. Just to be on the safe side however I
thought I'd check in the standard. But there I found 17.4.4.5
which just states "Which of the functions in the C++ Standard
Library are not reentrant subroutines is implementation
defined.". Not good.
|
Just for the record, you're not calling std::equal -- std::equal
is a template, not a function. You're calling two different
instantiations of std::equal, thus, two different functions.
Since the instantiations are on user defined types, I think it
is a pretty safe conclusion that no function in the standard
library calls your instantiation.
That doesn't mean that there isn't a problem in the standard.
| Quote: | So my question is, do I, realistically, have to rewrite my
functions if I'm to remain practically portable, or are in
practice implementations of std:equal (and other STL
algorithms) actually going to be reentrant (certainly the
naive implementation is)? Of course I plan to check the
implementation definition for the systems of critical interest
to me (at the moment MS VC++ 6.0 and g++ 3.x) - once I find
them, if they exist.
Any plans to improve this state of affairs in C++0X - or
better still have I missed something in the existing standard?
Without it, std::equal is a bit dead on arrival for class
usage (in general who knows whether the compared class used
it?).
|
Technically, this issue can be a real problem anytime the
standard library can call your functions, and your functions use
a component of the standard library -- including instantiations
of templates over types known to the standard library. In
practice, I can't imagine it being a problem except in
replacement functions, like a user defined global operator
new(); my debugging operator new uses memcpy and memcmp, for
example, and "assumes" that memcpy and memcmp don't call
operator new, directly or indirectly. Which seems like a very
safe bet, but there is absolutely no guarantee of it.
As far as I know, the only explicit guarantees are that
malloc/calloc/realloc don't call operator new(), and that free
doesn't call operator delete().
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Pete Becker
Guest
|
| Posted: Sat Oct 01, 2005 1:33 am Post subject: Re: Reentrancy and std::equal |
|
|
kanze wrote:
| Quote: |
Technically, this issue can be a real problem anytime the
standard library can call your functions, and your functions use
a component of the standard library -- including instantiations
of templates over types known to the standard library. In
practice, I can't imagine it being a problem except in
replacement functions, like a user defined global operator
new(); my debugging operator new uses memcpy and memcmp, for
example, and "assumes" that memcpy and memcmp don't call
operator new, directly or indirectly. Which seems like a very
safe bet, but there is absolutely no guarantee of it.
|
That's the difference between portable code and standards-conforming
code. Portable code often relies on things that aren't required by the
standard, but in practice always work. In that case, the task involved
in porting the code is ensuring that those things also work in the new
environment. The possibility that memcpy and memcmp will call operator
new isn't high on my list of things to worry about.
--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
chris.dearlove@baesystems
Guest
|
| Posted: Sat Oct 01, 2005 1:26 pm Post subject: Re: Reentrancy and std::equal |
|
|
kanze wrote:
| Quote: | Just for the record, you're not calling std::equal -- std::equal
is a template, not a function. You're calling two different
instantiations of std::equal, thus, two different functions.
|
Yes. Thank you. I shouldn't have missed that, but I did, and thanks for
putting me on the right track.
(Incidentally after I posted a colleague asked why not just compare the
vectors? However I would have had to convert my non-member non-friend
operator== to either a member or a friend to do that.)
| Quote: | Since the instantiations are on user defined types, I think it
is a pretty safe conclusion that no function in the standard
library calls your instantiation.
|
I could think up a totally insane implementation of std::equal that
breaks (needs to use a global, not even a static member in the function
as that would be different) but I'm not that paranoid.
| Quote: | That doesn't mean that there isn't a problem in the standard.
|
I was surprised to see such a minimal (and close to useless) note.
But a non-contributor shouldn't complain too much.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
James Kanze
Guest
|
| Posted: Sun Oct 02, 2005 8:14 pm Post subject: Re: Reentrancy and std::equal |
|
|
Pete Becker wrote:
| Quote: | kanze wrote:
Technically, this issue can be a real problem anytime the
standard library can call your functions, and your functions
use a component of the standard library -- including
instantiations of templates over types known to the standard
library. In practice, I can't imagine it being a problem
except in replacement functions, like a user defined global
operator new(); my debugging operator new uses memcpy and
memcmp, for example, and "assumes" that memcpy and memcmp
don't call operator new, directly or indirectly. Which seems
like a very safe bet, but there is absolutely no guarantee of
it.
That's the difference between portable code and
standards-conforming code. Portable code often relies on
things that aren't required by the standard, but in practice
always work. In that case, the task involved in porting the
code is ensuring that those things also work in the new
environment. The possibility that memcpy and memcmp will call
operator new isn't high on my list of things to worry about.
|
Which is more or less what I meant by my last sentence. I can't
say that I'm worried either. As a general rule, however, it
does bother me that nothing is specified. I feel pretty safe
using the functions in <string.h>; on the other hand, I know
that using ostream will cause problems. But where do I draw the
line? Common sense helps -- it certainly answers the question
for memcpy and for ostream::operator<< (at least if you know
that ostream may do buffered output), but the answer isn't
always as cut and dried. I can imagine many people supposing
that the functions in
imagine reasonable implementations in which they did use dynamic
memory.
--
James Kanze mailto: [email]james.kanze (AT) free (DOT) fr[/email]
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Pete Becker
Guest
|
| Posted: Tue Oct 04, 2005 1:44 pm Post subject: Re: Reentrancy and std::equal |
|
|
James Kanze wrote:
| Quote: |
Which is more or less what I meant by my last sentence. I can't
say that I'm worried either. As a general rule, however, it
does bother me that nothing is specified. I feel pretty safe
using the functions in <string.h>; on the other hand, I know
that using ostream will cause problems. But where do I draw the
line? Common sense helps -- it certainly answers the question
for memcpy and for ostream::operator<< (at least if you know
that ostream may do buffered output), but the answer isn't
always as cut and dried. I can imagine many people supposing
that the functions in
imagine reasonable implementations in which they did use dynamic
memory.
|
I agree that there are problems in this area. I was making a general
point about the tendency to overreact to undefined (or underspecified)
behavior.
--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
