This program leaks 100Megs/sec is this correct?
Spuds
running under latest Solaris.
#include <typeinfo.h>
class Yada { };
int main() {
Yada Y;
while(1) {
if (typeid(Yada) == typeid(Y)) { }
}
return 0;
}
C++ is so confusing!
Spuds.
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
Martin von Loewis
> Compiled with Workshop C++ 5.0 Patched to up to Sept. 7, 1999
> running under latest Solaris.
You're not supposed to clean-up type_info objects, so I'd say that's a
bug in CC 5.
Regards,
Martin
Michael Ball
>
> Spuds <sp...@mackenzie.com> writes:
>
> > Compiled with Workshop C++ 5.0 Patched to up to Sept. 7, 1999
> > running under latest Solaris.
>
> You're not supposed to clean-up type_info objects, so I'd say that's a
> bug in CC 5.
Yes it is. The typeinfo object for a static type is not being
properly reused, so a new one is being reallocated for each call.
This is conforming, but wasteful.
The obvious workaround is not to put them in a loop. Since it's
a program invariant, just move it out of the loop.
I might also recommend that you file a bug report for it.
Mike Ball
Sun MicroSystems Inc.
Nathan Myers
>Compiled with Workshop C++ 5.0 Patched to up to Sept. 7, 1999
>running under latest Solaris.
>
> if (typeid(Yada) == typeid(Y)) { } // [ leaks!]
>
>C++ is so confusing!
No, buggy compilers and runtime environments are frustrating.
--
Nathan Myers
n...@nospam.cantrip.org http://www.cantrip.org/
Jay
> > > running under latest Solaris.
> >
> > bug in CC 5.
>
> Yes it is. The typeinfo object for a static type is not being
> properly reused, so a new one is being reallocated for each call.
> This is conforming, but wasteful.
>
> The obvious workaround is not to put them in a loop. Since it's
> a program invariant, just move it out of the loop.
>From what I have seen, typeid leaks everywhere and not just in
loops. This is just the minimal program that demonstrates the
the problem distilled from a much larger program.
Jay
Steve Clamage
>From what I have seen, typeid leaks everywhere and not just in
>loops. This is just the minimal program that demonstrates the
>the problem distilled from a much larger program.
Let's be careful about using the term "memory leak".
The C++ standard requires that the typeid operator return a type_info
object (or an object of a type derived from type_info) whose lifetime
extends to the end of the program. In addition, the standard says it
is unspecified whether the object is ever destroyed.
You therefore cannot expect a type_info object's storage to be
reclaimed before program end. If you call failure to recover the
storage a memory leak, the "leak" is due to the requirements of
the C++ standard, and is the moral equivalent of "leaks" caused
by static objects.
The next question is what should happen when typeid is invoked
more than once for the same type. The standard does not require
that the type_info objects be the same, only that the objects
(as opposed to their addresses) compare equal. Here we have a
quality of implementation issue.
An implementation might simply create a new type_info object
for each use of typeid. The compiler in question (Sun C++ 5.0)
in fact works that way.
An implementation might keep track of type_info objects in such
a way that duplicates are avoided.
While the second option seems at first glance more attractive,
it is not obviously the best choice.
In general, the type being queried is not known until run time.
After all, the most likely use of typeid would be on polymorphic
pointers and references; if you know the type statically, you
probably don't need to use typeid. That means the implementation
must have auxiliary run-time data structures to determine whether
to use a type_info object that already exists, or to generate a
new type_info object (and remember it). The resultant time and
space overhead might be greater than simply creating a new object
for typical programs.
A third option might be for the implementation to emit a static
type_info object for each type in the program. Uses of typeid
would have no (extra) overhead, but would be potentially a large
amount of static type_info data in every program. (Consider the
the C++ standard library, apart from your own types.)
The Sun design was based on the assumption that typeid queries are
relatively rare. Apparently that is not the case for your program.
Since there is little you can reasonably expect about creation
and re-use of type_info objects, you should write your program
to keep the invocations of typeid to a reasonable minimum.
I also have to wonder whether so many uses of typeid represent
a good solution to your programming problem.
--
Steve Clamage, stephen...@sun.com
Michael Ball
> >From what I have seen, typeid leaks everywhere and not just in
> loops. This is just the minimal program that demonstrates the
> the problem distilled from a much larger program.
It allocates space for the typeid element. If you ask for another one
of the same static time, the bug causes it to allocate another.
The first allocation isn't a leak, it's the normal semantics of the
operator.
The way you get around the leak is simple
static const type_id& int_id = typeid(int);
No it's not a fix, but it has the correct semantics and it uses a
minimum
of memory.
-Mike-
James...@dresdner-bank.com
cla...@eng.sun.com (Steve Clamage) wrote:
> Jay <j...@jay.org> writes:
> >From what I have seen, typeid leaks everywhere and not just in
> >loops. This is just the minimal program that demonstrates the
> >the problem distilled from a much larger program.
> Let's be careful about using the term "memory leak".
A program whose memory use grows continuously during running, and is
unbound, has a memory leak. This is apparently the case.
> The C++ standard requires that the typeid operator return a type_info
> object (or an object of a type derived from type_info) whose lifetime
> extends to the end of the program. In addition, the standard says it
> is unspecified whether the object is ever destroyed.
This sounds like an indirect requirement that the objects be static.
> You therefore cannot expect a type_info object's storage to be
> reclaimed before program end. If you call failure to recover the
> storage a memory leak, the "leak" is due to the requirements of
> the C++ standard, and is the moral equivalent of "leaks" caused
> by static objects.
Right: if the objects are static, then it isn't a leak, because the
amount of memory never recovered is bound.
> The next question is what should happen when typeid is invoked
> more than once for the same type. The standard does not require
> that the type_info objects be the same, only that the objects
> (as opposed to their addresses) compare equal. Here we have a
> quality of implementation issue.
I suspect that one of the reasons why the standard doesn't want to
require the same objects has to do with DLL's: each DLL might contain
its own copy of the static object. (I believe that this is the case for
VC++, for example.)
> An implementation might simply create a new type_info object
> for each use of typeid. The compiler in question (Sun C++ 5.0)
> in fact works that way.
> An implementation might keep track of type_info objects in such
> a way that duplicates are avoided.
> While the second option seems at first glance more attractive,
> it is not obviously the best choice.
> In general, the type being queried is not known until run time.
> After all, the most likely use of typeid would be on polymorphic
> pointers and references; if you know the type statically, you
> probably don't need to use typeid. That means the implementation
> must have auxiliary run-time data structures to determine whether
> to use a type_info object that already exists, or to generate a
> new type_info object (and remember it). The resultant time and
> space overhead might be greater than simply creating a new object
> for typical programs.
> A third option might be for the implementation to emit a static
> type_info object for each type in the program. Uses of typeid
> would have no (extra) overhead, but would be potentially a large
> amount of static type_info data in every program. (Consider the
> the C++ standard library, apart from your own types.)
A fourth option would simply be to have a pointer to the type_info in
the object's vtable. (Increasing the size of the vtable by four bytes
surely isn't an issue.) The actual type_info's could then be allocated
lazily. (For non-polymorphic objects, there is no problem with
generating a static type_info at the call site, since the actual value
is known at compile time. Presumably, the extra copies shouldn't be a
problem with regards to total program size; how many typeid's on
non-polymorphic objects will a program contain?)
> The Sun design was based on the assumption that typeid queries are
> relatively rare. Apparently that is not the case for your program.
> Since there is little you can reasonably expect about creation
> and re-use of type_info objects, you should write your program
> to keep the invocations of typeid to a reasonable minimum.
Reasonably?
>From a standards point of view, there is nothing you can expect. An
implementation in which free was a no-op would be conforming. From a
quality of implementation point of view, however, I think it reasonable
to expect no memory leaks in the library, where a memory leak is defined
as above: unbounded use of the memory.
> I also have to wonder whether so many uses of typeid represent
> a good solution to your programming problem.
That's another question. It shouldn't be used to let the compiler
implementers off the hook. But I've yet to find *any* reasonable use
for typeid, so I'm curious as to what he's doing that would need it.
--
James Kanze mailto: James...@dresdner-bank.com
Conseils en informatique orientée objet/
Beratung in objekt orientierter Datenverarbeitung
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
Phlip
> Jay wrote:
>
> > >From what I have seen, typeid leaks everywhere and not just in
> > loops. This is just the minimal program that demonstrates the
> > the problem distilled from a much larger program.
>
> It allocates space for the typeid element. If you ask for another
one
> of the same static time, the bug causes it to allocate another.
By "bug" Mike means "conformant but leaky implementation result".
I'm glad I ever heard of this before putting a 'typeid' into
production code. It would obviously have gone in at the bottom of
some loop.
> The first allocation isn't a leak, it's the normal semantics of
the
> operator.
>
> The way you get around the leak is simple
>
> static const type_id& int_id = typeid(int);
>
> No it's not a fix, but it has the correct semantics and it uses a
> minimum
> of memory.
I forsee a generic solution:
template< class TypeMe >
type_info &
Wizard_Of_Id (TypeMe &)
{
static type_info *pId;
if (!pId) pId = &typeid (TypeMe);
return pId;
};
That wraps 'typeid()' with the behavior we wished an implementation
could have covered for us.
(But I'm right about there's one static instance of 'pId' for each
template instance, not one for all of them, right?)
New question: Should we use this everywhere, even in code we never
expect to port? or just on bad implementations?
Or could we empower the template to detect if 'typeid()' is leaky on
a given implementation and adjust its contents accordingly?
--
Phlip at politizen dot com (address munged)
======= http://users.deltanet.com/~tegan/home.html =======
-- Will the bailiff please remove
the juror who started the wave. --
alfred...@my-deja.com
> Jay <j...@jay.org> writes:
>
> >From what I have seen, typeid leaks everywhere and not just in
> >loops. This is just the minimal program that demonstrates the
> >the problem distilled from a much larger program.
>
cla...@eng.sun.com (Steve Clamage) wrote:
> Let's be careful about using the term "memory leak".
>
> The C++ standard requires that the typeid operator return a type_info
> object (or an object of a type derived from type_info) whose lifetime
> extends to the end of the program. In addition, the standard says it
> is unspecified whether the object is ever destroyed.
I think we all can assume that most C++ users and compiler
authors _expect_ that repeated typeid usage will not result
in memory leaks. Sun's 5.0 compiler leaks memory in this
regard plain and simple. There are some programming issues
where it better to pragmatic and err on the side of caution
rather than to be strictly "correct" as per the language
specification. This is one of them. Please fix this obvious
compiler bug.
You offer a few potential workarounds for your compiler,
perhaps there exists a still more space-efficient solution:
> An implementation might keep track of type_info objects in such
> a way that duplicates are avoided.
>
> While the second option seems at first glance more attractive,
> it is not obviously the best choice.
>
> In general, the type being queried is not known until run time.
> After all, the most likely use of typeid would be on polymorphic
> pointers and references; if you know the type statically, you
> probably don't need to use typeid. That means the implementation
> must have auxiliary run-time data structures to determine whether
> to use a type_info object that already exists, or to generate a
> new type_info object (and remember it). The resultant time and
> space overhead might be greater than simply creating a new object
> for typical programs.
>
> A third option might be for the implementation to emit a static
> type_info object for each type in the program. Uses of typeid
> would have no (extra) overhead, but would be potentially a large
> amount of static type_info data in every program. (Consider the
> the C++ standard library, apart from your own types.)
>
> The Sun design was based on the assumption that typeid queries are
> relatively rare. Apparently that is not the case for your program.
I seriously question this assumption. It is not an
assumption that most C++ programmers would share.
>
> Since there is little you can reasonably expect about creation
> and re-use of type_info objects, you should write your program
> to keep the invocations of typeid to a reasonable minimum.
>
> I also have to wonder whether so many uses of typeid represent
> a good solution to your programming problem.
The above statement is uncalled for - it is very insulting.
The typeid feature is a valid and very useful part of the
C++ specification and should be implemented with a
behavior that most C++ programmers would expect.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Jay
>
> Jay <j...@jay.org> writes:
>
> >From what I have seen, typeid leaks everywhere and not just in
> >loops. This is just the minimal program that demonstrates the
> >the problem distilled from a much larger program.
>
>
> The C++ standard requires that the typeid operator return a type_info
> object (or an object of a type derived from type_info) whose lifetime
> extends to the end of the program. In addition, the standard says it
> is unspecified whether the object is ever destroyed.
>
> reclaimed before program end. If you call failure to recover the
> storage a memory leak, the "leak" is due to the requirements of
> the C++ standard, and is the moral equivalent of "leaks" caused
> by static objects.
Yaw Yaw, but such initialization overheads are not likely to bring
a machine with 5 Gigs of memory to it knees.
> The next question is what should happen when typeid is invoked
> more than once for the same type. The standard does not require
> that the type_info objects be the same, only that the objects
> (as opposed to their addresses) compare equal. Here we have a
> quality of implementation issue.
>
> An implementation might simply create a new type_info object
> for each use of typeid. The compiler in question (Sun C++ 5.0)
> in fact works that way.
But Sun C++ 4.2 does not have this problem and neither does any other
C++ compiler I have encountered.
> An implementation might keep track of type_info objects in such
> a way that duplicates are avoided.
>
> While the second option seems at first glance more attractive,
> it is not obviously the best choice.
I will give you $100 if you can get Stroustrup to say
that he thinks that a quality C++ implementation should leak
memory (allocate unrecovered memory) for every "call" to typeid
in an such unbounded fashion (N "calls" to typeid() N*K memory
used) and that such an implementation of typeid()
should be used in software for life critical equipment.
> In general, the type being queried is not known until run time.
> After all, the most likely use of typeid would be on polymorphic
> pointers and references; if you know the type statically, you
> probably don't need to use typeid. That means the implementation
> must have auxiliary run-time data structures to determine whether
> to use a type_info object that already exists, or to generate a
> new type_info object (and remember it). The resultant time and
> space overhead might be greater than simply creating a new object
> for typical programs.
> A third option might be for the implementation to emit a static
> type_info object for each type in the program. Uses of typeid
> would have no (extra) overhead, but would be potentially a large
> amount of static type_info data in every program. (Consider the
> the C++ standard library, apart from your own types.)
> The Sun design was based on the assumption that typeid queries are
> relatively rare. Apparently that is not the case for your program.
But even if it did use typeid infrequently, a long running program
will have an unexplained growth in memory size which will
cause a programmer to think that he has a memory leak
in his code. So you are really saying that typeid() only
be used some small bounded number of times at the
beginning of the program (or end).
> Since there is little you can reasonably expect about creation
> and re-use of type_info objects, you should write your program
> to keep the invocations of typeid to a reasonable minimum.
I am just incredulous. I think you are just hiding behind
an "legislative" weakness in the C++ standard and
breaking the practical spirit of typeid(). I have
never seen a warning that a C++ program should
minimize the number of INVOCATIONS of typeid().
> I also have to wonder whether so many uses of typeid represent
> a good solution to your programming problem.
I really do not need you to tell what my program
does and doesn't need. Haven't you ever heard
that the customer is always right?
I am not a happy Sun customer at this point.
I suggest a "we will fix that implementation weakness ASAP"
tact would be a better approach.
Jay
Mike Schilling
>
> The C++ standard requires that the typeid operator return a type_info
> object (or an object of a type derived from type_info) whose lifetime
> extends to the end of the program. In addition, the standard says it
> is unspecified whether the object is ever destroyed.
>
> You therefore cannot expect a type_info object's storage to be
> reclaimed before program end. If you call failure to recover the
> storage a memory leak, the "leak" is due to the requirements of
> the C++ standard, and is the moral equivalent of "leaks" caused
> by static objects.
>
> The next question is what should happen when typeid is invoked
> more than once for the same type. The standard does not require
> that the type_info objects be the same, only that the objects
> (as opposed to their addresses) compare equal. Here we have a
> quality of implementation issue.
>
> An implementation might simply create a new type_info object
> for each use of typeid. The compiler in question (Sun C++ 5.0)
> in fact works that way.
>
> An implementation might keep track of type_info objects in such
> a way that duplicates are avoided.
>
> While the second option seems at first glance more attractive,
> it is not obviously the best choice.
>
> In general, the type being queried is not known until run time.
> After all, the most likely use of typeid would be on polymorphic
> pointers and references; if you know the type statically, you
> probably don't need to use typeid. That means the implementation
> must have auxiliary run-time data structures to determine whether
> to use a type_info object that already exists, or to generate a
> new type_info object (and remember it). The resultant time and
> space overhead might be greater than simply creating a new object
> for typical programs.
>
> A third option might be for the implementation to emit a static
> type_info object for each type in the program. Uses of typeid
> would have no (extra) overhead, but would be potentially a large
> amount of static type_info data in every program. (Consider the
> the C++ standard library, apart from your own types.)
>
> The Sun design was based on the assumption that typeid queries are
> relatively rare. Apparently that is not the case for your program.
>
> Since there is little you can reasonably expect about creation
> and re-use of type_info objects, you should write your program
> to keep the invocations of typeid to a reasonable minimum.
>
> I also have to wonder whether so many uses of typeid represent
> a good solution to your programming problem.
>
Take the example of a server process which is meant to run for an
indefinite period of time. As part of handling a request from a client, it
will create one typeid.
If I understand what you're saying, this program can't be written safely
under some implementations of C++, since it will eventually fill up its
free memory with typeid's. This isn't the moral equivalent of static
objects, since their size doesn't increase over time. It makes many uses of
typeid's unsafe for this class of program.
By the way, does the same reasoning apply to dynamic casts? Are they
allowed to permanently allocate memory for each cast? if so, are the
implementations which allocate a new typeid each time likely to do this as
well?
-----------------------------------------------------------------------
Mike Schilling (mi...@forte.com) (510)869-3474
Forte Software, Inc.
I always do my best to be just like I am
But everybody wants you to be just like them.
Bob Dylan
Paul D. DeRocco
>
> In article <7rmg2h$brd$1...@engnews1.eng.sun.com>,
> cla...@eng.sun.com (Steve Clamage) wrote:
>
> > A third option might be for the implementation to emit a static
> > type_info object for each type in the program. Uses of typeid
> > would have no (extra) overhead, but would be potentially a large
> > amount of static type_info data in every program. (Consider the
> > the C++ standard library, apart from your own types.)
>
> A fourth option would simply be to have a pointer to the type_info in
> the object's vtable. (Increasing the size of the vtable by four bytes
> surely isn't an issue.) The actual type_info's could then be allocated
> lazily. (For non-polymorphic objects, there is no problem with
> generating a static type_info at the call site, since the actual value
> is known at compile time. Presumably, the extra copies shouldn't be a
> problem with regards to total program size; how many typeid's on
> non-polymorphic objects will a program contain?)
In practice, a type_info needs to contain some sort of name string
(actually a const char[]), and if the strings are in a one-to-one
correspondence with actual types, that's all that's needed to compare
type_infos. And in practice, type_info objects also contain (or refer to
other objects that contain) info on the inheritance relationships among
types, for the benefit of dynamic_cast. I don't see how creating such an
object dynamically would save anything, because you can't derive this info
from anything that's signficantly smaller than a static type_info itself,
so that info from which the type_info is constructed would have to exist
statically anyway.
--
Ciao, Paul D. DeRocco
Paul mailto:pder...@ix.netcom.com
Paul D. DeRocco
>
> You therefore cannot expect a type_info object's storage to be
> reclaimed before program end. If you call failure to recover the
> storage a memory leak, the "leak" is due to the requirements of
> the C++ standard, and is the moral equivalent of "leaks" caused
> by static objects.
You cannot create static objects in a loop. You can call typeid in a loop.
Doug Harrison
>But I've yet to find *any* reasonable use
>for typeid
I use it as part of a "static data manager", which allows me to write class
templates that have static data, without that static data being duplicated
in every dynamically linked component that uses a given specialization,
which can be a major problem.
--
Doug Harrison
dHar...@worldnet.att.net
blargg
> > Jay <j...@jay.org> writes:
> >
> > >From what I have seen, typeid leaks everywhere and not just in
> > >loops. This is just the minimal program that demonstrates the
> > >the problem distilled from a much larger program.
>
> cla...@eng.sun.com (Steve Clamage) wrote:
> > Let's be careful about using the term "memory leak".
> >
> > The C++ standard requires that the typeid operator return a type_info
> > object (or an object of a type derived from type_info) whose lifetime
> > extends to the end of the program. In addition, the standard says it
> > is unspecified whether the object is ever destroyed.
>
> I think we all can assume that most C++ users and compiler
> authors _expect_ that repeated typeid usage will not result
> in memory leaks. Sun's 5.0 compiler leaks memory in this
> regard plain and simple. There are some programming issues
> where it better to pragmatic and err on the side of caution
> rather than to be strictly "correct" as per the language
> specification. This is one of them. Please fix this obvious
> compiler bug.
First understand what Steve is explaining. Then criticise the design, if
you feel it deserves it.
I simply cannot understand the design. I can't figure out why this would
give any extra opportunities for eliminating any significant amount of
static run-time information that must be generated.
Can anyone explain this to me?
[snip]
> > Since there is little you can reasonably expect about creation
> > and re-use of type_info objects, you should write your program
> > to keep the invocations of typeid to a reasonable minimum.
This is possible when the type of a non-polymorphic type is needed, but
for any polymorphic type, this is simply not possible. For example, a
non-intrusive persistent system that has a map from type_info to write
function (as Stroustrup suggests in one of his books).
> > I also have to wonder whether so many uses of typeid represent
> > a good solution to your programming problem.
>
> The above statement is uncalled for - it is very insulting.
> The typeid feature is a valid and very useful part of the
> C++ specification and should be implemented with a
> behavior that most C++ programmers would expect.
Perhaps he was referring to calling it in a tight, infinite loop? I think
it was some subtle humor :-)
Christopher Eltschka
>
> Michael Ball wrote:
>
> > Jay wrote:
> >
> > > loops. This is just the minimal program that demonstrates the
> > > the problem distilled from a much larger program.
> >
> one
> > of the same static time, the bug causes it to allocate another.
>
> By "bug" Mike means "conformant but leaky implementation result".
>
> I'm glad I ever heard of this before putting a 'typeid' into
> production code. It would obviously have gone in at the bottom of
> some loop.
>
> > The first allocation isn't a leak, it's the normal semantics of
> the
> > operator.
> >
> > The way you get around the leak is simple
> >
> > static const type_id& int_id = typeid(int);
> >
> > No it's not a fix, but it has the correct semantics and it uses a
> > minimum
> > of memory.
>
> I forsee a generic solution:
>
> template< class TypeMe >
> type_info &
> Wizard_Of_Id (TypeMe &)
> {
> static type_info *pId;
> if (!pId) pId = &typeid (TypeMe);
> return pId;
> };
>
> That wraps 'typeid()' with the behavior we wished an implementation
> could have covered for us.
I hope not:
struct Base { virtual ~Base() {} };
struct Derived: Base {};
Base* p1 = new Base;
Base* p2 = new Derived;
assert (Wizzard_Of_Id(*p1)!=Wizzard_Of_Id(*p2));
This would work with type_id, but will fail with Wizzard_Of_Id,
since Wizzard_Of_Id would be called with TypeMe == Base twice,
and therefore it will return a Base type_id even for *p2.
That is, your Wizzard_Of_Id is basically a typeid
for the _static_ type.
BTW, *if* that's what you want (instead of the typeinfo
behaviour), the following is an improved (and fixed) version:
template<class TypeMe>
type_info& static_typeid(TypeMe const volatile&)
{
static type_info& id = type_id(TypeMe);
return id;
}
>
> (But I'm right about there's one static instance of 'pId' for each
> template instance, not one for all of them, right?)
Yes.
>
> New question: Should we use this everywhere, even in code we never
> expect to port? or just on bad implementations?
No. If you want to use typeinfo for what it was invented for
(RTTI), you shouldn't use the template, since it effectively
disables RTTI (it doesn't even pass the object to typeid
- however if it did, that would make things even worse, since
the result for _all_ calls with the same static type would depend
on the dynamic type of the first object passed to it).
>
> Or could we empower the template to detect if 'typeid()' is leaky on
> a given implementation and adjust its contents accordingly?
Well, I'd guess that the following should give quite
a good estimate about if type_id leaks:
bool typeid_leaks()
{
static bool it_does = (&typeid(bool) != &typeid(bool));
return it_does;
}
(Of course, the optimizer might cause false negatives).
James...@dresdner-bank.com
> > The Sun design was based on the assumption that typeid queries are
> > relatively rare. Apparently that is not the case for your program.
> I seriously question this assumption. It is not an
> assumption that most C++ programmers would share.
I don't necessarily disagree with the assumption, but I don't find it
relevant. "Relatively rare" is relative, and leaking memory, even for
relatively rare events, is *not* acceptable. Some of my applications
run for years, and leaking an odd KByte every couple of seconds, or even
every minute, is a "rare" event I can't afford.
--
James Kanze mailto: James...@dresdner-bank.com
Conseils en informatique orientée objet/
Beratung in objekt orientierter Datenverarbeitung
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
James...@dresdner-bank.com
> > Jay wrote:
> > > >From what I have seen, typeid leaks everywhere and not just in
> > > loops. This is just the minimal program that demonstrates the
> > > the problem distilled from a much larger program.
> > It allocates space for the typeid element. If you ask for another
> > one of the same static time, the bug causes it to allocate another.
> By "bug" Mike means "conformant but leaky implementation result".
When a vendor (or an implementor) uses the word "bug" on his own
product, I interpret it to mean "something we did wrong". Presumably,
if something is recognized as a bug, there are plans to fix it.
Whether the "bug" renders the compiler non-conformant or not is really
irrelevant, at least for a serious vendor. The fact that a bug affects
conformance may cause it to receive higher priority. The fact that a
bug renders a certain feature useless should certainly increase its
priority as well, as should the fact that the bug represents a serious
blocking point for a customer, and that the work-around is relativly
complicated.
Normally, the fact that Mike Ball called it a bug would be enough for
me, but in this case, we seem to be getting mixed signals from Sun.
Steve Clamage
>cla...@eng.sun.com (Steve Clamage) wrote:
>> The Sun design was based on the assumption that typeid queries are
>> relatively rare. Apparently that is not the case for your program.
>I seriously question this assumption. It is not an
>assumption that most C++ programmers would share.
Have you polled some reasonable number of C++ programmers? Do they
typically use large numbers of typeid invocations in programs?
Our assumption was based on our experience. We didn't know of
anyone using typeid, and this was the first complaint we've had.
>> I also have to wonder whether so many uses of typeid represent
>> a good solution to your programming problem.
>The above statement is uncalled for - it is very insulting.
I apologize if you took it as an insult. It wasn't meant that way.
>The typeid feature is a valid and very useful part of the
>C++ specification
Well, that's subject to debate. It seems to me that any significant
use of typeid represents an attempt to write Smalltalk programs in
C++. C++ is a lousy Smalltalk. Different programming approaches
would produce better results in C++.
> and should be implemented with a
>behavior that most C++ programmers would expect.
We've decided to treat the memory leak as a bug, and we'll fix
it in a future release.
--
Steve Clamage, stephen...@sun.com
David Schwartz
> > >loops. This is just the minimal program that demonstrates the
> > >the problem distilled from a much larger program.
> >
>
> > Let's be careful about using the term "memory leak".
> >
> > The C++ standard requires that the typeid operator return a type_info
> > object (or an object of a type derived from type_info) whose lifetime
> > extends to the end of the program. In addition, the standard says it
> > is unspecified whether the object is ever destroyed.
>
> I think we all can assume that most C++ users and compiler
> authors _expect_ that repeated typeid usage will not result
> in memory leaks.
They might expect this, but then they should go read the standard. They
should then adjust their expectations to conform to the standard. The
whole point of the standard it to tell you what to expect.
> Sun's 5.0 compiler leaks memory in this
> regard plain and simple.
The compiler does not leak memory, your program leaks memory. The bug
in your program is that you create an unlimited number of objects that
the standard specifies will live until the end of the program's
execution.
DS
Biju Thomas
>
> alfred...@my-deja.com writes:
>
> >cla...@eng.sun.com (Steve Clamage) wrote:
>
> >> The Sun design was based on the assumption that typeid queries are
> >> relatively rare. Apparently that is not the case for your program.
>
> >I seriously question this assumption. It is not an
> >assumption that most C++ programmers would share.
>
> Have you polled some reasonable number of C++ programmers? Do they
> typically use large numbers of typeid invocations in programs?
> Our assumption was based on our experience. We didn't know of
> anyone using typeid, and this was the first complaint we've had.
>
I didn't do any polls, but, I have seen use of 'typeid' or simulated
'typeid' in programs. Of course, it is not as widespread as the use of
features like virtual functions or templates.
We can probably blame the use of such dynamic features on not-so-perfect
design. But, programmers are not perfect. And, there are situations
where use of typeid is unavoidable.
I find it quite strange that the chair of C++ committee saying that they
didn't know of anyone using typeid. May be you are saying that this was
the first complaint regarding this problem in the Sun compiler. That
might be correct because other users might never have noticed that there
is a memory leak.
--
Biju Thomas
Paul D. DeRocco
>
> An implementation might simply create a new type_info object
> for each use of typeid. The compiler in question (Sun C++ 5.0)
> in fact works that way.
> The Sun design was based on the assumption that typeid queries are
> relatively rare. Apparently that is not the case for your program.
I still don't understand how this works. When a program compiled by this
Sun compiler calls typeid, and it generates a type_info, where does it get
the information to put into the type_info? _Something_ must exist
statically, and I can't see how storing it in some other form and copying
it into a newly created type_info saves space.
--
Ciao, Paul D. DeRocco
Paul mailto:pder...@ix.netcom.com
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
blargg
<pder...@ix.netcom.com> wrote:
> James...@dresdner-bank.com wrote:
> >
> > In article <7rmg2h$brd$1...@engnews1.eng.sun.com>,
> > cla...@eng.sun.com (Steve Clamage) wrote:
> >
> > > A third option might be for the implementation to emit a static
> > > type_info object for each type in the program. Uses of typeid
> > > would have no (extra) overhead, but would be potentially a large
> > > amount of static type_info data in every program. (Consider the
> > > the C++ standard library, apart from your own types.)
> >
> > A fourth option would simply be to have a pointer to the type_info in
> > the object's vtable. (Increasing the size of the vtable by four bytes
> > surely isn't an issue.) The actual type_info's could then be allocated
> > lazily. (For non-polymorphic objects, there is no problem with
> > generating a static type_info at the call site, since the actual value
> > is known at compile time. Presumably, the extra copies shouldn't be a
> > problem with regards to total program size; how many typeid's on
> > non-polymorphic objects will a program contain?)
>
> In practice, a type_info needs to contain some sort of name string
> (actually a const char[]), and if the strings are in a one-to-one
> correspondence with actual types, that's all that's needed to compare
> type_infos.
Yes.
> And in practice, type_info objects also contain (or refer to
> other objects that contain) info on the inheritance relationships among
> types, for the benefit of dynamic_cast.
Why would a type_info object contain this information?
On a side note, I expect a decent exception implementation to use this
other information that is used for dynamic_cast<>, for catch handler
matching.
> I don't see how creating such an
> object dynamically would save anything, because you can't derive this info
> from anything that's signficantly smaller than a static type_info itself,
> so that info from which the type_info is constructed would have to exist
> statically anyway.
Yes, that is my point exactly. In fact, I can't even *imagine* how Sun's
implementation works! How does it create the stuff dynamically without it
taking static space?!? That is like the question recently that asked why
the standard requires string literals to be stored statically "wouldn't
that take up program space?" :-)
Bruce Hoult
<dav...@webmaster.com> wrote:
> > cla...@eng.sun.com (Steve Clamage) wrote:
> > > Let's be careful about using the term "memory leak".
> > >
> > > The C++ standard requires that the typeid operator return a type_info
> > > object (or an object of a type derived from type_info) whose lifetime
> > > extends to the end of the program. In addition, the standard says it
> > > is unspecified whether the object is ever destroyed.
> >
> > I think we all can assume that most C++ users and compiler
> > authors _expect_ that repeated typeid usage will not result
> > in memory leaks.
>
> They might expect this, but then they should go read the standard.
> They should then adjust their expectations to conform to the standard. The
> whole point of the standard it to tell you what to expect.
Oh boy.
The *intent* of the standard would appear to be to leave it unspecified
whether the object returned by typeid is statically created before
execution of the program, or dynamically on first use of "typeid" for a
particular class and then cached from then on.
While creating a new heap object every time might well meet the letter of
the standard that is most likely an oversight rather than something that
was intended.
-- Bruce
Jay
>
> alfred...@my-deja.com wrote:
> >
> > > Jay <j...@jay.org> writes:
> > >
> > > >From what I have seen, typeid leaks everywhere and not just in
> > > >loops. This is just the minimal program that demonstrates the
> > > >the problem distilled from a much larger program.
> > >
> >
> > > Let's be careful about using the term "memory leak".
> > >
> > > The C++ standard requires that the typeid operator return a type_info
> > > object (or an object of a type derived from type_info) whose lifetime
> > > extends to the end of the program. In addition, the standard says it
> > > is unspecified whether the object is ever destroyed.
> >
> > I think we all can assume that most C++ users and compiler
> > authors _expect_ that repeated typeid usage will not result
> > in memory leaks.
>
> They might expect this, but then they should go read the standard. They
> should then adjust their expectations to conform to the standard. The
> whole point of the standard it to tell you what to expect.
Nope.
>
> > Sun's 5.0 compiler leaks memory in this
> > regard plain and simple.
>
> The compiler does not leak memory, your program leaks memory. The bug
> in your program is that you create an unlimited number of objects that
> the standard specifies will live until the end of the program's
> execution.
Computer language standards (or any
standard processes) are corrupt political processes
and are not holy scriptures to be worshipped.
FORTRAN 77 was supposed to be a short term standard
lasting a couple years but due to political wars in
the standard process the new FORTRAN standard
took over 13 years which in this field is
eons.
With respect to language implementation issues,
language standards have always been hopelessly
vague and weak. This is to give the language
implements the widest possible latitude
for using new and innovative techniques
in their language tools.
For example, in Ada 83 the equivalent of C's
"free()" is not required in the standard to
do anything and there is no requirement for
garbage collection so there is basically no
enforced "standard" way to free dynamic memory.
Obviously, slavish following of whats not
enforced in the Ada "standard" would make
Ada a pretty much a worthless and uncompetitive
language. How did real programmers use Ada 83?
They relied on their compiler vendor to provide a
quality usable implementations and not become
"language lawyers" providing the
exact minimum as required by the "standard".
It would be easy with enough money to enforce
more stringent implementation "standards".
It would just require a body with ability
to make "standards" decisions on the fly
and the power to enforce them. Unfortunately,
computer industry politics would never let this
happen.
My position with respect to standards is
if a feature is widely available across
almost all compilers/systems, then it is
"defacto standard". Official standards
are great, but they are not everything.
Jay
alfred...@my-deja.com
David Schwartz <dav...@webmaster.com> wrote:
>
> alfred...@my-deja.com wrote:
> >
> > > Jay <j...@jay.org> writes:
> > >
> > > >From what I have seen, typeid leaks everywhere and not just in
> > > >loops. This is just the minimal program that demonstrates the
> > > >the problem distilled from a much larger program.
> > >
> >
> > cla...@eng.sun.com (Steve Clamage) wrote:
> > > Let's be careful about using the term "memory leak".
> > >
> > > The C++ standard requires that the typeid operator return a
type_info
> > > object (or an object of a type derived from type_info) whose
lifetime
> > > extends to the end of the program. In addition, the standard says
it
> > > is unspecified whether the object is ever destroyed.
> >
> > I think we all can assume that most C++ users and compiler
> > authors _expect_ that repeated typeid usage will not result
> > in memory leaks.
>
> They might expect this, but then they should go read the
standard. They
> should then adjust their expectations to conform to the standard. The
> whole point of the standard it to tell you what to expect.
Around eight other posters in this thread agree
that this typeid memory leak is undesirable
whether it is the specification or not. As of
this posting, 2 disagree. It's not very
scientific, but it is interesting to note.
This memory leak implies that this C++ language
feature could not be used in C++ server processes
that run indefinately (often years at a time)
because small repeated leaks over time becomes a
large leak.
I doubt that this typeid memory leak of the
Sun C++ 5.0 compiler is in the spirit of C++.
What good is a non-deterministic langauge feature
to anyone? It ultimely leads to non-productive
arguments like this one. The standard must adapt
to the practical needs of its users.
>
> > Sun's 5.0 compiler leaks memory in this
> > regard plain and simple.
>
> The compiler does not leak memory, your program leaks memory.
The bug
> in your program is that you create an unlimited number of objects that
> the standard specifies will live until the end of the program's
> execution.
>
> DS
Having an itch that you can't scratch is a
terrible thing indeed - just as bad is repeatedly
leaked memory for a typeid that you have no
explicit control over.
You may as well put in the C++ standard that this
feature should be avoided at all costs since it
is likely to leak memory in "standard" implementations.
Because there are many techniques to avoid heap
allocated typeids in a C++ compiler implementation
altogether, I find your point to be purely
argumentative.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Francis Glassborow
writes
>You may as well put in the C++ standard that this
>feature should be avoided at all costs since it
>is likely to leak memory in "standard" implementations.
No, it really isn't necessary. This is a QoI issue. I am sure that now
it has been exposed and explored all sane (i.e. want customers)
implementors will avoid this source of memory leakage.
Francis Glassborow Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
Valentin Bonnard
> Computer language standards (or any
> standard processes) are corrupt political processes
> and are not holy scriptures to be worshipped.
For having written that, you shall copy
::std::numeric_limits<int>::max () times [1] the
following sentences:
Standards are good. I like ISO 14882. ISO works
for the Progress of Humanity.
Note 1: without redefining int with the preprocessor
PS: I also recommend a prayer to the appropriate god.
--
Valentin Bonnard
Paul D. DeRocco
>
> In article <37E1B373...@ix.netcom.com>, "Paul D. DeRocco"
> <pder...@ix.netcom.com> wrote:
>
> > And in practice, type_info objects also contain (or refer to
> > other objects that contain) info on the inheritance relationships among
> > types, for the benefit of dynamic_cast.
>
> Why would a type_info object contain this information?
There is a one-to-one correspondence between a type_info and whatever data
structure dynamic_cast (and exception handler matching) uses to represent
inheritance relationships. I guess it isn't necessary for a type_info to
contain or refer to this internal stuff, but my point is only that there is
a bunch of static info describing polymorphic types, both for the benefit
of the typeid operator, as well as for dynamic_cast and EH matching, and
it's all related.
--
Ciao, Paul D. DeRocco
Paul mailto:pder...@ix.netcom.com
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Paul D. DeRocco
> > authors _expect_ that repeated typeid usage will not result
> > in memory leaks.
>
> They might expect this, but then they should go read the standard. They
> should then adjust their expectations to conform to the standard. The
> whole point of the standard it to tell you what to expect.
Does the standard actually say that 1+1 won't leak memory?