From: Amitha P. <pe...@cs...> - 2003-12-10 16:18:44
|
Hi all I propose that we allow dynamic_cast in vxl. With the current compilers, it should not add any cost (time or space) to those classes without virutal functions. To classes with virtual functions, it will probably add a few bytes per class (not per instance). dynamic_cast allows many things to be implemented cleanly and safely. (At least, more so that now.) Note also that dynamic_cast is Standard C++. Comments? Amitha. |
From: Peter V. <Pet...@es...> - 2003-12-10 16:55:47
|
> Comments? What about compilers not supporting RTTI, or supporting it with too much overhead ? Shall we just drop support for those? Or shall we "emulate" RTTI for those? -- Peter. |
From: Ian S. <ian...@st...> - 2003-12-10 16:27:54
|
I think the rule we decided in Zurich was that level 2 and greater libraries could use dynamic_cast and RTTI. Level 1 should avoid it. I know RTTI is useful, but I've never seen the need for it in vnl, vil, etc. Do you have an example where it would be useful? Ian. > -----Original Message----- > From: Amitha Perera [mailto:pe...@cs...] > Sent: Wednesday, December 10, 2003 4:19 PM > To: vxl...@li... > Subject: [Vxl-maintainers] Allow dynamic_cast in vxl? > > > Hi all > > I propose that we allow dynamic_cast in vxl. With the current > compilers, it should not add any cost (time or space) to those classes > without virutal functions. To classes with virtual functions, it will > probably add a few bytes per class (not per instance). dynamic_cast > allows many things to be implemented cleanly and safely. (At least, > more so that now.) > > Note also that dynamic_cast is Standard C++. > > Comments? > > Amitha. > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > |
From: Amitha P. <pe...@cs...> - 2003-12-10 17:39:10
|
Ian Scott wrote: > I think the rule we decided in Zurich was that level 2 and greater libraries > could use dynamic_cast and RTTI. Level 1 should avoid it. Did we? A quick grep in the notes didn't find it. However, this is a reasonable guideline. > I know RTTI is useful, but I've never seen the need for it in vnl, vil, etc. > Do you have an example where it would be useful? It would be useful in vgui, and, glancing at the implementation, in vcsl. It would also be useful in the gel/vtol and gel/vsol libraries. (At least, as currently implemented.) However, these are all level 2 libraries, so your comment above applies. Granted, overuse of dynamic_cast sometimes points to bad design, but there are useful designs that can use dynamic_cast. Peter Vanroose wrote: > What about compilers not supporting RTTI, or supporting it with too much > overhead ? Shall we just drop support for those? Or shall we "emulate" > RTTI for those? What compilers are those? I think all the compilers on the dashboard support RTTI. (Unless it's being explicitly disabled.) I think if a "recent" compiler doesn't support RTTI, then it's reasonable to consider dropping it. The issue of overhead is important. As I wrote, I think current compilers (i.e. those on the dashboard) support it with relatively little overhead. Do you know of a particular compiler that has expensive RTTI support? Can it be measured? The first step before allowing RTTI, of course, would be to put in a test suite to (a) ensure that RTTI works, and (b) it doesn't have any overheads that we are unwilling to accept. This would mean, for example, we would test that with class X { int[9]; }; sizeof(X) == 9 * sizeof(int) --- i.e. no space overhead for classes without virtual functions. As for emulation, I don't think any attempt is worth the cost. If we are going to emulate it for some compilers, we might as well use the emulation instead of RTTI everywhere. (See, for example, the various cast_to_X member functions in vcsl, vtol, and vsol.) Amitha. |
From: Ian S. <ian...@st...> - 2003-12-10 17:48:57
|
Just to confirm. The Zurich meeting notes http://cvs.sourceforge.net/viewcvs.py/vxl/vxl/core/doc/meetings/Zurich-meeti ng-notes.txt?annotate=1.2#216 say no RTTI in level 1. The VXL book says RTTI (and hence dynamic_cast) is not allowed in the "core" libraries. I think it means level 1. http://paine.wiau.man.ac.uk/pub/doc_vxl/books/core/book.html#SEC29 I think this use of "core" is due to the evolution of the word "core" over the years. It used to mean (and still does in the book) level 1 libraries. http://paine.wiau.man.ac.uk/pub/doc_vxl/books/core/book.html#SEC2 Since core now means "in vxl/core", we should probably fix the VXL book. Ian. > -----Original Message----- > From: Amitha Perera [mailto:pe...@cs...] > Sent: Wednesday, December 10, 2003 5:39 PM > To: Ian Scott; Peter Vanroose > Cc: vxl...@li... > Subject: Re: [Vxl-maintainers] Allow dynamic_cast in vxl? > > > Ian Scott wrote: > > I think the rule we decided in Zurich was that level 2 and > greater libraries > > could use dynamic_cast and RTTI. Level 1 should avoid it. > > Did we? A quick grep in the notes didn't find it. However, this is a > reasonable guideline. > > > I know RTTI is useful, but I've never seen the need for it > in vnl, vil, etc. > > Do you have an example where it would be useful? > > It would be useful in vgui, and, glancing at the implementation, in > vcsl. It would also be useful in the gel/vtol and gel/vsol > libraries. (At least, as currently implemented.) However, these are > all level 2 libraries, so your comment above applies. Granted, overuse > of dynamic_cast sometimes points to bad design, but there are useful > designs that can use dynamic_cast. > > > Peter Vanroose wrote: > > What about compilers not supporting RTTI, or supporting it > with too much > > overhead ? Shall we just drop support for those? Or shall > we "emulate" > > RTTI for those? > > What compilers are those? I think all the compilers on the dashboard > support RTTI. (Unless it's being explicitly disabled.) I think if a > "recent" compiler doesn't support RTTI, then it's reasonable to > consider dropping it. > > The issue of overhead is important. As I wrote, I think current > compilers (i.e. those on the dashboard) support it with relatively > little overhead. Do you know of a particular compiler that has > expensive RTTI support? Can it be measured? > > The first step before allowing RTTI, of course, would be to put in a > test suite to (a) ensure that RTTI works, and (b) it doesn't have any > overheads that we are unwilling to accept. This would mean, for > example, we would test that with > class X { int[9]; }; > sizeof(X) == 9 * sizeof(int) --- i.e. no space overhead for classes > without virtual functions. > > As for emulation, I don't think any attempt is worth the cost. If we > are going to emulate it for some compilers, we might as well use the > emulation instead of RTTI everywhere. (See, for example, the various > cast_to_X member functions in vcsl, vtol, and vsol.) > > Amitha. > |
From: Amitha P. <pe...@cs...> - 2003-12-10 18:08:18
|
Ian Scott wrote: > The Zurich meeting notes > http://cvs.sourceforge.net/viewcvs.py/vxl/vxl/core/doc/meetings/Zurich-meeti > ng-notes.txt?annotate=1.2#216 > say no RTTI in level 1. Yes. Silly me just grepped for "dynamic_cast", not RTTI. > Since core now means "in vxl/core", we should probably fix the VXL book. I agree. Not volunteering now, though. :-( So, let me modify my proposal to allow RTTI in level 2 libraries, and not support any compilers that do not allow RTTI. That it, I propose to that the decision on workarounds referred to in the meeting notes becomes "there is no workaround". Amitha. |
From: Peter V. <Pet...@es...> - 2003-12-10 18:46:07
|
> What compilers are those? I think all the compilers on the dashboard > support RTTI. I'm not sure (should check it) but I believe SGI's native compiler has no RTTI. vcsl, vsol and vtol indeed has their own "safe downcasting" mechanism. (So they need no RTTI ;-) -- Peter. |
From: Peter V. <Pet...@es...> - 2003-12-10 18:58:30
|
> What compilers are those? I think all the compilers on the dashboard > support RTTI. SGI's CC indeed supports dynamic_cast<T>. But I hqve never used it, so I don't know how reliable its implementation of RTTI is. -- Peter. |