| View Issue Details [ Jump to Notes ] | [ Print ] | ||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||
| 0007192 | VTK | (No Category) | public | 2008-06-14 17:43 | 2016-08-12 09:54 | ||||
| Reporter | Tom Fogal | ||||||||
| Assigned To | Kitware Robot | ||||||||
| Priority | normal | Severity | minor | Reproducibility | always | ||||
| Status | closed | Resolution | moved | ||||||
| Platform | OS | OS Version | |||||||
| Product Version | |||||||||
| Target Version | Fixed in Version | ||||||||
| Summary | 0007192: Read-only access to objects is not const correct | ||||||||
| Description | Accessing data within a VTK object is a mutable operation, even when the data access itself does not actually mutate the object's state. This imposes difficulties when using VTK in a const-correct environment. | ||||||||
| Additional Information | Attached is a small patch aimed at allowing easier use of VTK in a const correct program. The current definition of vtkGetObjectMacro essentially expands into: virtual type *GetWhateverYouSay() { ... } This causes the macro to expand into: virtual type *GetWhateverYouSay() { ... } virtual const type *GetWhateverYouSay() const { ... } As it provides both versions, it provides a backwards-compatible API while allowing new code to utilize the const correct version. The change to vtkObject was necessary to get the build to work; I made the `GetDebug' method const. Would you accept more patches of this nature? | ||||||||
| Tags | No tags attached. | ||||||||
| Project | |||||||||
| Type | |||||||||
| Attached Files |  const.patch [^] (1,627 bytes) 2008-06-14 17:43 [Show Content]
| ||||||||
| Relationships | |
| Relationships |
| Notes | |
|
(0012344) Tom Fogal (reporter) 2008-06-14 19:16 |
I was thinking that it might be better for constants to utilize references instead of pointers. This would differentiate their use -- since stack-based VTK objects are currently disallowed, it would call attention to the fact that whatever VTK object you have obtained via such a mechanism is constant. More concretely, this would mean that as I read code such as: v = XYZ->GetFoo().GetBar().GetBaz(); I know that 1) `XYZ' is a pointer; it is likely to be a mutable pointer. 2) I don't know the return type of GetFoo, but I know that the `Foo' is RO. 3) Likewise with `Bar', and `Baz' (1) comes from the fact that if the VTK library provides const& methods but not many const* methods, then the programmer would have to `break convention' to obtain a constant pointer (e.g. call a mutable method that returns a pointer, but store it in a pointer to const). (2) and (3) are useful because they do not require me to go load up the vtk.org doxygen documentation. Thoughts? |
|
(0036988) Kitware Robot (administrator) 2016-08-12 09:54 |
Resolving issue as `moved`. This issue tracker is no longer used. Further discussion of this issue may take place in the current VTK Issues page linked in the banner at the top of this page. |
| Notes |
| Issue History | |||
| Date Modified | Username | Field | Change |
| 2008-06-14 17:43 | Tom Fogal | New Issue | |
| 2008-06-14 17:43 | Tom Fogal | File Added: const.patch | |
| 2008-06-14 19:16 | Tom Fogal | Note Added: 0012344 | |
| 2011-06-16 13:11 | Zack Galbreath | Category | => (No Category) |
| 2016-08-12 09:54 | Kitware Robot | Note Added: 0036988 | |
| 2016-08-12 09:54 | Kitware Robot | Status | expired => closed |
| 2016-08-12 09:54 | Kitware Robot | Resolution | open => moved |
| 2016-08-12 09:54 | Kitware Robot | Assigned To | => Kitware Robot |
| Issue History |
| Copyright © 2000 - 2018 MantisBT Team |