 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Axter
Guest
|
 Posted: Thu Dec 29, 2005 2:23 am Post subject: replacement allocation function be declared inline |
 |
|
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#404
In the above link item 404 propose the following:
******************************************************************************
Add a new sentence to the end of 17.4.3.4 [lib.replacement.functions]
paragraph 3: "The program's definitions shall not be specified as
inline. No diagnostic is required."
******************************************************************************
Moreover, it has the following rationale:
******************************************************************************
The fact that inline isn't mentioned appears to have been nothing more
than an oversight. Existing implementations do not permit inline
functions as replacement memory allocation functions. Providing this
functionality would be difficult in some cases, and is believed to be
of limited value.
******************************************************************************
I disagree with the rationale. I have existing code that does leak
tracking, which depends on inline new operator.
http://code.axter.com/leaktracker.h
Moreover, I've seen this method used in other implementations that
performs memory leak detection.
I've tested my code on VC++ 7.1, 6.0, GNU 3.x, and Borland 5.5.
How can item 404 say that exiting implementations do not permit inline
functions, if the above code is able to work on all these compilers?
I disagree with the rationale in stating that it's of limited value.
For performming memory leak tracking, the inline new is of great value,
because it allows you to let the translation unit call the correct
associated allocator.
I recommend they reconsider this change to the standard.
[ 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 Dec 29, 2005 12:12 pm Post subject: Re: replacement allocation function be declared inline |
|
|
Axter wrote:
| Quote: | http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#404
In the above link item 404 propose the following:
******************************************************************************
Add a new sentence to the end of 17.4.3.4
[lib.replacement.functions] paragraph 3: "The program's
definitions shall not be specified as inline. No diagnostic is
required."
******************************************************************************
Moreover, it has the following rationale:
******************************************************************************
The fact that inline isn't mentioned appears to have been
nothing more than an oversight. Existing implementations do
not permit inline functions as replacement memory allocation
functions. Providing this functionality would be difficult in
some cases, and is believed to be of limited value.
******************************************************************************
I disagree with the rationale. I have existing code that does
leak tracking, which depends on inline new operator.
http://code.axter.com/leaktracker.h
Moreover, I've seen this method used in other implementations
that performs memory leak detection. I've tested my code on
VC++ 7.1, 6.0, GNU 3.x, and Borland 5.5. How can item 404 say
that exiting implementations do not permit inline functions,
if the above code is able to work on all these compilers?
|
It's undefined behavior, which depends on what you actually do
in the functions. Your implementations happen to be compatible
with the default implementation of the operators in the library,
so it happens to work. Change your implementation, and it
won't. If the default implementation in the next release of the
compiler changes, it won't work either.
The problem is that your inline definition is not visible to the
library code. Except for templates, where the definition used
will depend on where the compiler actually does the
instantiation. The invocation of new in the definition of e.g.
std::string::string( char const* ) will bind to the default
operator new in translation units in the library, and to your
overload in your translation units. If the code is such that it
doesn't matter which one is used, the results will probably
work. In your case, for example, your operator new simply calls
malloc, and returns the results. If this is what the default
operator new does (and it is frequently the case), then the code
will seem to work. If it isn't, then the code won't work.
Note that I regularly use a version of operator new and operator
delete that won't work with your code. (My operator new calls
gcmalloc, rather than malloc, and my operator delete is a
no-op.) I would be very surprised if, in the future, some
compilers didn't start using similar versions, at least with
some sets of options.
| Quote: | I disagree with the rationale in stating that it's of limited
value. For performming memory leak tracking, the inline new
is of great value, because it allows you to let the
translation unit call the correct associated allocator.
|
I don't quite understand your point. My debugging operator new
and operator delete (which are still pre-garbage collector)
aren't inline, and they still manage to give a stack walkback in
case of errors. For more complers and platforms than you seem
to support. (I don't currently have access to an up to date
version of a PC compiler, but users of my code have reported
back to me that the Linux PC version -- which was identical to
the version for VC++ 6.0 back then -- works with recent versions
of VC++ under Windows.)
Note too that in the case of factory methods, simply knowing the
translation unit which invoked new doesn't buy you anything.
| Quote: | I recommend they reconsider this change to the standard.
|
Impossible, since it cannot be made to work.
--
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 |
|
|
|
|
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
